Wikipedia:Edit filter noticeboard

"WP:EFN" redirects here. For information on the {{efn}} template, see WP:EXPLNOTE.

Welcome to the edit filter noticeboard

WATCH Recent filter changes (): Filter 1246 (new) — Actions: none; Flags: enabled,private; Pattern modified Last changed at 21:29, 21 April 2023 (UTC) Filter 1204 — Actions: tag; Pattern modified Last changed at 19:35, 19 April 2023 (UTC) Filter 2 — Actions: throttle; Flags: enabled Last changed at 18:18, 17 April 2023 (UTC) This is the edit filter noticeboard, for coordination and discussion of edit filter use and management. If you wish to request an edit filter, please post at Wikipedia:Edit filter/Requested. If you would like to report a false positive, please post at Wikipedia:Edit filter/False positives. Private filters should not be discussed in detail here; please email an edit filter manager if you have specific concerns or questions about the content of hidden filters. There are currently 287 enabled filters and 39 stale filters with no hits in the past 30 days. Filter condition use is ~801, out of a maximum of 2000. (). See also the profiling data and edit filter graphs. Click here to start a new discussion thread

Global abuse filters applying here

There's an RfC at m:Requests_for_comment/Make_global_abuse_filters_opt-out to make global abuse filters apply to enwiki and other large wikis. I think we should opt-out since we don't have the issues mentioned and shouldn't allow meta admins to bypass our local guidelines. Galobtter (pingó mió) 06:58, 18 March 2023 (UTC)

• Support opt-out. There's lots of reasons, but simply, our local capabilities are more than adequate. -- zzuuzz ^(talk) 08:30, 18 March 2023 (UTC)
• Opt-out we don't need this. I could list lots of reasons, but having too much overlap with the also-local ones and wanting local custom warnings to be first is one. — xaosflux ^Talk 09:14, 18 March 2023 (UTC)

  When both a local filter and a global filter are triggered for an edit at the same time, shouldn't the local filter's warning message be displayed instead of the global one? 0xDeadbeef→∞ (talk to me) 17:48, 18 March 2023 (UTC)

  @0xDeadbeef suppose more testing is needed, when multiple filters all hit at once (even just locally) sometimes the results are odd. — xaosflux ^Talk 08:51, 19 March 2023 (UTC)

  This sounds like a bug. Is there a Phab ticket somewhere or should I create one? 0xDeadbeef→∞ (talk to me) 08:55, 19 March 2023 (UTC)

  Not sure if a bug, it may be deterministic (say there is a local warn, but a global disallow, there may actually be an order of precedence) - but pretty sure we run in this even locally if there are multiple warn filters hitting at once. — xaosflux ^Talk 09:10, 19 March 2023 (UTC)

  Follow up: a "disallow" filter has the impact of protection and or a block, and we have more than enough local resources to make decisions about who may or who may not edit here. Compare configurations such as the MediaWiki:Spam-whitelist and LSGB - except in this case, there is no local whitelist. — xaosflux ^Talk 08:55, 19 March 2023 (UTC)

  @Xaosflux: That's T45761. Certainly would be nice to have, but I would think that having more en.wp EFMs have access to global filters (as I suggested below) and the option to exempt "enwiki" inside the filter itself should cover most use cases? Legoktm (talk) 02:28, 20 March 2023 (UTC)

  Having that open for 10 years isn't very promising. And having to run a "And not on project [array of projects]" on every filter is a bad idea. Also, not really a fan of making project admins meta efm's just to exempt their own projects. — xaosflux ^Talk 09:22, 20 March 2023 (UTC)

• Opt-out In addition to everyone above, the English Wikipedia does not generally like the usage of global rights (see Wikipedia:Global rights policy), and I seen no reason to make an exception here. * Pppery * _{it has begun...} 14:03, 18 March 2023 (UTC)
• Can someone who can view the private global abuse filters perform some kind of review to determine their utility for English Wikipedia? Perhaps there are some that may be helpful (or reproduced locally)? isaacl (talk) 15:06, 18 March 2023 (UTC)

Support opt out - Out of lack of need and filters overlapping. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 16:20, 18 March 2023 (UTC)

