Wikipedia:Edit filter noticeboard

Welcome to the edit filter noticeboard

WATCH Recent filter changes (): Filter 1323 — Pattern modified Last changed at 16:22, 13 September 2024 (UTC) Filter 2 — Actions: none Last changed at 01:46, 9 September 2024 (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 332 enabled filters and 49 stale filters with no hits in the past 30 days. Filter condition use is ~1017, out of a maximum of 2000. (). See also the profiling data and edit filter graphs. Click here to start a new discussion thread

revisiting local edit filter helpers group

Portions of the above thread were split out here for a longer discussion

• I love the idea of an edit filter viewer user right, and the only reason I haven't proposed one is I felt like doing so would be more hassle than it's worth without knowing what level of support/use it would get. Ks0stm ^{(T•C•G•E)} 21:09, 20 April 2017 (UTC)

• A localized version of the global "edit filter helpers" that allows for read only access to edit filters is possible - and is technically inexpensive (global access is not granted for local-only use normally). We would really need a proper RFC to create it, and to establish qualifications, etc. See Special:PermaLink/720950015#RFC_-_Proposed:_.22Page_mover.22_permission_to_be_created for an example of creating a new access group that was fairly successful. — xaosflux ^Talk 03:46, 21 April 2017 (UTC)
  • Note: I proposed a read-only group about 2 years ago (c.f. Wikipedia_talk:Edit_filter/Archive_7#Edit_filter_helpers) - but it was strongly opposed at the time; consensus may change though. — xaosflux ^Talk 03:56, 21 April 2017 (UTC)

• As an aside, I would also support the creation of an edit filter viewer user right. I have come across situations where it would have come in handy (RE: SPI stuff) as well which I had to escalate and if there were a viewer right I could certainly make good use of it. -- Dane ^talk 04:17, 21 April 2017 (UTC)
  • Seems like the primary opposition then was "go to meta", but someone from meta said "no, do it here", so I suspect it would pass this time around. And Chrissymad is a great example of someone who wouldn't be granted the ability to edit filters, but should be able to view them. Sam Walton (talk) 12:22, 21 April 2017 (UTC)

Ping in some of the opposition that has recently edited from last the 2 year old discussion - to see if any thoughts have changed. I don't want to go through setting up a new RfC that is just going to end up with the same conclusion. @Reaper Eternal and Epicgenius:. — xaosflux ^Talk 00:46, 22 April 2017 (UTC)

• Replying to the ping. Now that there is a "global abusefilter helper" right, I support this right. I don't see why a global right for this purpose could be created, but not the corresponding local right. epicgenius (talk) 02:39, 22 April 2017 (UTC)

• For me, this would've been great while developing DatBot 3. It could still be useful to check which filters to add. Dat Guy^Talk_Contribs 13:13, 23 April 2017 (UTC)
• I'd support such a right. I can also see it being a useful learning tool for someone who is trustworthy but has not had the ability to demonstrate readiness for write access. Thryduulf (talk) 22:28, 26 April 2017 (UTC)
• I don't know where I was the last go around or else I would have offered my strong support. The need for a read-only right comes up often enough, and we'll send people here instead of WP:PERM (where we see occasional hat shopping). In addition to Chirssymadm we granted access to Vito Genovese this past March when they only wanted read-only. I think Vito could have gotten the global group, but for others it doesn't make sense as they are only working with filters here on the English Wikipedia — MusikAnimal ^talk 02:40, 27 April 2017 (UTC)

Keeping this from archiving - Agree, lets keep this specialty out of PERM (just like EFM); we will need an advertised RfC to create this EFH group — xaosflux ^Talk 15:19, 8 May 2017 (UTC)

Happy to put an RfC together. So this would work like EFM; a post at this noticeboard with the request, open for 7 days? Should we put something in WP:EF regarding the criteria for being granted the user right? If so, what? Sam Walton (talk) 15:23, 8 May 2017 (UTC)

That sounds pretty good - the criteria is less stringent as they would not be able to actively disrupt editing; details on the process may change during an RfC (it is a request for comments after all :D ) but suggest starting with: "request at EFN"; 7 day discussion period; can be closed by any admin; minimum qualifications: maybe extended confirmed + demonstrated activity with edit filter assistance OR active administrator of another WMF site; no recent blocks or sanctions. requirements to maintain: should have decent account security; must not share private filters to unauthorized parties; must be active (removal after 1 year inactivity); -- I'm just throuhing ideas out here - perhaps draft this on a new page for more input. — xaosflux ^Talk 15:52, 8 May 2017 (UTC)

There needs to be a "need to know" requirement, such as demonstrated assistance at SPI or significant anti-vandal work. Non-admin SPI clerks once past training should automatically get this right. Since you brought up inactivity - does anyone actually remove TE/PM for inactivity? – Train2104 (t • c) 17:13, 8 May 2017 (UTC)

Yes - usually a few times a year batches of inactivities get cleaned up by various admins - generally a "no big deal" if someone comes back to readd. — xaosflux ^Talk 17:20, 8 May 2017 (UTC)

What's the current state of this - is an RFC being drafted somewhere? Thryduulf (talk) 14:28, 5 June 2017 (UTC)

It's basically stalled, @Thryduulf: if you are in the mood, here is the place to start the new RfC. — xaosflux ^Talk 23:11, 12 June 2017 (UTC)

I would appreciate having this right. I currently have EFM, but that's only for viewing purposes; if I've ever edited a filter, I don't remember it. Nyttend (talk) 03:37, 13 June 2017 (UTC)

@Nyttend: sysops now have (abusefilter-view-private) included with access, you do not need to hold the edit filter manager group for this purpose. Head over to Special:UserRights/Nyttend and toggle yourself off to see. This would be for adding "view only" access to all the filters to non-administrators (and possibly also viewing of the spam log as was done on meta). — xaosflux ^Talk 03:50, 13 June 2017 (UTC)

Edit filter helper right - pre-RFC discussion

As a final step before an RfC, I just want to see if there is local consensus for the following suggestions. They are numbered solely for ease of reference in this discussion, bullets (and possibly more expansive language) will likely be used in the final version.

'Process for requesting right

1. Make a request for right here (WP:EFN)
2. Discussion will be open at least 7 3 days
3. If a previous application for edit filter manager or edit filter helper was unsuccessful, the following people should be notified of the new discussion:
   • Participants in the most recent discussion
   • The closing administrator of the most recent discussion
4. If the edit filter manager or edit filter helper right was previously removed for any reason other than inactivity, the following people should be notified of the new discussion:
   • The administrator who removed the right
   • Participants in any discussion that resulted in the right being removed
   • The Arbitration Committee, if removal was at the committee's direction
5. Discussion will be closed by an administrator
6. If successful, an administrator will grant the right

Requirements for granting

• Must meet all of these criteria:
  1. At least auto-confirmed
  2. Demonstrated need for access (e.g. SPI clerk, involvement with edit filters)
  3. No recent blocks or relevant sanctions
  4. At least basic understanding of account security
  5. At least basic understanding of regex
  6. Sufficient ability with the English language to understand notes and explanations for edit filters
• Must also meet at least one of these criteria:
  1. Currently-active extended-confirmed editor on en.wp
  2. Current administrator on another WMF project
  3. Current edit filter manager on another WMF project
  4. Current WMF developer or staff member who needs access for WMF-related purposes (I expect this will be practically never needed, but it seems useful to have in case it is)

Requirements for retaining

1. Currently active on en.wp (defined as making edits or logged actions within the last 12 months)
2. Currently active with edit filters on en.wp (defined as making edits or logged actions related to edit filters within the last 12 months)

   Most "helpers" won't have logged actions since it is read only, most other advanced rights are just any activity - suggest we go there. — xaosflux ^Talk 14:59, 25 June 2017 (UTC)

• Note these are alternates - please note which you prefer.

Reasons for removal (excluding inactivity)

• Note this is not an exhaustive list - removal of the right will always be considered in these circumstances, but may be considered in other circumstances too.

1. Sharing details of private filters with unauthorised parties
2. Poor account security (including compromised and potentially compromised accounts)
3. Abuse of edit filters
4. Sanctioned by Arbcom or the community for actions that mean continued suitability is uncertain

Process for removing right

1. Any user with the right who no longer meets the activity requirement must be notified of this on their talk page. This notification may be given by any user or by a bot.
2. Any administrator may remove the right from any user who still does not meet the activity requirement 7 days after being notified. WP:EFN should be notified of the removal and reason.
3. If the situation is urgent, any administrator may remove the right without prior notification. WP:EFN should be notified of the removal, giving reasons unless privacy or similar concerns prevent this.
4. If the situation is not urgent, any user in good standing may make a request at WP:EFN for the right to be removed, giving reasons unless privacy or similar concerns prevent this (in which case, contact an administrator privately and note in the request you have done this). The user concerned must be notified on their talk page.
5. Any discussion about the removal of the right will be closed by an administrator. Uncontroversial requests, including self-requests, will be closed when actioned, other requests will remain open until at least 7 days after the user was notified.

Everything above is draft. Requirements can be added, removed or changed. Please comment. Thryduulf (talk) 14:35, 25 June 2017 (UTC)

Struck some of the "notification" requiremetns for inactivity removal, this is not hard to get we don't need all that. The only admin-controled flag we do this on is ip-block exempt, as it may impact article editing. If someone expires out of this they can come ask for it back. — xaosflux ^Talk 14:57, 25 June 2017 (UTC)

I've tweaked your striking so that removal for inactivity is explicitly allowed. Thryduulf (talk) 16:47, 25 June 2017 (UTC)

• We should specifically list out the included group names on this. It may be useful to also include viewing the spam blacklist log, it is related in that it is also a "filter" that can disallow edits and is sometimes the actual thing stopping an edit. — xaosflux ^Talk 14:57, 25 June 2017 (UTC)

  The exact permissions included in the global group should work here. -- Ajraddatz (talk) 19:48, 25 June 2017 (UTC)

  Many are already included in users here, need to add:

  (abusefilter-view-private) <What this is literally about>

  (spamblacklistlog) <related spam blacklist filter>

  (titleblacklistlog) <future titleblacklist filter log> phab:T68450 — xaosflux ^Talk 20:11, 25 June 2017 (UTC)

  Good point. Titleblacklistlog probably shouldn't be included at this point, given the continuing debate over what it should show, and the lack of technical implementation at the moment. (abusefilter-log-private) could be included as well. -- Ajraddatz (talk) 20:26, 25 June 2017 (UTC)

  Striken, abusefilter-log-private does not appear to exist? — xaosflux ^Talk 23:00, 25 June 2017 (UTC)

  The right exists, but isn't included in any local group here. It must be included as part of a higher-level right, maybe abusefilter-modify, so it's never needed to be explicitly bundled in to a group. Then again, it might be included in abusefilter-view-private - I'll test and get back to you on that. Edit: Looks like it is included in abusefilter-view-private, so good to go without it. -- Ajraddatz (talk) 02:12, 26 June 2017 (UTC)

• A 7 day voting period for read-only rights seems a bit excessive. I can't remember what the norm is on Meta these days for the global group, but 24-48 hours or even just admin approval would probably be sufficient here. As for reasons for removal, abuse of edit filters would be difficult give there is no write access given here. Other than that, the proposal looks reasonable. Though it still makes me a little sad to support adding to the endless number of non-sysop groups on enwiki for people that would have just been made admins 10 years ago, but this is perhaps one of the more useful proposals out of the recent ones. -- Ajraddatz (talk) 19:45, 25 June 2017 (UTC)

  I'd be good with reducing to from 7 to 3. — xaosflux ^Talk 20:11, 25 June 2017 (UTC)

  Yep, made the request period 3 days. I've left the removal discussion unchanged though. While abusing the edit filters themselves with read only access would be almost(?) impossible, it would be possible to edit around private filters or to flood filter logs. It's also useful to have in case someone does find a way to abuse them. Thryduulf (talk) 23:02, 25 June 2017 (UTC)

  3 days is more reasonable. Fair point with working around; hopefully it won't ever be an issue, but there certainly isn't a cost to keeping that condition in there. -- Ajraddatz (talk) 02:12, 26 June 2017 (UTC)

• I'm going to suggest that anyone who successfully completes the SPI clerk training be automatically granted the right if they are not an administrator, and that administrators be authorized to grant temporary rights to clerk trainees at their discretion, to be removed immediately should the user not complete the training. – Train2104 (t • c) 00:03, 26 June 2017 (UTC)

  @Train2104: what is involved in "completing" that? — xaosflux ^Talk 00:05, 26 June 2017 (UTC)

  I'm not familiar with the clerk training process, but WP:SPI/C says ...until the Checkusers (at the recommendation of a clerk) feel the trainee's track record demonstrates sufficient judgment and experience to be relied upon without supervision. – Train2104 (t • c) 13:46, 26 June 2017 (UTC)

  I'm fine with "Checkuser discretion" to add this to any editor a checkuser deems necessary. — xaosflux ^Talk 14:38, 26 June 2017 (UTC)

  I think I'd be OK with a checkuser giving it to anyone actively helping with CUs would would benefit, providing they meet the normal requirements and haven't had the edit filter helper or edit filter manager right removed previously for cause. Anyone who has had it removed for cause previously should come through the normal process. Thryduulf (talk) 20:40, 27 June 2017 (UTC)

Edit filter helper right - refined proposal

Based on the above discussion, I will put the following to an RfC in a few days if there are not further objections. Please particularly check I've got the technical bit at the start correct, if I haven't please just fix it. Also feel free to make any other changes you feel are uncontroversial but comment with more substantial changes. Thryduulf (talk) 10:10, 31 July 2017 (UTC)

Pinging those who have commented previously: @Ks0stm, Xaosflux, Dane, Samwalton9, DatGuy, MusikAnimal, Train2104, Nyttend, and Ajraddatz: Thryduulf (talk) 10:13, 31 July 2017 (UTC)

@Thryduulf: Looks pretty good to me. — xaosflux ^Talk 11:23, 31 July 2017 (UTC)

Yes, looks fine to me. Thryduulf, if you're striking a 7, please strike text next to it too; on first glance, I thought you were proposing a 73-day discussion period and wondered how/why you'd gotten it to display a slash like a handwritten numeral :-) Nyttend (talk) 11:44, 31 July 2017 (UTC)

's a lot of text. Sure that it is strictly necessary? Jo-Jo Eumerus (talk, contributions) 12:08, 31 July 2017 (UTC)

• The refined text looks good. I agree somewhat with Jo-Jo, but there isn't any particular wordiness present, more just a lot of detail. -- Ajraddatz (talk) 13:57, 31 July 2017 (UTC)

  As far as the "RfC" goes - this can all be put on a description page (e.g. Wikipedia:Edit filter helper (ala Wikipedia:Page mover) , the naming convention is keeping in line with other project - but that will also allow it to be linked better for the spam log access links. The RfC would be to approve the proposed page. — xaosflux ^Talk 13:58, 31 July 2017 (UTC)

This Salvidrim guy can't read. Salvidumbass! (talk) 18:28, 31 July 2017 (UTC)

Any administrator may remove the right from any user who does not meet the activity requirement. - These activity requirements are defined where? Ben – Salvidrim! ✉ 14:27, 31 July 2017 (UTC) @Salvidrim: the user has made edits or logged actions within the last 12 months) — xaosflux Talk 14:52, 31 July 2017 (UTC) That's one of the four granting criteria for EFH... so if the user has no edits on enwiki but is an frwiki sysop (for example), he could be granted EFH, and then immediately removed for not meeting activity requirements? The granting criteria and removal criteria need to be explicitly defined (and probably separately). Ben – Salvidrim! ✉ 14:57, 31 July 2017 (UTC) That is under the "Requirements for retaining" specific section already, and no - the fact that they asked for it would already mean they have an "edit" in the last year. — xaosflux Talk 15:49, 31 July 2017 (UTC) @Salvidrim: The granting criteria ("requirements for granting") and removal criteria ("requirements for retaining", "reasons for removal") are explicitly defined separately already. If the headings could be improved to make this more obvious, then please suggest alternatives - what you see is just my best effort, and I'm no particuar expert on these things. The "Requirements for retaining" is intentionally plural and general to fit with the others and to allow it to allow it to remain should the requirements change at any time without breaking any links. Thryduulf (talk) 17:42, 31 July 2017 (UTC)

Looks fine to me, if a bit lengthy. Usually we don't include "X must be notified" in user rights granting procedures, though. Also, should we include the ability to set up 2FA as one of the flags? – Train2104 (t • c) 15:43, 31 July 2017 (UTC)

I added the (oathauth-enable) to the list above. — xaosflux ^Talk 15:51, 31 July 2017 (UTC)

@Train2104: the lengthiness is because this is the combined information, requirements and procedures page about the right - it doesn't exist yet so all three need to be created and I don't see that there is any benefit to having that spread over three pages. As noted by Xaosflux it will go on Wikipedia:Edit filter helper (WP:EFH is conveniently available too) and the RfC here will be about approving (or not) the right and the processes defined there (and any consequential changes to the information pages about edit filters and usergroups, but they'll be uncontroversial simple factual updates that can be added and tweaked by the people who maintain those pages, so do not need to be explicitly defined). Thryduulf (talk) 17:42, 31 July 2017 (UTC)

• One complaint: At least basic understanding of regular expressions – I don't think that should apply here. Many of the SPI clerks and interested parties merely need to view the private logs. They of course are welcome to suggest changes to filters, but that's not what the edit filter helper right is for. If I trust a user with the private logs, and they're competent at regex, I'd probably be OK with giving them write access.
  Secondly, just a general comment: While I think including 2FA is fine (hopefully all users will have this ability at some point!), here I don't think it is pertinent. You can do zero damage by viewing filter and spam blacklist logs alone. The likelihood of one of the socks breaking into your account to figure out how to get around a filter seems very low. Instead of trial and erroring with your password, they'd have an easier time trial and erroring to get around the filter. Just my two cents... but like I said I don't think adding 2FA is a bad idea, I just wanted to point out the need for additional account security isn't really there with a view-only right (at least one that doesn't reveal super sensitive data such as checkuser logs) — MusikAnimal ^talk 16:41, 31 July 2017 (UTC)
  • @MusikAnimal: My thought process for including it was so that people could at least get the gist of what the edit filter was doing, but then I wasn't really thinking about SPI helper uses when drafting it. I'm not greatly attached to it, but what do others think? I'd say that 2FA isn't required for edit filter helpers, but if I've understood the right correctly then all it does is allow (not require) people to enable it. I don't see how that would be harmful? Thryduulf (talk) 17:42, 31 July 2017 (UTC)
    • Nope, definitely not harmful. As I said, it's fine to include 2FA. I was just pointing out that this new right does not privilege a user with anything that could cause damage. The clause about having to have familiarity with regex however is something I would remove — MusikAnimal ^talk 17:54, 31 July 2017 (UTC)
      • Yea, it's a GOOD to have and belongs on WP:EFH, but don't think it needs to be a "requirement" - along with the requirement for "basic understanding of account security": how are we going to "measure" this? (make them take a test?, "Enter your password in to this autofill form to continue!"). — xaosflux ^Talk 17:57, 31 July 2017 (UTC)
        • I was going to say the same. Basic account security is generally common knowledge, and we have no way to verify if they're actually following it, and again this right isn't that sensitive. Removing this would also take out some of the wordiness with the proposal. My 2 cents! :) — MusikAnimal ^talk 18:04, 31 July 2017 (UTC)
        • (edit conflict) @Xaosflux: I'm unclear what you are saying is a good thing to have - 2FA or basic knowledge of regex? Where would you put "good to haves"? I don't think we need to define how a basic understanding of account security will be verified in this page (particularly as what constitutes reasonable basic security may change over time with changes in technology, etc), but I imagine it being an implied self declaration thing by those requesting the right (i.e. by requesting the right you implicitly declare you meet the requirements) - good faith would be assumed unless there was a reason not to. Thryduulf (talk) 18:14, 31 July 2017 (UTC)
          • I took back out 2fa, it's really not needed here. For any "requirements" (like regex experience) - how do you intend to actually measure this? — xaosflux ^Talk 11:36, 1 August 2017 (UTC)
            • As I noted above, I wasn't intending it to be measured. It's a question of asking the candidate "do you have this knowledge?" if they say "yes" then AGF that they do unless there is some reason not to. It's as much a guide to what is useful for the job and a way to dissuade hat collectors than a strict "requirement" as such. If you can think of a better way to achieve this then suggest it but the ask and AGF the answer seems likely to be sufficient for what is not a very powerful right. If you don't think it's necessary to have at all then say so. If you'd prefer it as a "good to have" rather than a requirement, suggest how to indicate that. Thryduulf (talk) 14:58, 1 August 2017 (UTC)

OK, think its good enough to go forward. @MusikAnimal: you may be interested in meta:Requests for comment/Expand two-factor verification as an option for all users on all wikis . — xaosflux ^Talk 02:10, 3 August 2017 (UTC)

• I've just had a thought about the requirements for account security and regex knowledge and so propose to link them to a footnote about it. My first draft of that footnote is: "There is no formal definition of what constitutes a "basic understanding", but by requesting this right you are asserting that you meet these criteria. Those commenting on the request should assume good faith regarding this assertion unless they have a reason to do otherwise.". I think that wording could be improved though - suggestions welcome. Thryduulf (talk) 11:05, 3 August 2017 (UTC)
  • I still think we should remove the bit about "basic understanding of regex", even with the footnote. I understand we want to discourage hat collectors, but you might also discourage SPI clerks and those tracking LTAs who just need to see the logs. Why are they expected to have any understanding of regex? Or, how about rewording to "Basic understanding of regex, if the intent is to help with the filters". That makes it requirement for the relevant use-case — MusikAnimal ^talk 15:14, 3 August 2017 (UTC)
    • Good idea with the "if the intent is to help with the filters" but maybe better worded as "not relevant if working with the logs only (e.g. SPI or long term abuse tracking)"? I think that is less likely to cause confusion about whether it is relevant for someone working with edit filters on another wiki. Thryduulf (talk) 15:34, 3 August 2017 (UTC)
      • Ping: @MusikAnimal, Xaosflux, Train2104, and Salvidrim: Thryduulf (talk) 10:23, 7 August 2017 (UTC)
        • Still "useful" - knowing a log hit, but not why it hit doesn't let you help as much. — xaosflux ^Talk 11:34, 7 August 2017 (UTC)
          • Special:AbuseFilter/829 along with this filter request (which might become private) are good examples of where some non-EFMs want to see private logs. Meanwhile, User:Chrissymad was the latest example of a user who was granted EFM solely for this purpose. I've modified the proposal to something I think makes sense, but however you want to word it is fine. I just wanted to make it clear these use cases do exist :) — MusikAnimal ^talk 13:37, 7 August 2017 (UTC)
• Given that it's been a few days since the last comments, unless there are objections in the mean tiem I'll start an RfC on this tomorrow (UK time) using the version as it exists above including MusikAnimal's amendments. Thryduulf (talk) 08:53, 13 August 2017 (UTC)
• RfC now live in the #RFC - creation of the edit filter helper user right section below. Thryduulf (talk) 14:30, 14 August 2017 (UTC)

RFC - creation of the edit filter helper user right

In the section above #revisiting local edit filter helpers group there is local support for creating a new user right called edit filter helper that will allow read only access to private edit filters. That section is also where all the discussion leading up to this RfC took place. The details of the specific rights included, and the associated processes, are at the new information page Wikipedia:Edit filter helper (WP:EFH). While this RfC is in progress, please do not make significant changes to that page.

If this RfC is successful, a request will be made at Phabricator for the right to be created (an RfC or similar display of community support is a prerequiste for this), and once created Wikipedia:Edit filter helper will be changed from a proposal to an information and process page and updated appropriately. Thryduulf (talk) 14:23, 14 August 2017 (UTC)

Question: Should the user right detailed at Wikipedia:Edit filter helper be created, and the associated processes adopted?

Survey regarding edit filter helper

• Support as initiator. Thryduulf (talk) 14:23, 14 August 2017 (UTC)
• Support. I recognise a small previous discussion on this, but I would prefer the application is extended from 3 days to 4 days, as three days is only a weekend. I also think the recommendation to contact an administrator privately upon removal is a bit awkward, but that's not any real reason not to support. -- zzuuzz ^(talk) 17:15, 14 August 2017 (UTC)
• Support. I have the editor right, but I only need it (and occasionally at that) to view things. I want to be able to view filters without being able to make accidental edits. Nyttend (talk) 19:09, 14 August 2017 (UTC)

As an admin you should already have access to these rights without needing to grant yourself the EFM flag. – Train2104 (t • c) 23:02, 14 August 2017 (UTC)

Correct; abusefilter-view-private is included in the sysop group. Nyttend, you also removed your EFM rights in June ;-) -- Ajraddatz (talk) 23:03, 14 August 2017 (UTC)

Oops, I forgot :-) All the more reason to have such a user group — it proves that the system can work with a user-rights package that includes view but doesn't include edit, so creating this kind of user rights package shouldn't break anything. Nyttend (talk) 04:52, 15 August 2017 (UTC)

