Jump to content

Wikipedia:Edit filter noticeboard/Archive 13

From Wikipedia, the free encyclopedia
Archive 10Archive 11Archive 12Archive 13Archive 14

Error

Elmira High School, Elmira, OR. Notable Alumni: Paddi Moyer, artisan, has several websites. She is legitimate. There’s no possible way to add her name and it is impossible to contact any of you. 50.45.245.19 (talk) 09:45, 8 March 2024 (UTC)

In order for her to be accepted as notable for the Notable alumni section, she needs to have a Wikipedia article. Nobody (talk) 09:49, 8 March 2024 (UTC)

No mention of the new guitar player Caleb Tucker 2600:1700:A170:3AF0:B0AE:7D02:4851:7C87 (talk) 23:38, 9 March 2024 (UTC)

Please read WP:BIO and WP:MUSIC notability guidelines. Having "several websites" does not address notability criteria. OhNoitsJamie Talk 23:51, 9 March 2024 (UTC)

/Requests' archive

As can be seen from the last 400 edits at Wikipedia:Edit filter/Requested, the bot has, since 9 September 2023‎, been archiving everything into Wikipedia:Edit filter/Requested/Archive 4 - this appears to be because of <this change> by @EEng.
Should something be done about that? There are 21 archives.
Note that I'm posting this here because the talk page for /Requests redirects here.2804:F14:809E:DF01:1968:B0BD:7883:4C14 (talk) 22:41, 18 March 2024 (UTC)

All I did was increase the max size of the archive pages. Why that caused it to jump to Archive 4 is beyond me. EEng 04:34, 19 March 2024 (UTC)
Cluebot has its |numberstart= set to 4 (it doesn't use a counter system like {{User:MiszaBot/config}}, rather I think it figures out where it should archive every time), and since the archive size was increased enough to allow it to archive to the 4th archive, it did. Probably worth moving everything that ended up in 4 to 21 or 22 and upping numberstart. Aidan9382 (talk) 06:53, 19 March 2024 (UTC)
 Done EggRoll97 (talk) 04:35, 20 March 2024 (UTC)

Over the condition limit

Unless I'm missing something, it seems we're currently over the 1k condition limit (graph)? Though it doesn't seem any edits have been tagged as breaching the limot here ProcrastinatingReader (talk) 10:12, 2 April 2024 (UTC)

Ah, indeed I am missing something (phab) -- the limit is now 2k :) ProcrastinatingReader (talk) 10:17, 2 April 2024 (UTC)
Yep, "data expands to fill available space". No harm in doing a bit of pruning if you see anything stale. Suffusion of Yellow (talk) 23:20, 2 April 2024 (UTC)

Edit filter helper nomination for 1AmNobody24

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.



1AmNobody24 (t · th · c · del · cross-wiki · SUL · edit counter · pages created (xtools · sigma) · non-automated edits · BLP edits · undos · manual reverts · rollbacks · logs (blocks · rights · moves) · rfar · spi · cci) (assign permissions)(acc · ap · ev · fm · mms · npr · pm · pc · rb · te)

The earliest closure has started. (refresh)

For those of you that do not know him, 1AmNobody24 has been quite an active patroller of EFFPR spanning a little more than 700 edits in the past few months, and he would be a great asset to the edit filter team in order to review false positives that involve private filters, and to assist with improving and creating private filters. Some of his suggestions include Wikipedia:Edit filter noticeboard/Archive 12#Filter 1112, and Special:Permalink/1211462999#Improving Filter 1045.

Outside of edit filters, he does a great job of reverting obvious vandalism and spam, has decent UAA, AFC, CSD and SPI logs, fixes references (including but not limited to bare URLs, CS1 errors), adds wikilinks, and has signed the confidentiality agreement for nonpublic information per this diff on Meta.

Thank you for your consideration in whether or not you want to support him. Codename Noreste 🤔 talk 17:00, 25 March 2024 (UTC)

Candidate, please indicate acceptance of this nomination here: I accept this nomination. Nobody (talk) 17:16, 25 March 2024 (UTC)


  • Support as the nominator. Codename Noreste 🤔 talk 17:00, 25 March 2024 (UTC)
  • Support: Trusted user who has a clear need. – PharyngealImplosive7 (talk) 18:05, 25 March 2024 (UTC)
  • Oppose Weak support: I'm slightly concerned by this, as non-EFH/EFM/sysop should not generally be actioning reports involving private filters, regardless of how obvious the result may be. The key problem is that the person responding doesn't have access to all relevant logs, nor access to the necessary filters to check the report in full. A similar idea applies to this one. While I think they could be responsible with EFH, I'm not a fan of granting it to someone who recently (within 2 months and even 1 month) has shown to be actioning reports as described. EggRoll97 (talk) 21:50, 25 March 2024 (UTC)
    @EggRoll97 I agree that most private filter hits should not be actioned by non-EFH/EFM, but those two reports I can easily explain why I responded. The first one one triggered the Rapid disruption private filter and filters 61 and 636 in the same attempt. When looking at the public filters hits, one can see the obvious reason why that attempt is disruptive. The second report is also for an attempt thar hit both a private and a public filter. By looking at the public hit, one can easily see what part got hit for looking like a email. These were both obvious cases of disruptive attempts and even if I don't see the private filters it's obvious that the hits weren't false positives. Nobody (talk) 05:27, 26 March 2024 (UTC)
    I don't necessarily agree with that line of thought, but I find myself leaning neutrally. EggRoll97 (talk) 20:44, 26 March 2024 (UTC)
  • Support: They have demonstrated the need, and I trust them with EFH.– DreamRimmer (talk) 13:06, 28 March 2024 (UTC)
  • Support has continuous involvement with filters with technical contributions. 0xDeadbeef→∞ (talk to me) 13:55, 28 March 2024 (UTC)
  • The earliest closure has started. Would someone mind granting the perm as it seems that consensus agrees to grant? – PharyngealImplosive7 (talk) 17:39, 28 March 2024 (UTC)
  •  Comment: WP:EFH only talks about requesting the right for yourself, nothing about nominating others. This feels like it misses the candidate's own statement on why they want the right (even if it's obvious). That said, this reads like it was made using a template, so is this just undocumented? (Also the confidentiality agreement diff link is broken, as I've mentioned, please fix that)2804:F1...01:18F4 (talk) 21:02, 28 March 2024 (UTC)
There is a tradition of nominating others, even if it isn't written down on the guidelines. About the statement on why they want the right, I don't really know if it is needed in this case but it could be. – PharyngealImplosive7 (talk) 21:26, 28 March 2024 (UTC)
I'll also concur that it doesn't matter too much if they nominate themselves, so long as they're available to answer questions from others. Ultimately the test that is applied is whether the candidate can be trusted, and while self-nominations are fully acceptable, some also like the reassurance that comes from a nominator. Also, confidentiality noticeboard diff updated. (I hope you don't mind my fixing that diff, @Codename Noreste:.) EggRoll97 (talk) 22:34, 28 March 2024 (UTC)
About fixing that diff, I've did that so marked as  Done; we're still awaiting an uninvolved admin to grant the role to the nominee. Codename Noreste 🤔 talk 23:27, 28 March 2024 (UTC)
In addition to that, I have some of my own comments to say of what I've learned despite my two failed nominations:
  • Regardless if they're obvious or not, I also agree that reports that only involve private filters should be left to the ones that can view such log entries. I believe I have learned that the hard way.
  • Despite so many responses, account age probably matters (almost two years or more is recommended).
  • I'm not going to use scare quotes anymore as somebody mentioned, including if it's in the edit or summary.
Codename Noreste 🤔 talk 23:42, 28 March 2024 (UTC)
Just a tip. the {{tq}} template is usually used which is usually considered more friendly than quotes (Example vs "Example") 0xDeadbeef→∞ (talk to me) 02:08, 29 March 2024 (UTC)
Understood, and I will give myself a year at most to address these issues. In addition, I have written and proposed a filter by emailing its conditions to an EFM (1292 to be exact). Codename Noreste 🤔 talk 02:25, 29 March 2024 (UTC)


The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Edit to filter 54

Their are a few promotional accounts whose names have 'corporations' in them instead of simply 'corporation' which is currently filtered out. I suggest that we should change the syntax to also log these accounts. We could change the related part of the regex to CORP(?:S?.?$|ORATE|ORATIONS?\b). – PharyngealImplosive7 (talk) 00:29, 31 March 2024 (UTC)

Courtesy ping to Oshwah as the last editor to modify filter 54. Codename Noreste 🤔 talk 00:40, 31 March 2024 (UTC)
Hi PharyngealImplosive7! I'll implement your suggestion. Stand by... ~Oshwah~(talk) (contribs) 02:52, 2 April 2024 (UTC)
PharyngealImplosive7 -  Done. ~Oshwah~(talk) (contribs) 02:57, 2 April 2024 (UTC)
Thanks! – PharyngealImplosive7 (talk) 03:07, 2 April 2024 (UTC)

Filter 1162

I came across filter 1162, and I am wondering why there are no actions taken when the filter is triggered. Seems like this should be tagged at the very least. GrayStorm(Talk|Contributions) 22:54, 3 April 2024 (UTC)

For now, I don't think that tagging non-admins placing block templates are necessary. Logging only works fine. Codename Noreste 🤔 talk 03:14, 4 April 2024 (UTC)
Ok GrayStorm(Talk|Contributions) 20:00, 4 April 2024 (UTC)

Searching within filter code

Has anyone else had any problems with searching in filter code (as in, ctrl + f and no search box appearing)? I've tried clicking inside the code then pressing Ctrl+F, tried looking at different filters, tried restarting my computer, nothing. I don't think it's a script issue either, since I tried enabling safemode as well, and that didn't fix it, nor did trying to open the filter in an incognito window. Anyone know if maybe a recent update removed the ability or broke it? EggRoll97 (talk) 05:04, 4 April 2024 (UTC)

Generally speaking, ctrl+f is usually controlled by the browser, unless specifically overridden by the web page, for example in the case of visual editor. Are you just viewing a filter or trying to edit it? Can you link to a page giving you the problem? What skin and browser are you using? –Novem Linguae (talk) 05:23, 4 April 2024 (UTC)
Just viewing, haven't had the EFM bit toggled on (yet, still about 19 hours left on that one). I've tried Special:AbuseFilter/3, Special:AbuseFilter/12, and Special:AbuseFilter/11, among others, though it seems to affect every filter. I haven't had any problems previously with Ctrl+F searching in the filter while viewing before, and my normal Ctrl+F works fine (but it doesn't search the filter code, only the filter notes and anything else on the page). I'm on Chrome 123.0.6312.106, and it says it's the newest version. Skin is Vector legacy (not 2022). EggRoll97 (talk) 05:47, 4 April 2024 (UTC) Ignore my rampant stupidity, it appears the normal Ctrl+F actually now searches the filter code too (it didn't used to, as far as I could tell). EggRoll97 (talk) 05:52, 4 April 2024 (UTC)
The Ace editor does intercept CTRL-F, so long as you've focused on it first. At least, it's supposed to. Instead I get: The resource from “https://wiki.riteme.site/w/extensions/CodeEditor/modules/ace/ext-searchbox.js” was blocked due to MIME type (“text/plain”) mismatch (X-Content-Type-Options: nosniff). But oddly it does work on JavaScript pages. Suffusion of Yellow (talk) 19:25, 4 April 2024 (UTC)
Interesting. I did a search among pages in the WP/Module/Template/MediaWiki namespaces, and nothing exact came up for "ext-searchbox.js" other than this page. Searching Phabricator brings up T251545, not necessarily for the AbuseFilter, but looks like that was a problem a while ago as well, but it was closed as invalid. EggRoll97 (talk) 21:18, 4 April 2024 (UTC)

Edit filter manager for EggRoll97

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Hello all. I am presenting myself here to the community today to request that I be granted edit filter manager rights as a non-administrator. I've thought about this for a bit, and it's 0xDeadbeef's response to my request for a bit of advice and his encouragement of boldness here that has pushed me to bite the metaphorical "bullet", so to speak, and write this up. (As a side note, I've hovered over the publish changes button now for about an hour, uncertain if everything is perfect yet.)

Edit filter managers need demonstrated competency with the edit filter to be considered, as well as being trusted by the community to safely utilize the edit filter. As for trust, it's largely a factor that differs by person, though I of course will present that I have been an edit filter helper handling private filters for just over four months now without spilling the beans, and have signed the confidentiality agreement for non-public information (see m:Special:Diff/20180422). For technical competency, I have attached a few links below for both public and private filter changes I have requested. I've attempted to summarize the private filter changes as best I can without compromising private filter integrity.


Public filter changes:

Direct proposal for edits to a filter, implemented with modifications

Not a direct proposal for editing, but discussion about what could be done to reduce the false positive probability

Private filter changes:

A filter concern about problems with excessive matching

Some suggested improvements to an existing filter of simple changes

General changes to a filter to avoid false positives from it on innocent edits


Further, I have also passed by more than a few false positives reports that had small changes proposed to the filters that just needed an EFM to make them. This is something I would plan to work on a lot if granted the userright. The EFM right would also allow me to use filters filter 1 (public testing) and filter 2 (private testing) which can be more efficient than Special:AbuseFilter/test as it only tests the last 100 edits (though User:Suffusion of Yellow/FilterDebugger works wonders). I plan to extensively test any edit filter changes I implement, and with new edit filters as applicable, enable on log-only until fine-tuning has kept the false positive count to a low and reasonable degree. I am aware of the confidentiality expectations applicable to the private filters, and am aware of the extensive damage that edit filters can cause if recklessly implemented. I thank you for your consideration, and am fully open to and will respond to any questions and queries as applicable. EggRoll97 (talk) 00:11, 29 March 2024 (UTC)


@Codename Noreste: I'd likely take inspiration from the requests at Wikipedia:Edit_filter/Requested, though I believe the bulk of my contribution would come through fine-tuning existing filters based on false positives and filter history. We do, after all, already have a massive number of filters, so I'd be more likely to test changes to an existing filter and merge them in when properly vetted, then to create a new filter, if possible. For reference, at the time of writing, we have over 300 enabled filters. (314, to be exact.) To answer your question directly though, I'd probably start by enabling Wikipedia:Edit_filter/Requested#No_rcats? in log-only and monitoring. EggRoll97 (talk) 00:35, 29 March 2024 (UTC)
EggRoll97, I can also email you a new proposed (and private) filter early if there might be consensus to promote you to EFM. Codename Noreste 🤔 talk 00:38, 29 March 2024 (UTC)
@Codename Noreste: Since it's a private filter request, if you send it to the mailing list, I can take a look at it alongside the other EFHs and EFMs. EggRoll97 (talk) 00:40, 29 March 2024 (UTC)
… and emailed! I'm waiting for my request to pass moderator approval. Codename Noreste 🤔 talk 00:50, 29 March 2024 (UTC)
May sound somewhat off-topic, but it would be useful if you are a moderator of that edit filter mailing list who can accept or deny (and respond to) requests. Codename Noreste 🤔 talk 00:52, 29 March 2024 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Mark filter 1157 as public?

Per Wikipedia:Edit filter noticeboard/Archive 10#1157, I agree that I'm not sure if we have to keep 1157 (hist · log) private, since the filter only logs non-admins/clerks/CheckUsers tagging sockpuppets. Any objections if this filter was to be marked as public to maintain consistency with 1170 (hist · log)? Thanks. Codename Noreste 🤔 talk 23:38, 1 April 2024 (UTC)

Courtesy pings: @TheresNoTime and Blablubbs: -- zzuuzz (talk) 08:43, 2 April 2024 (UTC)
Sounds reasonable to me, but I'll defer to BlablubbsTheresNoTime (talk • they/them) 08:57, 2 April 2024 (UTC)
Thanks for the ping; I don't see any reason to keep it private. --Blablubbs (talk) 09:23, 2 April 2024 (UTC)
Me neither. Plus the history doesn't seem to contain anything private. [Insert delay for any further comments]. -- zzuuzz (talk) 09:52, 2 April 2024 (UTC)
Also support on making it public. EggRoll97 (talk) 17:37, 2 April 2024 (UTC)
Okay, if there are no objections before then I'll made the filter public on 5 April 2024 (based on UTC) so in just under 48 hours, giving a further delay in case there are others who haven't seen this thread yet (which I think is what zzuuzz was suggestion) --DannyS712 (talk) 00:53, 3 April 2024 (UTC)
CC other users who have edited the filter: @L235, @Tamzin, @Oshwah, @Galobtter --DannyS712 (talk) 00:54, 3 April 2024 (UTC)
No objections from me; make it public. :-) ~Oshwah~(talk) (contribs) 01:06, 3 April 2024 (UTC)
No objections. Best, KevinL (aka L235 · t · c) 01:14, 3 April 2024 (UTC)
 Done, now public: Special:AbuseFilter/history/1157/diff/prev/31865 --DannyS712 (talk) 01:34, 5 April 2024 (UTC)

