for detecting draft articles that already exist in mainspace? If there isn't, I think that would be a good filter to block page creations of draft articles in namespace. Aasim 20:15, 27 August 2020 (UTC)

To provide more context: suppose that a user creates a draft article at Draft:Sandbox when there is already a page at Sandbox. The user will get an error message informing them that the page already exists and that they need to choose a different title for that topic. Aasim 20:18, 27 August 2020 (UTC)

Awesome Aasim, The AFC helper has this feature built-in. ~~ CAPTAIN MEDUSA^talk 20:43, 27 August 2020 (UTC)

I don't think we have such a filter. It could probably be achieved when the draft article links to the main article within new_html, and that would probably specifically involve any edit introducing the {{Draft article}} template, since that template can say, "There is a Wikipedia article named <a href..." -- zzuuzz ^(talk) 22:58, 27 August 2020 (UTC)

• Combined logs of all filters discussed here

First, the current situation:

I'd like to make this more consistent:

• Exclude bots from 891. I assume that was just an oversight.  Done
• Exclude the summaries ^(Revert|rv|Undid)|AFCH|WP:TW|reFill from all the filters. Why reFill? Well, the source was already on the page; it just wasn't detectable until it was filled in. We shouldn't be warning people for fixing bare URLs, even if the URLs point to crappy sources. Done
• Exclude deletion tags from all the filters.  Done
• Remove the Talk: namespace from filter 1034. No idea why that was there. Not done
• Add the User: namespace to 869, 894, 1034. But not 1045 (it's okay to link to your blog from your user page), or 1057 (nothing wrong with citing an essay, discussion, etc.) Done
• Possibly add the Template: namespace to 869, 894, 1034, 1045. Not sure what the unintended consequences will be though. Done
• Possibly stop excluding extendedconfirmed and sysop from 1057. See the last eight hits of filer 1014.
• Create a new tag-only filter, which combines the regexes from all the filters, and ONLY trips if the user is a bot OR the summary matches ^(Revert|rv|Undid)|AFCH|WP:TW|reFill. This will be a bit of pain to update, but it's not a disaster if it falls behind.  Done

Pinging @JzG, Newslinger, and Headbomb: for thoughts. Suffusion of Yellow (talk) 20:35, 26 August 2020 (UTC)

For the refill/other semi-automated tools, having the filter triggered makes me look for what triggered it. Bots should be excluded from warnings, but their edit should nonetheless be tagged. Headbomb {t · c · p · b} 22:19, 26 August 2020 (UTC)

@Headbomb: To be clear, the new (tag-only) filter will tag uses of reFill, Twinkle, undo, etc. But I don't think we should be warning people about a source that a different user added. Particularly not if they are using a script; many scripts display filter warnings poorly. In Twinkle at least, if you trip filter 891, you get this helpful message: Grabbing data of the earlier revision: ⧼abusefilter-warning-predatory⧽. Suffusion of Yellow (talk) 22:29, 26 August 2020 (UTC)

Suffusion of Yellow, please keep the talk pages in 1034 - WikiLeaks is used to pull in all kinds of problematic crap. All should apply to Main and Draft. Otherwise, all that makes good sense, thanks.

Also, Y U NO ADMIN? Guy (help! - typo?) 22:48, 26 August 2020 (UTC)

And templates too. Headbomb {t · c · p · b} 18:38, 28 August 2020 (UTC)

Created the new catch-all filter at 1081 (hist · log). Before I update all the other filters, can anyone think of any more summaries or templates to exclude? We probably shouldn't warn if the user is adding {{copyvio-revdel}}. And others? Suffusion of Yellow (talk) 20:37, 28 August 2020 (UTC)

I think that filter 733 should prevent the user from performing the action in question. I don't see any situation where new users creating pages in other editors userspace are necessary. This should be done to prevent the attacks of vandals like this. ɴᴋᴏɴ21 ❯❯❯ talk 17:55, 31 August 2020 (UTC)

Hello, I'm from ckbwiki. I want to know how filter 135 works? I have just added my own language letters to the filter, but today I found out that the filter has rejected several good edits! How many times has a letter repeated? I did some tests and found out that every double-repeated letter would catch by the filter, am i right? Thanks! ⇒ AramTalk 22:08, 31 August 2020 (UTC)

The answer appears to be 8. What did you try? Filters on that wiki are not visible. ST47 (talk) 19:34, 2 September 2020 (UTC)

@ST47:, Here is the filter on ckbwiki and you should see it's content. Here is it's log with rejected many good edits! For example, this is a good edit, but the filter rejected it. I just imported the enwiki one and added local language letters. That is all. ⇒ AramTalk 16:10, 3 September 2020 (UTC)

Hi! I added The Sun to an article in my sandbox and got no warning; and when I pasted the article into Mainspace a vague warning that *some* link was deprecated (out of the 20+ I was using) but it didn’t tell me which one.

I’m hoping both these issues can be addressed. Gleeanon409 (talk) 04:18, 10 August 2020 (UTC)

@Gleeanon409: With regard to the first issue, see the section below, WP:EFN#"Bad source" warning filters. The filter should now warn when a deprecated source is added to a userspace draft. With regard to second issue, thats's an open feature request, at phab:T216001. Suffusion of Yellow (talk) 19:58, 3 September 2020 (UTC)

Thank you! Gleeanon409 (talk) 21:30, 3 September 2020 (UTC)

• 1085 (hist · log) (private)

Please see the notes. I'm not setting to disallow now, but if this turns out to be needed, it's there. Or should this be done now, per WP:UCS? Nothing has happened yet, but people are people. Should this be set to disallow right now, per IAR? Yes there will be FPs. If you have any suggested tweaks, please email the list. Suffusion of Yellow (talk) 00:21, 19 September 2020 (UTC)

Suffusion of Yellow, I say just go for it (but keep an eye on the filter!). GeneralNotability (talk) 00:32, 19 September 2020 (UTC)

Seconded. It's quite possible it will need semi-protection at some point, but the filter is a good not-too-obtrusive start. OhNoitsJamie ^Talk 00:33, 19 September 2020 (UTC)

 Done. I will keep an eye on the log, of course. Suffusion of Yellow (talk) 00:46, 19 September 2020 (UTC)

Just cleaned up a bunch of those. This one should be edit filtered, not sure which. Possibly 894 . Its uses are almost exclusively fringe. There are occasional exceptions, but they are exceedingly rare. Headbomb {t · c · p · b} 02:24, 22 September 2020 (UTC)

Headbomb, I'd prefer you to propose additions on MediaWiki talk:Spam-blacklist. I think 894 is not fit to add viXra.org with edit filter. Warm Regards, ZI Jony ^(Talk) 10:55, 22 September 2020 (UTC)

I really was hoping to avoid the blacklist, it's an overkill solution to a small problem that would be made very manageable by an EF, which would prevent all use of vixra, even when appropriate, or in discussions. Headbomb {t · c · p · b} 14:18, 22 September 2020 (UTC)

Headbomb, I think the message for 894 might not be appropriate since that's purely about self-publishing, whereas viXra is primarily woo. But I agree it's a good case for a filter, at least in the first instance. Guy (help! - typo?) 16:42, 22 September 2020 (UTC)

I wonder what the filter should be for "Woo/Fringe, or very high likelihood of such". A new filter could be made and catch a lot of the woo crap, from pseudoscience journals, to quack sources, to quantum woo idiocy. Headbomb {t · c · p · b} 16:47, 22 September 2020 (UTC)

We could have new filter for this as "* external link addition", so in future we could add more to be filtered. Warm Regards, ZI Jony ^(Talk) 17:37, 22 September 2020 (UTC)

Hi folks,

Something that has bugged me for a long time: it's really hard to examine what parts of a regex matched a given edit (when, say, trying to see which filter conditions were met for one of our big LTA filters). I would like to write a small userscript that, given a specific edit filter hit, will load the regex(es) and input data into a third-party regex tester, currently looking at regex101.com (let's be honest - odds are, most of our private filters have been tested on one of those at some point). I've looked at their privacy policy, the testing is all client-side and stuff only gets saved to their servers if you explicitly click the save button. The biggest source of a potential information leak is the URL itself, since the preload is done with URL params (i.e. https://regex101.com/?regex=something&text=somethingelse). Since the site uses https, the regex would be stored in the server's logs but wouldn't be visible to anyone else. The question: is that acceptable to edit filter folks, or is that too much of a potential leak? Personally I think it's a reasonable trade (assuming that the website isn't run by an LTA), but I wanted to ask for other folks' opinions before proceeding. If people do think it is a risk, I will still write the script, but will put in a safeguard to prevent it from sending private filter data off-wiki. GeneralNotability (talk) 01:45, 23 September 2020 (UTC)

Oh, to be clear, none of this is automatic - my thought is that for each regex in the filter, the script would generate a link which would prefill the regex and relevant text, but data would only be sent when something is actually clicked. GeneralNotability (talk) 02:15, 23 September 2020 (UTC)

On the page Hypatia, there is an IP vandal (not autoconfirmed) making edits that would normally be disallowed by the edit filter. The first edit, [1], the IP made involved persistent repeating characters and possibly nonsense characters that are normally disallowed under filters 135 and 231. The IP has made another edit [2] that I believe would normally be disallowed under filter 680 because it contained Emoji unicode characters. All three filters disallow such edits to prevent vandalism from occurring, and if the filters are broken then the vandalism which wastes other editors time just appears and possibly renders the edit filters useless. Can you please explain how and why these IPs bypassed such filters? Thanks. Train of Knowledge (Talk) 22:33, 28 September 2020 (UTC)

Train of Knowledge, as best I can tell: 135 missed it because it contained enough vowels to bypass the gibberish filter, there were spaces so 231 didn't trip (it triggers on strings of >50 chars without spaces). I have no idea why 680 missed the second edit, [3] says the regex in 680 should detect just fine. Note that 135 did trip later, see Special:AbuseLog/27765171. GeneralNotability (talk) 23:28, 28 September 2020 (UTC)

Actually...one of the lines in the filter is !(new_wikitext irlike "astro|category:unicode blocks") and the wikitext does contain "astro" (as "astronomy")...maybe that's it. King of Hearts, that appears to be your addition, so pinging you. It's entirely possible that we see so little vandalism like this that it's not worth fixing. GeneralNotability (talk) 23:31, 28 September 2020 (UTC)

Indeed. And I believe 135 was due specifically to adding repeating characters to a line containing "\n|" (filter line 12). I'm not sure why changing template (or similar) parameters is excluded from this filter, but I suspect there's a historical reason. It's difficult for filters to be 100% accurate all the time. More weight has to be given to false positives. But that should help a little with the mystery. -- zzuuzz ^(talk) 23:35, 28 September 2020 (UTC)

I was wondering if it is possible to have a filter on non-XCON editors that reminds editors of our non-free image usage policy? The message could be something like:

Such a filter would be useful to get new users to compress their non-free images. I just stumbled across an image by a seemingly new editor that was of too high a resolution. Aasim 16:54, 16 September 2020 (UTC)

Awesome Aasim, well I'll be darned...I was expecting this to be impossible, but we do in fact have variables for file width and file height, so it appears possible from a technical perspective. I think the message needs some work, since we do have a bot which can reduce oversized files if the file is tagged appropriately. GeneralNotability (talk) 17:09, 16 September 2020 (UTC)

@GeneralNotability maybe we can have the filter just detect high-res uploads in general and encourage users to upload their high-res image to Wikimedia Commons if it is a free image.

So maybe:

Aasim 17:18, 16 September 2020 (UTC)

• Question: do we not have bots that automatically tag/categorise large non-free images for downscaling? ProcrastinatingReader (talk) 20:00, 17 September 2020 (UTC)

  My bot tags oversized non-free images. DatBot is supposed to reduce them but, it hasn't been since July. There are also other types of non-free media (e.g. video) that are oversized. — JJMC89 (T·C) 00:17, 18 September 2020 (UTC)

  In that case, why do we need an edit filter to warn? If a bot will be downsizing them anyway, I'm not sure the warning helps? ProcrastinatingReader (talk) 03:19, 18 September 2020 (UTC)

  It is just a gentle reminder. While we do have bots to reduce them, not everything does get reduced like @JJMC89 says. The purpose of such a filter is to remind new editors to check the size of the image. Not every abuse filter means that the editor did anything wrong. It is called the abuse filter because the primary purpose is to catch bad contributions. Aasim 05:03, 18 September 2020 (UTC)

  And... have we come to consensus on a helpful message? Aasim (talk) 00:31, 5 October 2020 (UTC)

  Frankly, I personally don't think any message will be helpful. The warning is a surprise, most people to whom this warning applies (due to "user_editcount < 500" restriction) will find it a surprise, will find it confusing and will be startled by it. And I don't know what makes it any better if I upload a large non-free image (I have > 500 edits)? Just fix the bot to downsize imo... No need to bug people about this. Besides, we've now got entries in the log showing people aren't responsive to the warning. Even when the bot did downsize, some people uploaded large versions again to overwrite. ProcrastinatingReader (talk) 01:04, 5 October 2020 (UTC)

  How can we stop abuse filter messages from appearing in red? Oh, with CSS styling for the "error" message. But yeah, I can picture a new user be scared by an all red abuse filter message. Although we do not make them red, the MediaWiki software automatically displays red text when there is an error with saving. Aasim (talk) 04:55, 5 October 2020 (UTC)

856 (hist · log)

The current conditions are:

equals_to_any( page_namespace, 0, 2, 118 ) & (
  stringy := "{{\s*([Cc]opyvio/?core|[Cc]opyvio-revdel|[Rr]evdel).*}}";
  removed_lines rlike stringy &
  !(added_lines rlike stringy) &
  !contains_any(user_groups, "sysop", "patroller")
)

However, sometimes the copyvio template will span multiple lines, and its removal thus won't be caught, or switching it from one line to multiple will trigger a false positive (example: Special:Diff/980529995). I suggest changing it to

equals_to_any( page_namespace, 0, 2, 118 ) & (
  stringy := "{{([Cc]opyvio/?core|[Cc]opyvio-revdel|[Rr]evdel).*}}";
  rmwhitespace( removed_lines ) rlike stringy &
  !( rmwhitespace( added_lines ) rlike stringy) &
  !contains_any(user_groups, "sysop", "patroller")
)

which would remove whitespace from the diff before processing (and also remove the \s* since that matches any whitespace, which wouldn't be needed).

Testing with User:Suffusion of Yellow/batchtest-plus against prior hits to this filter showed a couple other cases where the new filter wouldn't match but the old one did. They all appear to have been false positives, except for

• I couldn't check one of the diffs that has been deleted, but the abuse filter log details from the hit confirm it was a false positive (not linking since they include the copyvio content).
• A number of edits from 5 February 2019 and earlier did not match, but did not appear to be false positives. I am unable to confirm why they no longer match, but when testing against the current version of the filter, they also did not match, so there is no change in the behaviour with respect to those edits.

This change would also catch more removals, eg if the template on the page was only multiple lines and then removed.

Thanks, --DannyS712 (talk) 18:34, 2 October 2020 (UTC)

 Implemented — JJMC89 (T·C) 04:16, 5 October 2020 (UTC)

@DannyS712: Some log entries from before early 2019 are missing all the lazy-loading varaibles, including added_lines. See phab:T176291. Suffusion of Yellow (talk) 17:34, 8 October 2020 (UTC)

• Filter 1091 (hist · log) (private)

Just noting that I've created this as an emergency filter, as it looks like we have someone running a bot (or working really fast) to vandalize high-profile pages. See the list of accounts in the notes, each of which got to around 50 edits before being blocked. I tested a different version of this on 1013 (hist · log), and I'm fairly confident that there will be few false positives. Set to log-only if needed. Suffusion of Yellow (talk) 06:09, 10 October 2020 (UTC)

Hello, May I request an edit filter helper to check my expanding on the page "Mrs.Gould's sunbird"? The filter seems automatically identified my work as unconstructive. I do what to know what is not good enough and I can fix it. Thank you very much. — Preceding unsigned comment added by DPB0976 (talk • contribs) 07:20, 13 October 2020 (UTC)

DPB0976, those requests usually go to Wikipedia:Edit filter/False positives. If I had to guess, it's probably triggering because the image File:Scarlet-breasted Gould's sunbird.jpg includes "breast" in its name. GeneralNotability (talk) 18:29, 13 October 2020 (UTC)

Probably of interest to the edit filter community: phab:T263024. Short version: the plan is to remove the rmwhitespace() behavior from rmspecials(), if you want that to be a part of your filter's behavior you can do rmwhitespace(rmspecials()), which should have the same behavior both before and after this change. GeneralNotability (talk) 17:01, 12 October 2020 (UTC)

I've gone ahead and made this change to existing filters (I think there were about seven with rmspecials(), of which two or three had rmspecials(rmwhitespace()) already set up) and left a comment in the notes section. This change is a noop before the change is deployed and will continue the existing behavior after the change is deployed. GeneralNotability (talk) 16:28, 14 October 2020 (UTC)

I noticed in the filter log for this user that there is a private edit filter brazenly titled "Catch the Loser LTA". Forgive me if I'm mistaken, but I thought that to prevent provoking investigation into circumvention that we don't describe private filters after the user they're meant to catch?

Apologies if discussing a private filter's public description is out of scope for this noticeboard. If so, I'll email instead.

Regards, User:TheDragonFire300. (Contact me | Contributions). 04:15, 16 October 2020 (UTC)

@TheDragonFire300: I gave it a more generic name. — xaosflux ^Talk 19:59, 16 October 2020 (UTC)

For anyone who missed it, from the recent Tech News:

In the AbuseFilter extension, the rmspecials() function will be updated soon so that it does not remove the "space" character. Wikis are advised to wrap all the uses of rmspecials() with rmwhitespace() wherever necessary to keep filters' behavior unchanged. You can use the search function on Special:AbuseFilter to locate its usage. (Phab ticket)

EEng 18:07, 19 October 2020 (UTC)

polite cough. Everything should be taken care of as far as enwiki filters are concerned. GeneralNotability (talk) 18:09, 19 October 2020 (UTC)

OK, so you EFMs are all so up to date and current and stuff. I'm just a lowly EFH. Go ahead, laugh! EEng 20:03, 19 October 2020 (UTC)

I made this userbox for anyone who identifies vandalism/disruptive editing through the Edit filter log such as myself. Jerm (talk) 18:06, 22 October 2020 (UTC)

Wikitext	userbox	where used
{{User wikipedia/Abuse log}}	This user identifies vandalism and disruptive editing through the Edit filter log.	linked pages

• Filter 1098 (hist · log) (private)

Same LTA as another filter (see the notes). Yes, it looks overly broad at first glance, but check the actions closely. Suffusion of Yellow (talk) 17:18, 31 October 2020 (UTC)

Currently, filter 1084 catches non-free image uploads of at least 120,000 pixels without a reduction request. I suggest lowering that to 105,000 in line with Wikipedia:Bots/Requests for approval/JJMC89 bot 19. Ntx61 (talk) 07:47, 25 October 2020 (UTC)

@GeneralNotability: The filter checks for >120000 pixels, but the notes say >100000. What was the intent here? Any problem with this change? Suffusion of Yellow (talk) 17:20, 31 October 2020 (UTC)

Suffusion of Yellow, Ntx61, lowered - I forget why I gave it that much of a buffer. GeneralNotability (talk) 17:26, 31 October 2020 (UTC)

Just a simple question, I hope: Is there a technique for using the filter log just to search for and generate a list of a specific user's edits? Thanks! Pasdecomplot (talk) 19:49, 5 November 2020 (UTC)

At Special:AbuseLog in the search options, you can specify the user to search for DannyS712 (talk) 19:58, 5 November 2020 (UTC)

For existing accounts this is possible with one line of code: (user_name == 'Pasdecomplot'), however on enwiki it's considered too inefficient to do this. -- zzuuzz ^(talk) 19:59, 5 November 2020 (UTC)

And if you really just want a "list of a specific user's edits" you can just use Special:Contributions/Pasdecomplot. — xaosflux ^Talk 20:13, 5 November 2020 (UTC)

Hello, I submitted a false positive report concerning my post at Talk:List of youngest birth mothers, but it displays the wrong IP address, page(s), and timestamp. I hope it is not overlooked due to this error. 144.96.41.37 (talk) 12:39, 10 November 2020 (UTC)

Looks like a vandal had messed with the reports page. I've added your message at Talk:List of youngest birth mothers. Suffusion of Yellow (talk) 19:45, 10 November 2020 (UTC)

Thanks 144.96.41.95 (talk) 11:52, 11 November 2020 (UTC)

• Filter 1085 (hist · log) (private)

Re-enabled. Add to the first line as needed. See the mailing list for more details. Suffusion of Yellow (talk) 20:43, 7 November 2020 (UTC)

I seem to have dropped off the mailing list; can you check? And please send a link to the Biden image vandalism filter. EEng 00:34, 9 November 2020 (UTC)

I got your messages. You are still subscribed, according to [4]. Don't know what's up. Can you access the archives? Suffusion of Yellow (talk) 00:57, 9 November 2020 (UTC)

Yeah, and I got my own message just sent. Someone said there's been no list activity since early September, but then what's the "see mailing list" activity mentioned above? No emergency, but I want to stay up to speed on this filter (which I realize now is the one linked here at the top!). Thanks. EEng 01:11, 9 November 2020 (UTC)

The email for this ended up in my spam box for some reason, just found it. Sam Walton (talk) 17:00, 9 November 2020 (UTC)

Huh, same...and that's pretty weird, almost nothing goes to spam on this email. I blame SoY. GeneralNotability (talk) 17:57, 9 November 2020 (UTC)

Probably the spammy words in the original thread with Oshwah. For example, "goatee" ... about half the spam emails I get are for beard-care products. Or maybe another word. Suffusion of Yellow (talk) 19:50, 10 November 2020 (UTC)

Mentions of pornography probably don't help either. Years ago at work a difficulty arose. In dealings with potential clients one of the things we explained was that we didn't take cases involving pornography. But the word pornography sometimes got these emails diverted to the client's trash folder. The boss asked me what to do. I suggested saying that we don't deal with material that's (suggestion 1) "unbowdlerized" or (suggestion 2) "not family friendly". Not sure which they went with but apparently the problem was solved. (The clients were attorneys, so unbowdlerized was a more reasonable choice than you might think.) EEng 06:58, 12 November 2020 (UTC)

Moonythedwarf (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 · fm · mms · npr · pm · pcr · rb · te)}

Hello! I would like to request the Edit Filter Helper permission, to:

• Assist with development of filters (I have a good grasp on regexp, and decent knowledge of common vandalism patterns that could be matched against)
• Be able to assist with more WP:EFFPR reports
• Help my ability to engage in my primary task on the site, fighting vandalism.

I've engaged in some prior discussion of filter development (admittedly not much), and have EFFPR on my watchlist, which I check on whenever I'm not doing some other task. Currently interested in developing a filter to help catch corporate spam (likely just as a tagging filter), and, as mentioned, helping at EFFPR. Thanks for considering the request, —moonythedwarf (Braden N.) 19:29, 10 November 2020 (UTC)

• So, no one else wants to comment here. I'm, as usual, torn. I think the chance that you're going to go rouge and leak all the private filters is close to zero. But if EFH is handed out to everyone with your experience level, the risk is substantial. I don't want EFH to become another rollback-like hat.
  But the best way to get experience is with Special:AbuseFilter/test and Special:AbuseFilter/examine, etc. I'm going to be a bit less paranoid than usual, and support temporary rights (maybe 3 months or so). That's not how we usually do things, though. If temporary rights are just not possible, then I am neutral. I basically see this role as "EFM in training". What will make me enthusiastically support will be a few months of in-depth investigation of filter issues. Suffusion of Yellow (talk) 18:51, 14 November 2020 (UTC)

  Suffusion of Yellow, I understand your concern with hats. EFH is not a risk-free, "we can fix it afterward", commonly-given right like Rollbacker, new page reviewer, or pending changes reviewer, and should remain that way. I specifically asked because I believe I have a valid reason and purpose for assisting with filters, and see no way to learn them besides the current route. I have a vested interest in both improving the filters (they reduce my workload) and also reducing false positives (not as much of a direct effect on my usual work, but heavily effects new editors which are people I'm trying to assist when possible.)

  I'm disappointed to see/hear that EFH has no way forward, however. This is not made completely clear, nor are the rest of the details around EFH nor the criteria to obtain it. I previously held back on requesting EFH because I simply did not understand the requirements (As it turns out they're entirely arbitrary, which sucks for everyone)

  On the page for EFH, it is explicitly stated that it is good for "Those interested in helping with edit filters but who do not meet the thresholds required to be able to modify them.", but apparently, per Crow and DannyS712, this isn't actually the case, you need a unclear "demonstrated need for access" which has no definition.

  I'm mildly torn on the request itself as it's abundantly clear requesting it will be mildly unhelpful ("helper" is in the name only, it doesn't actually grant much in terms of actually assisting with filters) and possibly just pointless, as there's no hard fast rules on what I need to do, be, or state. I understand the requirements for trustworthiness, but this is a bit much.

  I fully understand the lack of trust though, I don't actively interact with people much on-site, so the list of people who have actually spoken with me is small, and the only major thing to prove my competence is my (mainly semi-automated via twinkle) edits. Trust is important with the filters, and I recognize that. Going to cut it here as I could keep talking for a while on this. —moonythedwarf (Braden N.) 04:30, 15 November 2020 (UTC)

  @Moonythedwarf: Yes, unfortunately it's arbitrary. Not many people are active with filters, so it really comes down to who is watching this page at the time of the request. The alternative, a widely advertised RFA-like free-for-all, seems much much worse. Suffusion of Yellow (talk) 19:02, 15 November 2020 (UTC)

  Suffusion of Yellow, I do agree on that. —moonythedwarf (Braden N.) 19:58, 15 November 2020 (UTC)

• Respectfully, I have to disagree with Suffusion of Yellow regarding "EFM in training" - the two user groups have very different levels of trust required and different use cases, and I don't think users who get EFH should expect to eventually get EFM (though of course they can; its just not something to expect/assume). I also hate the idea of this being a hat, but agree that the most useful way to get experience is via Special:AbuseFilter/test, but unfortunately that page says "For security reasons, only users with the right to view private edit filters or modify filters may use this interface." so I'm also torn, but in this case I think the paranoia wins out regarding permanent rights. I have to oppose permanent rights - I don't really see a "Demonstrated need for access". Regarding temporary access, is there any precedent for that? --DannyS712 (talk) 19:06, 14 November 2020 (UTC)
• Since Earliest Closure has passed, let me jump in here with an Oppose for now. Detailed explanation shortly. I echo some of both editor's above comments. I don't see the "demonstrated need", which I personally define as: By not having the permission, one is hindered in their efforts to improve the encyclopedia. So I view it as different from other permissions such as rollback where "it helps" is usually sufficient justification. To the OPs nom statement, 1: the ability to view the private filters will typically be of no help in developing future filters; they're typically the same as most public filters, with only the vandal-specific regex that is being hidden. 2: Always appreciated, but the Private Filter backlog never gets big enough to consider this a Need. 3: The lack of the EFH permission doesn't hinder vandal fighting; at worst it simply keep you from knowing who the vandal is that you're reverting and reporting. I also agree with Danny that EFH is not a stepping stone to EF. It was intended from the start to be a rarely given-out permission for a narrow set of circumstances where EF is not appropriate but there is that demonstrated need. Crow^Caw 19:43, 14 November 2020 (UTC)

  For the record, the argument here doesn't feel consistent. Most recent request was Wikipedia:Edit_filter_noticeboard/Archive_7#Requesting_Wikipedia:Edit_filter_helper_right_(EEng) (EFH to edit filters, effectively as a stepping stone to EFM). Danny requested it to deal with false positives and better learn how specific (private) edit filters work: Wikipedia:Edit_filter_noticeboard/Archive_5#EFH_right_for_DannyS712 (passed). Suffusion requested it for false positives: Wikipedia:Edit_filter_noticeboard/Archive_4#Edit_filter_helper_right_for_Suffusion_of_Yellow. Even you don't meet your own demonstrated need criteria in Special:Diff/786616909. My point is that this request fails (at best) because 'lack of trust' but none of the other arguments seem to match history and precedent; I believe it's only fair to the requesting editor to give them helpful & accurate feedback for a failed request. ProcrastinatingReader (talk) 21:14, 14 November 2020 (UTC)

• Comment Grr...I had a whole response typed up an hour ago, but I guess I accidentally closed the window or something since I clearly didn't send it. My thoughts in a probably-less-eloquent summary (but with some additions following Crow's !oppose):
  • I think our "demonstrated need" threshold is impractically high, and we should be more willing to grant the perm to editors who have proven themselves trustworthy in areas related to private filters (mainly LTAs and some spammers/spambots) who would substantially benefit.
    • With that in mind, the last EFH we added was EEng, and in my opinion EEng did not have a "demonstrated need" at the time (not objecting to EEng having the perm! just saying they did not meet that threshold).
    • Spitballing: maybe we could have a "sponsoring" approach instead? Instead of the usual !vote, a current EFH/EFM can put a candidate forward and say "I trust them and think they'd benefit from having the permission" and the candidate is presumed to be suitable unless someone brings up a significant concern. Again, just writing off the top of my head here.
  • I am well aware of how OPSEC works (having worked in cybersecurity at various points), I know that every EFH we add is a risk for some of our filters getting leaked either to the internet in general or the people who the filters are trying to catch in particular. I still think that we're being too paranoid.
  • I do not think EFH should be thought of as a stepping stone for EFM.
  • I also do not think that EFH should be part of the "cursus honorum" (as it were) like rollbacker or new page reviewer. However, we currently have 18 EFHs. Of those, two are bots, and at least half of the remainder (that's 8, if I'm remembering my elementary school math right) rarely show up at edit filter noticeboards. I think we can stand to have a few more.
  • Regarding moony, I'm on the fence and so not voting here - they're competent but I haven't interacted with them enough to trust.
  • Yes, I know that exactly one bullet of this is actually relevant to "should moonythedwarf be an EFH?" Sue me.

GeneralNotability (talk) 21:42, 14 November 2020 (UTC)

In response to the 18 EFH comment, a breakdown of Special:ListUsers/abusefilter-helper. As far as I can surmise:

• 2 bots
• 1 bot operator (needed to allow the bot to have the rights; the other bot op is an admin so has access already, 85775458)
• 1 WMF staffer
• Chriswaterguy, Praxidicae, and Vito Genovese had EFM before the creation of EFH, and were downgraded since they had requested view-only access (103938831, 85713835, 85713726)
• 1997kB has a "valid need" as an SPI clerk, exempt from discussion here (98784998)
• Bri has a "demonstrated need" to see hidden filter hits related to their activity in COI cases (85962144)
• Compassionate727 has a "demonstrated need" due to their history of dealing with false positives specifically of private filters (91726387)
• Dane has a "demonstrated need" to view hidden filter hits as a tool administrator of WP:ACC (86171266)
• DannyS712 (myself) has a "demonstrated need" to be able to use testing interface (101089450)
• Nardog has a "demonstrated need" due to their involvement with a private filter (110302737)
• Nihlus has a "demonstrated need" due to their history of suggesting improvements to filters after finding false positives (86510903)
• Salvidrim! is a former sysop who as far as I can tell had EFM downgraded to EFH access on request, and had EFM because they added it themselves while a sysop, meaning there has been no discussion regarding "demonstrated need" (60065063, 88181788)
• Winged Blades of Godric has a "demonstrated need" due to their history of contributing to filters (95137750)
• There wasn't as clear of a specific "demonstrated need" for EEng or Home Lander

In short, I don't think there is a specific set of activities which qualify as "demonstrated need", but I think its more than just counter-vandalism experience. DannyS712 (talk) 22:16, 14 November 2020 (UTC)

Okay, my comment on who's doing what with EFH was a little on the flippant side. Forget I mentioned it. GeneralNotability (talk) 22:52, 14 November 2020 (UTC)

• The bar for need was (if you read the RFC that created this right) desired by many of the participants to be rather high. And yes there is no specific set of steps or whatnot to qualify, rather it's an "I know it when I see it" sort of thing. Crow^Caw 23:16, 14 November 2020 (UTC)

I would like to note I do not view EFH anywhere near the same as Rollbacker or PCR, it has a very good reason for not being a frequently-trusted right and should stay that way. —moonythedwarf (Braden N.) 04:18, 15 November 2020 (UTC)

• I originally wrote the following with the intent to close, but after thinking on it, I would prefer to be more opinionated and so lightly revised it. As a quick tally: SY supported a time-limited grant, Danny opposed specifically an indefinite grant for lack of "demonstrated need", Crow opposed a grant generally for lack of "demonstrated need", and two editors challenged the opposition without specifically supporting the grant. The only comment that could be seen as opposing a time-limited grant is Crow's, but that is also the only comment that received significant push-back. The edit filter helper policy is largely useless here since not only does it not elaborate on "demonstrated need" it also doesn't elaborate on what a successful request looks like, leaving it up to discussion and closure discretion (respectively). So going off the famous Air Bud Rule, absent a policy against it I believe a time-limited grant is something we can allow.
  Participants did point out useful examples of previous requests, and since policy follows practice, I looked to see how these issues have been resolved in previous requests. In general, demonstrated need is...well...need that has been demonstrated, and the way that demonstration typically occurs is usually through work at EFN, fixing false positives of public filters, SPI clerking, experience with specific LTAs (and their filters), and cross-wiki work. While moony does not fall into any of those categories, Suffusion of Yellow points out that one way to get experience is by using interfaces that are only available to those with EFH, and I agree. Similarly, there are some notable exceptions to the typical cases of "demonstrated need" such as EEng's request a few months ago where his rationale was specifically to get experience, and while Danny now qualifies for other reasons, he lists as his reason a need to use the testing interface. Given the comments here and previous requests, it seems that wanting to use the testing interfaces to gain experience helping with edit filters is a valid use case. That said, such requests are not guaranteed to be successful as the bar for EFH is meant to be intentionally high and getting EFM by having EFH is far from a guarantee.
  That leaves the final question of whether Moonythedwarf can be trusted for any period of time with the more powerful tools in EFH, namely viewing private filters. This really can't be understated because even a grant of 24 hours could---in the wrong hands---cause serious problems. Time limited grants are useful for "demonstrated need"- or experience-type problems, but in this case it cannot relieve us of our paranoia, and trust is the far more important part of EFH in my opinion. GeneralNotability finds moony competent, but has not interact enough to trust them. ProcrastinatingReader even suggests that they see this request as unsuccessful due to lack of trust. There's also only one explicit support which makes it hard to extrapolate a general sense of trust. The EEng and Danny examples brought up demonstrate an incredible amount of trust being required for these "gain experience" grants---Danny can break the wiki in more ways than I can imagine, and EEng already does.^[FBDB] The bar for EFH is high, and higher still when we're looking to relax one of the main requirements; I would say it's on par with admin rights but for people who (for whatever reason) don't want to go through RFA just to work on edit filters. Personally I agree with SY that the risk of damage is low, but I don't think Moony yet has the level of trust needed for what boils down to an IAR grant. While I really like the idea of a time-limited grant, absent a sponsor (like GN suggests) or enthusiastic support, I think I need to oppose very regretfully. — Wug·a·po·des​ 23:28, 17 November 2020 (UTC)

  Wugapodes, Thank you for your input, and I understand the reasoning for the oppose. I'm hoping to work more closely with other editors in the future specifically to avoid this kind of problem where nobody specifically has interacted with me for significant bits of time. As of now much of my time is spent actively working on handling WP:RCP, with very little (almost no) time spent discussing issues with other editors, partially due to discussing WP:TROLLs and WP:UPEs in public being a bad idea. I'm hoping to rectify the issue to an extent, and will likely re-run in the future when I feel other editors are more familiar with me, and i've further demonstrated my potential use of the privileges involved.

  I've begun work on my own tooling for spam hunting at the moment, a modified version of Headbomb's User:Headbomb/unreliable script that highlights common phrases and words that don't belong on-wiki and basically always point to spam. Much of the work involved is regex work, which I imagine will be helpful in the future for demonstrating I'm not clueless about how EFs function.

  Thanks everyone for your time, I'll be closing this thread in ~24h if I remember. —moonythedwarf (Braden N.) 14:17, 19 November 2020 (UTC)

So I recently tripped an edit filter and with edit summary reminder enabled, if I submit it without an edit summary the edit filter warning appears again, leading to a loop (EF warning -> summary reminder -> EF warning -> summary reminder) and so on. The only way I could escape this is entering an edit summary. Is this a known issue or what? FMecha (to talk|to see log) 06:06, 17 November 2020 (UTC)

yes, this is a known issue, phab:T21605 DannyS712 (talk) 16:56, 17 November 2020 (UTC)

IMHO, I think if a filter trips, you should definitely leave a summary explaining why your edit does not violate policy. The loop is only a minor set back, and you can always enter "m" for minor edits. And it only takes two seconds! Aasim (talk) 07:34, 23 November 2020 (UTC)

Does edit filter 320 have an exemption for Maternal insult and other similar pages? Thanks for your time. Opal|zukor^(discuss) 13:36, 1 December 2020 (UTC)

@Opalzukor: Yes :) Sam Walton (talk) 13:51, 1 December 2020 (UTC)