• Support - per my comments in the previous discussions. -- Ajraddatz (talk) 23:01, 14 August 2017 (UTC)
• Support per my comments in the workshop. — xaosflux ^Talk 01:39, 15 August 2017 (UTC)
• Oppose, as the criteria are not well defined. Provision #3 is "At least basic understanding of account security[note 1]" and Provision #4 is "At least basic understanding of regular expressions if the intent is to assist with authoring filters". These aren't defined in the policy page, and is explicitly defined as " There is no formal definition of what constitutes a "basic understanding", but by requesting this right you are asserting that you meet these criteria. ". Until this can be codified, I am opposed to this policy. Nakon 05:00, 15 August 2017 (UTC)
• Support Much needed for SPI clerks, LTA trackers, and sysops from other wikis who want to piggyback off of our filters. I do agree with Nakon though – I argue those two clauses should be removed entirely. They are immeasurable (highly doubt we'll be doing quizzes), and again I feel if they are competent at regex (demonstrated by working at WP:EF/R or mailing list, as explained at WP:EFM), and can be trusted with private logs, they probably can attain full-on edit filter management rights. The primary use case here I think is not for those who want to help with filter details (at least such that it'd require any regex competency), but I understand it could be seen as a stepping stone for those who do. Finally, again, this right as proposed isn't super sensitive, requiring 2FA or anything. I would expect stronger account security for a right that can actually allow you to cause damage. We could bikeshed all day about the requirements for granting, but even as proposed, admins should be able to deduce if a candidate can be trusted, which is all that matters — MusikAnimal ^talk 16:23, 16 August 2017 (UTC)
• Support and I think the 2 provisions in question should more be admin guidelines for granting rather than requirements, being difficult to codify/quantify otherwise. c.f Rollback expects the user to have a basic understanding of vandalism, which is always left to the judgement of the reviewing admin. Crow^Caw 16:52, 16 August 2017 (UTC)
• Support -- There'sNoTime ^{(to explain)} 17:04, 17 August 2017 (UTC)
• Support as an active LTA tracker but not admin. ☆ Bri (talk) 17:51, 17 August 2017 (UTC)
• Support as a tool that will help long time vandal fighters identify trends and per prior discussions. -- Dane ^talk 23:13, 17 August 2017 (UTC)
• Support per above. Clearly beneficial to editors focusing on LTA and SPI. -FASTILY 23:27, 17 August 2017 (UTC)
• Support: I've dealt with many socks and LTAs and this would be beneficial to those who specialize in these areas. —MRD2014 ^{Talk • Edits • Help!} 00:19, 18 August 2017 (UTC)
• Support: Useful for LTA and long-term vandal fighters. KGirl ^{(Wanna chat?)} 00:43, 18 August 2017 (UTC)
• Support Anything to help the users who are constantly fighting the losing battle against vandalism on en.wikipedia. SparklingPessimist ^{Scream at me!} 02:13, 18 August 2017 (UTC)
• Support could be useful. No reason not to have it so long as there is vetting. TonyBallioni (talk) 02:57, 18 August 2017 (UTC)
• Support I'm starting to get a little leery of there being too many user groups, but as per my comments in the workshop this is useful, especially given the danger involved with write access. – Train2104 (t • c) 03:02, 18 August 2017 (UTC)
• Support per SparklingPessimist. Double sharp (talk) 03:08, 18 August 2017 (UTC)
• Support. Will help those who work in these areas but don't qualify for the edit filter manager right. Anarchyte (work | talk) 03:42, 18 August 2017 (UTC)
• Support - will greatly help hopeful users that have been noticing relevant disruption associated with even private filters, i.e. filter 860. A certain EFM knows why I'm referencing that filter. jd22292 (Jalen D. Folf) (talk) 05:24, 18 August 2017 (UTC)
• Support - (first time voting on policy RfC) Taking the time to digest what this would entail but from what I've gathered so far it would help combat vandalism and what are so often described as good-faith edits. Edaham (talk) 07:25, 18 August 2017 (UTC)
• Support. Granting certain editors the ability to view but not edit hidden abuse filters will increase the number of editors available for relevant tasks by making the privilege easier to receive, since it is not as easy to abuse as the full set of rights. Inatan (talk) 10:38, 18 August 2017 (UTC)
• Support. Sure, why not. Edit filters are specialist tools so it doesn't hurt to have its own user-right hierarchy. The proposal has demonstrated the need for such a right, especially regarding admins and edit filter managers from other WMF wikis who want to learn from or contribute to enwiki. Deryck C. 10:42, 18 August 2017 (UTC)
• Support. Per WP:EFH. --Wario-Man (talk) 10:45, 18 August 2017 (UTC)
• Support Would be a great help for vandal fighters. RickinBaltimore (talk) 13:10, 18 August 2017 (UTC)
• Support: As a user involved in using edit filters to combat harassment, this would be useful to me. Funcrunch (talk) 13:54, 18 August 2017 (UTC)
• Strong support: Would really help defeat sockpuppetry and long-term abuse. Luis150902 (talk | contribs) 14:53, 18 August 2017 (UTC)
• Support: A useful improvement to help non-admins assisting with such long-time problems. The read-only limitation should prevent any unintentional damage to the filters' functionality. Note that I am probably a bit biased, as I would request such a user-right for spam-related research (several relevant filters about common spamming patterns are currently private). GermanJoe (talk) 15:36, 18 August 2017 (UTC)
• Support per so many above. This would be very useful for helping to protect the project.   — Jeff G. ツ 15:44, 18 August 2017 (UTC)
• Support, I see no harm in this and a lot of potential benefits. Seraphimblade ^{Talk to me} 16:08, 18 August 2017 (UTC)
• Support Take me as biased, I'm a non-admin working at SPI. --QEDK (愛 • 海) 17:58, 18 August 2017 (UTC)
• Oppose as the minimum requirements are fixed too low. Private edit filters are a very vulnerable system. If a malicious user wanted access to edit filters, they could just play good vandal fighter or SPI pseudo-clerk for a while and gain access to every edit filter, breaching the secrecy of the whole system. Private edit filters should be on a need-to-know basis for those who wouldn't be trusted with regular edit filter manager or adminship. Esquivalience (talk) 18:10, 18 August 2017 (UTC)