Is there any reason why block-autopromote is unavaliable?

Just a random thought, but I randomly found MediaWiki:Abusefilter-autopromote-blocked, which I believe blocks you and disallows the edit. However, we don't use on this wiki at least because it is "unavailable" for some reason. Any idea why? – PharyngealImplosive7 (talk) 01:15, 30 March 2024 (UTC)

@PharyngealImplosive7: It's not really "unavailable". It's available, and used on a few projects if I remember correctly, but it's considered a restricted action because if someone does something that merits that, they probably should just be blocked by an admin instead. The filters also don't auto-block because the idea in this project is that all blocks should be made by an admin, similarly to how userrights should be managed by admins in the community's view. It was discussed somewhere if I recall correctly. EggRoll97 (talk) 01:19, 30 March 2024 (UTC)
I think the message was more about autopromotion being blocked? It would revoke or prevent them to be autoconfirmed 0xDeadbeef→∞ (talk to me) 01:21, 30 March 2024 (UTC)
@0xDeadbeef: @EggRoll97: When you put it that way, it makes more sense and blocking someone from getting the confirmed right does indeed seem kind of extreme. – PharyngealImplosive7 (talk) 01:26, 30 March 2024 (UTC)
Correct. There isn't an automated edit filter action that blocks the user from editing. This template refers to when the "Prevent the user from performing the action in question" and "Revoke the user's autoconfirmed status" actions are used within an edit filter. ~Oshwah~(talk) (contribs) 03:01, 2 April 2024 (UTC)
Just a thought, but this might be useful for something like filter 68 (hist · log), that throttles page moves and might revoke autoconfirmed from page move vandals? This is just an assumption because I can’t see the private filters and it seems that disallow and throttle work just fine because this hasn’t been brought up recently as far as I know. Again, this is just a thought and it’s fine if it doesn’t work for some reason. – PharyngealImplosive7 (talk) 18:27, 5 April 2024 (UTC)
I don't think blocking autoconfirmed promotion for a few days is a good idea; if we do this, we need to warn the user first that attempting the page move again may result in their autoconfirmed status being revoked. Throttling and disallowing page moves seem to work fine. Codename Noreste 🤔 talk 20:11, 5 April 2024 (UTC)
Yeah that’s what I thought. I totally agree with you. – PharyngealImplosive7 (talk) 20:45, 5 April 2024 (UTC)
Page-move vandalism isn't as much of a thing these days, though every now and then someone goes on a spree. Most (but not all) of the filter 68 hits look more like clueless people fumbling around and making a mess. Probably good that we slow them down, but this certainly isn't enough of a problem to justify such drastic measures. Suffusion of Yellow (talk) 00:13, 6 April 2024 (UTC)

FWIW it looks like it's been used a few times in public filers:

Extended content
MariaDB [enwiki_p]> select afh_filter,afh_timestamp from abuse_filter_history where afh_actions like "%blockautopromote%" order by afh_timestamp desc;
+------------+----------------+
| afh_filter | afh_timestamp  |
+------------+----------------+
|       1028 | 20200212151256 |
|        201 | 20120810005233 |
|        201 | 20120810005150 |
|        201 | 20110916071759 |
|        201 | 20110827000025 |
|        201 | 20110306091844 |
|        201 | 20110306091603 |
|          1 | 20091203195833 |
|          1 | 20091203195531 |
|         54 | 20090318191118 |
|         54 | 20090318190355 |
|         54 | 20090318190101 |
|         54 | 20090318185315 |
|         54 | 20090318183632 |
|         54 | 20090318183119 |
|         54 | 20090318175241 |
|          1 | 20090318012627 |
+------------+----------------+
17 rows in set (0.044 sec)

The 2020 use was definitely a mis-click. I don't know how to search the private filter history short of sceen-scraping Special:AbuseFilter/history. Suffusion of Yellow (talk) 00:31, 6 April 2024 (UTC)

I believe the most famous use of blockautopromote, and why there might or should be some nervousness about people using it today, indeed it's a lesson for all time, can be found in the earliest logs of filter 58.[1] Public version starts approximately here -- zzuuzz (talk) 00:53, 6 April 2024 (UTC)
An example linked from somewhere else(from here), just for curiosity: 10:51, 31 May 20102804:F1...17:B3C2 (talk) 01:50, 6 April 2024 (UTC)
Ah nvm, zzuuzz's link had a bunch, just have to remove the &wpSearchFilter=58 part of the link. – 2804:F1...17:B3C2 (talk) 02:01, 6 April 2024 (UTC)
Here is an analysis of public filter uses of the action. As seen here, block-autopromote was used for some sort of LTA again just for curiosity. It was also just used for some tests and to block page move vandals. – PharyngealImplosive7 (talk) 02:49, 6 April 2024 (UTC)

Extending time for EFH discussions

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.



Historically, EFH has been considered a relatively high trust role. I appreciate opinions on this can vary, and so the "need" to grant has been decided by precedence at this board, and evaluated on a case-by-case basis. Since we do not evaluate EFH discussions against a set criteria (like we do TE in Special:Permalink/1215492787, for example), participation is quite important.

Since many editors in the edit-filter community aren't around every day, to maximise participation, I'd like to suggest we extend the time for EFH discussions to the standard 7 days. ProcrastinatingReader (talk) 12:18, 30 March 2024 (UTC)

If we'd want participation, we need to formulate explicit requirements for how many !votes are needed as minimum participation. A low participation pass for EFH was actually me from a year ago with only 4 support. 0xDeadbeef→∞ (talk to me) 12:23, 30 March 2024 (UTC)
Though if you count EFH/EFM !votes differently, I suppose it would be different.. 0xDeadbeef→∞ (talk to me) 12:29, 30 March 2024 (UTC)
I think that determination may be up to the closer. I personally wouldn't say it's low participation simply because your request had support from SoY, zzuuzz, Compassionate727 and Red-tailed hawk. It was obviously passing even if left open for more comments. That's in part because the number of active EFMs was quite small, and those two have been persistently dedicated to filters. But also in part because SoY and zzuuzz have criteria which I think roughly matches this board's criteria holistically. As a combination of both factors, I personally would tend to trust their judgement on a request, and I imagine others here do too. ProcrastinatingReader (talk) 12:32, 30 March 2024 (UTC)
I don't think low participation is really a thing on this noticeboard. It's a very small community of people that have the desire and technical knowledge to modify the filters. There are millions of accounts on this site. Of those, 864 at the time of writing are administrators. A lot of the edit filter managers are admins, and didn't go through a consensus !vote on EFN, but rather self-granted as admins. Depending on their interests, they may or may not be involved in edit filters to a deep degree, they may have just given themselves the bit for one edit and forgotten to take it off. Out of the 139 EFMs, I counted at one point and a little over 10 aren't admins. Next, there are 23 edit filter helpers. That means overall, there are maybe 30 non-admins plus a few unflagged who are involved in edit filters. Add in the few admins who are also involved here, and we maybe have 40-50 people in the edit filter "community". I'm sure my count is probably a bit off, but those who toil and tinker with the edit filters aren't a large community, so unless there's serious concerns about someone as a candidate, I don't see that much of a problem with low participation. EggRoll97 (talk) 15:56, 30 March 2024 (UTC)
I guess on this note, it's worth also considering the topic Barkeep49 brought up on the talk page regarding nominations for EFM rights. ProcrastinatingReader (talk) 12:25, 30 March 2024 (UTC)
It'd be real nice to stop these third party nominations for both EFH and EFM, at least those that are absent the nominee providing a few sentences of why they need the role or what benefit they can bring. The request for 1AmNobody24 passed without any writings from them besides a four word acceptance and a response to a specific point brought up in an oppose !vote. I'm sure some rationale was included in Codename Noreste's nomination after the two of them had a discussion who-knows-where, but we should really be hearing from the nominees themselves in these discussions.
And EFH discussions should indeed be open for at least seven days. Uhai (talk) 13:48, 30 March 2024 (UTC)
Totally agreed. This is a process where it makes sense that self-noms are a norm.
Extending EFH to seven days also makes sense as we have not failed to process the backlog. The need for EFH will be decreased for each additional EFH we take. 0xDeadbeef→∞ (talk to me) 14:07, 30 March 2024 (UTC)
I don't see any objections of extending EFH nominations to a week, but only self-nominations are allowed? Codename Noreste 🤔 talk 14:27, 30 March 2024 (UTC)
well, what is the reason we should allow third-party noms? 0xDeadbeef→∞ (talk to me) 14:29, 30 March 2024 (UTC)
I don't see any reason not to allow third party nominations, is that EFH nomination for 1AmNobody24 the last third party nomination a user may do? Codename Noreste 🤔 talk 14:31, 30 March 2024 (UTC)
If there is consensus to disallow. The reason for not allowing third-party noms has been said above: we should really be hearing from the nominees themselves in these discussions. 0xDeadbeef→∞ (talk to me) 14:55, 30 March 2024 (UTC)
Oh, I see. I also don't see any objection to not allow third party nominations, but we are going to need consensus for that and to extend the EFH nomination for one week, just like running for EFM. Codename Noreste 🤔 talk 15:21, 30 March 2024 (UTC)
I'd also like to introduce another possibility where non self-noms are allowed but the nominee must also add a few extra sentences at least with some sort of rationale so we can hear from them too. – PharyngealImplosive7 (talk) 00:04, 31 March 2024 (UTC)
For example, this might include: it's 0xDeadbeef's response to my request for a bit of advice and his encouragement of boldness here that has pushed me to bite the metaphorical "bullet". Codename Noreste 🤔 talk 00:41, 31 March 2024 (UTC)
  • Support amending earliest close time to 1 week for efh. In the future may also want to consider requiring at least one bolded !vote from an efm. No efm participation, or low efm/efh participation in the discussion, suggests to me that the discussion should be open longer so those folks can chime in. –Novem Linguae (talk) 15:41, 30 March 2024 (UTC)
    A self-nom rule also seems fine to me. –Novem Linguae (talk) 16:22, 30 March 2024 (UTC)
  • Support on extending to one week, and on requiring self-noms. I don't think third-party nominations are really very helpful here. EggRoll97 (talk) 15:56, 30 March 2024 (UTC)
  • Per the discussion above the two supporting votes, I support both the one week extension and the self-nomination requirement. Codename Noreste 🤔 talk 16:02, 30 March 2024 (UTC)
  • Support both the only self-noms (unless the nominee also gives some sort of rationale) and the extension to 1 week. – PharyngealImplosive7 (talk) 16:08, 30 March 2024 (UTC)
  • Support both extending to 1 week and only self-nominations(for EFH and EFM), more opportunity for input from people who aren't here so often can only do good, and self-noms are easier than having to coordinate third-party nominations with the candidate so they can provide rationale. – user in the /32 - currently 2804:F1...54:171E (talk) 22:45, 30 March 2024 (UTC)
  • Support one week. I also think we need a statement from any applicant, and I'll just say that I don't like 3rd party nominations for this role. Just ask for a support statement instead. (I can vaguely imagine scenarios where some highly experienced user might want to introduce an application, but it can probably be done with just a supporting statement). I'd also support some type of quorum, though I think admins closing these applications should probably know what they're doing here, and not rush to close something just because it's past the due date. Being a minor venue, I think admins should be using a wide discretion when it comes to process here. In a sense, the closing admin also needs to be a supporter and not just a closing-bot, which should add to the quorum. -- zzuuzz (talk) 00:23, 31 March 2024 (UTC)
    If your changes pass, such as adding a quorum, someone should also update the policy on these elections as they will be quite out of date otherwise. – PharyngealImplosive7 (talk) 00:46, 31 March 2024 (UTC)
  • Support one week earliest closure --DannyS712 (talk) 06:19, 31 March 2024 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Filter 1291

Would it be possible to add a check for {{pagelinks|Example Article Name}} to 1291 (hist · log)? This would allow it to catch edits like Special:Diff/1217679181 (where one instance of Example Article Name still needs replacing), in addition to edits like Special:AbuseLog/37383189. Pinging DannyS712 as the filter’s creator.

All the best. ‍—‍a smart kitten[meow] 18:01, 7 April 2024 (UTC)

@A smart kitten  Done Special:AbuseFilter/history/1291/diff/prev/31935 --DannyS712 (talk) 18:12, 7 April 2024 (UTC)

New report to check before going to EFR

Please check out User:Suffusion of Yellow/Commonly reverted words and phrases. Still working out the details, but likely any drive-by vandalism "worth" filtering will be there. Let me know what needs explaining. Suffusion of Yellow (talk) 23:19, 2 April 2024 (UTC)

That's great! Will be useful when some of these inevitably come up at WP:EFR. Philipnelson99 (talk) 20:41, 8 April 2024 (UTC)

Filter 1301

Filter 1301 (hist · log) has been recently created by an admin to prevent users from editing other users' committed identity templates on user pages, but I noticed some possible issues:

1. The !"sysop" in global_user_groups condition should either be changed to !("steward" in global_user_groups) or removed; the former global group doesn't actually exist at all.
2. The generic disallow message should either be changed or removed, since it can be bitey to newer users and irritating to experienced users.

Any opinions or suggestions? Thank you. Codename Noreste 🤔 𝙇𝙖 𝙎𝙪𝙢𝙖 02:08, 12 April 2024 (UTC)