@Samwalton9: Many apologies, I could just have checked the edit filter. Sorry for your time. Opal|zukor^(discuss) 13:56, 1 December 2020 (UTC)

Deferred Changes has been mentioned many times in these archives, most recently by me in June. enwiki passed it in WP:DC2016. It would allow edit filters to queue edits for review. We're still stuck on the technical implementation. As a result, perhaps the following Community Wishlist item will be of interest to talk page watchers: m:Community Wishlist Survey 2021/Admins and patrollers/Implement deferred changes. ProcrastinatingReader (talk) 00:46, 11 December 2020 (UTC)

• Original discussion: Wikipedia:Edit filter noticeboard/Archive 6 § Better message for LTA filters

Reviving an idea from back in January. I think we should use a friendlier message for some filters. I won't repeat all the arguments made in that thread, but basically:

If the user is an LTA, they know they're going to get blocked. There's no need to put that in the message. In fact the wording doesn't really matter.

If they're not the LTA, the false positive is totally confusing. No need to WP:BITE, or let them think that their work has been deleted forever. (Many people at WP:EF/FP/R seem to think this).

Standard disallow message:

Proposed new message:

The previous discussion got bogged down in the question of whether we should use this message for LTAs only, or for general vandalism filters also. Let's start with some of the LTA filters, and go from there. Suffusion of Yellow (talk) 21:11, 10 November 2020 (UTC)