• Opt out. The English Wikipedia is more than capable of managing its own day-to-day operations without WMF involvement. Thebiguglyalien (talk) 18:01, 18 March 2023 (UTC)
• Support opt out. I have been blocked only once on a Wikimedia Wiki—a false positive on a misconfigured global edit filter affecting the English WikiNews occurred when I was reverting vandalism, and the filter was set to block users automatically. Had Operator873 not stepped in to quickly unblock me, this bad global filter would have actively and substantially prevented me from continuing to revert vandalism while the Wiki was actively under attack from an IP-hopping vandalbot. I have low confidence that the global edit filters have the ability to automatically and appropriately block users in a manner that is consistent with the English Wikipedia's blocking policies, and I think that an opt-out is necessary to prevent future disruption to the English Wikipedia associated with the risks of these sorts of misconfigured global filters. — Red-tailed hawk _(nest) 18:56, 18 March 2023 (UTC)

  Red-tailed hawk you were blocked by a local filter on that project as a direct result of my action. My first change to the filters were to a local one that had block enabled and that is the action that lead to your block. After I saw that my action on that filter resulted in you being blocked, I reverted the change and created a dedicate filter which I should've done from the very beginning. Your block was a direct result of my mistake on a local filter with block enabled and I wholly own my mistake. This wasn't a global filter issue as global filters do not auto-block. Operator873 ^connect 20:05, 18 March 2023 (UTC)

  I had assumed that this was a global filter because I thought that Stewards generally couldn't edit local filters. I apologize for my mistake. That being said, I do support an opt-out of the global filters due to redundancy with EnWiki filters as well as the delocalization of the decision on whether to warn or deny users for edits away from our community. — Red-tailed hawk _(nest) 21:37, 18 March 2023 (UTC)

  For what it's worth, there are global filters that block users (LTA 306) as well as ones that block autopromotion (fuerdai vandalism, WP0 copyright infringement prevention mechanism). Blocking decisions must remain local to EnWiki. — Red-tailed hawk _(nest) 21:42, 18 March 2023 (UTC)

  I mean, en.wp EFMs deployed a filter that prevented anyone from adding the letter j (or some other letter, I might've gotten it wrong) for a few hours. Mistakes happen, it seems a bit extreme to opt-out solely on the basis that people could screw up (they will! but so will local filter editors). Blocking decisions haven't been solely local to en.wp for years now; stewards have mistakenly locked accounts or globally blocked IPs, but no one is calling for en.wp to opt-out of those global mechanisms. Legoktm (talk) 02:25, 20 March 2023 (UTC)

  The edit filter would create local blocks. Would you please tell me what people other than EnWiki admins have the policy-based authority to issue blocks locally on EnWiki? — Red-tailed hawk _(nest) 02:49, 20 March 2023 (UTC)

  Is there a meaningful distinction between a "local block" and other measures that have the same effect of preventing someone from editing? Like, hypothetically if global filters set global blocks instead of setting local blocks, would that be fine then?

  I should say, disallowing global filters from setting local blocks seems entirely reasonable to me. I just don't agree with the premise that currently blocking decisions are solely local. Legoktm (talk) 03:09, 20 March 2023 (UTC)

  I think that there is a meaningful distinction inasmuch as personal accountability is concerned. On the English Wikipedia, we have WP:ADMINCOND and WP:ADMINACCT: both of these allow users to hold specific admins to account for making bad blocks and bad admin actions. We also have a body that is accountable to EnWiki that allows for desysopping admins who fail to adhere to these criteria.

  No such accountability is guaranteed to the English Wikipedia community if Meta admins screw up, and those very same Meta admins are not required to have undergone vetting by the English Wikipedia community prior to being given the tools that would allow them to make decisions of blocking on EnWiki. The only policy on Meta allowing desysopping of full Meta-Wiki admins is one that pertains exclusively to inactivity. This setup would create a poor governance structure, where people who are fundamentally unaccountable for their screw-ups would get to make blocking decisions.

  As for why global locks and global blocks are different: neta admins do not have the policy-based authority nor technical ability to issue global blocks nor global locks. That is reserved for the Stewards, who are accountable to the community through elections and re-confirmations.

  Good community governance proceeds from accountability to that community, but failure to establish accountability creates weakness in governance structure. If we are to retain a strong and effective governance structure, and to mitigate risks associated with privileged users, then keeping local blocks local makes sense. — Red-tailed hawk _(nest) 07:04, 20 March 2023 (UTC)

• Support opt-out At the end of the day, the far reaching effects on enwiki of any mistakes, or unintentional implementations can be far and wide, with not many users who are active to fix them. We have far better quantity and quality of EFMs here then we do xwiki. I would like to think enwiki can hold it's own water about this. -- Amanda (she/her) 20:14, 18 March 2023 (UTC)
• It depends:
  • Support opting-in to logging and tagging, if the condition limit is doubled. If a little bit of clutter in our AbuseLog helps global patrollers track cross-wiki abuse, so what?
  • Weakly support opting-out of warn and disallow actions. I'm not comfortable with this, but that's mostly because I can't see what's really going on with the private filters. Maybe it's not as bad I as imagine? I'd support enabling these actions, but only with a sunset period, of, say, a month or two. If it causes too many problems, then no need for a second RFC.
  • Strongly support opting-out of blocking action. First, blocking filters (even local blocking filters) are not a good fit for enwiki's "clean block log" culture. I've seen long-time users quit after one 24-hour block. Second, this would effectively give meta-wiki admins the ability to block enwiki users. And third, there's a WP:BEANS reason that I'm sure at least TheresNoTime and a few others are aware of. That reason alone is deal breaker.
• If such fine-grained control is not possible, then I simply support opting out entirely. Suffusion of Yellow (talk) 20:37, 18 March 2023 (UTC)

  Do we know the effect that opting in would have on the condition count? — Red-tailed hawk _(nest) 22:01, 18 March 2023 (UTC)

  From phab:T309609 I gather that global filters would count against the limit. But the limit can be raised. Suffusion of Yellow (talk) 22:06, 18 March 2023 (UTC)

• For reference, this is the list of enabled global filters. I find it interesting that one filter is set to block and a couple others are set to block autopromote when there's the message on the abusefilter edit page for both that says "(do not set on global filters)". I'm not necessarily opposed to allowing logging as SoY mentions but as of yet that debundling is not possible. Galobtter (pingó mió) 21:09, 18 March 2023 (UTC)

  From meta:User:Legoktm/Global_filters_everywhere I gather that it's technically possible, using the $wgAbuseFilterLocallyDisabledGlobalActions. Suffusion of Yellow (talk) 21:15, 18 March 2023 (UTC)

  Struck, that's good that it is. I think opting in only to logging filters is something that we could definitely do if needed. Galobtter (pingó mió) 21:29, 18 March 2023 (UTC)

• Support opting out of warning, disallowing, and blocking actions. As somebody who watches the edit filters here and cross-wiki, having the global abuse filter log actions here would be helpful. However, we should definitely opt-out of the more direct actions, such as warning, blocking and disallowing, where we have our own filters here.—*Fehufangą (✉ Talk · ✎ Contribs) 22:59, 18 March 2023 (UTC)
• Support opt out, and FYI for @Suffusion of Yellow, Galobtter, and Red-tailed hawk: I intend to get T332521 (setting wgAbuseFilterLocallyDisabledGlobalActions) resolved in the next few days — TheresNoTime (talk • they/them) 22:52, 19 March 2023 (UTC)
• There are good reasons to opt-out, but I think focusing on them misses out on the long-term advantages and opportunities that having global filters brings us. en.wp hasn't opted out of other global anti-vandalism/spam tools like the global spam blacklist (technically possible) or global blocks (also technically possible) or the global locking of accounts (not technically possible). Why should filters be treated differently? en.wp has a lot of filter experience, I'd much rather see a good amount of our EFMs start operating on the global level to improve all Wikimedia wikis at once instead of constantly duplicating efforts. Legoktm (talk) 02:20, 20 March 2023 (UTC)

  We do manage local whitelists for GSBL and GBs, there is no whitelist for GAF. — xaosflux ^Talk 09:42, 20 March 2023 (UTC)

  Give us some mechanism to disable any one filter locally, and I would say we should accept the global filters except for individual ones we choose otherwise. We have this feature with global blocks and global blacklist; We probably rarely use this, but the fact that we can is crucial here. Animal lover |666| 22:14, 20 March 2023 (UTC)

• Absolutely allow opt-out from each global filter; this probably requires general opt-out from the global filter system. We certainly should have filter managers keeping an eye on global filters and decide on a case-by-case basis what we want. However, our filter managers (except where our community says otherwise) should have the last word for each filter, not some global authority (except for possible disallowing where legal issues make it necessary; should this actually be necessary, the Foundation can handle it here directly). Animal lover |666| 09:10, 20 March 2023 (UTC)

  Just for the record, I would support a bot which copies all new global filters to our local filter system, and copies modifications from all global filters which remain unmodified here. This would certainly meet the "opt out from individual filters" criterion, as we can simply disable a filter as a means of opt-out. Animal lover |666| 11:43, 21 March 2023 (UTC)

• Support opt-out and I'd expect the consensus here to be pretty close to unanimous. This global abuse filter sounds fantastic for smaller wikis that don't have enough people with the right skillset to manage a robust filter. It isn't a problem we experience here on enwiki. Every indication I've seen shows that we're more than capable of managing our own filters per our local policies. The Wordsmith^{Talk to me} 13:42, 20 March 2023 (UTC)
• Support opt-out Not an improvement for en-wiki and an ivory-tower-created version is likely to be inferior at best. North8000 (talk) 18:40, 20 March 2023 (UTC)
• Oppose opt-out I'm definitely in the minority here, but my viewpoint lies in supporting global contributions to anti-vandalism; vandalism is vandalism in any project. EpicPupper (talk) 20:03, 20 March 2023 (UTC)

  Antivandalism filters are not perfect, and enwiki's edit rate will produce a huge workload for maintainers of global filters (which I think I can count myself as) both simply because of the significant increase in filter hits and due to the large number of different false positives not yet accounted for, all for little gain given the active local filter assistance. If enwiki would like to mirror a global filter for logging purposes, asking a Meta admin is always an option. 1234qwer1234qwer4 20:03, 3 April 2023 (UTC)

• Support opt-out, except for tracking (if that's possible) - The underlying global RfC makes perfect sense, btw, I've no issues at that level. But for the reason covered above, we don't need it. If there's a way to keep the tracking bits working, then why not aid the global side to the degree we can? Nosebagbear (talk) 23:43, 20 March 2023 (UTC)
• Support opt-out. We are plenty capable of managing our own filters here. —Compassionate727 ^(T·C) 02:35, 21 March 2023 (UTC)
• Case-by-case. I think there should certainly be an option to pick and choose which abuse filters should not apply to English Wikipedia. However, I also believe that fully opting out can make it harder to catch cross wiki abuse. The global title blacklists and spam blacklists already allow for that. If we can pick and choose which filters should and shouldn't apply to us then it is all good. That will only be possible, though, if abuse filter managers here are given permission to view the contents of private global filters on Meta-Wiki. Aasim - Herrscher of Wikis ❄️ 19:57, 22 March 2023 (UTC)

  To add on to this: the only global filters that should be enabled on the English Wikipedia are those to enforce global policies on vandalism, spam, T&S, etc., not all global filters. Aasim - Herrscher of Wikis ❄️ 20:00, 22 March 2023 (UTC)

• Opt out per my comment above. More harm than use, both locally and globally. 1234qwer1234qwer4 20:05, 3 April 2023 (UTC)
• Opt out: No real need to duplicate filters if possible. Based on a hunch, such duplicates could also cause the "rapid disruption" filters to lose much usefulness. Still, having the logs for the benefit of global RC patorllers like Fehufanga would perhaps be nice, but en.wiki doesn't really need more duplicate filters. And we'd all rather not find out what happens when 256 filters trip at one edit (ok,

I'm joking there) Mako001 (C)  (T)  🇺🇦 14:11, 12 April 2023 (UTC)

Set 1243 to disallow?

I created Special:AbuseFilter/1243 as per Wikipedia:Edit filter/Requested#Prevent removal of talk page headers. It seems to be working pretty well - haven't really seen anything constructive there. So I think this should be a disallow. There is some overlap with the talk page blanking filter, but this also catches a lot of edits that it doesn't. Galobtter (talk) 06:20, 10 April 2023 (UTC)

Support disallow: I didn’t find any false positives, and the filter only applies to non-confirmed editors. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 00:50, 11 April 2023 (UTC)

I've set the filter to disallow with the message MediaWiki:Abusefilter-disallowed-talk-page-header-removal. Galobtter (talk) 05:23, 13 April 2023 (UTC)

Proxy URL filter question

Regarding the "Proxy URL" filter, does putting the url in <nowiki> tags bypass it? Because if so, can that please be looked into, because it seems like it is a workaround used to dodge the filter, which achieves absolutely nothing helpful. Mako001 (C)  (T)  🇺🇦 12:10, 10 April 2023 (UTC)

@Mako001: Which specific filter are you talking about? If it is private then the discussion should not take place here. 0xDeadbeef→∞ (talk to me) 12:18, 10 April 2023 (UTC)

@0xDeadbeef: Thanks for noticing something was a bit off there, I meant proxy URL, now corrected. Mako001 (C)  (T)  🇺🇦 12:21, 10 April 2023 (UTC)

Can you give some examples? from AbuseFilter/892 I don't see anything regarding nowiki tags. 0xDeadbeef→∞ (talk to me) 12:32, 10 April 2023 (UTC)

Putting the url in nowiki tags would make it not be in added_links. Galobtter (talk) 22:46, 10 April 2023 (UTC)

Are people actually bypassing this filter? This filter is for unintentional additions, so I wouldn't expect people to try to bypass it. Galobtter (talk) 22:45, 10 April 2023 (UTC)

Well, if it is slightly harder than simply modifying the url, then yes, they may try to avoid having to fix it the proper way. This here is me hitting the proxy URL filter whilst cleaning up nowikis from refs. Nowiki-ing these urls is the very worst thing that they can do, as it hides it from many attempts to find and fix these urls, whilst still giving the citation the appearance of verifiability. The same would go for the predatory/open access journal filter too I'd expect. People do it with the spam blacklist too as it turns out. Whilst trying to clean up some other refs, I found myself hitting the blacklist rather frequently. And I was only searching for a fairly narrow range of uses of nowiki tags around urls. If there is a disallow filter/blacklist set to stop people adding certain urls, then they shouldn't be bypassing it this way, at least not in mainspace. Mako001 (C)  (T)  🇺🇦 13:43, 12 April 2023 (UTC)

Maybe there should be a filter to stop nowikis around URLs. For the spam blacklist stuff, the URLs should be removed or whitelisted. I also didn't realize the filter is disallow. It should probably be warn and tag since it's for good faith edits and I feel like it's better to at least have the URL not be nowiki. Galobtter (talk) 22:50, 12 April 2023 (UTC)

Regarding the first part of your comment: A filter to stop nowiki-ing of URLs would need to be limited to when used inside ref tags, as URLs are often legitimately nowiki-ed inside the body of an article (in internet-related articles particularly). I agree that any URL that the addition of is being disallowed shouldn't be bypassed using nowiki tags, as clear consensus exists that such URLs (proxy URLs and blacklisted URLs) shouldn't be in the encyclopaedia without having a case-by-case assessment of use.

Regarding the second: No, not really, per this discussion (and several cases in the archives where the filter's purpose and set-up has been affirmed) the Proxy URL filter should be an exception to the general rule that filters stopping good-faith edits shouldn't be set to disallow. It was also initially tried as warn and tag. Mako001 (C)  (T)  🇺🇦 05:43, 16 April 2023 (UTC)

References

"Among Us" vandalism in usernames

Whichever filter is currently used to disallow "Among Us" related vandalism in articles, should be extended/expanded to cover account creations too. Usernames like this I'm starting to see too frequently. Taking Out The Trash (talk) 20:19, 12 April 2023 (UTC)

I personally don’t see a reason why usernames can’t have the word sus or similar in them. It’s not offensive or promotional: - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 10:09, 13 April 2023 (UTC)

And it's kinda easier to block a vandal indef immediately if the username is a meme-linked username. If they use a usename like "Amongus69420sus" and start to vandalise, they're bascially doing us all a favour by making it clear that they aren't here in good faith, which results in a faster block and less overall disruption than if they'd made the same edits using something nondescript like "Username147502". Mako001 (C)  (T)  🇺🇦 05:21, 16 April 2023 (UTC)

Just create a duplicate filter that is set to tag as possibly disruptive username, or something like that. Zippybonzo | Talk (he|him) 12:36, 19 April 2023 (UTC)

This is probably a better fit for User:AmandaNP/UAA/Blacklist. Suffusion of Yellow (talk) 20:27, 19 April 2023 (UTC)

Disallowing the mention of me by non-autoconfirmed users

I think some filter already exists that helps prevent mentioning users by vandals, as I have been mentioned in edit summaries by blocked users (example here where my user page is piped by the text "Kojad". Upon my 5.5 years as a registered Wikipedia user, I don't see any legitimate reason for non-confirmed users to mention me in edit summaries without good reason whereas mentions from those who are at least autoconfirmed generally do. (That is the advice given to me by email, not on Wikipedia itself.) Iggy (Swan) (Contribs) 15:22, 13 April 2023 (UTC)

@Iggy the Swan edit filters are "expensive" - how often is this occurring? Your example doesn't appear to be an edit by a "blocked user" either, can you elaborate? — xaosflux ^Talk 15:30, 13 April 2023 (UTC)

Re how often is this occurring - in March 2023: 4 times plus another 2 here and a further 2 within the space of two active Wednesdays. I have checked this account has been blocked which contains the edit I've linked when opening this section.

I have never realised edit filters are "expensive". Iggy (Swan) (Contribs) 15:44, 13 April 2023 (UTC)

@Iggy the Swan: that account was blocked on 2023-03-29T09:49:33, the edit was made prior to that at 2023-03-29T09:46:19, so at the time it was made the mention was not sent by a blocked user; generally the only way that could happen is if they were abusing their own talk page while not being blocked from it. Am I missing something about you getting mentioned in edit summaries by blocked users? — xaosflux ^Talk 16:26, 13 April 2023 (UTC)

Ah I see what you mean now about block status between accounts, obviously what you said is indeed very true. Apologies for possible confusion. Iggy (Swan) (Contribs) 18:44, 13 April 2023 (UTC)

Abusefilter improvements

People might want to add thoughts at m:Talk:Wikimedia_Foundation_Annual_Plan/2023-2024/Draft/Product_&_Technology/OKRs#Result_2_Workflow_improvements - the WMFs draft goals for the year include "complete improvements to four workflows that improve the experience of editors with extended rights (admins, patrollers, functionaries, and moderators of all kinds)", so we might be able to get some proper improvements to abusefilters in the coming year. Galobtter (talk) 22:06, 13 April 2023 (UTC)

That’s exciting! I am glad that abuse/edit filters are going to be improved soon. Good suggestions @Galobtter. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 01:47, 15 April 2023 (UTC)

Expanding 247 (email additions) to all namespaces?

From the discussion here, it seems like the consensus is that new users who add their own emails should have those edits reverted and suppressed. Special:AbuseFilter/247 currently disallows email additions to article and Wikipedia space, and I tested running the filter on contributions to other namespaces here. Most of the additions there are of personal emails, with those that are not being of the spam variety, so it seems like a very good idea to me to disallow those additions (when disallowing they would receive the friendly message given here). Any thoughts? Galobtter (talk) 07:45, 15 April 2023 (UTC)

I cannot access the page you linked (because I am not an EFH or EFM), but I trust your judgement on what these have shown. I support setting this to more namespaces if other users that can see private filters also agree. It seems like a no-brainer idea to me. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 19:16, 15 April 2023 (UTC)

This should at least apply to the talk namespace; there's basically no reason for anyone to put their email there. But some users like to keep a public email address. If this filter to also apply to userspace, what guidance should we offer to users to come to WP:EFFPR saying "Yes, please, I really want my email on my userpage, can you please add it because the filter won't let me?" In the test filter's log, I found one address belonging to a Ph.D., and another to a 10-year-old (now oversighted). But most cases aren't so obvious, and I don't want to be the one to share a child's personal information. Suffusion of Yellow (talk) 21:31, 15 April 2023 (UTC)

I think they can be told to use {{no spam}} and readd it themselves. The Ph.D person links to his university page where his email is similarily obfuscated to prevent spam, so it seems reasonable to me to tell people to at least make sure they don't get spammed. Galobtter (talk) 21:42, 15 April 2023 (UTC)

I agree. The filter should 100% not allow it on all talk pages. Just a thought, but we could make the filter only apply to non-extended confirmed users to prevent false positives. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 22:32, 15 April 2023 (UTC)

It only applies to editors with less than a 100 edits. Galobtter (talk) 01:25, 16 April 2023 (UTC)

I was unaware of this, @Galobtter. If the filter only applies to users with under 100 edits, than I support extending the filter to cover all namespaces. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 02:14, 16 April 2023 (UTC)

 Done, expanded to all namespaces. I'm open to excluding user space if that becomes a problem. Galobtter (talk) 23:17, 21 April 2023 (UTC)

Illusion Flame for edit filter helper

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

---

Hello Edit Filter community,

I am requesting Edit filter helper rights as I believe they would allow me to better help out around the edit filters. Currently, I spent most of my time commenting on discussions here, reviewing false positive reports, and occasionally commenting on the requested edit filter page. Being able to view private filters would allow me to better respond to false positive requests that involve private filters. I would also be able to coordinate with fellow EFH/EFM about private filter and how to improve them. (Not publicly if it involves private content of course)

For official requirements, here is how I stand:

Demonstrated need for access:

A: I can help around EFFP to review reports with private filters. This would also allow be to better help out on EFN and requested edit filters.

No recent blocks or relevant sanctions:

A: Clean bock log.

At least basic understanding of account security

A: I have a strong password and understand account security.

At least basic understanding of regular expressions if the intent is to assist with authoring filters

A: I have some understanding of REGEX, though I still have some to learn. I don’t intend to do a lot of filter authoring though.

Sufficient ability with the English language to understand notes and explanations for edit filters

A: I am fluent in English and am capable of understanding notes/explanations.

Currently-active extended confirmed editor on the English Wikipedia (i.e. has made edits or logged actions within the last 12 months):

A: I have over 4,000 edits, have been here for about 2 months as of writing and average ~70 edits per day.

As for non-edit filter related editing, I work a lot in anti-vandalism. I tag a lot of pages for speedy deletion and try to help out new users when possible.

I would also like to thank Zippybonzo for encouraging me to go for this role, as I usually lack self-confidence.

Thanks, - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 20:45, 20 April 2023 (UTC)

Support- Has a clue, active in the edit filter area, not a jerk, it will help them to improve at filter authoring and there is a need as there aren’t many people who help out with Private false positive reports. Zippybonzo | Talk (he|him) 20:47, 20 April 2023 (UTC)

Support. All things considered, I am not very active around edit filters: I only really use the promotional userpage filters. However, I know enough and have dealt with enough vandalism to tell you that Illusion Flame is one of the most committed beginners on Wikipedia in this area. Some people have before questioned their experience, but having only two months of tenure is a red herring to their ability to just get stuck in. I have been watching Illusion Flame's editing for a while now and although there have been some bumps (early CSD tagging) they have proven that they can be trusted. They demonstrate a clear need for these permissions and will likely do an excellent job. Schminnte (talk • contribs) 21:11, 20 April 2023 (UTC)

Oppose EFH is an extremely high-trust role, and two months of tenure is just nowhere near enough to have earned the trust the role requires. GeneralNotability (talk) 23:38, 20 April 2023 (UTC)

Understood @GeneralNotability. I trust your opinion, but I also feel that time since account creation isn’t everything. - 🔥𝑰𝒍𝒍𝒖𝒔𝒊𝒐𝒏 𝑭𝒍𝒂𝒎𝒆 (𝒕𝒂𝒍𝒌)🔥 23:44, 20 April 2023 (UTC)

Oppose for the reasons given at Special:Permalink/1150947285#WP:PERM clerking, and per GN above — it takes time and experience to build trust. I applaud your enthusiasm, but you can be plenty helpful without EFN while that experience (and trust) builds — TheresNoTime (talk • they/them) 02:19, 21 April 2023 (UTC)

Oppose need more time as per GeneralNotability. EFH should probably have a "at least 6 months of activity" requirement, as I wouldn't support anyone with less than that account age. Galobtter (talk) 05:45, 21 April 2023 (UTC)

Might this be something to start an RfC on to add this to policy, because that seems to be what these opposes are based on? Schminnte (talk • contribs) 07:01, 21 April 2023 (UTC)

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

• Adding this note post the closing of the section. Illusion is very talented and extremely active. I would support his application once a few more months go ahead with evidence of learning (which they are already displaying). Warmly, Lourdes 18:26, 21 April 2023 (UTC)