cc Daniel QuinlanNovem Linguae (talk) 02:40, 12 April 2024 (UTC)
Was this in response to some specific incident? I don't see the need for a filter here; the only people verifying committed identities should be WP:T&S, and I'd hope they check the page history to see who added the template. Suffusion of Yellow (talk) 03:38, 12 April 2024 (UTC)
I added it in response to this page protection request. I also hope T&S runs WikiBlame (or something similar) to find the edit that added an identity when handling requests as well, but "hope" isn't exactly a description of defense in depth. Daniel Quinlan (talk) 03:53, 12 April 2024 (UTC)
Filters aren't really security measures. A truly determined person could find a way around any of them. (I will email you one trick if you're curious.) Now that would be very difficult, but we're talking someone capable of conducting a social engineering attack against the T&S team of a ton-ten website. We're not talking about a drive-by vandal. What is a security measure is the protection against editing .js and .css pages; if Aditya-an11 doesn't want anyone editing their committed identity or GPG key, they can wrap it in /* ... */ and put it at something like User:Aditya-an11/key.js. There are also several BEANSy ways in which this filter could be exploited by vandals. Again, I'll email you if you're curious. Suffusion of Yellow (talk) 04:19, 12 April 2024 (UTC)
I don't think they have email enabled, so they'll have to email you instead. Codename Noreste 🤔 𝙇𝙖 𝙎𝙪𝙢𝙖 04:25, 12 April 2024 (UTC)
I already have his email, and just sent one. But I said "One weird trick" in the subject, so it probably got spam-filtered... Suffusion of Yellow (talk) 04:41, 12 April 2024 (UTC)
@Suffusion of Yellow, I haven't received your mail. I am quite unsure on how I didn't got the mail - I have enabled email in my preferences. Could it be that I am a new user?
Anyways, as I have mailed you -- as directed by @Codename Noreste. Aditya-an11 (talk) 07:28, 12 April 2024 (UTC)
@Aditya-an11 pretty sure Suffusion was talking about emailing Daniel Quinlan, not you. – 143.208.238.195 (talk) 08:20, 12 April 2024 (UTC)
Sorry, my bad. I have crossed it out Aditya-an11 (talk) 08:58, 12 April 2024 (UTC)
@Aditya-an11: Responding to your email, there isn't much you can do to protect against someone who has access to your account from modifying the page. Full protection won't really work; if the attacker says "Hey, I need to update my key, can you unprotect the page for bit" it's highly unlikely any admin would argue. You'll just have to trust that whoever is verifying your identity is clueful enough to check timestamps. Suffusion of Yellow (talk) 18:20, 12 April 2024 (UTC)
And I just realized that if the account is compromised, the attacker "is" the victim as far as MediaWiki knows, and will of course bypass the filter. If you plan on using anything in your userspace to prove your identity after a compromise, you'd better, again, hope, that someone goes looking for the oldest edit. Suffusion of Yellow (talk) 04:45, 12 April 2024 (UTC)
But the only things I have are that I have my committed identity listed on my local and global user pages (I've recently updated it minutes ago), and my account has a very strong password and has 2FA enabled globally.
Only my alternate account has a very strong password but can only be used in an emergency or in unsecure areas where I can't access my main. Codename Noreste 🤔 𝙇𝙖 𝙎𝙪𝙢𝙖 04:52, 12 April 2024 (UTC)
The point is that if someone gains your password and 2FA secret, and then they change your committed identity, this will be recorded as an edit coming from you. The only thing that will be sus is the fact that "you" changed "your" identity recently. If T&S has to distinguish between two people both claiming to be you (if only Brian had known about cryptographic hashes...), it's the oldest hash that they'd have to look at. Suffusion of Yellow (talk) 05:06, 12 April 2024 (UTC)
If the user has additional permissions, Wikipedia is definitely impacted. I'll respond to your email tomorrow or this weekend. Thanks for the additional context. Daniel Quinlan (talk) 05:38, 12 April 2024 (UTC)
This is a big drawback that I think this filter has. Not to mention that @Suffusion of Yellow believes that these filters could be exploited by vandals. And this is concerning to me....
Sure, the filter seems to provide basic protection, but I feel this fails when my account gets breached OR the person who is vandalising have apt technical knowledge to exploit it. Going by the case of Wikipedia:Wikipedia Signpost/2007-05-14/Committed identity, both the situation are probably.
These security concerns was partly what prompted me to ask for full page protection in the first place. "Full" as in even if a vandal gets access to my account, they can't edit the my committed-identity page. Only the admins can. And that's way more reassuring and secure than the filter. While I do understand this may not be common, I do see people page protecting their committed identity pages (like Gwern to which I cited here). Though, in all fairness, I am a new user and could be wrong. I would be happy if get any guidance on how to maturely approach this issue. Aditya-an11 (talk) 07:49, 12 April 2024 (UTC)
Thanks, steward is the appropriate group, I'll update the filter. As far as the message goes, this filter should almost never match, but I'm open to suggestions. Also, if the default disallow message is considered bitey for reasons (beyond it being non-specific), we should discuss making it less bitey under a new topic. Daniel Quinlan (talk) 04:02, 12 April 2024 (UTC)
Correct me if I'm wrong, but the filter also prevents any editing of any user page containing the template, which is likely to create its own problems (maybe SoY has already pointed this out by email). I took a look at the RFPP request and would say that of course protection can be used for 'important' subpages. I've had my own PGP sub-page semi-protected since I became an admin, and I'm sure I've even fully protected others' key pages, if that's what they asked for (semi is usually enough though, IMO). As SoY points out, timestamps are everything when it comes to key verification. -- zzuuzz (talk) 07:39, 12 April 2024 (UTC)
Honestly, I'd recommend making that filter private right now even if it didn't change from what it currently is(or it's ultimately disabled), if there's any worry of people trying to bypass it - isn't that the main reason filters are privated? @Zzuuzz, it's not every edit, though it is every user page yes. – 143.208.238.195 (talk) 07:54, 12 April 2024 (UTC)
Yes, you're right. What would be prohibited is something like courtesy blanking, replacing a user page with a sock tag or a banned notice (or reverting such), along with removing bad content placed by the user near the template. I'm still sceptical about the filter, or anyone relying on it, so will let someone else make that judgement about its visibility. -- zzuuzz (talk) 08:23, 12 April 2024 (UTC)
At this point, since you pretty much said it as an example, I might as well say it, the filter, as a side effect, gives all users the capability of fully protecting specific lines of their choice from non-admin users - this is not something which should be given lightly or even automatically unless it's really good automation (not the case with the way the filter currently is) because ill intentioned users exist. – 143.208.238.195 (talk) 08:43, 12 April 2024 (UTC)
Yeah, that's what I had in mind, e.g. {{committed identity|Zzuuzz is a total ...}} Yeah, we could tweak the regex so that they can only talk about how much DEADBEEF 15 A B00BFACE[FBDB], but is it worth the trouble? I've already though up about four ways to bypass this filter (again, emailed DQ, some of them are sort of relevant to other filters). Suffusion of Yellow (talk) 18:03, 12 April 2024 (UTC)
Bbb23, who is a much more frequent target for vandals, would not be exempt from that either. 0xDeadbeef→∞ (talk to me) 15:21, 13 April 2024 (UTC)
I've disabled the filter and set it to private for now. I think it might be better to integrate it into a more generalized (and probably private) filter for user page vandalism and shenanigans, one that flags edits rather than disallowing them. I'd also like to better address some weaknesses in the implementation (that was always the plan).
One option we might want to consider is designating a specific location (or locations) for committed identity information, PGP keys, etc. and protecting it similarly to .css and .js files. I think the concerns about the filter allowing users to "protect" specific lines are somewhat overblown as this is already possible with personal .css, .js, and .json pages and this hasn't been a major issue. Daniel Quinlan (talk) 19:43, 12 April 2024 (UTC)

[URGENT] Education Program needs to be exempted from filters

See this filter log, and this is something that I've seen before. Members or coordinators of the education program getting caught up in filters is probably one of the worst possible false positives and should be addressed immediately. Taking Out The Trash (talk) 17:38, 13 April 2024 (UTC)

Courtesy ping to Ohnoitsjamie as the last editor of the miscellaneous article/draft/talk LTA filter. Codename Noreste 🤔 𝙇𝙖 𝙎𝙪𝙢𝙖 18:14, 13 April 2024 (UTC)
 Fixed by Ohnoitsjamie. Nobody (talk) 20:06, 13 April 2024 (UTC)
Thanks, Nobody; I fixed it, then was unable to figure out where this ping originally came from. OhNoitsJamie Talk 20:11, 13 April 2024 (UTC)

Set filter 1294 to disallow

  • 1294 (hist · log) ("Test edits and low effort vandalism", public)

Standard notification. Split out of 260 (hist · log), 384 (hist · log), and 614 (hist · log), with a handful of additions. No FPs in the few dozen "new" matches. I'm not going to add this to Template:DatBot filters. In fact, that was part of the reason for the split. I doubt that users adding "lol" and "fdshksdjfhskdjdshfflshjfsldkhfdslkhsfd" are really going to put in the effort to work around the filters, so let's have a bit less clutter at WP:AIV/TB2. Suffusion of Yellow (talk) 00:36, 14 April 2024 (UTC)

Understood. This filter is targeted towards your run-of-the-mill everyday vandal who doesn't use much effort to bypass this filter and/or trigger 1296 and/or 1297 instead.
Also, this might be different from 664 (hist · log). Codename Noreste 🤔 𝙇𝙖 𝙎𝙪𝙢𝙖 00:50, 14 April 2024 (UTC)
664 is warn-only, though I haven't looked through the log to see if it can be set to disallow. 1296/1297 is an experiment that might go nowhere. 1297 is not going to be easy to maintain and IMO a filter that complicated is only justifiable if keeps out a huge amount of vandalism. Suffusion of Yellow (talk) 00:59, 14 April 2024 (UTC)
No problems here, seems solid from a glance at the filter. EggRoll97 (talk) 05:02, 14 April 2024 (UTC)

Need a change for #867

After noticing this, I suggest excluding undos and reverts from being logged onto the edit filter log by #867. Toadette (Let's talk together!) 14:47, 14 April 2024 (UTC)

 Fixed. EggRoll97 (talk) 17:56, 14 April 2024 (UTC)
Not sure if that's a good idea. After an AFD was closed as "redirect", it's common that someone will come back much later and try to undo the result. I see no harm in logging that. Suffusion of Yellow (talk) 18:47, 14 April 2024 (UTC)
Self-reverted for now, though anti-vandalism isn't exactly the scope of this filter. For example, Special:Diff/1218898491 isn't a large page creation, it's reverting redirect vandalism. EggRoll97 (talk) 20:52, 14 April 2024 (UTC)
Sure but there's no harm in a log-only filter catching a few out-of-scope edits. If I understand this change correctly, around next WP:THURSDAY you'll be able to write something like page_last_edit_age >= 86400 to exclude reverts of recent edits. But even that would exclude rapid edit warring to overturn an AFD. Suffusion of Yellow (talk) 20:59, 14 April 2024 (UTC)

Is this worth changing the 'Numeric change without summary' filter?

Until WP:VPT#I don't understand these edit summaries (task: T360164) is fixed, would it be worth it to change the pattern to match these cases too?
I'm not really sure how to check how often edits like that are happening and not getting logged by the filter, other than manually looking at Special:RecentChanges (I also don't know what other filter this might be affecting), but I figured I'd point it out and ask anyways. – 143.208.239.226 (talk) 02:32, 22 April 2024 (UTC)

Thanks, tweaked. Found one example out of the last 1000 mobile app edits. Suffusion of Yellow (talk) 03:56, 22 April 2024 (UTC)

Prepare for Armageddon: temporary accounts

(Topic name is a reference to one of my favorite error messages.)

The 15 April The Tech News weekly summary includes this blurb:

Volunteer developers are kindly asked to update the code of their tools and features to handle temporary accounts. Learn more

Of course, it's not just code that will need to be updated. A good number of edit filters are going to need to be updated. I don't think we necessarily want or need to update anything before it happens, but I'd suggest enumerating the variables and functions most likely to be affected and start building a list of filters expected to require updates.

(This may have been discussed before, but I didn't immediately find anything in the archive.) Daniel Quinlan (talk) 23:57, 15 April 2024 (UTC)

If we don't have anything to feed to ip_in_range(), that will be bad, and some filters will have to just be disabled. But otherwise, so long as temp accounts are never autoconfirmed, and have an edit count and age that stays at zero or null, I don't think a huge number of filters will need updating. If user_age and user_editcount start incrementing, then we might want to check user_type in some filters. I'd prefer to see how temp-account users act first. Will the vandals clear cookies after every edit? Or will most of them be too clueless? No way to know right now. Suffusion of Yellow (talk) 01:04, 16 April 2024 (UTC)
I'm hoping that the IP variables are unaffected, but I haven't dug into that. I was most concerned about user_age which is definitely used as an IP test. Daniel Quinlan (talk) 01:47, 16 April 2024 (UTC)
One thing we might have to consider is this: If people start crying "We're being flooded with vandalism! We need to require registration for everyone!" an alternative might be making the filters much harsher for temp users. As in, you add "gay" to a BLP, in any context, and you're told "you have to register an account to do that". You edit more than three pages in ten minutes: "sorry, either wait ten minutes or register an account". And so on. I hope it doesn't come to that, but disabling all logged out editing would be a greater loss, I think. Suffusion of Yellow (talk) 02:31, 16 April 2024 (UTC)
Yeah I agree with you as we have a lot of productive IP users. I think that once this gets implemented, using !("confirmed" in user_groups) (as long as the temp accounts can't become confirmed or get other user permissions but that should happen anyways) would work quite well to prevent new users and the new temp account issues. – PharyngealImplosive7 (talk) 02:39, 16 April 2024 (UTC)
It looks like the new user_type variable will probably work well for most simple filters.
We also need to understand how this affects filters that use the IP in throttling actions.
It might also be a good time to consider whether there are any additional variables or functions that could help alleviate any losses in functionality. There are "hacks" such as trying to detect reverts by looking at the edit summary. That example might not be something that wants to be fixed sooner because of temporary accounts, but are there other hacks that might be more important to replace with a better solution due to temporary accounts? Daniel Quinlan (talk) 06:29, 16 April 2024 (UTC)
I think, I hope, that IP masking causing that level of disruption would convince the WMF to roll it back at least locally. Snowmanonahoe (talk · contribs · typos) 12:45, 22 April 2024 (UTC)
The WMF legal department is requiring IP masking. I do not anticipate a rollback. –Novem Linguae (talk) 00:12, 23 April 2024 (UTC)
Damn, you're right... Snowmanonahoe (talk · contribs · typos) 03:49, 23 April 2024 (UTC)

Set filter 1076 to warn

("Draftified article more than 180 days old")

Has some inevitable false positives due to AfDs, but people closing those know what they're doing. Otherwise there are a lot of draftifications of old articles by people who either don't realize how old the page is, don't know they're not supposed to do that, or both, and it would be nice if they could be warned as they do it, not later if someone happens to notice. * Pppery * it has begun... 03:43, 20 April 2024 (UTC)

I agree, so I support warning. Changed to neutral because of the amount of FPs. Also note that if this passes, we'll have to make a new and specialized warning template but I'm sure you already know that...PharyngealImplosive7 (talk) 16:36, 20 April 2024 (UTC)
Also support. EggRoll97 (talk) 17:56, 20 April 2024 (UTC)
I'm on the leaning side of opposing due to the sheer amount of FPs and possibilities to pause and break scripts. Codename Noreste 🤔 La Suma 03:40, 24 April 2024 (UTC)

Not opposed to this, but both User:Evad37/MoveToDraft.js or User:MPGuy2824/MoveToDraft.js just say something like this when a filter is tripped:

Could not move page:
API error: abusefilter-warning

Try again ?

Also MPGuy's version already gives this warning:

Draftifying isn't appropriate per WP:DRAFTIFY, since this article is more than 90 days old.

which is kind of hard to miss. Ideally, these script would be updated to show the parsed warning, though I'm not sure how much of an effect it will have. (Courtesy pings Evad37, MPGuy2824.) Suffusion of Yellow (talk) 19:45, 20 April 2024 (UTC)

There are also, of course, manual draftifications not using the script, which currently get no warning. * Pppery * it has begun... 21:17, 20 April 2024 (UTC)
Yes, it's probably a fair trade-off even the if the scripts don't display the warning properly. Suffusion of Yellow (talk) 21:39, 20 April 2024 (UTC)

I'm not sure about this. I've manually analyzed the last 50 filter hits; and while 17 of those were true positives, there were 27 false positives (along with 6 cases in which it wasn't as clear to me). As far as I can see, the majority of the FPs came from round-robin page moves, draftification following WP:AFD/WP:REFUND, and situations in which the page itself had existed for more than 180 days, but had only recently been moved to mainspace (and were therefore within the time limit for draftification):

a smart kitten's analysis of recent 1076 (hist · log) filter hits

True positives

  1. Special:AbuseLog/37520237
  2. Special:AbuseLog/37517861 - the draftification was of a recently-created article on top of a redirect, so would have been within the time limit for draftification had it been a brand new page. however, given that the page was blanked-and-redirected as a result of an AfD, the page should probably have just been blanked-and-redirected again - rather than moving the page to draftspace, and taking the history of the previous article with it.
  3. Special:AbuseLog/37517848 - same as above
  4. Special:AbuseLog/37515983
  5. Special:AbuseLog/37515631
  6. Special:AbuseLog/37507112 - was originally draftified at an AfD, but was then later accepted through AfC. this draftification took place >180 days after the AfC acceptance
  7. Special:AbuseLog/37506617
  8. Special:AbuseLog/37501991
  9. Special:AbuseLog/37501990
  10. Special:AbuseLog/37501989
  11. Special:AbuseLog/37501988
  12. Special:AbuseLog/37474830
  13. Special:AbuseLog/37465973
  14. Special:AbuseLog/37462419
  15. Special:AbuseLog/37460722
  16. Special:AbuseLog/37442207
  17. Special:AbuseLog/37437883

False positives

Manual round-robin page moves

  1. Special:AbuseLog/37526456 - see Special:PageHistory/Mister Peabody
  2. Special:AbuseLog/37526444 - see Special:PageHistory/Una storia importante (song)
  3. Special:AbuseLog/37526437 - see Special:PageHistory/Ucisa
  4. Special:AbuseLog/37510585 - see Special:PageHistory/World egg
  5. Special:AbuseLog/37496701 - see Special:PageHistory/Project 8 (soccer league)
  6. Special:AbuseLog/37475553 - see Special:PageHistory/IT law
  7. Special:AbuseLog/37475530 - see Special:PageHistory/Ballyrory (disambiguation)
  8. Special:AbuseLog/37457511 - see Special:PageHistory/Espresso (Sabrina Carpenter song)
  9. Special:AbuseLog/37452252 - see Special:PageHistory/Conference Finals
  10. Special:AbuseLog/37423355 - see Special:PageHistory/Pentavryso, Kozani

Draftification from WP:REFUND

  1. Special:AbuseLog/37524078
  2. Special:AbuseLog/37494847
  3. Special:AbuseLog/37475645
  4. Special:AbuseLog/37442191
  5. Special:AbuseLog/37423697

Draftification from WP:AFD (or similar)

  1. Special:AbuseLog/37500939
  2. Special:AbuseLog/37478431 - was deleted at AfD, & draftified post hoc after a request was made to the closing administrator
  3. Special:AbuseLog/37429525
  4. Special:AbuseLog/37429351
  5. Special:AbuseLog/37419717 - was deleted at AfD in 2017, but draftified at a DRV

The page itself had existed for >180 days, but had only recently been moved to mainspace

  1. Special:AbuseLog/37517510 - see Special:PageHistory/Draft:Naima G. Sharaf
  2. Special:AbuseLog/37512391 - see Special:PageHistory/Draft:Miriam Grossman
  3. Special:AbuseLog/37439308 - see Special:PageHistory/Draft:Battle of Umbarkhind
  4. Special:AbuseLog/37437754 - see Special:PageHistory/Draft:Radha Krishna Public School, Amroha
  5. Special:AbuseLog/37433258 - see Special:PageHistory/Draft:Jimmy Gardner (labourer)
  6. Special:AbuseLog/37433081 - see Special:PageHistory/Draft:UV Creations
  7. Special:AbuseLog/37423896 - see Special:PageHistory/Draft:St. Rochus Clinic Bad Schönborn

Less clear/Other potential FPs

  1. Special:AbuseLog/37518209 - all of the substantive content was added to the page by the draftifying editor (see Special:PageHistory/Draft:MPL Philippines Season 11). could probably have been a G7
  2. Special:AbuseLog/37514053 - was draftified by a checkuser due to being a commissioned article, & therefore needing to go through AFC
  3. Special:AbuseLog/37511738 - draftified a newly-created article that was started on top of an older redirect. there was no prior page history besides the redirect, though, so the mainspace redirect was just able to be recreated after the new article was draftified
  4. Special:AbuseLog/37490978 - moved a redirect to draftspace to allow for the title to be taken by an article. should probably (imo) have just been a round-robin or {{db-move}} situation; but at the same time, it doesn't seem like what this filter was designed to catch
  5. Special:AbuseLog/37488312 - draftified a newly-created article that was started on top of an older redirect from a BLAR in 2021 (see Special:PageHistory/Draft:Samdish Bhatia)
  6. Special:AbuseLog/37455711 - was draftified partially due to possible COI concerns, but the article had existed since 2011

Although I think a warning for true positives would be beneficial (for the same reason as Pppery), I'm wondering if there are any ways that the rate of FPs can be decreased before this filter is set as such. As things currently stand, I'm leaning oppose, due to the large proportion of warnings that would be given to editors encountering false positives. (Also, Courtesy ping: Bradv as the filter's author.)

All the best. ‍—‍a smart kitten[meow] 16:39, 21 April 2024 (UTC)

Maybe we could reduce FPs from recently moved pages like this: moved_from_age > 15552000 & moved_to_last_edit > 604800
Note that I'm just using 1 week as a placeholder for when the article was last moved so it can be changed to whatever value is best. – PharyngealImplosive7 (talk) 17:03, 21 April 2024 (UTC)
moved_to_last_edit_age seems to be null if the target page doesn't exist; see testwiki:Special:AbuseLog/102036. Suffusion of Yellow (talk) 19:31, 21 April 2024 (UTC)
Maybe then it could be moved_from_age > 15552000 & (moved_to_last_edit > 604800 || moved_to_last_edit == null) but I'm not too sure about this. – PharyngealImplosive7 (talk) 20:12, 21 April 2024 (UTC)
Ugh, brain fart. Now I get it. You're saying that if the move was recent, the leftover redirect is probably still there in draft space, so we can use its age? Yes, that's a great idea! Though now I'm confused as to why there's a moved_to_last_edit_age variable at all. If the redirect-to-be-overwritten has only one revision, that's just the same as moved_to_age. And if it has more than one revision, the move is just impossible. Suffusion of Yellow (talk) 04:18, 22 April 2024 (UTC)
So then what variable would work better? I can't seem to find any suitable alternatives, but again you raise a point about the existence of the draft article preventing someone from moving back the page unless they are an admin or page mover (which isn't the majority of editors). So that wouldn't work because the move would be impossible. – PharyngealImplosive7 (talk) 02:36, 23 April 2024 (UTC)
This is not convincing to me on principle. because the people doing false positives are experienced users that know what they're doing so will just click through the warning. * Pppery * it has begun... 17:39, 21 April 2024 (UTC)
Thanks for all the digging! The first group of FPs all include a summary that contains either "robin", "swap", or "vacate". I don't know if that's a representative sample, but just excluding those summaries would produce few false negatives, unless someone deliberately uses them to avoid being logged by the filter, in which case they should at minimum receive a stern talking-to. The second group seems to come from one script (User:SD0001/RFUD-helper) which could be excluded. The others can, I suppose, just click past the warning. Compare 602 (hist · log), which warns every person leaving a CTOPS notice, appropriate or not. Suffusion of Yellow (talk) 19:28, 21 April 2024 (UTC)
Paranoia would suggest only excluding edits with the first FP summaries if the requester holds page mover rights, and also creating a separate filter to log any exclusions. * Pppery * it has begun... 20:11, 21 April 2024 (UTC)
If they don't have pagemover rights, then they've left a redirect behind in mainspace. I don't know what fraction of admins at least do a spot check on R2 deletions, but if anyone frequently gets up to shenanigans like this, they'll be caught eventually. Filters (especially public filters) are never meant to stop every clever person from finding a workaround. With all that said, I still wouldn't object to a second, log-only, no-exceptions filter. The condition limit was doubled last year, and "move" filters are cheap. Suffusion of Yellow (talk) 23:50, 22 April 2024 (UTC)
Fair point regarding the others just being able to click past the warning - I suppose one of the things I'm concerned about is inadvertently building up banner blindness; though maybe the warning could be worded in such a way that it doesn't state that the editor is definitely trying to improperly draftify a page, just that the edit filter has detected that they might be. I'm in agreement with Pppery regarding only excluding the first set of edit summaries if the editor holds pagemover rights (in a similar way, User:SD0001/RFUD-helper could be set to exclude only if the editor is an admin), and I don't have a strong opinion either way regarding creating a separate filter to log exclusions. Annoyingly, I'm not sure if there's a way to filter out 'page is old but was only recently moved to mainspace' hits.
As a side-note, I'm wondering if it's worth notifying Wikipedia talk:Draft of this proposal - would anyone have any objections if I did? All the best, ‍—‍a smart kitten[meow] 09:05, 22 April 2024 (UTC)
I'm disinclined to set anything to warn an experienced editor. The only warnings from the edit filter I receive as an experienced editor are "you're about to place a CTOP" warnings, and those are a pain. They are jarring to my workflow, and they break user scripts. Also a 54% false positive rate is very high. –Novem Linguae (talk) 10:41, 22 April 2024 (UTC)
That's the point. Trying to draftily old articles should be jarring. * Pppery * it has begun... 21:51, 23 April 2024 (UTC)
54% false positives, and the potential to break scripts such as WP:PAGESWAP, still leaves me with concerns. –Novem Linguae (talk) 00:48, 24 April 2024 (UTC)
To be fair, the round-robin moves I found in this filter's logs all appear to have been done manually (rather than using a script) - there appears to already be an exception in 1076 for moving to subpages of Draft:Move, which - as far as I'm aware - is what the scripts do. Personally speaking, I'd like to see if the false positive rate can be reduced before considering implementing a warning. All the best, ‍—‍a smart kitten[meow] 13:11, 24 April 2024 (UTC)

Set filter 1283 to disallow

Required notification; see filter notes. Suffusion of Yellow (talk) 18:28, 27 April 2024 (UTC)

PLEASE DO NOT DISCUSS PUBLICLY. Codename Noreste 🤔 La Suma 18:35, 27 April 2024 (UTC)
This seems fine, the hits are going crazy lately with true positives. EggRoll97 (talk) 18:51, 27 April 2024 (UTC)

Filter 1304

Untested and will probably need some tweaks. Please do not discuss details here, but set to disallow if needed without asking me. Suffusion of Yellow (talk) 18:28, 28 April 2024 (UTC)

Another reminder to not discuss private filters like this one publicly. – PharyngealImplosive7 (talk) 23:31, 28 April 2024 (UTC)
Yeah, that's going to need major tweaks before anyone even considers setting that one to disallow. Might as well consider that one a sort of emergency filter at the current state until it's far more built. EggRoll97 (talk) 02:54, 29 April 2024 (UTC)

Filter 139

  • 139 (hist · log) ("Fixed position vandalism", private)

Please do not discuss here (of course), but if anyone with access could pop an explanation in the filter notes or via email as to why this is hidden, I would appreciate it. I don't currently see any reason for it to be so, but I may be missing something right in front of my eyes. EggRoll97 (talk) 16:51, 29 April 2024 (UTC)

It's because it's an LTA filter, pretty sure: Wikipedia:Edit_filter_noticeboard/Archive_10#139. – 2804:F14:80C8:4701:20D2:F905:5323:F028 (talk) 21:26, 29 April 2024 (UTC)
This is from before my time, but I guess I'd call it slightly higher-effort vandalism than "skbidbdidi gyattt sigma". I think people doing that sort of thing, even if they aren't technically LTAs, are the sort who would find the filter and maybe even understand it. Suffusion of Yellow (talk) 21:47, 29 April 2024 (UTC)
Indeed. A little background, which I have a lot more of: The note added 28 June 2011 contains a distinct keyword, a (ns: 0|4) search of which can lead to some additional info. -- zzuuzz (talk) 21:53, 29 April 2024 (UTC)

Abuse filters for tagging speedy and PROD deletions

Right now it is a pain to filter deleted edits. I think the abuse filter should tag speedy deletions and PRODs to help find groups of pages that were deleted together.

For example, if one were to type in speedy-g6 in the "tags" field, then in the deletion log all the pages deleted under G6 should be visible. It would help with stuff like identifying the frequency of use of speedy criteria as well as allowing for searching of PRODs, etc. It possibly could also be done for XfDs. Awesome Aasim 17:48, 8 May 2024 (UTC)

It's not impossible, but I question the necessity of tagging every speedy deletion. Are there specific CSD criterion you're looking for, and/or a reason you're specifically looking for them? EggRoll97 (talk) 21:24, 8 May 2024 (UTC)
I was searching for G6 (I tagged a few pages for G6 yesterday and wanted to see if they were deleted, but I forgot the page title), but there is no way to search the deletion log by summary. The abuse filter tagging would really help. We would just need about as many filters as there are speedy criteria. Awesome Aasim 22:37, 8 May 2024 (UTC)
That sounds like a better job for a bot. I don't think this is worth using up 50 conditions, out of 2000. And a bot could apply tags retroactively. Suffusion of Yellow (talk) 00:20, 9 May 2024 (UTC)
Do you think that would be something good for a WP:BRFA? Tagging items and revisions in deletion logs and etc. to make searching easier, to avoid running up against condition limits? Awesome Aasim 16:23, 9 May 2024 (UTC)
Off the top of my head, I don't see any major issues. My first concern was that the tagging would add clutter to people's watchlists, but based on a quick test, manually adding a tag does not show up there. There may be some other problems I haven't thought of yet. Suffusion of Yellow (talk) 17:39, 9 May 2024 (UTC)
I mean, you're talking about retroactively adding millions of tags (there exist ~15.5 million non-suppressed deletion logs on this project) with no clear rationale as to the usefulness of this. Identifying the frequency of use of speedy criteria can be done with trivial queries to the replica database. Finding pages you've nominated can be done with Twinkle's CSD log. Searching the deletion log by summary can be done on the replica database as well, and there's an argument to be made this would be better off as a suggested feature for MediaWiki rather than this mass-tagging exercise. Uhai (talk) 03:24, 10 May 2024 (UTC)
I agree that we should be able to search the deletion log and past revisions easily. However, this tagging would be a good workaround. There should be some tag filters that work in the public logs, including deletion logs. Awesome Aasim 23:37, 10 May 2024 (UTC)
I agree that we should be able to search the deletion log and past revisions easily. If anyone wants to open a Phab task, go right ahead. However, I think tagging should still be done, if not for past deletions, then for current ones as well. We can also tag revdels as well. That or the tags should be added by MediaWiki when choosing a prefilled summary automatically. Awesome Aasim 23:54, 10 May 2024 (UTC)
@Awesome Aasim Reach out at WP:RAQ or consider enabling Twinkle's CSD logging at Wikipedia:Twinkle/Preferences#speedy to monitor pages you've nominated. Uhai (talk) 02:44, 9 May 2024 (UTC)
 Not done Agreed - using a query is one option, asking for a bot is another (though obviously you would have to go through BRFA and I would expect there to be some questions of community support/consensus for such a wide-ranging bot). By my count I'm the fourth EFM to decline to add such a filter in this discussion, marking this as not done --DannyS712 (talk) 02:16, 11 May 2024 (UTC)

Just a standard notification, but feel free to make any additional changes if you want to this template. Codename Noreste 🤔 La Suma 02:34, 1 May 2024 (UTC)

Might be worth adding suggestions for user scripts, such as the ones I use including User:Ingenuity/AbuseFilterContribs, User:Suffusion of Yellow/FilterDebugger, User:Suffusion of Yellow/batchtest-plus, User:Suffusion of Yellow/effp-helper, and User:DannyS712/EFFPRH/sandbox.js. 0xDeadbeef→∞ (talk to me) 10:59, 11 May 2024 (UTC)

Filter 1285

  • 1285 (hist · log) ("Removal of short description", public)

Is the line !(new_html contains "shortdescription") & /* Catch-all for weird edge cases */ working as intended? ~10 days ago I did <this edit>, and it didn't work initially: log.
Was that line supposed to have covered this case? Perhaps it could check for the category instead. – 2804:F14:80B7:8201:F172:9A68:94A0:768 (talk) 21:18, 12 May 2024 (UTC)

@Suffusion of Yellow, since it's your filter and your line. – 2804:F14:80B7:8201:F172:9A68:94A0:768 (talk) 21:19, 12 May 2024 (UTC)
Apparently not. I think this fix should do it. Suffusion of Yellow (talk) 21:36, 12 May 2024 (UTC)
Simpler than my idea, thank you. – 2804:F14:80B7:8201:F172:9A68:94A0:768 (talk) 21:42, 12 May 2024 (UTC)

Set filter 1305 to disallow

Standard notification. Looks overly broad at first glance, but zero FPs so far. There are a few other checks that could be used to narrow it down, but I'll wait for FPs before doing so. Suffusion of Yellow (talk) 17:51, 13 May 2024 (UTC)

Special note, I've assisted by creating changes for them to implement via email as this led to this filter's creation. Don't discuss details here. Codename Noreste 🤔 La Suma 18:47, 13 May 2024 (UTC)
And already added to DatBot. Definitly needed for now. Nobody (talk) 05:07, 14 May 2024 (UTC)

Expanding 614

In this thread, it was suggested to expand filter 614 (hist · log) to include low-effort ways to bypass the blocking of the meme "skibidi". While I know we can't block every variation, we could try to block some of the more common variations. Specifically, we could change \s*bozo|skibidi|gyatt part of 614 into \s*bozo|sk[i1]?b[i1]?d[i1]?(?<!skbd)|gyatt (change if there are any FPs, but I know that the string 'skbd' is used in some articles). Also pinging @Myrealnamm: and @Suffusion of Yellow: who participated in the previous discussion. – PharyngealImplosive7 (talk) 22:19, 16 May 2024 (UTC)

I have another suggestion: replace both gyatt and \bgyat\b with \bgyat{1,}\b, as the very latter I made (and tested with regex101) catches both gyat and gyatt. Codename Noreste 🤔 La Suma 17:36, 17 May 2024 (UTC)
I think the issue with that is that right now, 'gyatt' is disallowed by the filter if it is present anywhere in the added text, while 'gyat' only is disallowed when alone and surrounded by spaces. We might have to test if that change leads to any FNs first. – PharyngealImplosive7 (talk) 16:52, 19 May 2024 (UTC)
Correct. If the absence of a word boundary isn't causing FPs, best to just leave it. Some people just see a text entry box, stab their finger somewhere in the middle, and start typing. Suffusion of Yellow (talk) 20:13, 20 May 2024 (UTC)
This was already almost covered by \bs+k+[i1bdt]{4,}y*\b, but they actually used "cskbidi". I removed the beginning word boundary, which is probably safe. Removing the ending boundary would match "skidding" and "skittish". Suffusion of Yellow (talk) 20:05, 20 May 2024 (UTC)

"Nuh uh"

I recently encountered this vandalism adding "Nuh uh" to the end of the artice. Anyone else encountered something like this as well? Feels like it's a possible candidate for mix-used words, noting how a known meme exists for the phrase as well. ABG (Talk/Report any mistakes here) 01:48, 23 May 2024 (UTC)

I'm not 100% confident, but I'm pretty sure the mixed-use words and other related filters started based on data collated at User:Suffusion of Yellow/Commonly reverted words and phrases (EFN post: #New report to check before going to EFR).
@Suffusion of Yellow, would it have shown in your reports if it was significant? – 2804:F14:80E4:8401:DCFE:5436:C21:470C (talk) 02:41, 23 May 2024 (UTC)
"Nuh" is already a part of 1297 (hist · log); they just ignored the warning. It seems to fluctuate in and out of the report, probably because I'm including all namespaces, and it's not revert-on-sight when posted on a talk page. Suffusion of Yellow (talk) 05:11, 23 May 2024 (UTC)

Reminder

From WP:EF (emphasis added): Except in urgent situations, new edit filters must not be set to disallow without thorough testing and a notice at the noticeboard to give other edit filter managers and the community time to review the filter for technical accuracy and necessity. In urgent situations, the notice may be made after-the-fact. I think this is still important, even if most people have gotten out of this habit. Except in the most extreme cases, a day or two in log-only isn't going to hurt, and there may be subtleties you haven't considered. And more eyes are always better. Suffusion of Yellow (talk) 18:39, 28 May 2024 (UTC)

There's also User:MusikBot/FilterMonitor/Recent changes to keep track of filter changes. Nobody (talk) 05:23, 29 May 2024 (UTC)
Tag-only can't hurt as well, right? Codename Noreste 🤔 La Suma 05:41, 29 May 2024 (UTC)
Log only is best, because if a filter goes awry and starts firing constantly it would leave lots of changetags that could confuse other editors. — xaosflux Talk 17:31, 29 May 2024 (UTC)

Skibidi uwu gyatt 42069

I just got done with the bot-reported part of AIV: thank you, thank you to all of you building these filters that keep SO MUCH SHIT out of our articles. I appreciate it. Drmies (talk) 14:20, 23 May 2024 (UTC)

I had a look because I was curious, and I can absolutely say I have had enough of "gyatt" and related terminology for at least a few years. EggRoll97 (talk) 00:50, 24 May 2024 (UTC)
Kudos to 614 (hist · log) for keeping all of this brainrot nonsense out from articles, ¿eh? Codename Noreste 🤔 La Suma 01:35, 24 May 2024 (UTC)
Yep. Whenever a newly coined word becomes popular enough to enter the mainstream, some immediately think "Can I vandalize Wikipedia with it?" Thanks to our filter managers for preventing that. Justarandomamerican (talk) Have a good day! 21:38, 30 May 2024 (UTC)

Filter 1310

Shortly after Trump was impeached, the was a flood of people trying to add "and the only X to be impeached by the house" every place his name was mentioned. See 1018 (hist · log). Now, of course, it's "convicted felon". We already have this at a page about a number, and this at a page about his son's school. Obviously, keeping this log-only; in some contexts it's going to be appropriate. But please keep an eye out. Suffusion of Yellow (talk) 00:28, 31 May 2024 (UTC)

Should the templating instructions be collapsed by default on the EFFPR page?

So I tried a bit of tinkering, and it's fully possible of course to collapse the instructions from the editnotice at Template:Editnotices/Page/Wikipedia:Edit filter/False positives/Reports so that the page isn't half taken up by the templates when editing the page (removing duplicates, anything that has to be done manually instead of script-assisted). It's a useful guide when one is first starting out on the false positives page, but for those who already have experience dealing with them (I would characterize a majority of the editors on the page), a guide to the EFFP template is helpful to have there, but not always necessary. So I would therefore propose that the editnotice be changed from:

{{EFFP/codes}}

to the following:

{{Collapse top|title=Instructions}} {{EFFP/codes}} {{Collapse bottom}}

EggRoll97 (talk) 20:08, 31 May 2024 (UTC)

I second this as well. Codename Noreste 🤔 La Suma 02:00, 1 June 2024 (UTC)
I'm opposed to this change. Since I don't use a script to answer the requests and instead use the 1-click Short Codes this creates more work for me. Nobody (talk) 06:47, 1 June 2024 (UTC)

Prevent users from adding middle fingers in user space

Per subject, personally I feel that middle finger emoji is inappropriate Wikipedia itself, noting how it is often used for talk page vandalism, I suggest here after a talk that filter 680 (or any other appropriate filter) should block middle finger emojis (and potentially other emojis being added by non-autoconfirmed/IP) from userspace, not just mainspace. ABG (Talk/Report any mistakes here) 01:24, 8 May 2024 (UTC)

I recommend adding it to 1053 (hist · log) and have a possible filter change, if any EFM wants to take a look mail me. Nobody (talk) 06:53, 8 May 2024 (UTC)
@1AmNobody24: Is this what you had in mind? Suffusion of Yellow (talk) 21:52, 12 May 2024 (UTC)
@Suffusion of Yellow Not exactly, sent you a mail. Nobody (talk) 05:14, 13 May 2024 (UTC)
I've added this condition to filter 53; it'll flag edits that add this emoji to any namespace. ~Oshwah~(talk) (contribs) 01:59, 2 June 2024 (UTC)

Set filter 1311 to disallow?

Should be self explanatory. Private really means private here. Please do not even allude to what it's doing. Suffusion of Yellow (talk) 20:14, 2 June 2024 (UTC)

Looks fine, but needs very close monitoring (trying to be highly vague here, but I agree it's best to have this on disallow). EggRoll97 (talk) 21:54, 2 June 2024 (UTC)
Support disallow, was going to be a neutral but then I read up on who LTA 1311 is --DannyS712 (talk) 02:19, 4 June 2024 (UTC)
I'm not sure disallow is the best option. I would like to maximize the chances that it will continue to work for a long while. Daniel Quinlan (talk) 00:17, 6 June 2024 (UTC)
Edited my previous comment for clarity. Daniel Quinlan (talk) 20:04, 6 June 2024 (UTC)

Do you think this warrants a filter?

A new account suspiciously added 10 thousand bytes (my removal) of an invisible character to one of the templates at ANI when they made a reply. They also added them to their userpage just before that.
I know this is probably crafty vandalism that only happens once in a while, if at all, but I don't think there's any legitimate reason that anyone would want to add more than a handful of invisible characters (if any invisible characters at all). – 2804:F14:80BE:B501:C033:1C2F:5D84:A79C (talk) 07:52, 6 June 2024 (UTC)

This looks like it could also benefit from a software fix. I've filed private ticket phab:T366777. –Novem Linguae (talk) 08:59, 6 June 2024 (UTC)
That user was blocked indefinitely by Spicy as a sockpuppet. Codename Noreste 🤔 Talk 03:50, 7 June 2024 (UTC)
Clarification: by that user, Codename Noreste meant the vandalizing user, not the IP posting the request. – PharyngealImplosive7 (talk) 06:28, 7 June 2024 (UTC)

Requesting Edit filter helper rights

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Sakura emad (t · th · c · del · cross-wiki · SUL · edit counter · pages created (xtools · sigma) · non-automated edits · BLP edits · undos · manual reverts · rollbacks · logs (blocks · rights · moves) · rfar · spi · cci) (assign permissions)(acc · ap · ev · fm · mms · npr · pm · pc · rb · te)

Hi,
I am requesting Edit Filter Helper rights to aid in expanding and enhancing the quality and experience of AbuseFilter on the CKB Wikipedia.
I aim to learn from the English Wikipedia's approach to improve ckbwiki's filters and its effectiveness. also i have a good understanding of account security. and as an extended confirmed editor and reviewer on the English Wikipedia, I believe that i have sufficient English understanding and proficiency.
Additionally, I am an interface-admin and sysop on ckbwiki and hold various rights across multiple WMF projects, demonstrating my trustworthiness and capability.
Thanks —— 🌸 Sakura emad 💖 (talk) 05:47, 1 June 2024 (UTC)

QuestionNeutral You've satisfied the bar (probably?) for trust. I'm more interested on if you'd be able to elaborate on your working with filters on your homewiki. I've tried to check for your contributions to filters over there, but everything about the AbuseFilter is locked down on CKB, and so it's pretty hard to examine any work you've done with filters without being in the GAFH usergroup. Your rights on CKBwiki are currently sysop and interface admin, the latter of which doesn't relate to the AbuseFilter extension on CKBwiki (Another group, "Interface editors", appears to be the local equivalent of non-admin edit filter manager on CKB?), and the former of which doesn't necessarily indicate work with the edit filter by default. EggRoll97 (talk) 07:25, 1 June 2024 (UTC)
Correction, only admins on ckbwiki can modify filters, based on looking at the ListGroupRights special page over there. Codename Noreste 🤔 La Suma 20:44, 1 June 2024 (UTC)
As far as I can tell, the abusefilter-modify right is available to interface editors (not interface administrators, despite the commonality of naming) as well as admins. EggRoll97 (talk) 18:56, 2 June 2024 (UTC)
  • To provide some input and context: I was approached by Sakura about some of our edit filters on the Wikipedia Community Discord (which is off-wiki). Her original request to me was for the regex code for the private edit filters that I created and manage (51, 53). Obviously, that didn't and really can't happen. The conditions and methods I use in those filters to efficiently identify and tag abuse would be significantly compromised if any of the regex code were to fall into the wrong hands. I do trust Sakura emad and I do believe that she is doing this to try and improve the chb-wiki's filter rules. But, as you all know, if a mistake or mishandling of the code were to occur (such as accidentally being made public in a change, etc), you can't "get the cat back into the bag once set loose". Hence, I suggested she gather demonstrable experience from her contributions and create a request for edit filter helper instead. When I asked Sakura on the wiki discord about her level of experience with regex and with modifying filter rules, she responded, "i [sic] send most of them to https://ckb.wikipedia.org/wiki/user:aram [sic]" and that "he is ckb technican". I was able to review the edit filters on the ckb-wiki as well as her level of involvement with them, and her contributions don't show much in that manner. Since I was approached by her off-wiki (Wikipedia Community Discord), I'm just going to add the information and facts about this request. I hope the information I provided is useful either way. ~Oshwah~(talk) (contribs) 02:23, 2 June 2024 (UTC)
Have you tried asking for the contents of individual private filters? Are there any specific filters in your mind? I also note that I can't view the logs for abuse filters on ckbwiki without being confirmed. 0xDeadbeef→∞ (talk to me) 10:44, 1 June 2024 (UTC)
0xDeadbeef- EggRoll97, I've learned quite a few things from my experiences on the English and Simple Wikipedia. My adminship, particularly on Simple Wikipedia, has been crucial in shaping the admin I am today. Most of my experiences i've got came from these wikis, and the admins that helped me. even my global rollback right came from the experience of fighting and preventing vandalism on simplewiki. Given this background, it's clear that much of what I've learned did not come from ckbwiki alone. I believe that learning from the English Wikipedia’s approach to edit filters will greatly enhance my ability to improve and work on the current abusefilter on ckbwiki. I am committed to respect and responsibly use the rights I am granted.
I have reviewed WP:EFH, especially the WP:EFHCRITERIA and the "Common use cases" on that page. I meet the requirements and specifically fit the second case under common use cases, as someone working with edit filters on another WMF wiki who wants to learn from the English Wikipedia's experience and approach.
Thanks —— 🌸 Sakura emad 💖 (talk) 16:32, 1 June 2024 (UTC)
You don't have adminship on Simple, as far as I can tell...you have rollback, but that is far from any work with the AbuseFilter outside of CKBwiki, which you still have yet to elaborate on your work regarding. EggRoll97 (talk) 20:22, 1 June 2024 (UTC)
EggRoll97, let me clarify-; What I meant is that if it were not for my experiences on simplewiki in dealing with vandalism, deletion requests, etc. i wouldn't be the admin i am today on ckbwiki. Of course, it is obvious that I am not an admin on simplewiki my global status is already in public knowledge. —— 🌸 Sakura emad 💖 (talk) 06:08, 2 June 2024 (UTC)
I think EggRol97 is asking you to talk about what you have used the abuse filter for in CKBwiki itself, so could you elaborate on that? – PharyngealImplosive7 (talk) 21:59, 3 June 2024 (UTC)
Sakura emad, do you also intend to help with filters on enwiki, now that you work with filters on ckbwiki as an administrator over there? I'm also curious about your regex knowledge in relation to edit filters here and there. Codename Noreste 🤔 La Suma 17:11, 1 June 2024 (UTC)
Codename Noreste, Yes i would love to, actually. But i believe that i have to gain more experience first. Then I'd be happy to contribute on both WMF projects.
Thanks —— 🌸 Sakura emad 💖 (talk) 06:24, 2 June 2024 (UTC)
However, based on what Oshwah said in this context, it's pretty clear that you should gain much more experience with edit filters here, as well as your edit count. There are the public filters in which you can help here, and I'm not sure if your need requires access to private filters, in which most of those filters are private because of specific LTAs on this project, and some are hidden as well because the logs can contain personal information and/or other stuff that should not be made public. So because of ER97 and Ingenuity, I'm gonna have to oppose your EFH request at this time. Sorry. Codename Noreste 🤔 La Suma 18:59, 2 June 2024 (UTC)
Ingenuity - I just added some information and context in this discussion that will answer your question. ~Oshwah~(talk) (contribs) 02:33, 2 June 2024 (UTC)
  • Oppose Based on the information given by Oshwah through off-wiki contact, I don't have much confidence that the requestor is actively involved with edit filter work on their homewiki. EggRoll97 (talk) 03:10, 2 June 2024 (UTC)
    • EggRoll97, I understand the concern about my activity level with edit filters. I am working on them actually, but my limited experience and knowledge mean my contributions might not be as visible as expected of me yet. as you know Abusefilters are highly sensitive matter, and i just can't make changes for learning or experimentation. That's why my activity might not appear as high, but i do work on them on ckbwiki to the best of my current abilities. —— 🌸 Sakura emad 💖 (talk) 06:45, 2 June 2024 (UTC)
      • Much of the problem is that we can't see your contributions to CKBwiki's edit filters, and even if you were to post the logs publicly, it wouldn't be verifiable since it's not the actual logs themselves. A lot of it as well is that you still haven't elaborated either here or to the mailing list (which only contains EFH/EFM/sysops and where you could easily disclose any private filter contributions on CKBwiki that might not be best to post publicly) about your work on edit filters. Further, having seen the edit filters you requested from Oshwah, the contents of those filters are extremely sensitive to any type of outside access, and so are a lot of the other private filters, with one of them being traditionally information that would be oversighted if it wasn't a private filter. EggRoll97 (talk) 18:55, 2 June 2024 (UTC)
        • EggRoll97, are you suggesting that my request for 'extremely sensitive' filters implies an intention to harm the community? Out of the 54 abuse filters on ckbwiki, 10 are under my name. I need this right specifically to improve the quality of abuse filters on ckbwiki and contribute to them effectively. My account age is almost 4 years. Also regardless of contributions and Group-rights promotions i've received on ckb, please check CentralAuth—my home wiki is not ckbwiki, it is Enwiki.
          Oshwah failed to mention that I asked for 3 filters back then; I didn't specifically ask for his filters, but because he was the only admin I reached out to, 2 of the 3 filters were his. The reason I asked for the filters that Oshwah made was purely for improvement and gaining experience, since they were the only private filters at the time that I thought ckbwiki didn't have and that I needed to learn from, for the benefit of both projects in the future. Do you think Oshwah would have assisted me with the requesting procedure if he didn't trust me with abuse filters? —— 🌸 Sakura emad 💖 (talk) 20:30, 2 June 2024 (UTC)
          Before requesting anything, I carefully examined the vital details of Wikipedia:Edit filter helper and only requested this right after I fully understood that I meet the requirements mentioned and that I'm fit for the position. Reading "Those working with edit filters on another WMF wiki who want to learn from the English Wikipedia's experience," I believe I did what I was guided to do. These opposes are unexpected for me since I don't know what regulations or rules I broke. —— 🌸 Sakura emad 💖 (talk) 20:30, 2 June 2024 (UTC)
          • I suggested nothing of the sort. See WP:EFHCRITERIA, This is a highly specialized right that is routinely denied even to experienced editors...Meeting all the above criteria does not guarantee a request will obtain consensus support to pass, and I don't believe you have a demonstrated need currently to see private filters. EggRoll97 (talk) 22:05, 2 June 2024 (UTC)
            • EggRoll97, I believe I have repeatedly stated that I am working on improving the quality of ckbwiki abusefilters. If this doesn't demonstrate my commitment, then what else does?, however, it seems, Showing demonstration does not necessarily equate to being seen as one. —— 🌸 Sakura emad 💖 (talk) 04:54, 3 June 2024 (UTC)
              • You have stated that, yes, but the modification log for CKBwiki's filters is hidden to almost everyone here, and your only specific comment about your work on them is what you said to Oshwah, which is that you send fixes to someone else. So all we really have to go on here is your own word. EggRoll97 (talk) 18:46, 3 June 2024 (UTC)
  • Oppose per EggRoll. I also don't really see why access to private filters is needed. —Ingenuity (t • c) 14:33, 2 June 2024 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Request to remove a user from filter 856's line 8

Please remove Vami IV from filter 856's line 8 (copyvio clerks) because that user has passed away. Thank you. Codename Noreste 🤔 Talk 19:06, 8 June 2024 (UTC)

 Done -- zzuuzz (talk) 19:58, 8 June 2024 (UTC)
Did other cleanup there, the current list of names is useless, and the group is really the right way to handle that anyway. — xaosflux Talk 12:20, 10 June 2024 (UTC)

Request to change line 4 of filter 98

98 (hist · log) (Creating very short new article, public)

Per Wikipedia:Edit filter/Traps and pitfalls#user_rights, I would suggest changing !"extendedconfirmed" in user_rights & on line 4 with !contains_any(user_groups, "extendedconfirmed", "sysop", "bot") & because of this: but this will not work as expected if the user did not grant editprotected when setting up a bot password.. user_rights may be limited if the user has logged in using a bot password, or is editing with an OAuth application. Thank you. Codename Noreste 🤔 Talk 00:41, 21 June 2024 (UTC)

@Codename Noreste  Done, nice catch: Special:AbuseFilter/history/98/diff/prev/32847 --DannyS712 (talk) 00:57, 21 June 2024 (UTC)

Error when saving filters

Heads up: as of last WP:THURSDAY attempting to save certain filters will give you a Fatal exception of type "MediaWiki\Extension\AbuseFilter\Parser\Exception\UserVisibleException". See the task for details. If you need to disable a filter and can't wait for the problem to be fixed, just blank and disable it, but remember you won't be able to restore the old version until the bug is fixed. Suffusion of Yellow (talk) 01:36, 24 June 2024 (UTC)

A quick thought: Should WP:EFM be a page instead of a section?

I've wondered for a while whether WP:EFM should be an actual page (similar to WP:EFH), rather than just a section on the edit filter page. Does anyone have any thoughts about whether this might break WP:CREEP, or whether this might be beneficial? EggRoll97 (talk) 01:34, 20 June 2024 (UTC)

At this point, yea - I've been meaning to do it forever and just kept putting it off. Feel free to draft something modeled on Wikipedia:Edit filter helper. — xaosflux Talk 02:06, 20 June 2024 (UTC)
I don't object to this thought at all, but it's also worth noting that administrators can only modify edit filters that use restricted actions, as well as being able to enable such actions on filters. Codename Noreste 🤔 Talk 03:34, 20 June 2024 (UTC)
Will do, though functionally the only restricted action is block-autopromote, which hasn't been used in over a decade, and would likely need multiple discussions to just have a single filter with it enabled anyways. EggRoll97 (talk) 21:31, 20 June 2024 (UTC)
@Xaosflux and Codename Noreste: Thoughts on what I've whipped up currently at Wikipedia:Edit filter manager? EggRoll97 (talk) 23:50, 20 June 2024 (UTC)
@EggRoll97 the revocation criteria prob need work, as it is generally not appropriate for admins to just remove this from other admins, as opposed to the non-admin EFMs. — xaosflux Talk 23:59, 20 June 2024 (UTC)
If this is going to contain any changes from the current content that are meaningful, like criteria for revocation, we should have a slightly more formal discussion/approval of the changes. E.g. "The editor has failed to report to an administrator after noticing unauthorized use of their account..." - if I were ever to notice unauthorized use of my account, I don't think I would be reporting it to admins on each wiki I have advanced rights. I would change my passwords and probably mention it to stewards, perform a crosswiki audit of every action performed recently, and likely reach out to the WMF security team since I have 2FA and would be curious how someone had bypassed it, but why do I need to tell an enwiki admin if when compromised the account didn't make any changes on enwiki? --DannyS712 (talk) 01:00, 21 June 2024 (UTC)
Also "If a previous application for edit filter manager or edit filter helper was unsuccessful" - I think I had an unsuccessful EFH request before I was granted it, but when I applied for EFM this currently suggests that I should have pinged the participants of the successful EFH discussion. I.e. I should have told the people at Special:Permalink/909783210#EFH for DannyS712 (2) about my EFM request, which would feel like canvassing to me. --DannyS712 (talk) 01:03, 21 June 2024 (UTC)
@DannyS712: I've removed the "edit filter helper" bit currently, that was just a copy direct from WP:EFH, I thought I took out the helper one. The intention was only to require notification about prior EFM requests. As for the account security language, I'm pretty sure that's just the standard language, but I don't see much reason for it to be in there honestly. It was just part of EFH and so got copied over. EggRoll97 (talk) 01:55, 21 June 2024 (UTC)
@Xaosflux: I should ask, why would removal of this right from an admin not be considered appropriate? Admins are able to self-grant, so their granting of edit filter manager rights isn't subject to a community process in the same manner as non-admin EFMs (they are given adminship at RfA, though that doesn't necessarily assess technical ability unless the admin is running on being a tech-admin). I'd actually think it should be easier to remove from an admin, considering it would be trivially easy to regrant (just a talk page discussion between the revoking admin and the revokee), compared to the process to re-grant to a non-admin (a formal request to WP:EFN, requiring the action of an admin to re-grant). EggRoll97 (talk) 01:55, 21 June 2024 (UTC)
Short answer, sanctioning admins is always a "big deal". — xaosflux Talk 09:35, 21 June 2024 (UTC)
@EggRoll97: I'm seeing a lot of WP:CREEP in there. For example, it's never been a convention that disabling a filter, or changing it from disallow to log-only requires discussion. Sometimes, the meme dies a natural death, or the LTA gets bored, and a discussion will be the very thing that brings them back. I think any new rules for EFMs should be in response to some problem that's actually happened, not a problem that might happen. Suffusion of Yellow (talk) 21:42, 23 June 2024 (UTC)
@Suffusion of Yellow: Yeah...I may have just gone on a bit when trying to start as detailed as possible. Removed, it doesn't make much sense in hindsight. EggRoll97 (talk) 00:42, 24 June 2024 (UTC)
Thanks. Suffusion of Yellow (talk) 01:07, 24 June 2024 (UTC)
Tonight I made a couple edits to WP:EFH and WP:EFM that reduce WP:CREEP. We had a couple very detailed procedures for things that almost never happen, so I deleted those sections or changed them to a couple sentences. Hope it helps. –Novem Linguae (talk) 04:12, 24 June 2024 (UTC)
@Novem Linguae: In Special:Diff/1230686585, should say edit filter helper, right? – 2804:F14:80BA:C801:4029:C761:8E13:F724 (talk) 22:17, 24 June 2024 (UTC)
Yes. Fixed now. Thanks for alerting me. –Novem Linguae (talk) 23:21, 24 June 2024 (UTC)

Set 365 To Warn?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


365 unusual changes to featured or good content i think to warn 51.235.113.220 (talk) 07:09, 8 July 2024 (UTC)

What's the point of requesting changes to random filters and at the same time being disruptive elsewhere (in filter logs and edits)? This is the third time I've seen you do this (1st, 2nd), and while the second one resulted in a filter being set to disallow, your disruption does not seem worth it. – 2804:F1...13:E752 (talk) 08:23, 8 July 2024 (UTC)
Oppose I see no good reason for this change. Nobody (talk) 08:58, 8 July 2024 (UTC)
Oppose: no good reason provided. – PharyngealImplosive7 (talk) 14:18, 8 July 2024 (UTC)
Strong oppose per everyone, no reason was provided. Codename Noreste 🤔 Talk 13:28, 9 July 2024 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Marking 491 Private

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Why 491 as public i think 491 private 128.234.122.41 (talk) 10:51, 15 July 2024 (UTC)

This post seems a bit low effort. Care to elaborate on why you'd like this changed? –Novem Linguae (talk) 11:10, 15 July 2024 (UTC)
Oppose The filters name already says why the edits are disallowed so hiding how the filter works isn't helpful nor is there any private information in the filter that makes it required. Nobody (talk) 11:12, 15 July 2024 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Wikipedia:Edit filter manager has an RfC for possible consensus. A discussion is taking place. If you would like to participate in the discussion, you are invited to add your comments on the discussion page. Thank you. EggRoll97 (talk) 19:03, 6 July 2024 (UTC)

Should global abuse filter helpers have access to the private filter mailing list?

Just another thought today, but because global abuse filter helpers can view every single filter on every project (whether public or private) including the English Wikipedia, I was wondering if we could at least give them access to the edit filter mailing list on lists.wikimedia.org. They might share some other private (including LTA) filters from other wikis, including non-content projects such as Meta. Codename Noreste 🤔 Talk 17:58, 6 July 2024 (UTC)

If they request it, I see no problems, but as far as I know they usually don't. EggRoll97 (talk) 20:07, 6 July 2024 (UTC)

Set 491 to disallow

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


I think 491 end ! To disallow 128.234.101.4 (talk) 10:23, 4 July 2024 (UTC)

Wouldn't be against it, though warn seems to already be working fairly well. Basically, I see the technical accuracy, but not the necessity of setting it to disallow. EggRoll97 (talk) 20:36, 4 July 2024 (UTC)
I would support disallow in this case, as it seems to be doing its job pretty well and we want this junk out of our articles. – PharyngealImplosive7 (talk) 01:15, 6 July 2024 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Edit filter 53

I'm just sending an FYI that one of my updates to this filter accidentally added a | at the very end of one of the string variables (it causes ALL edits to be flagged as a hit). It was caught and fixed two minutes later. Any false positive notifications regarding this filter can be closed as 'resolved'. ~Oshwah~(talk) (contribs) 12:35, 6 July 2024 (UTC)

And that, fellow users, is why EFMs are recommended to test their updates thoroughly before implementing said updates to any filter. There is the test interface in which admins, edit filter helpers and managers can access, or there's User:Suffusion of Yellow/batchtest-plus but you still need the same permissions to access that interface, just so that you can also use that script. Codename Noreste 🤔 Talk 16:55, 6 July 2024 (UTC)
Perhaps if it weren't for my sudden curiosity about such edit filters, this could have gone unnoticed.102.159.221.21 (talk) 04:50, 12 July 2024 (UTC)

Edit filter helper for Codename Noreste (third nomination)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.



Codename Noreste (t · th · c · del · cross-wiki · SUL · edit counter · pages created (xtools · sigma) · non-automated edits · BLP edits · undos · manual reverts · rollbacks · logs (blocks · rights · moves) · rfar · spi · cci) (assign permissions)(acc · ap · ev · fm · mms · npr · pm · pc · rb · te)
The earliest closure has started. (refresh)

Hello, everyone. This has been a few months after my failed nomination back in February, but after I have addressed your concerns seriously, I am requesting the edit filter helper right again. But this time, I now intend to assist with writing filters using my basic knowledge of regular expressions.

I have proposed additions to filter 936 (hist · log) (implemented by Suffusion of Yellow via email), and I have written and requested updates on 1292 (hist · log) (a global filter that tracks 1292's target was implemented on Meta as 344 (Meta admins only)) and 1308 (hist · log) (both filters are maintained by Ingenuity except the global filter, in which that global filter is maintained by SHB2000 on Meta), and 1313 (hist · log). Given these filters' sensitive detection strategies, I do not intend to discuss their details on public or outside of the edit filter mailing list.

With respect to account security and nonpublic information, I use a strong password and have 2FA enabled on my main account, and I have signed the confidentiality agreement for nonpublic information (verify).

Thank you for your consideration. Codename Noreste 🤔 Talk 03:48, 6 July 2024 (UTC)

Discussion

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

EFH nomination for PharyngealImplosive7 (second nomination)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


PharyngealImplosive7 (t · th · c · del · cross-wiki · SUL · edit counter · pages created (xtools · sigma) · non-automated edits · BLP edits · undos · manual reverts · rollbacks · logs (blocks · rights · moves) · rfar · spi · cci) (assign permissions)(acc · ap · ev · fm · mms · npr · pm · pc · rb · te)
Link to my previous nomination (withdrawn).
Pinging the admin who closed the last nomination: @0xDeadbeef.
The earliest closure has started. (refresh)

Hello everyone. Back in February, I had my last self-nom for EFH. I was relatively new in general, and even newer to the edit filter space. As I've reflected on that failed nomination, I've tried to take in to account your feedback and I think that now I have a much more solid nomination.

First of all, I have made about ~1100 edits to WP:EFFPR, and have tried to be as cautious as possible while clerking all reports, private and not. (as can be seen on xtools: [2]). I also have made numerous contributions to filters, such as helping to create the private filter 1313 (hist · log) (courtesy ping to @Codename Noreste to our conversation over email, before he sent the code we made together to the mailing list for further improvements), as well as the public filter 1298 (hist · log). I also helped create some regex for the private filter 1161 (hist · log) (to enforce WP:DADASAHEB). I've also made quite a few minor improvements to filters 54 (hist · log), 614 (hist · log), and a few others, but they all help catch unwanted edits that wouldn't have been otherwise. I believe that these examples can show that I have enough experience in regex that I can help author filters on this wiki.

I know the responsibility of this user right and know the sensitivity of private filters. As a result, if I gain this permission, I will only discuss information about private filters on the mailing list. I also care a lot about security, and although I don't have 2FA enabled, I do have a strong password, so I think that is highly unlikely that my account will be compromised. I also have signed the access to nonpublic information agreement (verify).

I thank everyone for their participation and feedback last time, as it helped me get a better sense for the gravity of this permission. Thank you in advance. – PharyngealImplosive7 (talk) 23:40, 7 July 2024 (UTC)

Support

Oppose

  • Oppose I've read over your work, but I'm also not really seeing the need either. Your hit on the mailing list wasn't bad, but ultimately the filter Codename Noreste proposed was fleshed out, while your proposal (at least as seen in the mailing list) was a single line of regex. At the current time, I'm not seeing the need. I wasn't sure whether I should chime in, but frankly 0xDeadbeef's neutral has swayed me away enough from neutrality to chime in here. EggRoll97 (talk) 21:00, 13 July 2024 (UTC)
    I understand your point of view. If I may, could I send you an email with some RegEx showing a more concrete understanding? It's a meta LTA filter that I added more sophisticated lines of code. – PharyngealImplosive7 (talk) 21:47, 13 July 2024 (UTC)
    And its sent. – PharyngealImplosive7 (talk) 21:48, 13 July 2024 (UTC)
    In the interest of transparency, I disclose on-wiki that I have received your email, which contains the contents described in the above comment, and have read such email. As for my response, since it doesn't contain any sensitive information, that filter is a meta-wiki filter, and doesn't necessarily show work towards enwiki's filters. I'm sure it would be great if you were running for Meta adminship, or GAFH, but I should have been clearer. I was moreso referring to your work with edit filters on enwiki, not necessarily on Meta. EggRoll97 (talk) 03:24, 14 July 2024 (UTC)

Neutral

Discussion

  1. Have you sent private filter regex updates to the mailing list or to an EFM?
  2. Do you intend to create a private filter that you can send to an EFM or to the mailing list?

If so, please explain them in a non-beansy manner. Thank you. Codename Noreste 🤔 Talk 00:01, 8 July 2024 (UTC)

1. No. I have not besides for 1313. I only helped create thee other private filter I worked on, 1161. However, I do plan to do so in the future.
2. Yes in fact! I have a few ideas kicking around in my head, but my most developed one is for BBB. – PharyngealImplosive7 (talk) 00:20, 8 July 2024 (UTC)
There are already some filters trying to track what you said in number 2, and that's all what I'm allowed to say in public. Codename Noreste 🤔 Talk 16:53, 13 July 2024 (UTC)
Ok thanks for letting me know. – PharyngealImplosive7 (talk) 17:04, 13 July 2024 (UTC)
  • If you're willing to share, is there any specific reason you don't have 2FA enabled? While it's not a requirement for EFH (and isn't a formal requirement outside of interface admins), I'm curious to know if there's a reason, or if it's just that you haven't necessarily turned it on (I'm aware it's not available unless a steward activates the global group). EggRoll97 (talk) 18:05, 8 July 2024 (UTC)
    Yeah. I just haven't turned it on, because I haven't asked a steward yet to enable it. I don't really have a specific reason besides that I haven't done it yet, though if I get sesnitive perms like this one, I'll think about enabling it. – PharyngealImplosive7 (talk) 18:17, 8 July 2024 (UTC)
  • I am counting at least two supports, one neutral and one objection -- would an uninvolved administrator close this discussion please? Codename Noreste 🤔 Talk 16:06, 16 July 2024 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Racist term that needs blacklisting

Coming here from Wikipedia:Administrators' noticeboard/Incidents#Racist comments by IP user. Asking for the blacklisting/filtering of wikt:pajeet/wikt:poojeet, a highly offensive racist slur that has seen a surge in usage in recent times. Appears to be used by trolls and bad-faith editors/IP users.

A suggestion for an addition to Special:AbuseFilter/384, has been made at the ANI thread above. Gotitbro (talk) 14:44, 1 August 2024 (UTC)

That is quite easy to fix. Just add \bp(?:a|o{2})je{2}t\b to the end of the regex. – PharyngealImplosive7 (talk) 23:44, 2 August 2024 (UTC)
384 only covers the main namespace (articles); we could add it to 478 (hist · log) for the talk page namespace or similar. Codename Noreste 🤔 Talk 01:23, 3 August 2024 (UTC)
I share the same concerns as the admins at the ANI thread, personally. The edits are fairly stale and aren't very active disruption. EggRoll97 (talk) 04:54, 3 August 2024 (UTC)
I don't think it matters, since these are spread over several months, and there is no evidence that a single user is responsible for most of these. –LaundryPizza03 (d) 04:25, 4 August 2024 (UTC)

Page protection

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


I protected Wikipedia:Edit filter/False positives/Reports for 1 day 3 hours due to persistent vandalism from multiple accounts. Ohnoitsjamie and other administrators, please feel free to lift the protection earlier at your discretion. Daniel Quinlan (talk) 03:26, 8 July 2024 (UTC)

Good protection, but it looks like these diffs (Special:Diff/1233248166, Special:Diff/1233232866, Special:Diff/1233232682, and others with more than 100,000 text bytes added) will need to be revision-deleted because of disruptive Zalgo text. Codename Noreste 🤔 Talk 03:46, 8 July 2024 (UTC)
Done. Daniel Quinlan (talk) 04:40, 8 July 2024 (UTC)

Not the same person this time, but I'd just like to make people aware (I probably don't need to, tbh, but just making sure) that @JJMC89 has protected EFFPR for 48 hours. – 2804:F14:8084:CE01:9034:B5CB:942A:939E (talk) 20:43, 1 August 2024 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Set filter 1319 to disallow

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


This is a request that this filter be set to disallow. See filter notes, but please do NOT discuss this publicly. I can explain through the mailing list or individual email if needed. EggRoll97 (talk) 04:57, 3 August 2024 (UTC)

I've fixed one problem. There seems to be another problem at the end of line 4. I'm still trying to parse the rest of it. -- zzuuzz (talk) 07:30, 3 August 2024 (UTC)
I disagree with setting this to disallow. I've sent the reasons to a new thread on the mailing list. 0xDeadbeef→∞ (talk to me) 15:14, 3 August 2024 (UTC)
I'm not a list member, but I think sometimes there's a time and a place. Other than that, no strong opinions about it. Anyway, I've edited the filter to address the concern I previously had. It has changed the meaning, so please review. It still needs some work methinks. -- zzuuzz (talk) 18:30, 3 August 2024 (UTC)
I'll withdraw this based on the discussion on the mailing list. zzuuzz, I've indicated in a filter note the problem mentioned on the mailing list. With that in mind, probably fine to keep this as log-only. The edit you made seems fine from a glance. EggRoll97 (talk) 19:54, 3 August 2024 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Set filter 707 to disallow?

707 (hist · log) (EFFPR disruption, public)

Per the recent hits, it's working great, and we need to stop this type of disruption on that page. Also, check that filter's notes. Codename Noreste 🤔 Talk 06:45, 25 July 2024 (UTC)

No objections, though probably best to put in a custom edit notice to re-target to the edit filter noticeboard instead since it targets the EFFPR page, something like:
This perhaps? EggRoll97 (talk) 21:16, 25 July 2024 (UTC)
If we plan to use your proposed disallow message, it should be made on MediaWiki:Abusefilter-disallowed-EFFPR by an admin; alternatively, we could use the default disallow message, but users would click on the Report error button because there's a button to press, and would lead to pointless reports of people begging for help on WP:EFFPR. Also, I believe the word disruption is probably more accurate than vandalism, since filters 768 and 984 use the former word, but not 707. Codename Noreste 🤔 Talk 21:34, 25 July 2024 (UTC)

Here's the new disallow message code if anyone's interested:

{{edit filter warning
| action   = disallow
| text     = <div style="text-align: center;">An automated filter has identified this edit as potentially unconstructive. Please be aware that [[Wikipedia:Vandalism|vandalism]] will result in [[Wikipedia:Blocking policy|revocation of your editing privileges]]. If this edit was disallowed in error, please make a new section on the same page you were editing.</div>
| fplink   = no
}}

Codename Noreste 🤔 Talk 21:36, 25 July 2024 (UTC)

Based on the IP's comments below, we could simply direct to leave a new section on the false positives page, but without the report error button featured in the default disallow message, making the message, An automated filter has identified this edit as potentially unconstructive. Please be aware that vandalism may result in revocation of your editing privileges. If this edit was disallowed in error, please make a new section on the same page you were editing. I don't think there really needs to be a report error button since the filter is very narrowly targeted and shouldn't have any false positives. Also, Codename Noreste, I've BOLDly changed the filter description to "disruption" instead. Doesn't seem like that big of a deal whether it's referred to as vandalism or disruption, but who knows. EggRoll97 (talk) 03:00, 26 July 2024 (UTC)
Feel free to modify the message code I posted and the proposed disallow message to reflect what you said, and about changing from vandalism to disruption, I'm not sure how to describe 707 in public, but it catches more than just vandalism obviously. Codename Noreste 🤔 Talk 03:03, 26 July 2024 (UTC) (I modified it anyway) -- Codename Noreste
Obviously private, but is reporting false positives about this at EFFPR even a problem? Is it actually going to set off the filter too? – 2804:F1...E9:11BA (talk) 00:25, 26 July 2024 (UTC)
Reporting false positives will not trigger the filter. Codename Noreste 🤔 Talk 00:30, 26 July 2024 (UTC)
I think If this edit was disallowed in error, please leave a message on the edit filter noticeboard should point to WP:EFFPR, not EFN. –Novem Linguae (talk) 03:05, 26 July 2024 (UTC)
I modified the message to reflect this, but I took out the big warning thing. Codename Noreste 🤔 Talk 03:11, 26 July 2024 (UTC)
Yeah, that looks good. EggRoll97 (talk) 03:12, 26 July 2024 (UTC)
Minor change, but "may be blocked" sounds a little soft, so I'm modifying the notice to say "will" instead of "may". – PharyngealImplosive7 (talk) 02:55, 27 July 2024 (UTC)
 Done MediaWiki page creation requested, and I'll toggle the disallow as soon as an admin makes the page. EggRoll97 (talk) 15:34, 27 July 2024 (UTC)
I've created the page. I have two observations. First, does this need to be private? I'm not aware of any private-type issues, but I haven't looked far. Second, there's a boolean condition which is 'true and true or true'. The precedence is probably written up somewhere, but I find non-parenthesised conditions like this highly confusing and subject to errors. Maybe clarify the intention? -- zzuuzz (talk) 16:30, 27 July 2024 (UTC)
@Zzuuzz: I'm actually not sure if it needs to be private. It was private on the initial iteration, so I didn't change the visibility when re-enabling. No objections to publicizing, though. As for the boolean condition, it seems to be parenthesized, but I woke up fairly early today so I'm not sure if I'm looking in the same place that you are. EggRoll97 (talk) 16:46, 27 July 2024 (UTC)
I think we're looking at the same thing, but I probably wasn't clear. Let's have an example: (year == 2024 and month == 7 or day = "Saturday"). It's difficult to know what this means. Maybe the year needs to be 2024, or it can be any Saturday? The documentation says not. In fact I'll quote the documentation: A & B | C is equivalent to (A & B) | C, not to A & (B | C). In particular, both false & true | true and false & false | true evaluates to true. Complicated huh. Compare to: ((year == 2024 and month == 7) or day == "Saturday") or perhaps (year == 2024 and (month == 7 or day == "Saturday")) (and it can get really complicated when people start adding more conditions). -- zzuuzz (talk) 17:31, 27 July 2024 (UTC)
Agreed. Always use parentheses with boolean algebra. For readability. –Novem Linguae (talk) 17:50, 27 July 2024 (UTC)
I've even confused myself above. It can be any Saturday. It certainly is one today.. -- zzuuzz (talk) 18:03, 27 July 2024 (UTC)
What lines of filter 707 was this starting the boolean problem? Codename Noreste 🤔 Talk 18:18, 27 July 2024 (UTC)
@Zzuuzz: Assuming you're referring to lines 15-19 (I've now unhidden the filter, because it shouldn't be catching much more than drive-by vandals), I think the fix would just be (new_size < 300 & old_size > 300 & edit_delta < -250) &. EggRoll97 (talk) 18:34, 27 July 2024 (UTC)
I have no objections to 707 being public, but after testing the new code, this doesn't seem to catch the blanking disruption, rather just header removal disruption. Also pinging PharyngealImplosive7 since 707 is already unhidden. Codename Noreste 🤔 Talk 18:39, 27 July 2024 (UTC)

I think that we should make a modification to this filter. It's working great so far except in one place, when users remove their own false positive report (see this catch for example). The user was just removing their own report. Maybe we could add this condition to new_size < 300 & old_size > 300 | edit_delta < -250:

!(removed_lines irlike "\={2}\s*" +  user_unnamed_ip + "\s*\={2}") & 
!(removed_lines irlike "\={2}\s*" +  user_name + "\s*\={2}")

to fix this (which should exclude people from removing their own reports). – PharyngealImplosive7 (talk) 19:05, 27 July 2024 (UTC)

Do you have any other non-variable condition that checks for IP addresses other than user_unnamed_ip? Codename Noreste 🤔 Talk 20:15, 27 July 2024 (UTC)
No, I don't. If anyone else does I am open to suggestions. – PharyngealImplosive7 (talk) 21:28, 27 July 2024 (UTC)
@EggRoll97: Any progress on adding this to the filter to reduce the amount of FPs? – PharyngealImplosive7 (talk) 23:22, 3 August 2024 (UTC)
I'm not sure this does what you used it for? The wording at mw:Extension:AbuseFilter/Rules format#Protected variables makes me think this variable currently shows the IP and when temporary accounts get enabled it will still show the IP, but you're using it to search if the account name/IP is in the removed lines, which user_name already does for accounts and IPs and presumably will continue to do for temporary account names too.
Not to mention, using it will apparently make the filter permanently protected from being viewed by users who do not have the abusefilter-access-protected-vars permission. – 2804:F1...E6:56E2 (talk) 23:42, 3 August 2024 (UTC)
Hmmm. That's interesting. I don't know what to do then to check for IPs since this doesn't work. – PharyngealImplosive7 (talk) 23:44, 3 August 2024 (UTC)
The second line works for both IPs and accounts, and will also continue to work when temporary accounts are added (I've seen no indication that it won't).
The docs of user_name say it's the IP for IPs. – 2804:F1...E6:56E2 (talk) 00:07, 4 August 2024 (UTC)
Oh thank you for letting me know. I thought that the second line would only work on registered accounts. – PharyngealImplosive7 (talk) 00:15, 4 August 2024 (UTC)
Just recording here that I have seen this, just have been a bit busy lately. I'll review it when I have time, unless another EFM stops by in the meanwhile. EggRoll97 (talk) 02:47, 7 August 2024 (UTC)

CAPTCHA consequence for edit filters

Hello all! I've been keeping an eye on this one for a couple days, but requiring someone to complete a CAPTCHA is finally enabled as an edit filter consequence. The full description is "Require the user to complete a CAPTCHA in order to proceed with the action. Users with permission to skip a CAPTCHA are exempt." This, of course, means that autoconfirmed users won't be affected by it, but it would require any new and unregistered users who hit a filter to complete a CAPTCHA, meaning it may be a somewhat effective tool at slowing down spambots and IP-only vandals. EggRoll97 (talk) 11:53, 7 August 2024 (UTC)

How about this, for example:
13:25, August 7, 2024: Example triggered filter 1, performing the action "edit" on Wikipedia:Sandbox. Actions taken: Show CAPTCHA; Filter description: General test filter (details | examine | debug)
Instead of showcaptcha, we just say Show CAPTCHA. Also, two questions:
  1. Is enabling CAPTCHA on a filter a restricted action?
  2. Perhaps we can re-enable 271 (hist · log) with this new action? While I'm not going to discuss much about 271 here, I can email you some new code.
Thank you. Codename Noreste 🤔 Talk 17:25, 7 August 2024 (UTC)
I verified that EFM's can enable the captcha consequence without also being admins (see log). — xaosflux Talk 19:31, 7 August 2024 (UTC)

Special:AbuseFilter/957 and disambiguation pages

An anon's attempt to do this edit was disallowed by Special:AbuseFilter/957, designed to stop removal of article lead sections. However, the page in question, NDS, is a disambiguation page, and the edit was merely splitting it into topic-based sections. I believe that disambiguation pages should be excluded from this specific filter. Animal lover |666| 05:47, 14 August 2024 (UTC)

WP:EFFPR may be a good place to report these in the future. –Novem Linguae (talk) 08:49, 14 August 2024 (UTC)
I came here after a report was filed by the anon in question. Animal lover |666| 16:50, 14 August 2024 (UTC)

Recurring Hindi vandalism

There have been edits of Hindi vandalism that have references to violence (including sexual violence) with very similar patterns. These edits, which merit revision deletion, should be disallowed. A new filter may need to be added. I saw a pattern with those recent edits:

This has been recurring for about a year (from one year ago there is Special:AbuseLog/35487610). Eyesnore talk💬 15:09, 4 August 2024 (UTC)

Just to note that's User:Master12112wp. Filter 1231 has some relevant content. -- zzuuzz (talk) 16:51, 4 August 2024 (UTC)
According to the LTA case, filter 1160 (hidden) is mentioned and enabled, but I believe none of the recent edits with changes similar to the one I mentioned triggered that filter. Eyesnore talk💬 17:24, 4 August 2024 (UTC)
There are filters for this LTA, though more EFM eyes are appreciated. fwiw I believe that particular LTA reads internal wiki pages, so it's best to avoid too much discussion in public about them. ProcrastinatingReader (talk) 04:03, 15 August 2024 (UTC)
The mailing list is more recommended for these types of situations, as proc's comment is relevant above. Codename Noreste 🤔 Talk 04:17, 15 August 2024 (UTC)

Set filter 1154 to CAPTCHA?

I think filters similar to 1154 would be suitable to use the new show CAPTCHA function. Opinions? Lordseriouspig 11:28, 14 August 2024 (UTC)

I would think that a CAPTCHA function should only be used when both of the following are true:
  1. There is clear evidence of multiple rounds of bot hits.
  2. The human hits show a false positive rate too high to make the filter set to disallow.
As far as I can tell, from the last 250 hits (this goes back to July 7), the first is not the case here; and I (full disclosure: I'm an Israeli) would find it hard to believe the second. Animal lover |666| 09:38, 15 August 2024 (UTC)

Proposal for 1157 update

1157 catches tagging even if the Template prefix is used, but it fails to catch edits using the TM: alias, the msg: prefix, or both (as in msg:TM: or msg:Template: which also work). See Special:Diff/1239799166 and Special:Diff/1239799326. Pinging @DannyS712 who added the Template: check. Nickps (talk) 16:40, 11 August 2024 (UTC)

We should also add (Sir Sputnik \(mobile\)) to the ignoreusers string per this. Codename Noreste 🤔 Talk 16:45, 11 August 2024 (UTC)
Actually, you should probably ignore this since it's actually impossible to catch everything with an edit filter. Things like {{soc{{void}}k}} cannot be caught with a regex. But, if you decide to add something anyway, I forgot to mention in my original request that things like {{w:sock}}, {{en:sock}} as well as any combinations like {{MSG:w:w:en:en:en:w:TM:sock}} are also valid. Nickps (talk) 08:13, 12 August 2024 (UTC)
I don’t know if this already exists, but we could probably have a filter that warns for {{void}} and namespace/wiki spam on a template for newbies. Example regex for namespace spam might be ({{|\[\[)(\w+:){3,}.+(}}|\]\]). I’ll take this to suggested if we don’t already have one. Lordseriouspig 03:35, 18 August 2024 (UTC)
Should change the first dot for a \w(alphanumeric characters + underscore) or something, otherwise it will match things like:
@[[User:Lordseriouspig|Lordseriouspig]]: Try asking at [[WP:VPT]], or [[WP:EFN]]. – 2804:F1...49:C8BD (talk) 04:14, 18 August 2024 (UTC)
Good idea. btw you might be logged out Lordseriouspig 04:26, 18 August 2024 (UTC)
And to the IP address, you might consider creating an account – it's free and it comes with many other benefits. Codename Noreste 🤔 Talk 05:49, 18 August 2024 (UTC)

1321 set to disallow

See my rationale in the comments. Please don't discuss this filter on-wiki; email me if you have any concerns. —Ingenuity (t • c) 19:55, 17 August 2024 (UTC)

I'm not in any position to have taken part or even know where the previous discussion happened exactly - but you did consider the discussed reasons why the previous filter wasn't set to disallow before making this one, right? – 2804:F1...49:C8BD (talk) 22:58, 17 August 2024 (UTC)
Yes. —Ingenuity (t • c) 00:38, 18 August 2024 (UTC)

1297: is "fake[ ]news" a potential mixed-use word?

I think I mostly understand what the filter's useful for—but I'm not sure whether this would be useful, borderline, or not useful. Thanks for the patience in advance. Remsense ‥  03:41, 23 August 2024 (UTC)

This is far too common in actual constructive revisions to put into the filter. There are so many possible uses for it that the filter would probably be tripping far too often to be effective. EggRoll97 (talk) 23:53, 23 August 2024 (UTC)
Naturally. I guess I'm just unduly interested in the filter system for some reason—is there an acquired rule of thumb for how many false positives is too many? I would imagine it's extremely low, and quantifying it strictly would be asinine, but naturally thinking we stopped 5 constructive contributions would sting, even if we prevented thousands of routine vandals. Remsense ‥  00:53, 24 August 2024 (UTC)
It's not so much the amount of false positives here, but the common usage. It's used in news reports, legitimate article content, and so much more. For example, see the full fifteen mentions of fake news on Presidency of Donald Trump, plus Fake news and similar articles. At the same time, you do have a valid point, it's a fairly mixed-use word, though probably for the best if we don't add that without strong evidence that it's being misused. I don't think I've seen much that gets past RecentChanges, personally. EggRoll97 (talk) 02:30, 24 August 2024 (UTC)

Short form versions of various EFFP parameters?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


I've noticed that {{EFFP|pagenameadded}}, {{EFFP|pagenamefixed}}, and {{EFFP|reportfixed}} have no short versions. May I suggest that we add short versions of these parameters of {{EFFP}} just so that they are easier to type out? For example, we could use "EFFP|pna" for pagenameadded, "EFFP|pnf" for pagenamefixed and "EFFP|rf" for reportfixed. Let me know what you all think. – PharyngealImplosive7 (talk) 21:46, 25 August 2024 (UTC)

For what it's worth, it doesn't seem like any of these would affect MajavahBot even with the note saying that the bot uses them - seems pretty easy to implement too. If no one else comments here I'd recommend just being bold and adding them (can even test in the /sandbox). – 2804:F1...E1:EACF (talk) 03:38, 29 August 2024 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Filter 174

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Why is filter 174 only set to warn & tag? And why does it only apply to non-autoconfirmed users? I see a lot of removals by autoconfirmed users that have to be repeatedly reverted. I don't see any disadvantage to disallowing removal by all non-extended-confirmed users. Anyone with less than 500 edits generally isn't experienced enough to be closing XfD discussions. C F A 💬 18:32, 26 August 2024 (UTC)

I imagine benefit of the doubt, and reversion of vandalism? Best that it apply to as few people as possible, unless you're seeing specific examples of autoconfirmed users needing to be caught by this. EggRoll97 (talk) 06:03, 29 August 2024 (UTC)
Might be worth to run a test filter for autonfirmed users for a while to see if it should be added to the filter. Nobody (talk) 06:22, 29 August 2024 (UTC)
I think without actual disruption occurring, best not to. EggRoll97 (talk) 15:47, 29 August 2024 (UTC)
Yeah, I see autoconfirmed users removing AfD tags from their own articles all the time in my work at NPP. In fact, it's probably more common than non-autoconfirmed editors doing so because article creations by non-autoconfirmed editors have to go through AfC (and thus are much less likely to be nominated for deletion). In the rare case that someone maliciously adds an AfD tag (without starting a discussion), it will just be removed by an extended-confirmed editor. These rare cases are tracked at WP:NPPEASY and fixed within a few hours. If an editor maliciously starts a deletion discussion, it will be speedily kept by an AFD closer (who are always extended-confirmed). The vast, vast majority of AFD tag removals by non-extended-confirmed editors are disruptive. Even if the filter isn't set to disallow, it should at least log removals by autoconfirmed editors so people can track them. C F A 💬 02:27, 2 September 2024 (UTC)
This filter will now catch autoconfirmed users as well. Extended-confirmed editors are exempt now. I will so far decline to switch it to disallow unless there is consensus to do so, though. EggRoll97 (talk) 04:36, 2 September 2024 (UTC)
Thanks. C F A 💬 21:15, 2 September 2024 (UTC)
@EggRoll97: Should the name be changed?
To "Non-extendedconfirmed user removing XfD template", perhaps? – 2804:F14:80E2:E301:70E6:DA2D:5A4C:A92D (talk) 22:41, 2 September 2024 (UTC)
New user generally seems to still apply to the intended use-case. Getting autoconfirmed is extraordinarily easy, after all. EggRoll97 (talk) 01:31, 3 September 2024 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Set filter 707 to disallow? (round 2)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


This is a continued discussion from Wikipedia:Edit filter noticeboard/Archive 13#Set filter 707 to disallow?.

We've made the message for the filter, and based on the hits, it's working as it should be (logging all drive-by vandals disrupting EFFPR). Does anyone object if we actually set the filter to disallow? Codename Noreste 🤔 Talk 01:41, 28 August 2024 (UTC)

No objections from me, filter doesn't seem to have any FPs, I think it can be safely set to disallow. Lordseriouspig 09:56, 30 August 2024 (UTC)
Support if bot and sysop also get put in the user groups. Nobody (talk) 11:15, 30 August 2024 (UTC)
I believe confirmed user rights are also implied in the administrator and bot user groups, FYI. Codename Noreste 🤔 Talk 14:18, 30 August 2024 (UTC)
Just tested it, looks like you're right. TY Nobody (talk) 14:34, 30 August 2024 (UTC)
SupportPharyngealImplosive7 (talk) 14:35, 30 August 2024 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Edit filter helper

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


NYC Guru (t · th · c · del · cross-wiki · SUL · edit counter · pages created (xtools · sigma) · non-automated edits · BLP edits · undos · manual reverts · rollbacks · logs (blocks · rights · moves) · rfar · spi · cci) (assign permissions)(acc · ap · ev · fm · mms · npr · pm · pc · rb · te)

I'm requesting permission which will allow me explain false positives tripped by private edit filters at Wikipedia:Edit filter/False positives. NYC Guru (talk) 08:55, 3 September 2024 (UTC)

@NYC Guru Gonna be frank with you, that's not happening. You've had no involvement with edit filters since you started editing, which fails WP:EFHCRITERIA. Nobody (talk) 09:24, 3 September 2024 (UTC)
You might want to.. actually get yourself involved? 0xDeadbeef→∞ (talk to me) 09:40, 3 September 2024 (UTC)
if it means being an admin on another project then it's certainly not happening but yes i would like to "get involved". NYC Guru (talk) 10:32, 3 September 2024 (UTC)
I'm not seeing your username on the last 500 edits to WP:EFFPR.. 0xDeadbeef→∞ (talk to me) 10:35, 3 September 2024 (UTC)
Oppose per my comments above since this is turning into an actual discussion somehow 0xDeadbeef→∞ (talk to me) 01:33, 4 September 2024 (UTC)
Well, assuming I did have edits I an not an admin on any wikiproject so this would fail anyway, but I'll try to get involved as I'd like to volunteer beyone stub sorting and WP:NPP. Didn't think this was an-RFA style discussion, though but I'll let it run it's course. NYC Guru (talk) 01:48, 4 September 2024 (UTC)
The standard applied to EFH candidates has often exceeded RfA. EFH needs serious trust as it contains private information. It is, in my opinion, impossible to get EFH without any involvement in the area first. 0xDeadbeef→∞ (talk to me) 02:02, 4 September 2024 (UTC)
The standard applied to EFH candidates has often exceeded RfA. I'm not sure about that. RFA is notoriously stressful and toxic. And RFA has hundreds more participants. But I definitely agree that EFH isn't just handed out to anyone. For someone that doesn't have a valid need-to-know such as an SPI clerk, it requires a blend of experience at WP:EFFPR and community trust. –Novem Linguae (talk) 03:11, 4 September 2024 (UTC)
@Novem Linguae:To be fair I'll wait a day given I didn't expect all these comments. Too bad I didn't get the courtesy when I WP:BOLDly tried an RFA back in January 2023. NYC Guru (talk) 03:45, 4 September 2024 (UTC)
Well, this point has been said here before and it might not be a fair comparison. But I think there have been people have expressed here that they might oppose an EFH candidate one that they do not necessarily oppose/could support in an RfA. Even though having sysop gives you what an EFH would have anyways. (I think a layer to this is that some people will only support EFH if they will support EFM as well) 0xDeadbeef→∞ (talk to me) 11:21, 4 September 2024 (UTC)
I don't see a demonstrated need for this, and there's also a lack of activity on any related noticeboards. Daniel Quinlan (talk) 15:24, 3 September 2024 (UTC)
Unfortunately, I strongly agree with what everyone says below; the edit filter helper and manager permissions both require a high level of trust (comparable to that of an administrator). In addition, some private filters' logs often contain personal information such as emails and phone numbers. Codename Noreste 🤔 Talk 16:44, 3 September 2024 (UTC)
Note: I've added the countdown and links, since this technically does count as a valid self-nomination and the user does meet the technical requirements. EggRoll97 (talk) 18:25, 3 September 2024 (UTC)
Oppose Clearly not ready, and I think this probably is a WP:NOTNOW situation, but I don't see any harm in letting it run if the user really wants it to run. EggRoll97 (talk) 18:25, 3 September 2024 (UTC)
Oppose No edits to WP:EFFPR? Ternera (talk) 21:12, 3 September 2024 (UTC)
Oppose: Per everyone else. – PharyngealImplosive7 (talk) 22:59, 3 September 2024 (UTC)
Oppose for now. If you don't mind, I'd suggest withdrawing to save the community some time. –Novem Linguae (talk) 03:10, 4 September 2024 (UTC)
Comment @NYC Guru: you can't just change the earliest closure date. The discussion is required to run for 7 days at minimum if you need it to run its course. A withdrawal would be best, I guess I could also see SNOW if someone else decides to. 0xDeadbeef→∞ (talk to me) 11:21, 4 September 2024 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Edit filter helper for A09

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


A09 (t · th · c · del · cross-wiki · SUL · edit counter · pages created (xtools · sigma) · non-automated edits · BLP edits · undos · manual reverts · rollbacks · logs (blocks · rights · moves) · rfar · spi · cci) (assign permissions)(acc · ap · ev · fm · mms · npr · pm · pc · rb · te)

Hello! I'd like to request edit filter helper rights. I confirm I have read the appropriate policy. Even tough I am not directly involved with abuse filters on enwiki, I believe I have a handful of use-cases. Firstly, I am an admin and a checkuser on slwiki (see SUL), and I maintain many abuse filters there (see sl:Posebno:AbuseFilter). EFH rights would be a chance for me to see certain enwiki approaches to LTAs and to possibly implement these on a crosswiki level, especially since I had to ask for enwiki filters examples/improvments many times in the past years. Furthermore, I believe I could help in improving existing LTA filters as I deal with a handful of them on a daily basis. I am happy to receive any feedback, and also fully prepared to withdraw the request if community wouldn't grant this rights. A09|(talk) 18:33, 5 September 2024 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Edit filter helper for Ternera

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


Ternera (t · th · c · del · cross-wiki · SUL · edit counter · pages created (xtools · sigma) · non-automated edits · BLP edits · undos · manual reverts · rollbacks · logs (blocks · rights · moves) · rfar · spi · cci) (assign permissions)(acc · ap · ev · fm · mms · npr · pm · pc · rb · te)

Hi everyone. I've been active at WP:EFFPR over the past few months replying to false positives that get reported. My reason for requesting the EFH right is so I can reply to reports where the filters triggered are private. Sometimes, I notice these reports go without answer for longer periods of time than reports where the filters triggered are public, and I believe I can be helpful by handling them when I see them. I have a basic understanding of regular expressions (I can generally read through them and have an idea of what is going on). I have read over the page and understand the secrecy of filter contents - I also have some other "advanced" rights like global rollback due to my involvement in anti-vandalism work and I'm a sysop over at the Rwanda Wikipedia. If the community does not think I'm a good fit for this, then I'm content to continue what I've been doing and replying to reports about public filters. Thank you for the input! Ternera (talk) 14:45, 6 September 2024 (UTC)

  • The global rollback is a big plus, but I'm going to oppose this for now. Your global and local edit counts are relatively low, and 71 edits to EFFPR isn't as much as I'd like to see if that's going to be your main involvement with edit filters. Thanks for your help and interest in this area, but I think it's a bit early for EFH. —Ingenuity (t • c) 03:50, 7 September 2024 (UTC)
  • I've had a look through, and the 71 edits to EFFPR locally are discouraging. Your sysop history on rwwiki has no involvement with the edit filters in the AF log, nor, as far as I can tell, any troubleshooting. So it would be an oppose for me as well, though I encourage you to help out with the public filters. EggRoll97 (talk) 04:04, 7 September 2024 (UTC)
  • Neutral, but slightly leaning on opposing. As someone pointed out, your EFFPR response count is too low according to XTools. I strongly encourage you to be involved more with public filters (such as regex additions or troubleshooting false positives) and much more responses to public filter reports on EFFPR, and when you try again in at least six months or in a year, you might have my full support. Don’t let my vote discourage you. Codename Noreste 🤔 Talk 14:43, 7 September 2024 (UTC)
  • Weak Oppose: As others have stated, you haven't edited EFFPR enough to warrant this right, and clerking reports on the page doesn't necessarily mean you need this perm still. You are a sysop on another wiki, but as EggRoll97 said, you have no involvement with filters there. I feel like after around a year, with more involvement with filters, you should be ready for this right. – PharyngealImplosive7 (talk) 22:31, 7 September 2024 (UTC)
  • Withdrawing this request. I see that I need even more experience before being trusted with this. I'll continue my involvement as I have been doing and hopefully have a successful request next year! Ternera (talk) 21:05, 8 September 2024 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.