Pinging previous participants: @Newslinger, Reaper Eternal, MusikAnimal, Zzuuzz, and CAPTAIN MEDUSA: Suffusion of Yellow (talk) 21:14, 10 November 2020 (UTC)

Suffusion of Yellow, Maybe make it clear that they should not leave the current page, and should open the report page in a new window. —moonythedwarf (Braden N.) 21:17, 10 November 2020 (UTC)

@Moonythedwarf: After a filter has been triggered we have a permanent record of the attempted edit, so they don't need to stay on the same page. Unless I'm missing something. — MusikAnimal ^talk 21:23, 10 November 2020 (UTC)

MusikAnimal, I mean it as a way to allow them to personally keep the contents of the edit window. We may still have it, but they have no (obvious) way to get their edit back into the edit window. —moonythedwarf (Braden N.) 21:24, 10 November 2020 (UTC)

Support and frankly I think it's fine to do this for MediaWiki:Abusefilter-disallowed too, but I realize that's not the proposal :) — MusikAnimal ^talk 21:23, 10 November 2020 (UTC)

• Support per nom. ~~ CAPTAIN MEDUSA^talk 11:35, 11 November 2020 (UTC)
• Support. Thanks for reviving this, Suffusion of Yellow, and also for creating the message in this new template. As I stated in January, the proposed template is likely to be more effective than the current template at retaining good-faith editors who stumbled into the filtered pattern. Changing the template message would be unlikely to affect the behavior of any LTAs. Altogether, I expect the change to be a net positive: beneficial for good-faith editors and neutral for LTAs. — Newslinger talk 10:05, 16 November 2020 (UTC)
• Support but I would recommend amending the wording slightly to say “If this edit was constructive, please go the report page and follow the instructions.” OhKayeSierra (talk) 04:18, 22 November 2020 (UTC)

  @OhKayeSierra: I'm totally fine with vandals self-reporting to EFFPR. Makes their vandalism easier to find. Suffusion of Yellow (talk) 04:22, 22 November 2020 (UTC)

  @Suffusion of Yellow: Haha! That’s a very good point. I’ve struck my comment accordingly. OhKayeSierra (talk) 04:24, 22 November 2020 (UTC)