This is a right that will given on a strictly need-to-use basis. SPI clerks undergo significant vetting (not being modest, I know) and good vandal fighter is not at all enough for EPH. EPHs will not have any write access, which leads me to ask why you'd think there would be serious misuse. --QEDK (愛 • 海) 18:48, 18 August 2017 (UTC)

Private edit filters generally target specific patterns, and can usually be easily circumvented if the pattern is known to the vandal. A malicious user would not need write access to sabotage them. T. Canens (talk) 03:07, 19 August 2017 (UTC)

I doubt anyone would find it feasible enough to go through strict vetting, display a demonstrated need for access, just to gain access to regex patterns. The only possibility of abuse here is if people go rogue, and that's plausible everywhere. --QEDK (愛 • 海) 09:53, 20 August 2017 (UTC)

Wikipedia:Requests for adminship/Pastor Theo - anything is possible, and it looks like with the declining standards it may happen again. Esquivalience (talk) 20:44, 20 August 2017 (UTC)

• Support: Would be useful in the fight against vandalism.  FITINDIA  18:36, 18 August 2017 (UTC)
• Question Thryduulf Regarding point 1 Demonstrated need for access (e.g. SPI clerk, involvement with edit filters) What exactly does this mean? Does it mean that being a vandal fighter, who has knowledge of SAF, has used/patrols SAF to catch vandals and report them, counts as "demonstrated need for access"? L3X1 (distænt write) )evidence( 18:43, 18 August 2017 (UTC)
  • There is no list of what does or does not count as a demonstrated need, that's up to the people commenting on the application, but if you can't explain why you need to see the details of private edit filters (and most people don't) then you won't be granted the right. Thryduulf (talk) 21:43, 18 August 2017 (UTC)
• Comment - is this just an admission that it's too hard to promote people to sysop these days? Sorry, but I have this concern that we're going to reach the point where nobody without the most spotless record can get through an RfA and so there are thirty different permissions replacing adminship for which people apply individually and the result is less transparency. Blythwood (talk) 19:31, 18 August 2017 (UTC)
  • While I understand those concerns, and share them to some degree, the lack of new sysops is not relevant to the need for this right. Edit filters are a very specialised area (most admins don't even know they have edit filter manager rights, and the separate right for that has existed for years) and not everyone working with them wants or needs the other admin tools. This right will also be useful for users who are not active on en.wp but who are working with edit filters on another project (ru wiktionary as a random example) and are here to borrow our knowledge and expertise. Thryduulf (talk) 21:43, 18 August 2017 (UTC)
• Question - In creating this new user group, bearing in mind that it has some degree of the similarities of administration in it, albeit you're not an admin, would users be required to apply for it in a similar way to an RFA? What would be the process for acceptance into the user group / granting of the right? Dane|Geld 00:17, 19 August 2017 (UTC)
  • The process for application is detailed at Wikipedia:Edit filter helper#Process for requesting. It's nothing as big as an RFA because this is very specialised tool that requires a demonstrated need for access and technical competence to gain, so there really aren't that many similarities to admins. Thryduulf (talk) 07:45, 19 August 2017 (UTC)
• Oppose for now due to the low criteria for granting. Extended confirmed? Way, way too low of a bar. Why don't we just invite the sockmasters in to see the filters aimed to block them? If the criteria for granting (and revoking) is raised, I could support this. But it needs to be much harder for socks to game their way to this right and then go on a vandalism spree. ~ Rob₁₃^Talk 03:35, 19 August 2017 (UTC)
  • @BU Rob13: Only extended confirmed users with no recent sanctions and a demonstrated need for access will get this right, and even then it's only read only so they can't change anything. It would actually be very difficult for a sockmaster to game their way to this right (requiring likely several months minimum of productive working with edit filters or managing to become an SPI clerk (not easy). Thryduulf (talk) 07:45, 19 August 2017 (UTC)
    • @Thryduulf: Very, very false. I regularly see sockmasters working their way toward extended confirmed. They do it already to attempt to get past ECP protection. It requires only 500 edits to become extended confirmed, which can be achieved in a couple days of counter-vandalism. Further, you haven't defined demonstrated need rigorously enough. I would assume that counter-vandalism activities related to sockpuppetry would be demonstrated need. The reality is that no-one except those who edit edit filters (or perhaps those who do so on other wikis) really need to see them. Why does an SPI clerk need to see a filter rather than grab an edit filter manager and ask them to take a look? They'd need an edit filter manager anyway if they needed to make any changes. I'm very sympathetic to a use case of allowing edit filter managers from other wikis to view our filters, but I'm seriously worried about how easily this will be granted. Keep in mind that effective standards for user rights at PERM tend to be very low. Often, I see admins grant rights to editors who have no business having them, because they handle rights they do not know much about (see, for instance, the AWB PERM page). I'm very worried about what this vague and relatively low criteria will result in. A sockmaster viewing the filter intended to block their actions can get around it very easily. ~ Rob₁₃^Talk 16:02, 19 August 2017 (UTC)
      • Just doing counter-vandalism work would not be a demonstrated need for access as you don't need to be able to see the filters to do that, and a new user requesting this right would raise red flags even if it were sufficient - the standard is "demonstrated need" not "it would be helpful" or "I would like". I agree re WP:PERM which is why requests for this very specialised right will be handled on this page (edit filter noticeboard). SPI clerks, AIUI, mainly need access to see the edit filter logs (a right that the software does not separate from viewing the filters themselves) and the spam blacklist logs but MusikAnimal knows more about that aspect than I do. Thryduulf (talk) 16:31, 19 August 2017 (UTC)
        • @Thryduulf: Why don't we just give edit filter manager to the SPI clerks? I'm fine with that. As for non-SPI clerks, I'll keep the conversation in the subsection below. ~ Rob₁₃^Talk 18:13, 19 August 2017 (UTC)
          • "Why don't we just give edit filter manager to the SPI clerks?" because they don't need, or in at least some cases, want write access. Viewing the details of filters and logs, and seeing why a filter was triggered is not the same as writing or modifying a filter. Thryduulf (talk) 18:28, 19 August 2017 (UTC)
  • After further consideration, neutral. What I'd really want to see happen is a decoupling of "view filters" from "view filter logs" and the establishment of an "SPI clerk" user right which allows viewing filter logs (and blocking temporarily for a period not to exceed 72 hours? is that possible with the new temporary blocks?). I'm not convinced by the "I don't want write access". The trust required for write and the trust required for read is the same, so long as we think the applicant is competent to not use the write access if we tell them not to without consulting an experienced filter manager (note that most admins have theoretic access to edit filters but would break the site if they tried using that access...). Still, my concerns are largely addressed by the fact that this won't happen at PERM and will only happen after consensus in a discussion. I anticipate the criteria as written will be raised above "extended confirmed" before this goes live. ~ Rob₁₃^Talk 03:27, 20 August 2017 (UTC)
    • I don't know the answer to your question about temporary blocks. Decoupling view filters from view filter logs will require a patch to MediaWiki, which is beyond the scope of this discussion and will need to be requested at Phabricator - I have no idea how likely it is to be actioned. Thryduulf (talk) 09:56, 20 August 2017 (UTC)
      • (edit conflict) While the idea is novel, yes, but community consensus would surely be against such an userright. Personally, I would never get across adminship/something similar to gain blocking (temporary or not) rights. Also, since non-admin SPI clerks are a handful in number, I do not think people would find it feasible to implement. IMO, giving write-access to EFH wouldn't be a major problem, since the level of trust, as you said, is similar; the only thing holding them back would probably be competency at regex (I myself am very much a rookie at it). --QEDK (愛 • 海) 09:59, 20 August 2017 (UTC)
        • @QEDK: Well, competency at regex isn't a problem. All you need to not fuck up with write access is competency to know not to touch the shiny buttons when you don't know what you're doing. We trust hundreds of completely non-technical admins with the ability to grant themselves write access and then use it because we trust they'll know not to. Note that write access is needed to write comments on the filters, which it sounds like this group should probably be able to do. ~ Rob₁₃^Talk 20:51, 20 August 2017 (UTC)
          • The comments on the filters are for attribution of and explanations regarding changes to the filters or changes to the status of them (e.g. setting/unsetting the filter to disallow matching edits). Edit filter helps will not be making changes to the filters so they will have no need to write filter comments on them. They can of course discuss filters on this page/on the mailing list as appropriate. Thryduulf (talk) 00:38, 21 August 2017 (UTC)
• Oppose. The level of trust required for this should at least be at the same level of admin, so I don't see the point. If you need this, you might as well stand for admin. -- Tavix ^(talk) 04:29, 19 August 2017 (UTC)
  • @Tavix: Why? It's not like any extended confirmed user will get this - they have to demonstrate a need for it and have no recent relevant blocks or sanctions - and remember that the edit filter manager right (which also gives write access, unlike this will) is also available to non-admins and has been for years without any problems that I'm aware of - indeed the only editor who has abused edit filters in recent years was an administrator (Kww). Thryduulf (talk) 07:45, 19 August 2017 (UTC)
• Oppose Great! The community has decided to cherry pick the admin tools. I don't care for the requirements because I'm definitely not putting my trust in non-admins. — JudeccaXIII (talk) 05:18, 19 August 2017 (UTC) (Move to "Support") — JudeccaXIII (talk) 19:44, 22 August 2017 (UTC)
  • This has nothing to do with cherry picking the admin tools - firstly admins have write access to the edit filters, this will only grant read access. Secondly almost no admins actually do any work with edit filters (~15 of 850). Thirdly, the edit filter manager right (which gives write access) has existed independently of the admin toolkit for years - this is just a subset of that. Thryduulf (talk) 07:45, 19 August 2017 (UTC)

  Thryduulf Question Once an editor is granted this right, I assume (s)he will be able to view the following information: Documentation#Variables. If so, will our actually names associated with our accounts be viewable along with our IPs from all devices we use? — JudeccaXIII (talk) 02:27, 21 August 2017 (UTC)

  @JudeccaXIII: The additional rights do not grant access to additional variables, it simply allows access to view filter configuration that is not hidden, and the logs associated with those filters, and to view the contents of the spamblacklist log. As far as the filters go, it is the same variables that are already used (example logs). — xaosflux ^Talk 03:44, 21 August 2017 (UTC)

  @JudgeccaXII: I don't fully understand your question, but the only people who can see the IP addresses used by logged-in users are checkusers and developers. The logs for hidden filters are identical in structure and information presented to the logs for public filters. Any filter may be set or unset as private at any time, and changing that status does not alter the content of the log at all. Thryduulf (talk) 09:30, 21 August 2017 (UTC)

• Support Callanecc (talk • contribs • logs) 11:08, 19 August 2017 (UTC)
• Support. I usually support any process that spread the rights amongst different classes of users, i consider the overall scenario more balanced in this case. And it allows a little bit of cursus honorum too. So, even if there will be some rearrangement in the future of flag architectures, it is good that this functions is not given only to sysops like other ones. In big and variegated community like enwiki it is possible to do it, there should be enough candidate to justify its creation. Maybe we can insert this request for flag in the same watchlists of the procedures of sysops if this gesture reassure or persuade some of the opponents. We could also restrict the flag to only specific classes of users (global patroller, sysops and patrollers on sister platforms, long term autopatrolled users...) for the same reason. In any case, IMHO the core idea is a good one.--Alexmar983 (talk) 12:51, 19 August 2017 (UTC)
• Support, since it looks like a great idea. Enterprisey (talk!) 14:13, 19 August 2017 (UTC)
• Support WP:PERM could be used, and bump up the requirement to 5K edits and 1 year. Not many LTAs get that far. L3X1 (distænt write) )evidence( 15:26, 19 August 2017 (UTC)
  • Using WP:PERM was considered and rejected as this is a very specialised right that needs evaluation by people who are actively involved with edit filters, so the requests for the right come here. We want to make as difficult for hat collectors to get as we can, and not having it there will also make it lower profile which is a good thing. Thryduulf (talk) 16:42, 19 August 2017 (UTC)
• Support; and I may be interested in gaining these permissions. groig (talk) 23:05, 19 August 2017 (UTC)
• Support. It makes sense to me that there are users who would make good use of this tool. And I like the idea of granting selected admin-like permissions to non-admins (unbundling!). I've thought about the issue of the wrong users slipping through, and I'm a little bit reassured by the processes for removal of the right. Beyond that, I think it comes down to: don't be foolish about granting the right, and take the granting process seriously. --Tryptofish (talk) 00:14, 20 August 2017 (UTC)
• Oppose: I fail to see the necessity of this proposed user group. Javert2113 (talk) 04:10, 20 August 2017 (UTC)
• Support Creating more specific user rights is a good way of allowing work to be done by people who might not have the overall experience needed to use all admin tools. For example an admin will need to have engaged in Afd, making articles, anti-vandalism, mediation, helping newcomers etc. all while keeping a conflict free record. Whereas this user right could be given to someone who has a track record of dealing with evil minions/vandals/sockpuppets, but may never have engaged in Afd discussions or made many articles. A Guy into Books (talk) 08:49, 20 August 2017 (UTC)
• Oppose Simply not needed in my opinion.--Jasper Deng (talk) 22:24, 20 August 2017 (UTC)
  • @Jasper Deng: Why do you think it is not needed? There are quite a few usecases presented in this discussion and in the discussion that occurred prior to the RfC. Thryduulf (talk) 00:38, 21 August 2017 (UTC)
    • The use cases can be all accomplished by assignment of the existing EFM right. If they can't be trusted to not abuse that right by modifying filters they aren't knowledgeable about, then they can't be trusted with the right in the first place.--Jasper Deng (talk) 01:12, 21 August 2017 (UTC)
• Oppose. If the user is trusted and experienced enough, give them admin rights. They still don't have to use all the admin rights if they don't want to. No need for a separate permission, anyway. Gestumblindi (talk) 11:06, 21 August 2017 (UTC)

• "Give them admin rights" is easier said than done. Only two people a month (on average) go through RfA. This proposal recognizes that fact and is a lightweight way to have some users, vetted and reviewed, granted the rights without the full RfA process. The proposal is also recognizing that for various reasons, we have more people willing to do some of the work currently restricted to admins, than are willing to go through RfA. ☆ Bri (talk) 18:17, 21 August 2017 (UTC)

• Support - Smokin'🐻 14:37, 21 August 2017 (UTC)
• Support. Will come in handy for SPI clerks and a lot of vandal fighters. RadiX∞ 18:23, 21 August 2017 (UTC)
  • @RadiX: To be abundantly clear, "a lot of vandal fighters" will not be getting access to this. That's actually the major reason I initially opposed. This isn't neo-rollback. It's a highly specialized user right that probably would be given to no more than 20 editors total, if even that. ~ Rob₁₃^Talk 16:03, 22 August 2017 (UTC)
• Support – I find it very useful to distinguish read access from write access: needs for each, and prerequisite skills are markedly different. — JFG ^talk 11:51, 22 August 2017 (UTC)
• Support - anything that helps make administrator status less of a big deal is always a good thing in my book. Twitbookspacetube 11:51, 22 August 2017 (UTC)

  Comment moved from the "Discussion" section by Thryduulf (talk) 12:00, 22 August 2017 (UTC)

• Support My main concern was privacy, but my question was answered. Though I still think there are enough user rights already, but if it helps, sure. — JudeccaXIII (talk) 19:44, 22 August 2017 (UTC)
• Reluctant Support. I see this very much as a way of granting a right while avoiding the RfA process, which is simultaneously good and bad. Obviously, RfA has a very high passing bar, and is almost impossible to pass for anyone without a stellar track record, 40 years of experience on WP, and 6 million page creations. The addition of this right to users that have not gone through the RfA process is a good thing, because it avoids that process, but creation of these usergroups for things that have traditionally been admin rights makes adminship even more of a big deal -- it is not. However, with the current state of RfA, I believe that we need to begin exploring alternate avenues to begin granting these rights... Because RfA doesn't look like it's going to change. Keira1996 01:11, 23 August 2017 (UTC)
• Support but careful vetting would be required. jcc (tea and biscuits) 16:12, 23 August 2017 (UTC)
• Oppose, anyone who needs that right should be made an admin. —Kusma (t·c) 09:20, 25 August 2017 (UTC)
  • @Kusma: Even people who have not contributed to a single discussion on en.wp but need this to assist with edit filters on another project? What about those people who are doing SPI work and have no interest or experience in closing XfDs or assessing consensus of discussions (required to stand a chance of passing RFA). It's also worth noting that the edit filter manager right, which is much more powerful than this one, has been available to non-admins for years without a problem. Thryduulf (talk) 11:24, 25 August 2017 (UTC)
    • All of those people should be admins. It is sad that the sets of skills required to be an admin is so different from that currently optimal to pass RfA, but creating new user rights is the wrong direction in my (probably minority) opinion. —Kusma (t·c) 11:40, 25 August 2017 (UTC)
      • @Kusma: I don't think I'm understanding you. Are you saying that people with zero edits on enwiki who do not know our policies but need to view our filters to be able to implement filters on sister projects should be made enwiki admins? This is a common thing that ends with existing edit filter managers emailing with those folks. It would be easier for them to view filters directly. That's the issue. ~ Rob₁₃^Talk 00:08, 26 August 2017 (UTC)
        • I don't have a problem with zero-edit admins. Compare Wikipedia:Requests for adminship/Lustiger seth. —Kusma (t·c) 20:48, 27 August 2017 (UTC)
• Support I came here from phab, after realizing that I needed the view-rights for suggesting changes to a private filter that's malfunctioning. Such a view-only option would be helpful. Lourdes 12:43, 25 August 2017 (UTC)
• Support - I haven't used edit filters much in SPI work but I certainly see how it's a valuable tool for certain long-term cases. I don't see any risk of damage from allowing more users access to this information. Ivanvector (^Talk/_Edits) 16:27, 25 August 2017 (UTC)
• Oppose The existence of this right will only invite EFMs to keep private filters that should be made public. Furrykiller (talk) 21:51, 28 August 2017 (UTC)

  @Furrykiller::--That's a pretty bad reason to oppose.Making certain edit-filters visible to everybody is practically impossible since it will, at large defeat their purpose(s).See WP:BEANS.Regards:)Winged Blades of Godric^{On leave} 11:43, 29 August 2017 (UTC)

  Perhaps I was unclear. Filters that are narrowly targeted at LTA cases are and must remain private if they are to be any use at all. My comment was directed at a few low-risk, easily probed private filters that probably produce a lot of false positives (eg #34). This proposal is obviously going to pass, and I hope that when it does, the EFMs don't use it as an excuse to mark filters as private without a good reason. Furrykiller (talk) 12:10, 29 August 2017 (UTC)

  I don't think this is at all likely - after all they would have been doing it for years now if they were going to. Thryduulf (talk) 20:50, 30 August 2017 (UTC)

• Support - There is nothing wrong with giving certain editors this newer right to only view private, hidden edits, especially if editors meet the proposed (or amended) criteria and are trusted to acquire this right. Otherwise, an editor would not deserve this right. Simple as that... I hope. The opponents are opposing this proposal for various reasons neither sufficient nor convincing enough to change my mind about this proposal. BTW, I think publicizing filtered edits would bring more harm than good. --George Ho (talk) 23:11, 28 August 2017 (UTC)
• Comment: Tally so far is 48 support, 8 oppose ☆ Bri (talk) 04:40, 29 August 2017 (UTC)
• Support - Would come in handy for vandal fighters.SshibumXZ (talk) 10:46, 29 August 2017 (UTC)
• Oppose "Demonstrated need" is too vague and subject to creep. Change criteria 1 to "1. Currently-active highly-trusted user that would otherwise qualify for the EFM userright on the English Wikipedia", and, since this is aimed at SPI clerks, add criterion 5: "5. Currently-active SPI clerk or trainee clerk on the English Wikipedia". Then this proposal would have my full support. --Ahecht (TALK
  PAGE) 16:10, 29 August 2017 (UTC)
• I lean slightly toward opposing since it looks like an unnecessary complication, but I do not fully understand it so I have no strong opinion. However, I do have questions.

I've been an admin on Wikitravel & then Wikivoyage for about a decade & am an experienced abuse fighter back to the 1990s Usenet spam wars. On WP, though, I'm only an occasional contributor. Would I be eligible for this? If so, what use would it be to me?

Is it possible this should be done on a cross-wiki basis rather than just WP? Pashley (talk) 20:41, 29 August 2017 (UTC)

@Pashley: If you have no need for it, and don't see the use for it, then I would say that there's no reason for you to have the permissions. We do have editors who absolutely understand how viewing private filters and logs could help them in our anti-abuse efforts. There is a global group: mw:Abuse filter helpers - obviously it's better to restrict things locally when there isn't a global need. -- zzuuzz ^(talk) 21:12, 29 August 2017 (UTC)

• Strong oppose Pointless. Without the ability to edit anything, this whole thing is useless. Also, I don't see a need. — Mr. Guye (talk) (contribs)  03:48, 30 August 2017 (UTC)
• Support - the ability to grant it should be restricted to Admins who are also EFMs. Cabayi (talk) 07:20, 30 August 2017 (UTC)
  • @Cabay: Slightly pointless as any administrator is able to make themselves and edit filter manager at any time. If you mean that only those administrators who work with edit filters should grant it, then there is no technical method available to enforce that but that is one reason why the requests are to be handled on this page rather than WP:PERM. Thryduulf (talk) 20:50, 30 August 2017 (UTC)
• Strong oppose - If you want to be an edit filter helper than be an admin simple as that. –Davey2010^Talk 20:37, 30 August 2017 (UTC)
  • @Davey2010: So do you believe that we should remove the edit filter manager right then, given that it is more powerful and available to non-administrators? Thryduulf (talk) 20:50, 30 August 2017 (UTC)

• Absolutely but that's just my personal opinion just the above is my personal opinion .... You can reply and essentially disagree with it but it wont change my mind. –Davey2010^Talk 21:06, 30 August 2017 (UTC)

Discussion regarding edit filter helper

• The following people commented in the discussion leading to this RfC: @Ks0stm, Xaosflux, Dane, Samwalton9, DatGuy, MusikAnimal, Train2104, Nyttend, and Ajraddatz:. Thryduulf (talk) 14:24, 14 August 2017 (UTC)

Contrast to the admin right

Edit filter helpers would need to be highly trusted. You need to be highly trusted to be an admin. Admins can see the private edit filter.

What is the need to create this separate right? Is the theory that RfA is too onerous? Do we see there being many people who would get the edit filter helper right who would not make it through a request for adminship?

Yaris678 (talk) 16:58, 18 August 2017 (UTC)

Yaris678, while it's true that only 15 of the EFMs are not admins, I would argue that their contributions are just as valuable as those of the admins. Some people simply don't want to be admins, and it's not for us to judge whether they should be forced to go into administration simply to get EFM. Plus, I'll note that only 150 admins actually use EFM, demonstrating that even with the bit there aren't that many who have an interest. Why look a gift horse in the mouth? If someone wants to help out, let them. Primefac (talk) 17:23, 18 August 2017 (UTC)

@Primefac: Actually, it is for us to "judge whether they should be forced to go into administration simply to get EFM." That's what this RfC is about. The community sets policy and access rights, so it really is for us to judge. ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 17:39, 18 August 2017 (UTC)

Nihonjoe, you make a very good point. I meant more in an "as of this point in time" metric, though given the nearly unanimous support for the above proposal, it looks like it would go that way in the future as well. I meant more in the fact that we should not make EFM only accessible to admins because that would be like shooting ourselves in the foot.

The EFH right was proposed based on a case a few months ago where I requested the right for a user because she was demonstrating a definite need to view the edit filters, but was not comfortable with actually editing them. Her gaining the right came with an "unofficial tban" towards actually editing the filters, which made a few of us realize that trusted users could/should still be able to view them if necessary. Primefac (talk) 17:47, 18 August 2017 (UTC)

Concerns about ease of access to the right

@Tavis, JudeccaZIII, BU Rob13, and Timotheus Canens: and others concerned about it being easy for sockmasters or vandals to get access, it's probably worth noting that the biggest hurdle for getting access to this is the "demonstrated need for access" criterion. The significant majority of people who will benefit from this right will be non-admin SPI clerks, which is a position that requires significant effort to get, it would surprise me if there were more than 2-3 other editors a year who meet the criteria, and some of them will get it by virtue of being an admin on another project - something a sockmaster or vandal is extremely unlikely to be. See Wikipedia:Edit filter noticeboard/Archive 2#Copies of private filters for where a sockmaster (I love bridges) attempted to get access to private filters but failed. New users requesting this rather specialised and almost certainly quite obscure right will be quite a big flag that there might be something to investigate. Thryduulf (talk) 07:59, 19 August 2017 (UTC)

• @JudeccaXIII and Tavix: let's try spelling your names correctly this time. Thryduulf (talk) 08:00, 19 August 2017 (UTC)
  • @Thryduulf: What is "demonstrated need"? Is doing counter-vandalism related to sockpuppetry "demonstrated need"? I would assume yes, or I would at least assume other admins would say yes at PERM on occasion. As for your assertion that sockpuppets don't get the bit on other wikis, that is ill-timed, since this literally happened last week. See INeverCry, who got sysop on Commons with a sock and then went on a spree of vandalism. ~ Rob₁₃^Talk 16:05, 19 August 2017 (UTC)

• Concerns about abuse of the right and infiltration of privileged toolsets are completely legitimate. (I have also seen evidence that bad actors have tried to infiltrate OTRS.) However it seems a bit circular to say we only trust admins with the tools, but simultaneously say we don't think they are able to determine who is trustworthy enough to receive permissions to use the tools. At some point don't we have to take action with expansion of access, or else remain paralyzed by fear of abuse? ☆ Bri (talk) 16:24, 19 August 2017 (UTC)
• See also my reply above, but WP:PERM is irrelevant as the right is requested and granted here not there, and it can only be granted when there is consensus to do so. Simply doing counter vandalism work is not a demonstrated need as very few people doing counter vandalism work actually do need to have any involvements with the details of the private filters. Even syspos on other wikis still need to have a demonstrated need for access here and any blocks or sanctions on another wiki will be looked at. Thryduulf (talk) 16:37, 19 August 2017 (UTC)
• I agree the requirement of extended confirmed is a bit low. I can think of a handful of users who I would grant this to right now, and they all have tens of thousands of edits and have been around for quite some time. Indeed the position of being an SPI clerk is not easy to attain, and the only other relevant position (aside from non-enwiki admins) is someone who has long been working toward tracking LTAs, like EvergreenFir. Another thing to consider is trusted users who regularly request new filters and amendments at WP:EF/R, targeted towards specific socks. Some of these people I communicate via email since they can't see the logs, so obviously a read-only right would help them. It's all on a case by case basis, and the people here who work on edit filters I think can be trusted to make the right call. Each and every request for this right involves a discussion, after all, not the judgement of a single admin as is the case at WP:PERM. That being said it wouldn't hurt to be more explicit in the granting guideline and raise the bar a bit — MusikAnimal ^talk 17:17, 19 August 2017 (UTC)

• I'm all for just granting edit filter manager to the non-admins who are regularly requesting new filters/amendments at WP:EF/R and have passed a high threshold of trust. Read-only doesn't help them as much as learning how to actually change filters. If I trust them to read a filter, I trust them to write one. I'm very worried that we're setting a hard threshold too low and this will lead to "well, it's just read access" arguments when a good-faith user seems to vaguely need the right (but not urgently). ~ Rob₁₃^Talk 18:12, 19 August 2017 (UTC)

• Not everybody needs or wants write access - not everybody is comfortable with making the changes (especially as even a minor typo can have very significant consequences), and not everybody has the technical skills required to adjust filters but does understand enough to review logs, and get the gist of the regex (for example, me). It's also a good learning tool and a way for people who want edit filter manager to demonstrate competence before being granted write access. Thryduulf (talk) 18:34, 19 August 2017 (UTC)
• Good points. The bar for write permissions however is super high, much higher than what I would expect for read-only, as it should be. If I see a regular at WP:EF/R is competent at regex and is trusted, I would recommend them ask for write access. This is exactly what happened with Crow, who didn't even want write-access but I sort of pushed them into it as I saw they were perfectly capable :) Meanwhile, others at EF/R are more saying the "sock is now doing this so the filter should do this" in plain English, and may have no conception of technical details. These are the people who would benefit from the logs, because currently all they can tell me is "this edit got through", and have no idea if the sock is active, likewise for SPI clerks and LTA trackers who don't work at EF/R. As the filter author, I monitor to make sure there are no obvious false positives, but sometimes I have to defer to the requester via email. These use cases admittedly don't happen often, but if I know I trust someone, and I know they have no desire to edit filters, why not? Obtaining write access for them wouldn't be easy. Read-only I don't think is near admin-level at all. Admins can cause significant damage, this read-only right by itself can cause zero. It's for trusted users who would clearly benefit from it, that simple. I think we have an excellent edit filter management team, and no one is going to hand out the read-only right without sufficient scrutiny — MusikAnimal ^talk 22:24, 19 August 2017 (UTC)

• Random thoughts on the above: As with any permission, there's never a requirement to grant it, so a new, suspicious, out of nowhere helper suddenly appearing and requesting doesn't bind anyone's hands. I personally might be a bit more judicious with granting to someone who doesn't know regex but knows what they want the filter to do... the logs will tell you if a filter was hit, but they won't tell you why it *wasn't* hit, so you need to be able to sort through the code to make useful suggested corrections. (There's still a few non-hits that I can't figure out why they didn't trip). I agree with {u|BU Rob13}} that we mustn't set the bar too low, and I think that's where the judgement for "demonstrated need" is crucial. Editorial or technical curiosity (even in good faith), or requests focused around one sock or disruption to one article, should not be considered meeting that need, as the requests page is quite viable for that. I suspect that it will become one of those scenarios where you "just know" if a requester is right or wrong for the permission. Crow^Caw 17:03, 22 August 2017 (UTC)

• Yes, and there is a fairly large set of long-term, trustworthy editors who don't want to be admins as I've alluded to above. Some of them have even been collated and vetted as part of an organized admin recruiting effort. ☆ Bri (talk) 17:56, 22 August 2017 (UTC)

• If the intent is to have this permission for admins/filter managers on other wikis, SPI clerks and trainee clerks, and people who would qualify for EFM but don't want the ability to edit, why not just limit it to those groups instead of using the vague "demonstrated need"? --Ahecht (TALK
  PAGE) 17:36, 29 August 2017 (UTC)

@Ahect: because that is not the intent. The intent is to restrict it to those who have a need, which includes some (but not all) SPI clerks and admins/edit filter managers on other wikis, but is not limited to them - for example Lourdes would benefit from this right to assist with identifying and debugging a (probably MediaWiki) problem that is affecting at leas one filter (see #Can someone more competent than me take a look). In other words not all SPI clerks etc have a need and not everyone with a need is an SPI clerk/admin on another wiki, etc. Thryduulf (talk) 20:58, 30 August 2017 (UTC)

Vandals and sockmasters can get around filters through trial and error, which would be much easier to do than making an account, becoming an established editor, becoming active in some area of the project that requires filter viewing, and then requesting this permission. I can understand opposing this because we already have a user group - edit filter managers - that can give people view access, with years of it not being abused to work with. But opposing the new group because a troll could use it to view private filters and save themselves a couple minutes figuring out how to bypass the filter manually, after spending months trying to collect the various prerequisites? Truly ridiculous. -- Ajraddatz (talk) 19:15, 22 August 2017 (UTC)

I'll also add that the sysop unbundling comments don't make sense here either. If anything, complain about EFM unbundling, and tell any candidates to request the full editing rights instead. -- Ajraddatz (talk) 23:57, 25 August 2017 (UTC)

Concern about "at least a basic understanding" of account security

This needs to be more than just a single sentence. There is a reason why WP:PAGEMOVER#Have a strong password, WP:TPE#Have a strong password and WP:EF#Have a strong password are sections instead of semtences. Anybody with this edit helper privilege should also fully understand and follow personal security practices, have a strong password, and everything else listed on WP:SECURITY. It has been mentioned in the concerns about ease of access discussion, but I'll basically repeat it: a vandal or sockpuppet with this would be able to view the private edit filters designed to combat vandalism. Therefore, a compromised account would also have to be blocked and its privileges removed on grounds of site security. Zzyzx11 (talk) 02:04, 25 August 2017 (UTC)

• I feel this is fully answered elsewhere, but if there is any concern that someone's account security practices are too weak then they wont get the right. This was also brought up in the #revisiting local edit filter helpers group discussion which came before this RfC, which I encourage you to read. There are far easier, and thus far more likely, ways for a vandal to bypass filters. Thryduulf (talk) 11:31, 25 August 2017 (UTC)
  • perhaps 2FA should be extended to include this new group? Cabayi (talk) 11:36, 25 August 2017 (UTC)
    • This was discussed at #Edit filter helper right - refined proposal. Given the conclusion there that this is not a necessity and the number of people who have already commented in this RfC it will probably better to propose the extension of it to this group separately after the right is created (assuming the RFC is closed as supporting the proposal). I don't know where the best place to make such a proposal would be though. Thryduulf (talk) 11:48, 25 August 2017 (UTC)
      • You can turn on 2FA now, without being an admin, by asking on meta. I know because I did it this week. ☆ Bri (talk) 03:16, 26 August 2017 (UTC)

Filter 642

Can someone please modify 642 to allow admins? Because it only allows OTRS users, it prevents cleanup of things like [1] where someone subst'd the tag. --B (talk) 22:23, 14 August 2017 (UTC)

Why is this filter set to disallow anyway? The end goal is essentially that of of Special:AbuseFilter/856, which doesn't even warn, let alone disallow. – Train2104 (t • c) 22:44, 14 August 2017 (UTC)

It looks like DeltaQuad was the one who set it to disallow in January this year. Thryduulf (talk) 23:31, 14 August 2017 (UTC)

• @B: sysop exception has been added. — xaosflux ^Talk 02:54, 18 August 2017 (UTC)

We had a problem that was identified in January where non-OTRS agents were adding OTRS templates. This resulted in files being marked as verified to a specific ticket when nothing of the sort had happened, essentially tricking editors who couldn't view OTRS (and readers!) into thinking the content was free. That's rather serious, which is why the filter was set to disallow. Keep in mind that we have an OTRS noticeboard that anyone can use to request OTRS assistance from those who can edit through the filter. The sysop exception is fine. ~ Rob₁₃^Talk 09:54, 20 August 2017 (UTC)

Filter 351 doesn't work properly

This filter does not work as well as it used to. Before it was modified in 2013 (history), the filter would catch edits that added content after categories (example), but now it does not ([2] [3]) (the filter applies to the Category namespace in addition to the mainspace). This is the change that messed up the filter. I was thinking that it should be fixed to the pre-2013 version and look something like this (most of it copied from the pre-2013 version):

! 'confirmed' in user_groups &
old_size > 0 &
(article_namespace == 0 | article_namespace == 14) &
removed_lines rlike '^\[\[([a-z]{2,3}|Category):.*\]\] *$' &
strpos(added_lines, removed_lines) == 0 &
 (
  add := substr(added_lines, length(removed_lines));
  substr(new_wikitext, length(new_wikitext)+1-length(add)) + '\n' == add
  &! contains_any(add,'{{','[[')
 )
& !(rcount("(^|\n)\s*\S",added_lines) = rcount("(^|\n)\[\[",added_lines)
)

...which is similar to what the filter used to look like. Fixing it would then catch edits that actually added text after categories again. —MRD2014 ^{Talk • Edits • Help!} 19:26, 17 August 2017 (UTC)

Ping to @Materialscientist: who made the change you referenced. — xaosflux ^Talk 12:01, 18 August 2017 (UTC)

In 2013 the filter stopped working. Completely. My change was a quick hack (copy/paste from pt.wiki), I didn't expect it would work well here. Revert me at will, I haven't designed this filter, and can't make time to investigate the problem these days. Materialscientist (talk) 23:30, 18 August 2017 (UTC)

It would appear that the purpose of the edit in question is to prevent the exception of interwikis - which belonged after the categories before 2013, but now belong on WikiData. עוד מישהו Od Mishehu 09:05, 20 August 2017 (UTC)

Re-titled section to give a better idea of what's going on with the filter. —MRD2014 ^{Talk • Edits • Help!} 01:43, 25 August 2017 (UTC)

Can someone more competent than me take a look

Tracked in Phabricator
Task T173977

I know essentially nothing about how the edit filters work. I just removed a false positive from WP:AIV/TB2. SorinaPopescu was reported for triggering filter 279. But when I click on the "diff" link in the EF log, it's showing edits by Dilloncoulter. Why are Dilloncoulter's edits showing up in the edit filter logs of SorinaPopescu? See [4]. Both editors seem to be good faith editors, so also not sure why either one is triggering a vandalism filter. --Floquenbeam (talk) 16:07, 23 August 2017 (UTC)

Related question: where is the best place to report a filter's false positive? Here? --Floquenbeam (talk) 16:08, 23 August 2017 (UTC)

• Investigating. At first glance the filter logs show Sorina's edits to Wikipedia:Wiki Ed/Mississippi State University/General Biochemistry (Fall 2017) as triggering. Also @Floquenbeam: False Positives can be reported at Wikipedia:Edit filter/False positives. Crow^Caw 18:15, 23 August 2017 (UTC)

• The log, examine, and details panes seem to show Sorina's edits, but the Diff link in the EF log shows Dillon's... odd... And Sorina hasn't edited since since Aug 10. Crow^Caw 18:18, 23 August 2017 (UTC)

• Looks like a bug. The 12 log entries over 5 minutes all reference the same diff. Coder needed! @MusikAnimal: Crow^Caw 18:27, 23 August 2017 (UTC)

• Thanks for the link to WP:Edit filter/False positives, and for not telling me to stop being an idiot and to actually read the notice at the top of the page (which is probably what I deserved). Glad someone competent is on the case. --Floquenbeam (talk) 18:29, 23 August 2017 (UTC)

• First, "repeated attempts to vandalize" is a misnomer, since all that filter does is look for repeated edits that failed to save. Here however they did save, yet somehow the filter was triggered numerous times for a single action, and the edit wasn't tagged which that filter is supposed to do. Baffling! I'm going to create a bug in Phabricator — MusikAnimal ^talk 18:58, 23 August 2017 (UTC)

  Tracked at phab:T173977. If I'm wrong about anything I said, please comment there or ping me here. Best — MusikAnimal ^talk 19:53, 23 August 2017 (UTC)

Filter 869

Unless I'm misreading the filter log, filter 869 (the WP:DAILYMAIL filter) does not seem to actually be warning anyone, which is its entire purpose. And unless I'm misreading the filter, that's because the warning function was never enabled. Assuming I'm right about that, could someone please enable it?

An additional concern, though, is that AFAICT there has never been a proper consensus to treat The Daily Star and The Sun the same way that The Daily Mail is treated. The Mail RfC was seen as meriting a five-editor closing panel, while, unless I'm missing something, the only consensus regarding the Star and Sun was a six-comment exchange among four users at AN. On a personal level, I would tend to agree that the Star and Sun should be banned, but on an administrative level I seriously question whether it is appropriate for an edit filter to do so with so little consensus.

If someone is willing to enable the warning function, I would propose the following text for MediaWiki:Abusefilter-tabloid-warning:

If consensus is that we should retain the Star and Sun filtering as well, I'm happy to redraft. But the lack of a significant consensus to cite makes that challenging, which is why I propose removing them from the filter (for now). — PinkAmpers&^{(Je vous invite à me parler)} 00:23, 27 August 2017 (UTC)

This filter is new this month, expect it is still being tuned. It is currently in "log only" mode. — xaosflux ^Talk 00:56, 27 August 2017 (UTC)

Special:AbuseFilter/684 disallowing

Recent uptick in some vandalism from proxies - no false positives yet but likely to have some. I'm monitoring the log, and will keep it disallowed for the shortest period possible. Any eyes on the log would be appreciated -- There'sNoTime ^{(to explain)} 12:58, 30 August 2017 (UTC)

There have been some (4) false positives, but the abuse is still ongoing - keeping the filter disallowing -- There'sNoTime ^{(to explain)} 13:09, 30 August 2017 (UTC)

"Derp vandal II" and "Derp 3" filters

I've noticed that these private filters are logging a lot of edits. What exactly is the purpose of these? Why are they private, what does "derp" stand for, and if they are targeting a vandal, why aren't they disallowing? 24.91.248.60 (talk) 15:52, 31 August 2017 (UTC)