Support but I'd suggest using an exclamation point instead of a stop hand, and something like "We're sorry, but we could not save your edit because it matches an abuse filter "$1". Please contact an administrator or the edit filter management team explaining what you are trying to do. We apologize for the inconvenience." Aasim (talk) 07:22, 23 November 2020 (UTC)

Also, I'd propose this change to MediaWiki:Abusefilter-warning:

Aasim (talk) 07:31, 23 November 2020 (UTC)

@Awesome Aasim: The default Mediawiki:Abusefilter-warning should never be used for minor issues like "broken wiki markup". It's for edits that are probably bad-faith, but not always. Filters that target good-faith editors should always use a custom message that says exactly why that individual filter tripped, so the users knows what to fix. Suffusion of Yellow (talk) 02:48, 2 December 2020 (UTC)

Yep, but it can still happen on accident. We can get rid of the example, and leave it as "potential problems with your edit". Aasim (talk) 03:34, 2 December 2020 (UTC)

@Awesome Aasim: Can you give an example from one of the default message warn-only filters (most are public), where this would be helpful? What potential problems is a new user (who is ignorant of 99% of our policies and 100% of our MOS) supposed to look for? Suffusion of Yellow (talk) 02:11, 5 December 2020 (UTC)

Extraneous markup, too many links, etc. It does not imply wrongdoing but it serves as a safety in case a filter manager forgets to set a warning message. Aasim (talk) 02:44, 5 December 2020 (UTC)

• Support, looks good! Enterprisey (talk!) 08:32, 30 November 2020 (UTC)
• I'm not sure exactly which one of these we are discussing now, but telling editors that "Don't worry, your work has not been lost! The full content of this edit has been saved, but it will not be visible to readers unless you take further action." is not accurate - we have not "saved" anything here and shouldn't be saying that. — xaosflux ^Talk 15:23, 1 December 2020 (UTC)

  Hmm, we do technically have a copy of their edit logged, right? And for a new editor seeing that message I'm not sure the distinction matters, and it's certainly more understandable than "Do not fret, the time you spent writing the edit has not been wasted! Your attempted edit's revision has been logged in the edit filter logs." ProcrastinatingReader (talk) 15:48, 1 December 2020 (UTC)

  We should not try to assure an editor that their efforts are "saved" just because it is in a (possibly private) log file - then having to make a workflow for them to engage someone to retrieve what is "saved" for them out of said log. If you want to refer to it still being on the screen, "available below" may be better. — xaosflux ^Talk 16:10, 1 December 2020 (UTC)

  If the editor wants to reconsider that for future publication, they should save it locally. — xaosflux ^Talk 16:13, 1 December 2020 (UTC)

  @Xaosflux: I'm just trying to say "Don't Panic!" Would replacing "saved" with "stored on the server" be acceptable? Suffusion of Yellow (talk) 02:45, 2 December 2020 (UTC)

  @Suffusion of Yellow: I don't think any of those are good. For one, we shouldn't try to guarantee that the AF log will be there for revision recovery. But simpler, what is the workflow supposed to be in that situation from a UX perspective? If an editor gets an AF filter disallow, this tells them to go fill out an EF/FP report - then what? An admin is going to go find the AF log of wikitext and do what with it - send it to their talk page so that they can c/p it back in to the article the original editor was trying to update? — xaosflux ^Talk 03:39, 2 December 2020 (UTC)

  @Xaosflux: Most of the time, we just save it for them, and credit them in the summary. Are you thinking about the situation where the text isn't vandalism, but still needs major fixes, i.e. not something the EF/FP "clerk" wants to waste time with? That's pretty rare, and yes, we could save it to a sandbox instead.

  But I suppose they might want to save a copy locally too. Can you suggest an alternate phrasing of the second paragraph? All I really care about is not calling the edit "disruptive" or threatening the user with block. Suffusion of Yellow (talk) 02:11, 5 December 2020 (UTC)

  @Suffusion of Yellow: I'm just considering that while their edit was an attempt to create the derivative work of the page they were editing, it didn't actually complete the publication in these scenarios - so then for someone else to publish their failed attempt based on log data may lead to attribution licensing issues. (The original author never actually published their changes, and the "recovering" editor is using the first editor's original work - and even possibly incorporating it in to an encyclopedia article - but there is not a use license from the original author.) I'm fine with any improvements about changing the appearance of disruption/blocking/etc, my only concern was about the "saving" part and then potential fall out from the licensing side about that. — xaosflux ^Talk 03:01, 5 December 2020 (UTC)

• @Xaosflux: That's how we've been doing it for years. User:Suffusion of Yellow/effp-helper, which I wrote based on what was already common practice in 2018, has over 25 users (including several admins and a WMF employee and steward) and has probably been used for thousands of edits. I think if there was a legal issue, someone would have brought it up by now. When they clicked "publish", they agreed to the CC-BY-SA. Suffusion of Yellow (talk) 03:16, 5 December 2020 (UTC)

  It does say "By publishing changes, you agree..." and it is arguable that the change was not actually "published" in these cases. Also, as EF is fickle I don't think we should be trying to advertise that we have actually "saved" their attempted publication. — xaosflux ^Talk 03:27, 5 December 2020 (UTC)

  And "but it will not be visible to readers" is also a bit dubious, it suggests that the saving has been done in some sort of private manner - which isn't necessarily true. — xaosflux ^Talk 03:28, 5 December 2020 (UTC)

  It said "By clicking the ... button" until Special:Diff/738595177. Which was apparently based on the concern that people who press "enter" instead of clicking might not be agreeing to the license. If the unintended effect was to cause us to host millions of copyright violations at Special:AbuseLog, that definitely needs to be fixed.

  IANAL, but I don't think it's a problem. The user's intent was clear enough. Unless they knew in advance that the edit would be disallowed, they intended to publish their changes, so they agreed.

  I'll address your other point re. public filters once I think of a better wording. I was thinking of the WP:READER but I guess it could be taken to imply anyone who accesses the site. Suffusion of Yellow (talk) 21:02, 5 December 2020 (UTC)

• Support --DannyS712 (talk) 03:17, 22 December 2020 (UTC)

Can we adjust 602 to also flag usages of {{Ds/aware}} (insertion and removal)? Reason being that currently system logs don't flag it, so when filing a WP:AE report one has to dig the page history (or use WikiBlame) to find an inserting edit. Similarly, if it's removed (but was present at time of problematic diffs) one may not realise the person was aware at the time. Example case is this current AE case, with this log. ProcrastinatingReader (talk) 16:32, 15 December 2020 (UTC)

Technically, wrap lines 6 to 10 in brackets and add an or condition to detect insertion/removal of template text. ProcrastinatingReader (talk) 16:35, 15 December 2020 (UTC)

Would it make sense to have a separate tracking filter, since the tag name ("discretionary sanctions alert") doesn't really apply to this? Or since its close enough... either way, it would be a good idea to track them somehow DannyS712 (talk) 03:19, 22 December 2020 (UTC)

Hmm. Partially no, as it just means an editor will have to click two links every time they try to check if an editor is aware of a sanction. Just having to check one is bad enough (in terms of effort), heh. However, there is some slight extended nuance in the sense that normal alerts expire after a year, and these stay forever until removed. So in that sense, maybe yeah, it’s worth another filter and updating our links to show the filter log of both filters together (using a pipe). The different tag (ds/aware modified) may be helpful. ProcrastinatingReader (talk) 13:09, 22 December 2020 (UTC)

IP address has used the term "bruv" on the page John O. Bennett. I know that the phrase Bruh is disallowed through 614, but the term Bruv which is also used in vandalism trends is similarly used (especially by IPs and newly registered users wishing to circumvent the filter). Can you please add Bruv to 614? Thanks. Train of Knowledge (Talk) 23:03, 3 December 2020 (UTC)

@Ohnoitsjamie: since you added "bruh", thoughts on "bruv"? DannyS712 (talk) 03:18, 22 December 2020 (UTC)

 Done I'll note that there are a few legitimate uses of it (titles, quotes), but no more than "bruh." OhNoitsJamie ^Talk 14:50, 22 December 2020 (UTC)

Just started Wikipedia talk:Edit filter helper#Nomination requirement?; thoughts welcome. Enterprisey (talk!) 05:20, 23 December 2020 (UTC)

Noticed 712 exists whilst reviewing Wikipedia:Bots/Requests for approval/BattyBot 53. Could we change this filter to also track changes in death date, not just birth date? Pinging Galobtter & Rich Farmbrough who may have interest in doing this (or anyone else!). Thanks, ProcrastinatingReader (talk) 20:23, 31 December 2020 (UTC)

ProcrastinatingReader  Done All the best: Rich Farmbrough 03:57, 1 January 2021 (UTC).

Thanks Rich! ProcrastinatingReader (talk) 04:11, 1 January 2021 (UTC)

• Change facebook|twitter|instagram| to facebook|fb|twitter|instagram|ig|
• Change me|us to me|us|him|her|them
• Optionally, enable for userspace (maybe not user talk though) as it's already filtering by auto-confirmed, so this could catch some U5-type promo, if that's desirable for this filter. Draft might also be viable, but possibly unnecessary. Excluding draft, this would be page_namespace == 0 to equals_to_any(page_namespace, 0, 2).

Perryprog (talk) 22:00, 3 January 2021 (UTC)

One other abbreviation that could be helpful might be "insta".

I'm also wondering if this filter could be generalized a little bit more, although that could, of course, lead to more false positives. Maybe something like checking for added text of one of the sites and a separate check for anything that looks like a social media handle, probably in the same line. This could potentially catch a wider range of situations like "Their insta: @foobar". (I'm not totally sure what the idiomatic way of implementing that would be, though.) Perryprog (talk) 22:12, 3 January 2021 (UTC)

• I added the abbreviations. The filter already catches him/her/them (though it may not be obvious from the code) as you can see at Special:AbuseLog/28525256. Also this sort of request should go to WP:EFR. Thanks! Crow^Caw 22:18, 3 January 2021 (UTC)
  • To the other items mentioned, I didn't add userspace as we do allow some leeway to users for that kind of thing. If their user page consists of *only* social media then NPP should catch it, but if its a passing line in a page full of wikipedia related stuff then it typically gets a pass. Similarly we allow limited social media listings in articles under certain conditions so an outright block of handles would be implementing a policy that doesn't exist. Crow^Caw 22:24, 3 January 2021 (UTC)
    • Fair enough, the net certainly seems wide enough as it is. Perryprog (talk) 22:56, 3 January 2021 (UTC)
  • Crow, I might be wrong because I'm pretty tired, but I believe the filter currently doesn't catch things like "follow them on @foobar at ig"; the example you linked only worked due to an alteration that looks for something similar to a handle (one word, maybe with an @)—this alteration still needs a directly preceding verb, so stuff it matches looks like "follow @foobar on instagram" and not "follow them on @foobar at instagram".

    Sorry for posting this in the wrong place; I was under the impression that EFR was for requesting new filters—its header only seems to mention requesting new filters, so it wasn't very obvious where to post this. Perryprog (talk) 22:54, 3 January 2021 (UTC)

• Yes it would not catch the extended version as you mentioned. It should be easy enough to have it catch "follow <pronoun> on/at @handle" with a quick variable add. It seems like that should be enough without needing the platform name in that case as it is clearly a social media spam at that point. Crow^Caw 23:05, 3 January 2021 (UTC)
  • Good point—that would also lead to a less convoluted regex. I could possibly look into rewriting it with that in mind (likely not today though), assuming you or someone else aren't already planning to. Also, the non-talk page CSS really makes this indentation funky :(. Perryprog (talk) 23:14, 3 January 2021 (UTC)

• I've made the change to 1043, added the handle text check. Crow^Caw 23:16, 3 January 2021 (UTC)

Related to some recent discussions about the bar for entry for EFH, phab:T242821 proposes splitting the right to use the testing interface to be separate from the right to view private filters. --DannyS712 (talk) 22:15, 5 January 2021 (UTC)

I believe that the Wikileaks filter is misleading. The description at Special:Tags says "This edit added a deprecated source. Deprecated sources are not usually appropriate for Wikipedia articles" however Wikileaks is not a deprecated source (it's classified as generally unreliable and the consensus is that "It may be appropriate to cite a document from WikiLeaks as a primary source, but only if it is discussed by a reliable source"). Due to the tag wording users who see edits tagged by this filter revert such edits thinking it's a deprecated source.

Please note that we already have a filter for true deprecated sources. As far as I can tell there is no tag for unreliable sources - as many of them have certain legitimate uses - so the wikileaks filter should be deactivated for now. I'm not against marking generally unreliable sources but it should be a community decision and it should be applied to all of them rather than selectively. Alaexis_¿question? 21:59, 27 December 2020 (UTC)

It is possible to have a filter for a particular non deprecated source. An RfC found consensus to warn for adding Facebook, for example. Not sure about Wikileaks. ProcrastinatingReader (talk) 01:32, 28 December 2020 (UTC)

It's certainly possible but having read all posts on Wikileaks at WP:RSP (there are 13 of them) I haven't found any discussion, let alone consensus on edit filters. Alaexis_¿question? 07:21, 28 December 2020 (UTC)

Filter created by JzG so he can probably answer your question better, but I’m acutely aware he’s taking a semi-wikibreak atm. ProcrastinatingReader (talk) 13:24, 28 December 2020 (UTC)

I understand that he must have got an alert when you mentioned him? Let's at least fix the factually incorrect wording (Wikileaks is not deprecated) and then discuss the merits of tagging such edits. Alaexis_¿question? 07:34, 30 December 2020 (UTC)

@ProcrastinatingReader: as we are still waiting for JzG's response, could you fix the incorrect wording? Alaexis_¿question? 13:31, 6 January 2021 (UTC)

Only an admin can edit the interface page for the warning. But I don’t believe mediawiki:Abusefilter-warning-WikiLeaks says it’s deprecated, simply that it’s generally unreliable, which appears to be its RSP classification? ProcrastinatingReader (talk) 08:20, 12 January 2021 (UTC)

Sorry, I thought you had the permissions to do it. You are right, but I was referring to the small tags that appear next to edits (example) where the word "deprecated" does appear. Alaexis_¿question? 06:56, 18 January 2021 (UTC)

Can someone fix the wording or explain why it shouldn't be changed? It seems like a matter of a few minutes. Alaexis_¿question? 09:45, 23 January 2021 (UTC)

@Alaexis: I've had a quick look and don't see why the tag shouldn't be changed, however there is no obviously existing tag already available to change it to (see Special:Tags) so that would need creating first. That's not an area I've ever worked in so don't know the how or what the associated policies/guidelines/conventions are so I can't help directly. I see your question at Wikipedia talk:Tags has gone completely unanswered so referring you there seems pointless. I do note that JzG appears to have returned from their wikibreak so maybe they will be able to answer the query above. Thryduulf (talk) 02:37, 24 January 2021 (UTC)

@Thryduulf: Thanks for the answer. I didn't realise the tag and the filter are separate things. Sure, let's wait for them some time. By the way, I haven't been able to find how this tag/filter came about, considering that there are lots of other "unreliable" sources which are not tagged this way. Probably there was a good reason, but I'd like to know if there was a consensus. Alaexis_¿question? 06:25, 24 January 2021 (UTC)

@Thryduulf: A new tag is created when a filter is saved with a non-existent tag. I have done so.

Two more steps, admin-only:

1. Create the page MediaWiki:Tag-WikiLeaks. This is what will display in revision histories, user contributions, recent changes, etc. You can use wikitext, but keep it short.
2. Create the page MediaWiki:Tag-WikiLeaks-description. User the {{Tag description}} template and be sure to specify the filter ID. This is what will appear at Special:Tags, and the dropdown menu at Special:RecentChanges, etc.

As to your other question, Alaexis, I think it was a WP:BOLD move by JzG but I could be mistaken. Suffusion of Yellow (talk) 20:22, 24 January 2021 (UTC)

Thank you. Alaexis_¿question? 21:33, 25 January 2021 (UTC)

CaptainEek semi-protected this for a day, I brought it up on their talk page, but they seem to have gone offline mid-conversation. This protection makes no sense. The vast majority of filters start with !("confirmed" in user_groups). There's no point in having this page, if it's protected. I'm nervous now to update 1112; a serious mistake could cause a flood of FPs to disappear into the bigger flood of bad edits. BS reports can be removed without comment.

Also can someone answer my request at MediaWiki talk:Abusefilter-disallowed-1112? The new message might cut down on bad reports. If it makes it worse, I'll switch back to the default. Suffusion of Yellow (talk) 00:16, 27 January 2021 (UTC)

@Suffusion of Yellow: You'll notice I've added the filter message. I'm generally in favour of unprotecting EFPR, but I am about to go offline and think it would be irresponsible for me to unprotect the page without monitoring it for at least a while. These are extraordinary levels of nonsense, and I'd expect it to persist. Of course the filter message doesn't make as much sense without unprotection. -- zzuuzz ^(talk) 00:36, 27 January 2021 (UTC)

Thanks. IMO, since EFFPR is not a reader-facing page, there's only so much harm that people can cause there. Suffusion of Yellow (talk) 00:41, 27 January 2021 (UTC)

Suffusion of Yellow, That message is a suitable addition for me, I have removed the protection. Sorry about the late response, the real world suddenly pulled me away :) CaptainEek ^{Edits Ho Cap'n!}⚓ 03:55, 27 January 2021 (UTC)

@CaptainEek: Of course, WP:NOTCOMPULSORY. But before I start unpacking the case of WP:TROUT, you unprotected the wrong page. That should be Wikipedia:Edit filter/False positives/Reports, not Wikipedia:Edit filter/False positives, which should be indef semi to prevent "free-form" reports. Suffusion of Yellow (talk) 03:59, 27 January 2021 (UTC)

 Done. Let's see how it goes. I note that lots of people were posting on the EFPR talk page instead, so it ain't over yet. It'll probably pick up again bigly when we hit US-time. -- zzuuzz ^(talk) 11:46, 27 January 2021 (UTC)

See this AN/I thread for context. --C o r t e x ^💬talk 22:53, 21 January 2021 (UTC)

@Cortex128: A bit busy now, but see 1111 (hist · log). Just monitoring all redlinks right now. Any suggestion from anyone about narrowing it down? It looks to be too spammy to monitor the log. Also @DannyS712 and MusikAnimal: that's not showing up on the slow filters dashboard, is it? Suffusion of Yellow (talk) 02:24, 23 January 2021 (UTC)

@Suffusion of Yellow: No hits in the Slow Filters Dashboard so far, but I agree the implementation looks expensive. I'm not sure how effective this will be, to be frank. We'll at least need to check for "Notable people" or something in the entire wikitext, as adding red links by itself is a super common newbie thing to do. Also several examples from the AN/I thread did not involve links at all. Perhaps we should instead look for something like ^\*\s*(?:\[\[)?\w+ \w+ since they're usually bulleted items followed by a first and last name. — MusikAnimal ^talk 02:53, 23 January 2021 (UTC)

@MusikAnimal: Thanks for checking. See also 1112 (hist · log), which is also overly broad in its own way, but I'll look for patterns in the log tomorrow. Suffusion of Yellow (talk) 03:47, 23 January 2021 (UTC)

@MusikAnimal and Suffusion of Yellow: With no objection to enhancing effectiveness, at the moment this filter actually seems to have a reasonable heat:light ratio for crap edits. My back of the envelope observation is well over 1/4 have been (and should have been) reverted at first sight. Although once this TikTok shenanigans dies down, the cost:benefit balance may very well tip in a different direction... --Jack Frost (talk) 03:51, 23 January 2021 (UTC)

Set filter 1112 to warn, temporarily?

This is flooding in at an absurd rate. The filter is not perfect, but it should hopefully be only a few days before the TikTok kids move on to the Nose Bean Challenge or whatever. Should there a be custom warning? On the one hand there will be some innocent users who don't know about WP:N etc.. On the other, I don't want to tell people how to avoid the filter. Suffusion of Yellow (talk) 23:35, 23 January 2021 (UTC)

In my experience, usually, the people adding non-notable people to an article are not trying to neutrally add links to provide a more thorough list, but are trying to add a particular person to an article. If this is also generally true, I doubt linking them to WP:N or telling them the rules for adding links will be of much positive help to them. ProcrastinatingReader (talk) 00:18, 24 January 2021 (UTC)

I've set it to warn with the default message. We'll see how many click past the warning. Suffusion of Yellow (talk) 20:34, 24 January 2021 (UTC)

And now set to disallow

• 1112 (hist · log)

This is ridiculous. 50 saved changes in last hour in spite of the warning, with only a few FPs. I've set the 1112 to disallow, but it shouldn't be left that way longer than necessary, unless someone can reduce FPs more. Suffusion of Yellow (talk) 22:17, 24 January 2021 (UTC)

And see 1113 (hist · log) in case people start evading 1112 (prefer to keep it public so more users can help with FPs). Really really broad, private, log-only. View the log with saved changes only to see what's slipping by. Suffusion of Yellow (talk) 22:46, 24 January 2021 (UTC)

1112 seems to be working well, its keeping a lot of the edits out. Only two construcitve edits that were disallowed reported at EF/FP: Special:AbuseLog/28715624 and Special:AbuseLog/28712573. A few false negatives: Special:diff/1002747243, Special:diff/1002751787 and a few others flagged by 1111. Pahunkat (talk) 22:11, 25 January 2021 (UTC)

Any objections to this disallow message?

Yes, it's making certain assumptions that aren't always going to be true. But it gets right to the point, and won't leave them wondering what's "disruptive" about the edit. Suffusion of Yellow (talk) 00:56, 26 January 2021 (UTC)

Yeah, that's fine. ~ ToBeFree (talk) 08:37, 26 January 2021 (UTC)

Looks fine, that will work well. Pahunkat (talk) 09:04, 26 January 2021 (UTC)

Works for me. --C o r t e x ^💬talk 00:18, 27 January 2021 (UTC)

Can I just remove reports from EF/FP or request immediate archiving? Quite a few of these editors who've been stopped for the right reasons by the filter are posting reports that will obviously have no action. Pahunkat (talk) 21:16, 26 January 2021 (UTC)

@Pahunkat: If it's a hopeless case, sure, just remove it. If it might be someone notable, best to ask for sources. Thanks for all your help there, BTW! 22:05, 26 January 2021 (UTC)

No problem! BTW, I think the bot's down on EF/FP - not sure why. Pahunkat (talk) 20:43, 27 January 2021 (UTC)

Ok, fixed by Suffusion of Yellow now. Pahunkat (talk) 22:04, 27 January 2021 (UTC)

This may not be the correct place to post this, however I noticed recently that reverting an edit will erroneously trigger edit filter 686. Link.

I don't see any explicit check for a reverted edit in Extension:AbuseFilter but something like this could be used:

!"confirmed" in user_groups &
page_namespace == 0 &
old_wikitext rlike "Category:Living people" &
edit_delta > 200 & !added_lines rlike "\|-" &
rcount ("<ref\b|http|[Ii]nfobox", added_lines) <= rcount ("<ref\b|http|[Ii]nfobox", removed_lines) &
!summary contains "(Undid revision "

It's a quick fix and there's almost certainly a better way to do it, so someone smarter than me ought to figure it out. — Preceding unsigned comment added by Catalyzzt (talk • contribs)

I don't think that's a false positive. Your revert reintroduced unsourced material to a BLP, thus the tagging is correct. Thus this seems to be an example of why the filter shouldn't exclude reverts, because many people revert IPs who are removing bad content and that should be tagged. ProcrastinatingReader (talk) 17:28, 29 January 2021 (UTC)

Hi, wanted to mention how useful the "CSD tag removed by page creator" tag is when wading through a watchlist. If there are any plans on reopening that discussion from last May about setting it to disallow then I would be in support of that! (Doesn't seem like anyone was really opposed to it) – Thjarkur (talk) 22:49, 23 January 2021 (UTC)
— Special:Permalink/1002340365

As Thjarkur has reminded me on my talk page: Any objections to setting filter 1060 to disallow?

Proposed disallow message: MediaWiki:Abusefilter-disallowed-remove-csd.

~ ToBeFree (talk) 02:31, 24 January 2021 (UTC)

if possible, allowing removal of tags the creator placed themselves would probably be sensible. Thryduulf (talk) 02:39, 24 January 2021 (UTC)

Line 4 of the filter exempts these. ~ ToBeFree (talk) 02:41, 24 January 2021 (UTC)

@ToBeFree: Might be better to link to {{TALKPAGENAME}} instead of Help:Talk pages? Suffusion of Yellow (talk) 04:06, 25 January 2021 (UTC)

Definitely! I wasn't aware such an easy magic word exists for the purpose, and I was unsure if it works in the filter message, so I just copied the warning code which had a link to Help:Talk pages instead. Fixed in the above example and on the MediaWiki page. ~ ToBeFree (talk) 19:22, 25 January 2021 (UTC)

Disallowing would be quite beneficial. Would suggest allowing the removal of: A1/A3/G2 (usually an article that's a work in progress and was prematurely tagged), G6 and R2 (the draftify script adds an R2 but you might want to create a redirect from it), and A7 etc outside of mainspace (some new authors move their A7 articles to draftspace after it has been tagged and try to work on it further). – Thjarkur (talk) 21:55, 25 January 2021 (UTC)

Thanks, implemented. A1, A3, G2, G6, R2 exempted per request; ACSD exempted from non-mainspace articles. ~ ToBeFree (talk) 19:46, 27 January 2021 (UTC)

 Done ~ ToBeFree (talk) 08:41, 31 January 2021 (UTC)

I was wondering if filter 733 could be set to disallow. This is because there's not really any reason for a new user to create a page in someone else's userspace, and also to stop the LTA Evlekis who attacks like that all the time. It might also be helpful for this to include the user talk namespace. Pahunkat (talk) 21:25, 21 January 2021 (UTC)

Draft:DWTS ALL STARS was created as User:Bailando con las Estrellas/DWTS ALL STARS by a new account of the soft-blocked user Bailando con las Estrellas (talk · contribs). I generally support setting filter 733 to disallow, but the disallow message must explain how to easily rescue the creation by opening Wikipedia in a new tab, clicking "Sandbox" at the top and copying the content there. ~ ToBeFree (talk) 03:12, 24 January 2021 (UTC)

The disallow message should be clear enough to make, but does anyone have objections to setting it to disallow? Pahunkat (talk) 22:05, 30 January 2021 (UTC)

In all honesty, I don't think this would do much. Evlekis does the same kinds of page creations also in the Talk and Drat/Draft talk namespaces. Sro23 (talk) 18:05, 31 January 2021 (UTC)

@Ohnoitsjamie and Suffusion of Yellow: Multiple attempts, the last one successful at saving. https://en.wikipedia.org/w/index.php?title=Special:AbuseLog&wpSearchUser=172.58.203.179 ~ ToBeFree (talk) 11:09, 31 January 2021 (UTC)

@ToBeFree: Special:AbuseFilter/history/909/diff/prev/24520 Suffusion of Yellow (talk) 19:15, 31 January 2021 (UTC)

There's about 20 requests for filters there, and at least a few seem like useful suggestions. Can some more people take a look at processing some of those requests? ProcrastinatingReader (talk) 08:41, 10 February 2021 (UTC)

• 1102 (hist · log) (private)

First, see my summary of the most recent 50 unique users to trip this filter. Mostly vandalism, a few very aggressive edit warriors, and one weird FP. The only obvious way decrease the possibility of that kind of FP would be to increase the number of edits allowed before the filter trips. I'm willing to do that if anyone is bothered by that FP; the filter will still catch the worst cases.

This is the disallow message I have in mind:

Yes, I'm telling people one way to evade the filter! But I think that's fine; this filter should only trip after one or more editors are already aware of the disruption. It's basically just meant to slow them down until an admin looks at WP:AIV or WP:AIV/TB2. Even they aren't reported, they'll probably get bored in that time anyway. And for the FPs, waiting seems preferable to begging for help at EFFP. Suffusion of Yellow (talk) 20:54, 2 February 2021 (UTC)

If the false positive had happened, with this specific error message, it would have been fine. And setting the filter to disallow seems nicely reasoned. ~ ToBeFree (talk) 22:17, 4 February 2021 (UTC)

 Done. Suffusion of Yellow (talk) 18:41, 14 February 2021 (UTC)

Not sure is this is the right place to ask, but how to help at edit filters without special permissions like EFH or EFM? Steve M (talk) 01:43, 19 February 2021 (UTC)

@Steve M: most filters are not hidden, and general discussion, help, and review is welcome here, at WP:EFFP and WP:EFR. — xaosflux ^Talk 01:49, 19 February 2021 (UTC)

• 1122 (hist · log) (private)

No, I don't like it either. Please comment on the mailing list, if desired. Suffusion of Yellow (talk) 17:32, 20 February 2021 (UTC)

Also see 1123 (hist · log). Suffusion of Yellow (talk) 21:34, 20 February 2021 (UTC)

It's a relatively minor thing, but given that 1060 has been set to disallow shouldn't the filter be renamed to something like "Attempted CSD tag removal by creator" instead of "CSD tag removed by page creator"? Pahunkat (talk) 19:00, 20 February 2021 (UTC)

@Pahunkat: I renamed it to "Disallow CSD tag removal by page creator" - as that is what it now does. — xaosflux ^Talk 05:32, 21 February 2021 (UTC)

Xaosflux, thanks for doing that :-) Pahunkat (talk) 17:03, 21 February 2021 (UTC)

• 1120 (hist · log) (public)

Obligatory notification; just a boring meme. Suffusion of Yellow (talk) 03:22, 23 February 2021 (UTC)

• 1124 (hist · log) (public)

Standard notification; another boring meme. Suffusion of Yellow (talk) 16:55, 23 February 2021 (UTC)

@Suffusion of Yellow: Just got a false positive on this filter after it was set to disallow. See Special:AbuseLog/29110993, no relation to the Among Us meme, as far as I can tell. EggRoll97 ^(talk) 06:47, 24 February 2021 (UTC)

@EggRoll97: Thanks. That sort of FP, like song titles containing "fuck", is gong to be difficult to prevent, but I at least excluded "Gods Among Us". Suffusion of Yellow (talk) 17:32, 24 February 2021 (UTC)

(via discord) [5] is an example of the edit that is triggering 1113 as a false-positive. There is a section entitled "List of notable Canadians of Romanian ancestry", but I hope that wouldn't trigger the filter for an edit adding a maintenance tag. My guess is that this is triggering as a false positive since nothing is removed, but I'm certainly not an expert at edit-filters. power~enwiki (π, ν) 05:14, 24 February 2021 (UTC)

@Power~enwiki: 1113 (hist · log) (log-only) is supposed to be a really broad filter catching whatever slips by 1112 (hist · log) (disallow). If there's a specific kind of FP that's making the log so spammy that it's not worth checking, that might be worth fixing, but I don't see any other examples of templates being added in the last 100 hits. Suffusion of Yellow (talk) 17:43, 24 February 2021 (UTC)

The page ID is 66355661, not 63640560. 83.6.99.89 (talk) 07:45, 25 February 2021 (UTC)

It seems a page with ID 63640560 does not even exist. Wonder what happened there? ProcrastinatingReader (talk) 11:53, 25 February 2021 (UTC)

Ah... It was originally changed by GeneralNotability as a result of this discussion. Looks like it changed again because it was deleted again. Good catch, IP. ProcrastinatingReader (talk) 11:56, 25 February 2021 (UTC)

It seems to get deleted a lot, so I've converted it to use the page title instead. -- zzuuzz ^(talk) 12:06, 25 February 2021 (UTC)

Courtesy notification: per the rules at WP:EFH, I've granted Blablubbs the EFH bit since he is SPI clerk trainee. A bit of IAR here - the rules as written say that the bit should be granted by a CheckUser, and I'm not a CU, but I received permission from TonyBallioni, who is both a CU and Blablubbs's trainer. WP:NOTBURO and all that. GeneralNotability (talk) 00:28, 23 February 2021 (UTC)

Thanks GN. KevinL (aka L235 · t · c) 03:00, 26 February 2021 (UTC)

I was unable to undo the blanking/redirection of Bibliography of South America because of a filter warning of links or references running through a local proxy. I am aware that the reason for this error is that the bibliography contains links on EBSCO which need to be fixed. However, the more pressing issue is that the complete blanking and redirection of the page without prior discussion should be reverted. I am unable to do so because of the filter, and I determined this would be the appropriate place to note it. I apologize in advance if this is not the correct place. ―NK1406 03:20, 4 March 2021 (UTC)

NK1406, I've done that for you as a contested bold edit - I didn't get stopped by the filter when using RW. Please attempt to discuss it with Reywas92 though. Pahunkat (talk) 17:25, 4 March 2021 (UTC)

FYI next time adding a report at WP:EF/FP/R might get something like this noticed quicker. Please also fix the links if possible :-) Pahunkat (talk) 17:28, 4 March 2021 (UTC)

Yes, it's always possible to bypass filters and the spam blacklist using rollback. I was also about to say "just fix the links then", but it seems there are 69 EBSCO links on the page, and they've been there since it was created in 2010... Suffusion of Yellow (talk) 17:49, 4 March 2021 (UTC)

• 1126 (hist · log) (public)

Standard notice. See Wikipedia:Administrators' noticeboard/IncidentArchive1060#Uptick in vandalism on months pages. The vandalism had completely stopped, but picked up again today. Of course this can be merged with another filter later, but it's useful to track it separately for now. Suffusion of Yellow (talk) 19:27, 4 March 2021 (UTC)

• 1131 (hist · log) (private)

Obligatory notice. Just another LTA; logging separately but will likely merge to 906 (hist · log) once I see what effect the filter has on their behavior. Suffusion of Yellow (talk) 20:29, 16 March 2021 (UTC)

Can we improve Wikipedia:Edit filter/Requested/Header somewhat? My proposal is at User:ProcrastinatingReader/sandbox9. Contains various changes from observing EFR over a period of time, and (now) having some experience of seeing requests through the lens of an EFM:

• Requests without diffs, sometimes without even links to the relevant SPIs, are not motivating to take on (imo). Also providing diffs makes more clear what is actually requested in some cases.
• Revdelled edits are a pain. A lot of requests seem to include revdelled edits, which I can't see. So that includes a note to email them to the list
• Trim fluff / cut down on some of the extensive verbiage to make it more likely the notice is actually read + other copyedits
• More clarity on sending details of LTA filters to the list, rather than public discussion (on that note, I think we're overusing private filters, but that's a future discussion). Include email rather than a link to WP:EFMAILING.

ProcrastinatingReader (talk) 13:40, 9 March 2021 (UTC)

If I'm allowed to comment as a non-EFM, then the changes appear sensible to me. I'd recommend updating the "click here to create a new section" to preload the new wikitext including the "diffs" line, but no doubt you've already thought of that :) ƒirefly ( t · c ) 15:25, 9 March 2021 (UTC)

Not going to lie, I didn't even notice that button was there (somehow), never mind notice the preload needs updating! My eye scans material in strange ways, I guess. ProcrastinatingReader (talk) 15:40, 9 March 2021 (UTC)

ProcrastinatingReader, Most of this looks great to me with two nitpicks:

The edit filter is primarily used to address common patterns of harmful editing. I think Edit filters areprimarily used to address common patterns of harmful editing. might be better, since technically its one system but there are multiple filters. It also feels a bit odd to establish the edit filter and then have people ask for a new one.

Not directly related but related to the edit notice, Template:Editnotices/Page/Wikipedia:Edit filter/Requested right now states please consider emailing the edit filter mailing list at wikipedia-en-editfilters@lists.wikimedia.org. I feel like the wording could be changed here to something stronger. Asartea ^{Talk | Contribs} 09:43, 10 March 2021 (UTC)

Thanks, done that copyedit. ProcrastinatingReader (talk) 18:05, 10 March 2021 (UTC)

@ProcrastinatingReader: Looks good, except I'd leave out the line where there's a reasonable suspicion that the LTA is technically proficient. I really don't like it when people say publicly "Can you create a filter to stop the LTA who says 'Ni'?" because if they find EFR, they are now the LTA who until recently said "Ni". It's not only a question of technical proficiency; even if they can't read regex, they can still read the plain English description that filter-requestor "helpfully" provided at EFR. Suffusion of Yellow (talk) 21:35, 10 March 2021 (UTC)

Suffusion of Yellow, In a similar vein might I propose changing editnotice from consider emailing to email? Asartea ^{Talk | Contribs} 07:11, 11 March 2021 (UTC)

Done and updated the header. Haven't looked at the editnotice yet (re Asartea's cmt above). ProcrastinatingReader (talk) 17:04, 13 March 2021 (UTC)

Updated the editnotice slightly. ProcrastinatingReader (talk) 20:47, 18 March 2021 (UTC)

I noticed an IP added a non-existent template to an article page. I think there should be an abuse filter for that to warn new editors about it.

What it may look like:

And for sandbox templates:

Aasim (talk) 07:44, 19 March 2021 (UTC)

@Awesome Aasim: I'm not aware of a trigger for (new transclusion of page that doesn't exist), is there a parameter you had in mind (nb old_html is disabled for performance)? — xaosflux ^Talk 10:31, 19 March 2021 (UTC)

Can use something like 1111 (hist · log). That doesn't catch templates because it's looking for [[ not {{. The logic of that filter is not precise enough for a warning filter though, but I might be able to work something out. Suffusion of Yellow (talk) 22:55, 19 March 2021 (UTC)

• 1134 (hist · log) (private)

See the mailing list. Suffusion of Yellow (talk) 23:15, 26 March 2021 (UTC)

A few new user scripts that I hope will be useful for EFMs:

• filterDiff: Adds a "Show changes" button to the filter editor. Great anxiety-reducer!
• filterTest: Adds a "Test changes" button. Opens Special:AbuseFilter/test with what's currently in the edit form, not with what's saved in the database, so you don't have to copy-paste your changes.
• filterNotes: Parses filter notes as wikitext (so links are clickable), and signs and dates new comments for you.

Suffusion of Yellow (talk) 20:34, 21 March 2021 (UTC)

As a non-EFM, I love these scripts. JJP...MASTER!_{[talk to] JJP... master?} 00:40, 26 March 2021 (UTC)

@JJPMaster: Thanks! Now that you say it, I suppose filterNotes could be useful to non-EFMs. I'll try to remove the "add note" box for users who can't edit filters, when I get around to it. But what do the other scripts do for you? Suffusion of Yellow (talk) 21:04, 27 March 2021 (UTC)

@Suffusion of Yellow: filterTest and filterDiff require EFM (and I therefore cannot use them), but filterNotes is quite useful (because I see [[]] syntax in filter notes quite often), however the add note button actually allows me to add pseudo-notes (and they actually appear in the note box) until I purge the page and they disappear. JJP...MASTER!_{[talk to] JJP... master?} 21:11, 27 March 2021 (UTC)

@JJPMaster: Is that something you actually want to do? I'll leave it alone, then. Suffusion of Yellow (talk) 21:13, 27 March 2021 (UTC)

@Suffusion of Yellow: if you mean adding "pseudo-notes", no, I do not actually want to do that. JJP...MASTER!_{[talk to] JJP... master?} 21:15, 27 March 2021 (UTC)

@JJPMaster: The useless parts should be removed now. Notes are still parsed, but for users without EFM acccess, there should only be a "View source" button. Suffusion of Yellow (talk) 23:18, 27 March 2021 (UTC)

@Suffusion of Yellow: Thank you. JJP...MASTER!_{[talk to] JJP... master?} 23:20, 27 March 2021 (UTC)

There is some problem with it please see [6]Shrike (talk) 07:41, 5 April 2021 (UTC)

Shrike, so it's more a problem with the message than a problem with the filter. What user were you trying to alert when you got that message? ^{SubjectiveNotability} _{a GN franchise} (talk to the boss) 13:15, 5 April 2021 (UTC)

GeneralNotability, I think its happen to all the users even if I try to alert myself. Shrike (talk) 13:17, 5 April 2021 (UTC)

Could be related to T247661. Badtitle/ApiErrorFormatter::getDummyTitle reads like a PHP class and method name. Probably unrelated to anything onwiki and more something related to MediaWiki. In particular, it seems like it can't read {{BASEPAGENAME}} on MediaWiki:Abusefilter-warning-DS. Best to file a phab ticket. ProcrastinatingReader (talk) 13:25, 5 April 2021 (UTC)

ProcrastinatingReader, Please do because it helpful to search alerts in user history and not give unnecessary alerts Shrike (talk) 13:54, 5 April 2021 (UTC)

I can confirm this; the 2017 text editor gives me the same message, but it works fine in the 2010 editor. So this is the same issue as phab:T247661; there's no need for another ticket. Something like {{#ifexpr:{{In string|{{BASEPAGENAME}}|Badtitle}}|simple message|fancy message}} (untested) might make the message less ugly, at least. Suffusion of Yellow (talk) 23:29, 5 April 2021 (UTC)

I've noticed vandals either replacing infobox names with "DaBaby" or randomly adding "DaBaby" to an article, is there already a filter that catches these edits? And if not, could one be created or modified to include this? Thanks. Deauthorized. ^(talk) 15:26, 27 April 2021 (UTC)

@Deauthorized: See WP:EFR#Inappropriately inserting "dababy" into random articles?. Suffusion of Yellow (talk) 20:06, 5 May 2021 (UTC)

(ping relevant admins) @Reaper Eternal, Zzuuzz, Oshwah, and EdJohnston: I've set up a filter at Special:AbuseFilter/1148 that should hopefully prevent the recent user talk disruption. I'm testing it now to make sure there aren't false positives, but if you've noticed any patterns or see edits slip through in the future, feel free to email me or the edit filter mailing list (I can't find the email or remember it, anyone who does feel free to replace this with the answer) — Wug·a·po·des​ 22:19, 12 May 2021 (UTC)

Wugapodes - Sounds good, thanks for doing that! :-) ~Oshwah~^{(talk) (contribs)} 23:30, 12 May 2021 (UTC)

• 1146 (hist · log) (public)

Obligatory notice. Just another boring meme. Suffusion of Yellow (talk) 01:01, 17 May 2021 (UTC)

• Filter 1047 (hist · log) ("Coronavirus tracking III (BLPs)", public)
• Filter 1111 (hist · log) ("Redlinks monitor", public)
• Filter 1113 (hist · log) (""Notable people" catch-all", public)

I created all these filters, but I'm not even looking at the log anymore. Unless anyone objects I'm going to disable filters 1047 and 1113, and try to create something out of 1111 that only looks at disambiguation pages. Will anyone miss these filters? Suffusion of Yellow (talk) 20:05, 5 May 2021 (UTC)

I won't. — xaosflux ^Talk 23:10, 12 May 2021 (UTC)

All disabled. If I create the DAB-only filter, it will be at a new number. Suffusion of Yellow (talk) 20:42, 16 May 2021 (UTC)

@Suffusion of Yellow: I added some logic to check for dabs to 1111 if you're still interested in that log. I have not enabled it though so feel free to do nothing with it if you don't care or were planning to start from scratch. — Wug·a·po·des​ 21:56, 27 May 2021 (UTC)

• 846 (hist · log)

I saw edits tagged as "review edit", which I didn't remember having seen before. I suspected it was an editing tool I wasn't familiar with (à la "Mobile edit", "Visual edit", etc.), so I was surprised to learn that it just tagged certain IP ranges. Couldn't we use a more descriptive, or at least less counterintuitive, name? Nardog (talk) 04:42, 27 May 2021 (UTC)

@Nardog: the filter uses the possible disruption tag; that tag has a label, "review edit" which certainly sounds less ABF - that label can be updated here: MediaWiki:Tag-Possible disruption. That filter was supposed to be 'temporary' from 5 years ago - so a better question would be: is anyone actually patrolling based on these tags anymore? — xaosflux ^Talk 13:39, 27 May 2021 (UTC)

@Xaosflux: It's not about whether it is or is not ABF. I'm not suggesting we change it back to "possible disruption", but "a more descriptive, or at least less counterintuitive, name". Don't you find the current label misleading? (What is it even supposed to mean? If it's an imperative, how common is it to see tag labels that are imperatives, anyway?)

The filter was last modified by Beetstra 14 months ago, so I assume they are. Nardog (talk) 01:56, 28 May 2021 (UTC)

Nardog, mine was just a note,I guess User:Coffee may be of more help. Though this was caught today. Maybe a better tag is warranted but the current tag does cover it. Dirk Beetstra ^{T C} 06:53, 28 May 2021 (UTC)

@Nardog: I rarely do RCP based on tags, so it isn't misleading me - but it certainly can be changed to whatever could be more useful. The filter itself doesn't need to be changed to change the label, which is why I was asking who might even be making use of it, as they may have insight in to a better label -- but if no one is using it, we can just shut down the old filter. — xaosflux ^Talk 11:00, 28 May 2021 (UTC)

@Nardog: @Xaosflux: I've always thought it would be better if it was "review this edit", tbh. Gatemansgc (TɅ̊LK) 23:45, 31 May 2021 (UTC)

Is 899 now redundant to 869, since the latter is now set to warn? ProcrastinatingReader (talk) 14:04, 19 June 2021 (UTC)

No objections raised so I'll disable 899. 899 covers 2/3 sources; it doesn't cover theknot.com but that source seems to be neither deprecated nor blacklisted, so relevant discussions could take place to get it onto one of those lists. ProcrastinatingReader (talk) 22:14, 1 July 2021 (UTC)

If a filter is created that uses a loose condition (that usually would cause too many issues) but uses ip_in_range (doc) to narrow this down to prevent FPs, would that be tantamount to an IP block? Just wondering if it's in my remit to do. A normal IP block would, also, be too wide. ProcrastinatingReader (talk) 10:59, 9 July 2021 (UTC)

@ProcrastinatingReader: it wouldn't technically be a block, however disallowing filters - especially those that will impact many potential editors - should be proposed, reviewed, and carefully tested prior to be enforced. — xaosflux ^Talk 12:46, 9 July 2021 (UTC)

I've re-set 1106 (hist · log) "Caliphate disruption" to disallow, with a few tweaks to reduce false positives, following a resurgence of WP:CALIPH disruption and complaints at ANI. I'm running a parallel public log-only filter at 1108 (hist · log) to monitor any related non-caught disruption. -- zzuuzz ^(talk) 18:23, 16 July 2021 (UTC)

• AN discussion

First step will be to create MediaWiki:Abusefilter-disallowed-WPWP with the appropriate page content (that has to be done by an admin). Or just create it to transclude a TE-protected template. That'll be for the throttle. I'm still figuring out the best way to implement 2.1. ProcrastinatingReader (talk) 15:21, 5 August 2021 (UTC)

I created the mediawiki page to transclude {{Wanted Pictures contest throttle message}} which I have also template protected. You can edit that as needed and when it's stable I can move it over the transclusion if need be (I'm not sure what the standard on this is). — Wug·a·po·des​ 20:41, 5 August 2021 (UTC)

Personally I'm not a huge fan of transcluding templatespace -> mediawikispace, but I suppose this isn't a super-high-risk page and is TE protected, so I won't raise a huge fuss. GeneralNotability (talk) 01:10, 6 August 2021 (UTC)

Implemented at 1158 (hist · log) ProcrastinatingReader (talk) 16:11, 7 August 2021 (UTC)

Moved the template to mediawiki space. If you need further edits let someone know. — Wug·a·po·des​ 07:03, 8 August 2021 (UTC)

LTA filter 1160 set to throttle/disallow. ProcrastinatingReader (talk) 16:24, 11 August 2021 (UTC)

Ruy (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 · fm · mms · npr · pm · pcr · rb · te)}

I request the Edit filter helper for to view the private filters, this because I have problems for to report spambots with a single edition and I cannot assure you that the filters activated by those accounts are by improper promotional activity. I am Edit filter in eswiki, I read the policy and I want to help in this area. Regards Ruy (talk) 13:50, 12 August 2021 (UTC)

• This is probably not the place to raise this, but I think we again need a broader discussion on dealing with WP:EFH. Along with the previous request, this would set a precedent for EFH akin to rollbacker or less. I still think we used to be too touchy with this permission but full access to all filters and their patterns, well, it's probably best not to hand it out too lightly. One solution might be the use of a Toolforge tool that shows the logs of certain private filters (including the diffs, for disallow/warn) and thus still hiding the filter regex, and making that available to rollbackers or some-such. That would be more sustainable long-term and allow for more people to be able to do antivandalism work through the logs of private filters. ProcrastinatingReader (talk) 14:03, 12 August 2021 (UTC)

  @ProcrastinatingReader: I respect your opinion but I do not share it, my request is not a precedent about the level of EFH because I am a user with experience in the Edit filter (see my records) and I am a active user in enwiki, in any case I will assume the decision about this request. Regards Ruy (talk) 14:36, 12 August 2021 (UTC)

  I know yours is just a request for EFH rather than a discussion on when it should be given out, I’m just aware that the history on these requests tends to be quite hit-or-miss, as reporting spambots is a relatively common task and there’s generally been a consensus that it doesn’t rise to the level of EFH access. I just had a different idea on how we could facilitate the legitimate anti vandalism needs of seeing log entries with the broadness of the EFH permission. In theory, every roll backer would probably meet these same need requirements. ProcrastinatingReader (talk) 15:11, 12 August 2021 (UTC)

•  Administrator note - criteria review:
  • ? Minimum requirements (all required):
  1. ? Demonstrated need for access (e.g. SPI clerk, involvement with edit filters)
  2. Y No recent blocks or relevant sanctions
  3. Y At least basic understanding of account security

     (assumed via eswiki access)

  4. YAt least basic understanding of regular expressions if the intent is to assist with authoring filters

     (assumed via eswiki access)

  5. YSufficient ability with the English language to understand notes and explanations for edit filters
  • YAdditional requirements (at least one):
  1. YCurrently-active extended confirmed editor on the English Wikipedia
  2. N Current administrator on another WMF project
  3. Y Current edit filter manager on another WMF project
  4. N/A Current WMF developer or staff member who needs access for WMF-related purposes
  • — xaosflux ^Talk 15:13, 12 August 2021 (UTC)
• Leaning support here, I'm not too concerned that Ruy will leak hidden log or filter configs. As Ruy is a EFM on a major project (though making sparse use) of the access - EFH here could also be helpful there. As the use-case being request is about local bot support, I'd like to hear any other discussion about that component first. — xaosflux ^Talk 15:19, 12 August 2021 (UTC)

Perhaps I’m misunderstanding, but isn’t the request to report spambots here on enwiki? ProcrastinatingReader (talk) 15:26, 12 August 2021 (UTC)

@ProcrastinatingReader: yup, that's why I'm only "leaning support" with the "Demonstrated need for access" criteria still being a bit questionable. — xaosflux ^Talk 16:02, 12 August 2021 (UTC)

• Support Seems to meet all the criteria for granting the userright. EggRoll97 ^(talk) 18:50, 12 August 2021 (UTC)

Can we disable or merge 554 into 869 / 894 / 1045 (as/if appropriate), or add to revert bot / spam blacklist? It seems a bit extreme to disallow these sources, which is stronger than we even do to deprecated ones, and they don't seem to have been subject to RSN discussions so aren't deprecated per se. ProcrastinatingReader (talk) 19:31, 13 August 2021 (UTC)

I don't know if this is the right place to request filter changes, but if so would someone mind tweaking Filter 1159? Suggested changes are mocked up here. Wanting to broaden the namespace so talkpages are included, and add another common term associated with this particular run of vandalism. Pinging ProcrastinatingReader whom created the filter. Thanks, --Jack Frost (talk) 08:00, 15 August 2021 (UTC)

 Done ProcrastinatingReader (talk) 15:23, 15 August 2021 (UTC)

Thanks ProcrastinatingReader! --Jack Frost (talk) 10:38, 17 August 2021 (UTC)

I suggested this in a thread over at VPPROP: would a filter tracking non-EC edits which add images to templates be useful? Even if we up protection of templates, there will still be a gap in our protection that we will need to monitor, which is why I think this might be useful. I can't imagine why adding an image to a template would be particularly useful in most cases, and they probably warrant additional scrutiny anyway. Before working on this, do others think this is a good idea? — Wug·a·po·des​ 00:35, 18 August 2021 (UTC)

I'm sure there are templates based on maps that use images, and plenty of use cases you'd start finding if you disallowed addition. But a log-only filter sounds great to me. Another possible thing to look at: since the edits were revdelled or oversighted, I can't see where the vandal was getting the image from—was it something they uploaded from a different account (can't see any deleted edits or edits to Commons) or an existing image that should have been on some bad image list? — Bilorv (talk) 11:11, 18 August 2021 (UTC)

@Bilorv: none of that would matter for an edit filter, image properties are not EF variables. — xaosflux ^Talk 13:21, 18 August 2021 (UTC)

I looked into adding the image to the bad image list, but it's a file that is legitimately used on nearly 200 articles, apparently by way of a navigational side bar. That's a lot of exceptions and if I understand BIL correctly, any time an article gets added to the series we'd need to add another exception. It's not impossible but the relative gains of adding the specific image to BIL would need more discussion. — Wug·a·po·des​ 19:01, 18 August 2021 (UTC)

I think this could be useful - as Bilorv says there will be legitimate uses for this, however as it'd be log-only and infrequently triggered that doesn't really matter. firefly ( t · c ) 11:14, 18 August 2021 (UTC)

Discussed with Wug but just for the record: a filter along these lines does currently exist. ProcrastinatingReader (talk) 13:23, 18 August 2021 (UTC)

Special:AbuseFilter/600 has worked well for me, and it also reports other suspicious activity on templates. However it is limited to only new-ish users. I suspect removing that check will produce a lot of noise, but feel free to fork the filter and adjust as desired. — MusikAnimal ^talk 03:21, 20 August 2021 (UTC)

Don't remember which specific filter it is, but I know there is a filter that is blocking various additions of "Your Mom" and related vandalism. I think whichever filter does this should be extended to account creations if possible, i.e. in order to prevent usernames like this from being registered. Taking Out The Trash (talk) 15:35, 21 August 2021 (UTC)

Regarding Special:AbuseFilter/1139, @ProcrastinatingReader: following up from AN. Having a filter that requires checking every edit for a static list of text usernames in the filter is something I think is a horrible idea for so many reasons. It is creating a parallel blocking system with estoteric logging, requires admins to manually edit filters, not to mention the overhead and sustainability of having freeform text usernames that would need to grow and grow. There have GOT to be better solutions to the problem this is trying to solve? — xaosflux ^Talk 16:04, 11 August 2021 (UTC)

@Xaosflux: not possible I'm afraid. The mobile apps really are that busted. It is currently disabled for a reason though, and if ever enabled it should only be used for perhaps a couple days and only for a specific user. It should be unlikely it would ever target more than one user at a given time. As far as whether it should be used goes, and the logging concerns... I think that's probably a decision for admins/the community? Personally I think the benefits (potentially being able to communicate with a user who is about to be blocked at ANI) outweigh the costs (losing a user who, from their perspective, has been contributing well and then suddenly got a "vandalism block" (even if the block message says something else)). ProcrastinatingReader (talk) 16:14, 11 August 2021 (UTC)

I will add though that phab:T276147 seems to be resolved for Android, although on a beta version and the tags say "Wikipedia-Android-App-Backlog (Android Release FY2020-21) (Ready for release)" so perhaps it is not yet deployed to the Play Store, not sure. ProcrastinatingReader (talk) 16:17, 11 August 2021 (UTC)

@ProcrastinatingReader: as this is effectively a targeted block (pblock) note that means it is completely inappropriate for non-admin EFM's to use something like this, and even for admins I can't see this being an emergency - so would still need to go through the process of proposing enabling a blocking filter here at EFN to activate. Work-flow-wise, most admins don't have a clue about edit filters and getting them to edit an EF as opposed to pressing block isn't a great UX for them. — xaosflux ^Talk 16:28, 11 August 2021 (UTC)

Yes, I fully agree only admins should set it.

The idea was that it's used when an admin is going to set a block anyway for disruption + non-responsiveness, as was the outcome of ANIs where this has been a problem. If folks think the filter is unsuitable for use that's fine with me, but I don't personally see the issue. It's the only technical means of sending a useful message to iOS app users. The alternative is we just block them as normal, which may be fine as a matter of 'procedure', but IMO is unhelpful and not really fair (even if this is really the WMF's problem, not ours). ProcrastinatingReader (talk) 16:35, 11 August 2021 (UTC)

Is it possible to rig the filter so that it detects blocked users? Perhaps that would resolve the accountability/technical issue. Jo-Jo Eumerus (talk) 17:48, 11 August 2021 (UTC)

Crossposted this to WT:BLOCK besides. Jo-Jo Eumerus (talk) 17:50, 11 August 2021 (UTC)

There is a user_blocked but I don't know whether the filter checks run before the check for whether the user is blocked. I'd suspect yes, since the variable exists; would have to test. ProcrastinatingReader (talk) 17:59, 11 August 2021 (UTC)

@Jo-Jo Eumerus: Just tested on User:ProcSock (see block log). Didn't work. Apparently the check for blocked users runs before the filter does, so if the user is blocked they only see the core software block message and the attempted edit is not even logged in the filter. I dunno why user_blocked even exists, then... ProcrastinatingReader (talk) 00:20, 22 August 2021 (UTC)

Perhaps something worth asking for in Phabricator? Jo-Jo Eumerus (talk) 08:30, 22 August 2021 (UTC)

• NR deblocked (talk⁺ · tag · contribs · deleted contribs · logs · filter log · block user · block log · CA · CheckUser(log) · investigate · cuwiki)

I've noticed for several days that this user has attempted to link their global account locally to enwiki, but keeps getting blocked by a disallowing private filter for "LTA Username/Impersonation creations". They have a global account and don't appear to be blocked anywhere, so I'd appreciate som eyes on this to try and figure out what's going on. Taking Out The Trash (talk) 18:36, 23 August 2021 (UTC)

Pinging @MusikAnimal:, @Suffusion of Yellow: and @ProcrastinatingReader: to both this thread and the thread immediately above it. Taking Out The Trash (talk) 18:40, 23 August 2021 (UTC)

Adding this template as I just saw the same thing yet again. Someone really needs to look into what is going on here. Taking Out The Trash (talk) 18:15, 26 August 2021 (UTC)

I've made a change that should fix this. ProcrastinatingReader (talk) 22:17, 26 August 2021 (UTC)

Thanks. As a reminder, the new admin-only Special:CreateLocalAccount can be used in similar situations. Suffusion of Yellow (talk) 23:37, 26 August 2021 (UTC)

Not sure if this is technically possible, but if so, would it be a good idea to create a filter in that warns (and possibly tags) when someone creates a new article that is a BLP without sources? I know there are already filters that tag edits that add unsourced information to preexisting BLPs, which is a good start, but having a filter to warn users that BLPs are required to have at least one source upon creation might be benifical. The number of articles that I've had to BLPPROD as of lately is starting to become a bit staggering. Ping for reference @MusikAnimal: @Suffusion of Yellow: @ProcrastinatingReader: Taking Out The Trash (talk) 20:13, 6 September 2021 (UTC)

This is technically possible, yes, however there's no guarantee that once a new page is created, it's already properly categorized (which is how we would deduce that it is a BLP). That might happen in a subsequent edit, which I suspect is the more common scenario for new-ish users who are most likely to leave a BLP unsourced. Continually scanning the whole article for the category and referencing syntax I think is fairly inefficient and in this case perhaps not worth it. Unsourced BLPs will undoubtedly be noticed by new page patrollers in due time and properly handled. I personally don't see the advantage the edit filter will give us over human patrollers, especially since we do not and should not expect users to have a perfectly sourced and categorized article on the first edit. — MusikAnimal ^talk 18:11, 7 September 2021 (UTC)

I saw 1076 got triggered for this move, but I don't think that was intended? The article was moved from draftspace just today and moved back rather quickly. Isn't the filter for when an article from mainspace gets moved into draftspace for the first time? –MJL ‐Talk‐^☖ 03:48, 7 September 2021 (UTC)

Definitely a false positive in terms of what the filter is intended to do; the reason is that the article was created a long time ago, it just only got moved to article space recently. moved_from_age doesn't know when the article was first moved to article space, just when it was first created. I'm not sure if there's a good solution for avoiding this edge case. Sam Walton (talk) 18:51, 7 September 2021 (UTC)

• Round 1 discussion: Wikipedia:Edit filter noticeboard/Archive 6 § Better message for LTA filters
• Round 2 discussion: Wikipedia:Edit filter noticeboard/Archive 8 § Better message for LTA filters (round 2)

Round 2 proposal by SoY to edit MediaWiki:Abusefilter-disallowed:

Standard disallow message:

Proposed new message:

As far as I can tell, SoY's proposal had consensus in round 2, although we didn't get to implementation. Is that a correct reading of the discussion? Having seen some FPs, and had my own frustrations (to put it mildly) when bugs in editing tools cause my entire edit to disappear and having to rewrite it again, I really think this change (and its associated reassurance) is needed. It's also a clearer message in general. Pinging previous contributors: @Suffusion of Yellow, MusikAnimal, Newslinger, OhKayeSierra, Awesome Aasim, Enterprisey, Xaosflux, and DannyS712 -- are we good to implement this change? ProcrastinatingReader (talk) 16:16, 31 August 2021 (UTC)

@ProcrastinatingReader: What was the scope of this again? Only non-public LTA filters? — xaosflux ^Talk 16:21, 31 August 2021 (UTC)

Based on SoY's comment I believe that's correct; non-public LTA filters and seeing how that goes. ProcrastinatingReader (talk) 16:28, 31 August 2021 (UTC)

OK, seems alright for non-public filters, that are in disallow, that target action=edit. — xaosflux ^Talk 16:32, 31 August 2021 (UTC)

@Xaosflux: Sounds good. Could you create MediaWiki:Abusefilter-disallowed-LTA with that content? ProcrastinatingReader (talk) 12:15, 1 September 2021 (UTC)

 Done — xaosflux ^Talk 13:03, 1 September 2021 (UTC)

@ProcrastinatingReader and Xaosflux: A bit late to the party here, but thanks for reviving this discussion and implementing this! Suffusion of Yellow (talk) 21:42, 12 September 2021 (UTC)

I floated this idea for a new EF on the WP:DISCORD and was recommended to suggest it on-wiki: could there be something to mark IPs/new (non-AC) accounts adding redlinks to forename or surname set index articles (e.g. Diver (surname), presumably articles with the {{surname}} template or in Category:Lists of people by given name / Category:Given names)? I've ended up on several of these recently, and it seems that this is not uncommon and usually just someone adding themselves to the list. Thanks, eviolite (talk) 19:04, 15 September 2021 (UTC)

Something like this existed before but was disabled as too spammy and it being unlikely anyone was reviewing the logs. [7] Special:AbuseFilter/1112 still exists but is more narrow. ProcrastinatingReader (talk) 20:51, 15 September 2021 (UTC)

Regarding the "redlinks" component - the abuse filter doesn't have a variable to know if a wikilink will be red or blue. — xaosflux ^Talk 21:41, 15 September 2021 (UTC)