Jump to content

Wikipedia:Edit filter noticeboard/Archive 3

Add links
From Wikipedia, the free encyclopedia
Archive 1Archive 2Archive 3Archive 4Archive 5→Archive 10

RFC - creation of the edit filter helper user right

Tracked in Phabricator
Task T175684
The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
  • Summary:--The proposal to create a new user right called edit filter helper , that will allow read only access to private edit filters, (per the criterion laid out at WP:EFH) has garnered consensus.
  • Details:--
    • By a rough count of heads, the RFC has roughly received 4 support votes for every single oppose.That's a quite high standard, of that we can seek, to implement a new policy.
    • Most valid oppose votes have opposed the proposal on a two-forked axis of opposition:--
      • Opposed to disbundling (Many have even proposed that the probable target candidates venture to RFA):--
        • The Edit filter manager right (which even grants write access!) has existed as a separate flag independently for years; without any problems. Also, (this being a highly specialised right), it's unfair for a perfectly suitable candidate (SPI clerks etc.) to miss out because they don't have the overall all-square skill-set required to pass an RfA.It may be also prudential that only a minority of the sysops use the right.Further, granting of the right to aid in cross-wiki anti-sock/vandal efforts is also a proposed benefit and an RfA of this type is a rarity.
      • Ease of access and consequential abuse:--
        • The phrase Demonstrated need seems to tackle the problems of easy granting and/or hat collecting etc.
and thus I believe that the arguments from the opposite camp have been pretty well defended by the proposers of the right.
  • Caveats:--
    • All that being said, the community and/or the granting administrator are adviced to carefully evaluate the candidates before granting the flag due to the huge fallouts of any misuse.
    • Account-secutity-practices et al may be reviewed at a local discussion.
  • Signed by Winged Blades of GodricOn leave at 11:30, 12 September 2017 (UTC)

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. CrowCaw 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)
  • 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. ~ Rob13Talk 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. ~ Rob13Talk 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. ~ Rob13Talk 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. ~ Rob13Talk 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. ~ Rob13Talk 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 851). 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. ~ Rob13Talk 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)
  • 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 GodricOn 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)
  • 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. –Davey2010Talk 21:06, 30 August 2017 (UTC)
  • Oppose unless very selective — On the upside, it would demonstrably be useful for the requests that have come, in the past, from other wikis wanting to copy filters, where someone's an admin "there" and by-federation likely trustworthy enough here to be temporarily granted EFM with the agreement it's read-only. Same goes for those who only requested EFM for read-only yet still demonstrated relative trust here. However, if this is put in action, it should be relatively-guarded rather than hat-collectible (e.g., there should be a good reason: demonstrated prior assistance with crafting/debugging public edit filters, being an SPI clerk, being an admin on another wiki, running an approved bot or bot approved for a trial, etc...). A few reasons for my caution: 1.) Edit filters have been extremely useful/game-changing when it comes to fighting both sockpuppetry and vandalism, in part because it's open-source to the trusted but closed-source to the stupid and idiotic (i.e., people who think disrupting a non-profit and wasting volunteer time is somehow good for anyone / socks). 2.) The vast majority of vandalism fighters don't actually need to see explicitly-private edit filters, lack the requisite technical knowledge to modify or contribute to them, and therefore don't clearly demonstrate a need for the extra tool, which isn't even an actionable extra tool otherwise. 3.) Private edit filters tend to be those that are most useful for monitoring severe, long-term sockpuppetry, particularly from the most dedicated sockpuppeteers—possibly even those who can appear to be vandal fighters just by huggling for a few weeks just to find out how they can evade. Forcing substantial, non-trivial contributions to the community seems a good-enough barrier, however; something that's done with EFMs. 4.) We already have a relatively open-door policy of "if you want details on the private filter, ask." 5.) People who actually do have the technical knowledge and/or one or all of the example prerequisites I mentioned can already get EFM. See the various requests over the years. It's not that difficult for someone to get EFM so long as they demonstrate a moderate level of trust and technical capability, which would logically be required for this right to be enabling for a would-be helper in the first place. --slakr\ talk / 03:04, 1 September 2017 (UTC)
    • Pretty much every one of your reasons for caution have been designed into the process - particularly making it difficult for hat collectors, and yes it will be very selective - you only get it if you have a demonstrated need to have it (rather than only refusing if there is a reason to refuse, as some other rights). The reason this is required as well as EFM is that several people who have been given EFM didn't need/want full write access and others who were given EFM when they wouldn't have been if this right were available. Anyone can ask for details of a private filter, but that does not mean the details are given out in public or even given at all in many cases. Thryduulf (talk) 08:39, 1 September 2017 (UTC)

Discussion regarding edit filter helper

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. ~ Rob13Talk 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). ~ Rob13Talk 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. CrowCaw 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)

Name

"Edit filter helper" isn't really accurate or descriptive. These people aren't really helping the edit filter managers create filters; if they were, we'd just give them edit filter manager. Can we call this "edit filter viewer" instead? this is far more descriptive and clearly accurate. ~ Rob13Talk 04:15, 5 September 2017 (UTC)

The name is a bit of a historical oddity. The global group was originally created specifically so people could help design filters globally, while being granted only view access so they had to work with the local admins and abusefilter managers. I have no objection to the local group being called viewers instead, and the global group should probably be changed at some point given its expanded scope now. -- Ajraddatz (talk) 05:20, 5 September 2017 (UTC)
And note, the proposed local, just like the global, includes spamblacklist viewing as well - I suppose that is still a form of a "filter" but its not from the abusefilter system. Let's make sure to not get hung up on this, we can always localize the name. — xaosflux Talk 12:00, 5 September 2017 (UTC)
I'm not bothered about the name - I came to this after someone else had originally proposed it and just ran with what they were calling it. If we can change the name locally after the right is created (I don't know) then that's probably the simplest way to go about it, but using the same name as the global group seems like it has less potential to cause confusion when the request is made to the devs on phabricator. Thryduulf (talk) 23:18, 8 September 2017 (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.

Publicity of filter 879, filter also affecting accounts

Two things I want to say about this filter:

  1. Should this filter be private? It seems like it's targeting possible broken proxies, and the "Possible open proxy" filter (464) is private.
  2. I feel like this filter, since it's titled "Possible broken proxy", shouldn't be affecting accounts. Should it be limited to just IPs (replacing !"confirmed" in user_groups with user_age == 0)?

—MRD2014 Talk • Edits • Help! 23:40, 12 September 2017 (UTC)

I think there's no reason for 879 to be private. Malforming edits with a broken proxy is fairly unavoidable - you are either using an IP which breaks articles, or one which doesn't. As far as I can tell there's no one deliberately making these edits, and if someone was trying to avoid the filter that would actually be a good thing. I've been thinking about 464, and am leaning towards thinking it should be also public for the same reasons, but I will add that it is slightly different in that it is more likely to be triggered by some long term abuse cases.[1] My preferred option is to eventually merge the filters and use a custom warning for both. As for edits made by accounts, they are affected exactly the same as the IP addresses they are using,[2][3] but there is some allowance made for the fact that established users are less likely to make these edits. -- zzuuzz (talk) 04:47, 13 September 2017 (UTC)
I see. The word "proxy" in the description confused me. —MRD2014 Talk • Edits • Help! 12:54, 13 September 2017 (UTC)

Move Special:AbuseFilter/879 to disallow, or tag?

No false positives since the filter was refined late on September 11. I don't actually understand why this is happening, but it looks like none are good edits. — MusikAnimal talk 17:34, 14 September 2017 (UTC)

@Zzuuzz: Just now noticing your comment above. What confuses me is the tripped edits don't seem to make any change beyond HTML-encoding those characters, and they're always from the mobile interface. I'll admit I am also confused as to what "proxy" means in this case. Also, I lied, there is a false positive here :( We might could use rcount to make sure the before/after are the same — MusikAnimal talk 18:01, 14 September 2017 (UTC)
I'll be honest I don't know exactly what's happening, but I do know we needed to be at least logging it. It did occur to me that it might be a Wikipedia bug, and nearly got around to asking you if CU could help fill in some of the details with the user agent. This doesn't look like deliberate changes - it could be that other changes are being discarded, but here's two interesting edits (possible vandalism or possible browser bug?). There are two distinct mobile networks which repeatedly appear and I don't think that is a coincidence: roughly 197.156/15 and 42.110/15 and I'm sure I've also seen non-mobile interface edits, but that one's probably still on a mobile, per whois. Mobile networks are far more likely to be doing caching or something, but it could be being broken even before that. It's the type of behaviour I expect from a bad PHP proxy. I'm not sure where to head next with the filter - it still looks a bit to liable for me, and I think we'll need in particular to figure out encoding in URLs. Maybe a warning? -- zzuuzz (talk) 18:47, 14 September 2017 (UTC)
There is a consistency with the UA come to find out... A browser bug sounds more likely, from what I can tell — MusikAnimal talk 19:44, 14 September 2017 (UTC)
Thanks, that sounds about right. Perhaps I should rename the filter. So I think tagging would be pointless, and disallowing would be a bit harsh at this stage, but that warning should be able to filter out any accidental edits and we'll see what happens? -- zzuuzz (talk) 20:11, 14 September 2017 (UTC)
I've renamed the filter and set it to warn for the time being, and we'll see what happens eh. -- zzuuzz (talk) 06:30, 16 September 2017 (UTC)

We built some graphs to monitor Edit filter performance

Hello everyone! As part of our research into improving Edit filter the WMF's Anti-Harassment Tools team has implemented performance tracking to monitor how fast (or slow) the feature is operating. The graphs can be found at https://grafana.wikimedia.org/dashboard/db/mediawiki-abusefilter-profiling. The graph on the left shows the 75th and 99th percentile of runtime, and the other shows the total filters and total conditions run.

Over the next week we'll be adding in some additional reporting for sub-optimal filters. This work can be tracked on Phabricator at T174205.

We're hoping to use this new measuring to make some decisions on how we can make AbuseFilter more performant or if we can raise the condition limit. — Trevor Bolliger, WMF Product Manager 🗨 23:46, 14 September 2017 (UTC)

Looks good, especially the conditions/limits one! — xaosflux Talk 12:03, 16 September 2017 (UTC)

Edit filter helper - implementation

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.

Tracked in Phabricator
Task T175684

Following the closure of the RfC above with consensus in favour of creating the right, I have:

  • Updated the header of WP:EFH from "proposed" to "pending" and added the {{procedural policy}} tag
    • Ideally it should have an "information page" tag at the top and "procedural policy" tag in the relevant section, but the information page tags explicitly say they are not policies or guidelines. If anyone knows how to represent this better, please change it.
  • Created a request on Phabricator for the group conferring the rights to be created - see Phab:T175684.

Things that should be considered while we are waiting:

If anyone has strong feelings about either of these (I don't) then I don't see a reason not to be bold. Thryduulf (talk) 13:19, 12 September 2017 (UTC)

I think the talk page should be directed to WT:EF. Instead of being a standalone page, the content could be added under the edit filter managers section of WP:EF. -- Ajraddatz (talk) 17:11, 12 September 2017 (UTC)
This has gone live, has been tested and is working, including the new non-admin SBL viewing. Localized labels / page directs can be updated as needed. — xaosflux Talk 21:53, 18 September 2017 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Filter 98 and ACTRIAL

The autoconfirmed article creation trial has begun. Filter 98 (Creating very short new article) only triggers when a non-autoconfirmed user creates an article less than 150 bytes in size. Now that ACTRIAL has begun, all articles will be created by autoconfirmed users and this filter will not trigger for the duration of the trial (trial ends March 2018). —MRD2014 Talk • Edits • Help! 01:34, 15 September 2017 (UTC)

There are a bunch of similar filters. Should we just disable them all, or maybe change them to target non-extended confirmed users? Or users with less than say, 50 edits? — MusikAnimal talk 04:03, 15 September 2017 (UTC)
See T175225 for a phabricator task about a related issue with the page curation filters. We're keeping the old AC filter for now and simply adding the "learner" filter additionally there. I think in this case it would make sense to simply up the definition of new user to be non-extended confirmed. TonyBallioni (talk) 05:52, 15 September 2017 (UTC)
I've updated 98 to target extended confirmed. The only other filter I could find directly affected by ACTRIAL was Page creation throttle for new users. This one actually disallows if they attempt to create more than 2 pages in a 90-second period. My guess is we don't want this for non-extended confirmed users, as there would seemingly be some legitimate use cases? Maybe target users with less than say, 20 edits? — MusikAnimal talk 03:35, 19 September 2017 (UTC)

Edit filter helper for DatBot

 Done — xaosflux Talk 17:59, 21 September 2017 (UTC)

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.

DatBot (t · th · c · del · cross-wiki · SUL · edit counter · pages created (xtools · sigma) · non-automated edits · BLP edits · undos · manual reverts · rollbacks · logs (blocks · rights · moves) · rfar · spi · cci) (assign permissions)(acc · ap · ev · fm · mms · npr · pm · pc · rb · te)
DatGuy (t · th · c · del · cross-wiki · SUL · edit counter · pages created (xtools · sigma) · non-automated edits · BLP edits · undos · manual reverts · rollbacks · logs (blocks · rights · moves) · rfar · spi · cci) (assign permissions)(acc · ap · ev · fm · mms · npr · pm · pc · rb · te)
Ends at: 14:25, 21 September 2017 (UTC)

(I believe this is how a request was meant to be. PS to do the 'ends at' thing use {{subst:#time: H:i, j F Y "(UTC)"|+7 days}}

I'd like to get this flag for my bot so it could use the API to report users. Currently, the bot has to use the database, which frequently lags, thus producing stale reports.

— Preceding unsigned comment added by DatGuy (talk • contribs)
@DatGuy: This access group doesn't give any access to "report users" - do you mean to "report on" users? Can you provide a link to your existing BRFA? — xaosflux Talk 21:55, 18 September 2017 (UTC)
@Xaosflux: Sure, here it is. This is the part of the code that isn't very effective: "SELECT SQL_NO_CACHE afl_id, afl_action, afl_namespace, afl_title, afl_user_text, afl_timestamp, afl_filter FROM abuse_filter_log". It basically tries to get into about the attempted edit. If the bot had access to the API, I wouldn't have to force it to use the SQL database, which has replication lag. Dat GuyTalkContribs 22:00, 18 September 2017 (UTC)
I'm fine with the bot access from a technical level. — xaosflux Talk 22:08, 18 September 2017 (UTC)
Note from a practical level, DatGuy does not have this access today so this request should focus on if he qualifies himself. — xaosflux Talk 22:08, 18 September 2017 (UTC)
I have zero problem with both DatGuy and DatBot getting EFH. Would actually help some aspects of the bot's performance significantly. Ks0stm (T•C•G•E) 22:11, 18 September 2017 (UTC)
  • That is completely up to you, my point is that as you have control of the bot credential you will effectively have the access anyway and as bots are extensions of their operators the general review of meeting criteria should be of the operator (for operators that don't already have access). — xaosflux Talk 11:28, 19 September 2017 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Filter 869 - "Users adding tabloid journalism to BLPs" - move from "log" to "disallow"

This filter traps web citations to The Sun, the Daily Mail and the Daily Star on any BLPs. It's been logging for the past couple of weeks, and I think it's time we turned it on to "disallow". There are a couple of diffs I want to query - for example, this diff by Midnightblueowl which is actually talking about the Daily Mail might be argued as a false positive, though I would say per WP:BLPSOURCES that if the information is that noteworthy, the broadsheets would have picked it up. (eg: See Enemies of the People which is entirely about a Daily Mail headline without containing a single source to it). As an alternative, we could set it to disallow on just the Sun and the Daily Star, which seem to be far less contentious than the Mail, which seems to trip up the lion's share of the filter logs. Your thoughts, please. Ritchie333 (talk) (cont) 15:55, 21 September 2017 (UTC)

I'd say disallow is far more problematic than warning, and it doesn't get my support. Plus, the RfC was very narrow and doesn't support a total ban on the other tabloids. -- zzuuzz (talk) 17:10, 21 September 2017 (UTC)
The RFC also noted that there were situations where the Mail could be cited (e.g. in articles where it is the subject, and in older stories from before it went downhill quality wise). I don't support disallow. Thryduulf (talk) 00:39, 22 September 2017 (UTC)
I think changing it to warn might be a better option than to disallow. —MRD2014 Talk • Edits • Help! 12:19, 22 September 2017 (UTC)
I'd prefer disallow, but I'd go with warn as well. At least any editor adding the material cannot then complain when it is reverted, as they've already been warned not to add it. Black Kite (talk) 12:31, 22 September 2017 (UTC)
Such links shouldn't be added in most circumstances, but there are exceptions so if it does go to warn (which I'm happy with) the wording should reflect that. Thryduulf (talk) 23:48, 22 September 2017 (UTC)

As Ritchie mentions, I added a citation from the Daily Mail in this instance as part of a sentence openly discussing that very Daily Mail article itself (which is discussed by other Reliable Sources). I'll bow to whatever the general consensus is on this one, but I personally don't think that there are any problems in having the citation in this particular instance. Midnightblueowl (talk) 19:27, 22 September 2017 (UTC)

A potential issue with any disallow on such things is a WP:ABOUTSELF and WP:PRIMARY conflict, especially when the site is a news source (even if a low-quality one). They remain legit sources for direct quotations, even if they're worthless as secondary sources for WP:AEIS material.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  17:57, 23 September 2017 (UTC)

Special:AbuseFilter/261 and WP:ACTRIAL

I asked about this above and got no reply. Since this filter currently doesn't do anything, I've disabled it. I think it might be useful to have it check for an edit count less than say, 50, but I'm not sure about the disallow action — MusikAnimal talk 20:03, 27 September 2017 (UTC)

an invitation to Edit filter managers

Hi,

This is an invitation to Edit filter managers and patrollers who refer to edit filters from your wiki project to share and know about effective public filters from various wikimedia wiki projects.

It is almost eight years since March 2009, that Edit filters are in use on various Wikimedia wiki projects. At meta we have started a platform page m:Edit filters benefiting to various local Wikiprojects to know good and effective (public) edit filters by sharing of relevant information with rest of wikimedia community. This will help editfilter managers, and there by concerned projects, to benefit from maximising potential of best possible (public) edit filters.

We are keen to have your participation in this collaborative and constructive endeavour and the discussions.

Mahitgar (talk) 11:09, 30 September 2017 (UTC)

EFH bit request

Having gained endorsement, and no objections this has been granted. — xaosflux Talk 01:51, 1 October 2017 (UTC)

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.

Requesting EFH bit to view hidden logs. I do a lot of work at COIN leading discussions about conflicts of interest. I expect this right would help me discover relevant COI/UPE cases as well as general vandalism etc. I understand the BEANS need for discretion. If it matters I have academic training in regexp and have demonstrated their use here. ☆ Bri (talk) 16:03, 27 September 2017 (UTC)

 Done — xaosflux Talk 01:51, 1 October 2017 (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.

EFH bit request for Mahitgar

☒NWithdrawn.EFH is not granted.Winged Blades of GodricOn leave 05:33, 3 October 2017 (UTC)

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.

Requesting EFH bit to view hidden logs. My interest is more of academic nature to study and help improve m:Edit filters benefiting to various local Wikiprojects this meta page started by me. It will also help in giving references to my bugs filed at phab.

I am not technical expert on regex but have learned, compared and implemented techniques from en:wp and other lang wps past four-five years public filters here. While I have tried inter acting on en wp ef forums, frankly many times may be due to lack of man power, its slow in responding. Over the years I have been supporting mainly help pages on my local lang wiki. I suppose my participation may help, help pages and and once in a while in en wp ef related support/ help activities.

Whatever you decide but please keep supporting. m:Edit filters benefiting to various local Wikiprojects

Thanks and regards

Mahitgar (talk) 08:19, 1 October 2017 (UTC)

  • Oppose I'm not sure how viewing the hidden logs will help with the page you've set up. Almost all private filters pertain to specific vandals here on English Wikipedia. They likely will not be of as much use elsewhere, and moreover they should not be published on any public page like the one you speak of.
    I would also recommend renaming your page to something like "Edit filters of cross-wiki interest". The term "Wikiproject" can be confused with Wikipedia:WikiProject, which is different than a project like enwiki, frwiki, etc., also known simply as a wiki. Other wikis also use the term "WikiProject" to refer to their own internal, specialized collaboration groups. — MusikAnimal talk 14:32, 2 October 2017 (UTC)
  • Oppose per MA. ~ Rob13Talk 15:23, 2 October 2017 (UTC)
  • Oppose per above concerns. I'd like to see a bit more local activity before this was handed out, as was decided in the perm's RfC -- There'sNoTime (to explain) 15:37, 2 October 2017 (UTC)
  • Strong Oppose--I want to see much more local activities related to specific usage of EFs before granting the right.Winged Blades of GodricOn leave 16:18, 2 October 2017 (UTC)
Comment: Thanks, As per MA's good suggession I will go for change of page name. In most cases specific words which want to get filtered are confidential and not all technical configurations. If not all atleast few stable configurations are shared (sans confidential part/wors) on common meta page all wikis will benefit from experience and help improve efficiancy to all of us.
As I said my interest in EFH bit is limited only and not granting as of now is not an issue to me. Just I wanted to bring a common page into focus, and that has been achieved by this discussion. Thanks for considerations. It is ok to close the discussion as EFH bit not accepted.
Mahitgar (talk) 05:00, 3 October 2017 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Request for edit filter manager bit

 Not done for now. A request for edit filter helper (not manager) should be made separately — MusikAnimal talk 17:15, 3 October 2017 (UTC)

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.

SMcCandlish (t · th · c · del · cross-wiki · SUL · edit counter · pages created (xtools · sigma) · non-automated edits · BLP edits · undos · manual reverts · rollbacks · logs (blocks · rights · moves) · rfar · spi · cci) (assign permissions)(acc · ap · ev · fm · mms · npr · pm · pc · rb · te)
Ends at: 17:41, 30 September 2017 (UTC)

Professional coder and sysadmin, been here 10 years, 100K+ edits. TemplateEditor (I'm one of the more active non-admins who answers {{edit template-protected}} requests, and often go out of my way to implement and sandbox what's requested if the requester doesn't have the skills to do the testing personally). I do not presently run any bots.

Would like to create some informational/tracking edit filters (frequently misused templates, Web sources that are questionably reliable, and a few other cases), for editors to use as cleanup/verification tools. I have no interest in making filters that trigger actions like preventing the edit or delivering a warning (that seems more like an admin-level role to me).
 — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  17:22, 23 September 2017 (UTC)

It sounds like you'll want to be asking for the edit filter manager bit instead. If that's the case could you first of all mention any experience with edit filters and perhaps regex. I've got to also say one thing we're constantly battling against is an explosion in the number of filters and associated runtime, so an application expressing an interest in creating lots of tracking filters, which in my experience not many people consistently look at, may not seem an obvious way to go. But could you give an example of such a filter, including perhaps its expression? -- zzuuzz (talk) 17:35, 23 September 2017 (UTC)
Ah, I see, yes I mean the bit for editing them, then (I don't actually care about hidden ones. :-). Changed the heading. Don't want to create lots, and I'd be perfectly happy adding to some rather than adding new ones. As a sysadmin, I work with regex in multiple flavors all the time. Am versed in sandboxing, and of course read WP:Edit filter#Recommended uses and its material on not implementing a filter that actually does anything without first observing that it triggers exactly as expected. I've not directly worked on the edit filters here, lacking the bit to do so. Just think I can be of use; I'm one of the more tech-oriented sorts who's active most of the time. PS: I have a long reputation as an outright nay-sayer when it comes to poorly-thought-out changes to important templates, WP:P&G material, interface pages, processes, and other things that could have wide-ranging side effects; I think that's a plus in this context.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  17:41, 23 September 2017 (UTC)
Thank you for answering most of the question. You know people here can be quite fussy so I'm just trying to elicit the relevant things. We can't expect anyone to know everything, but I'm sensing an element of unfamiliarity with the topic. You're welcome to persuade me otherwise. Personally I don't particularly doubt your technical abilities - what you consider a plus I consider a lack of negatives - but what I'd really like to hear about is what you intend to do. Have you considered having a go at WP:EFR or EFFP? -- zzuuzz (talk) 18:05, 23 September 2017 (UTC)
I had not looked into EFR or EFFP; can do so. I'm more volunteering to assist than coming in with an agenda.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  12:45, 24 September 2017 (UTC)
What I intend to do is draft and test some low-key edit filters mostly related to questionable sourcing, and to help fulfill requests for new EFs that are requested and not rejected (i.e. perform TemplateEditor-like work, just also with regard to EFs).  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  14:30, 24 September 2017 (UTC)
  • Q: Can you give an example of a filter you might create and how you would code it? CrowCaw 18:03, 23 September 2017 (UTC)
    Two examples that come to mind are citations to QuickAndDirtyTips.com/grammar-girl and MessyBeast.com. Both of these are personal blogs by people with some credentials in a tangentially related field, but not expertise in the one central to what they're writing about (the author of the "Grammar Girl" material at the first is not a linguist but a journalism professor (i.e., steeped in one very particular form of writing, which has numerous norms that conflict sharply with other writing styles and registers of English), and the author of the latter is not a zoologist (or veterinarian, ethologist, etc., much less a felinologist). The sites have huge followings, and are frequently cited on the web as "authorities", but do not make their own sourcing clear, and are mostly advice columns (primary source material) and collections of factoids from other places (tertiary material). They can be legitimately cited here as primary sources for certain things when this is done properly, but more often people try to cite them as secondary. We have very few watchers on the sorts of pages where citations to these websites are most likely to appear. Haven't had coffee yet (it's 5:40-something a.m. where I am), but I can produce a sample filter later. I'll look first into the EFR and EFFP recommendation above. I'm not here to collect some headwear but to be of use.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  12:45, 24 September 2017 (UTC) PS: Looking at the QuickAndDirtyTips.com site again for the first time in ages, I note that it's ballooned to way more than the Grammar Girl material and how has multiple columnists writing on fitness, business, psychology, etc., making it more likely to be used as an probably-bad source on more pages, like the old About.com.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  14:30, 24 September 2017 (UTC)
  • Looks good for a tag-only, though as you implied there's some tuning to streamline it (such as one keyword that will catch all case variations). You may want to read [4], there's some serious power in this tool. :-) CrowCaw 17:12, 24 September 2017 (UTC)
  • Just on the technicalities of the filter - and I won't particularly hold this against SMcCandlish as he doesn't have proper access to the filter testing tools - it seems to be confusing plain text searches (contains | contains_any), with regex (which uses the pipe (|) character). Compare the use of irlike in 657 which is referenced with perhaps 31. It also seems to be lacking enough parentheses, and is testing for (Namespace == 0 AND link1 OR link2). Compare 869 and see the archive. -- zzuuzz (talk) 18:35, 24 September 2017 (UTC)
  • Additionally you didn't escape the . in the URL, which is needed since it is a valid regex character. I'll note this involves an understanding of regex in general, not a familiarity of the extension, though you might have discovered your mistake using the debugging tools — MusikAnimal talk 14:50, 27 September 2017 (UTC)
  • Lack of testing tools (and more detailed documentation – though I'll go check out that mediawiki.org page) is a bit of a hamper. Deets:
    I was avoiding irlike on purpose, because the docs say regexes are expensive for edit filters; the implication appeared to be that contains will match literal strings not regexes. That keyword is essentially undocumented, but the contains_any says it works with strings. I noted that filter 126 didn't escape the . in youtube.com. It wasn't clear that the pipe wouldn't work without irlike or rlike. The pipe is used as an OR more generally in the syntax in other ways, so it didn't seem confined to regex parsing. I had my doubts about "foo|bar", and suspected "foo"|"bar" might be required.
    Anyway, I'm not sure if it's better to just use irlike, or try to catch case variations another way. That's a "what we've learned about filter efficiency" question for you all. :-)
    On parens, yes, the intent was (Namespace == 0 AND (link1 OR link2)); methinks this is the fix.
     — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  21:18, 29 September 2017 (UTC)
  • Q: I know it's been a while (7 years), but your last RfA had a lot of opposition. Do you think you have overcome the issues that led to that opposition, if so how? — xaosflux Talk 23:12, 23 September 2017 (UTC)
    Oh, geeze that's from an embarrassing time. At my first RFA I was an enthusiastic noob, and at the second I'd been taking excessively bureaucratic and argumentative stances that were more about trying to make WP operate the way I thought it should rather than vice versa. I've done a 180 on that stuff. These days I'm a huge fan of the WP:POLICY / WP:LAWYER principle that WP's rules and processes are to be interpreted in the spirit in which they're intended not their exact letter, and that they're here to serve our needs and to codify our best practices, not change them. At any rate, I have no interest in an RfA no. 3; the "enforcement" aspects of adminship are of zero interest to me; instead, I've been highly supportive of tech-work unbundlings like template editor and page mover (and would have commented favorably in the unbundling RfC atop this page if I'd not been busy off-site at the time). Happy to address any more specific concerns, but this may all be moot if I need to be shunted into EFR and EFFP for a long while before being considered for EFM.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  12:45, 24 September 2017 (UTC)
    Thank you for the reply, like I led with it has been a long time. I don't know about "a long while" but I would like to see activity at EFR/EFFP for this access. Creating any deny filter is in effect "enforcement" of something as well. — xaosflux Talk 17:23, 24 September 2017 (UTC)
    Sure. I didn't have any interest in deny filters, just logging ones.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  21:18, 29 September 2017 (UTC)

Endorsements / Comments

  • Oppose at this time, however I encourage EFR/EFFP engagement as a way to enter this arena. — xaosflux Talk 15:38, 27 September 2017 (UTC)
  • Oppose also at this time. I'd like to see more familiarity with the edit filter before granting the bit. I'd encourage more reading of the existing filters, the documentation, and have some input to practise (and demonstrate) putting it all together. -- zzuuzz (talk) 18:21, 27 September 2017 (UTC)
  • Request change: EFH rather than EFM might be helpful; it provides a lot more access to pre-existing filter code, which honestly seems like better documentation. :-) A large number of the filters I attempted to examine were not available to me. E.g., I can't look at 31, which zzuuzz suggested looking at.  — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼  21:18, 29 September 2017 (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.

Suggested filter

Just a heads up, but I sent an email to the editfilter list email with a suggestion to expand the filters to stop a recent type of spam. I emailed it in order to not give any ideas to possible vandals. Thank you. Nihlus 01:52, 3 October 2017 (UTC)

checkY Responded to by MA -- There'sNoTime (to explain) 20:52, 4 October 2017 (UTC)

Filter 148

Is filter 148 functioning correctly? Activity on it has diminished drastically since mid-September. --Drm310 🍁 (talk) 16:38, 6 October 2017 (UTC)

This is most likely because of WP:ACTRIAL — MusikAnimal talk 17:25, 6 October 2017 (UTC)
Ah, OK. That makes sense. That's actually very positive outcome, IMHO. --Drm310 🍁 (talk) 17:52, 6 October 2017 (UTC)

Request for EFH bit for QEDK

EFH GRANTED
Primarily granted per the provision at WP:EFH which allows SPI clerks to be granted the right, but with due note to the consensus formed here. I take BU Rob13's comment on its support merit -- There'sNoTime (to explain) 20:07, 8 October 2017 (UTC)

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, I'm QEDK, a non-admin trainee clerk at WP:SPI. I think EFH might help me with certain cases where I can view the private logs (just citing the Europefan one for now, and more, probably). I hope this right will help in discovering prolific socks which trip private filters, some of which land up at SPI. I understand that this is a need-only basis right and the BEANS requirement for granting this right. With thanks. --QEDK (愛 • 海) 18:54, 5 October 2017 (UTC)

  • Support at least once you're out of training. In my opinion EFH makes sense for any SPI clerk — MusikAnimal talk 01:24, 6 October 2017 (UTC)
    In interest of full disclosure, I was in the December 2015 batch which started off but ended before the training was deemed complete. Either way, in the May period next year, which is when the promotion to full clerk was considered, I was inactive then and did not get promoted to full clerk on that basis. I have been working actively as a trainee since but not asked about the promotion to full clerk, just a wandering soul until some CU decides. :) --QEDK (愛 • 海) 04:17, 6 October 2017 (UTC)
  • Support - sure. Trusted user with some use for the bit. -- Ajraddatz (talk) 02:00, 6 October 2017 (UTC)
  • Oppose until out of training. As soon as you're out of training, support. I note that you've been in training since December 2015, and if I recall correctly, you weren't promoted initially due to inactivity (correct me if I'm wrong). Either way, I'd want to see you in the role indefinitely before granting this right. ~ Rob13Talk 10:31, 6 October 2017 (UTC)
    • @KrakotoaKatie: QEDK has been working entirely independently at SPI as a clerk for a while. Could you start a formal discussion to promote them to a full clerk if you find their work satisfactory? Any CU can do so. I'd recommend placing this on hold until such a discussion concludes. ~ Rob13Talk 01:32, 7 October 2017 (UTC)
      • @KrakatoaKatie: Stupid typo - see above. ~ Rob13Talk 01:33, 7 October 2017 (UTC)
        • Yeah, you are certainly correct but there was no formal training thereafter and since the trainee clerk status wasn't exactly an impediment to any SPI work, I didn't ask for a promotion, but thanks for taking it up with Katie, Rob, I've been promoted to full clerk now. While the requirements do say that trainee clerks can be granted the right too, I'm guessing you have your own thoughts on this, which is absolutely fine. --QEDK (愛 • 海) 17:41, 8 October 2017 (UTC)
  • Support I don't see the harm in viewing hidden filters. The user has enough experience at SPI to be trusted, and if this helps at SPI, even better. As a trainee, QEDK can still acquire EFH permission per Wikipedia:Edit_filter_helper#Granting_the_right. — JudeccaXIII (talk) 20:42, 6 October 2017 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Request for EFH bit for GermanJoe

 Not done as general support was not achieved. On a related note, Filter 711 has been un-hidden. — xaosflux Talk 01:09, 9 October 2017 (UTC)

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, I am a Wikipedian since 2010 and often involved in handling spam and other forms of promotional editing (link cleanup, blacklist reporting, COI-related content cleanup). Access to some spam- and promotion-related logs (for example filter 711 for dead links) would be useful to look for possible spam domains and patterns. As a software project manager I am not a professional full-time developer, but have basic knowledge in regex (and a few structured languages). I also have a strong password as required and know how to handle non-public information. GermanJoe (talk) 23:06, 5 October 2017 (UTC)

  • Support - trusted user with a use for the bit. It seems to me that someone involved in COI-related cleanup would benefit from seeing if an account had triggered the SBL or certain private filters. -- Ajraddatz (talk) 02:06, 6 October 2017 (UTC)
  • @GermanJoe: Could you explain your use case more? I'm not particularly convinced by the filter 711 reference. I need to see something that puts your "need" above that of a typical vandal fighter. ~ Rob13Talk 10:37, 6 October 2017 (UTC)
    • @BU Rob13: - initially the filter was public, so I'll try to offer a few more details from the past usage. I (and a few other non-admin regulars) could find new dead link spammmers quite easily while looking through these logs. I know, I have cleaned up atleast 5-6 new cases that way. Granted, such cases would have been found out eventually with regular editing, but sometimes such spamming goes undetected for years - especially in low-traffic articles. Access to the SBL would be another obvious benefit to keep an eye on additional spamming attempts. I am not sure, how you define "need" in that context, but the availability of such data can help to detect problems in this area a lot easier and more efficient (compared to a luck-based random approach). Several other spam-related filters (i.e. 752, 762, 793 etc.) would possibly also contain useful data in occasional related situations, although with hidden filters it's hard to tell for me of course. GermanJoe (talk) 12:35, 6 October 2017 (UTC)
      • @GermanJoe: Could you explain this "dead link spam" issue? Perhaps I'm just not understanding. Are you saying there are editors spamming already dead links onto pages? How is that a problem? ~ Rob13Talk 12:37, 6 October 2017 (UTC)
        • @BU Rob13: Oops, I am sorry for the misunderstanding. I wasn't aware this jargon-y term was unclear. "Dead link spamming" (professional spammers probably have a more technical term) searches for dead external links, that are usually tagged with Wikipedia's "dead link" maintenance tag. Such tagged links are then systematically replaced with spam links (usually for products or other commercial sites). This type of spam is one of the more "popular" tactics, and also a good example for how logs and semi-automated measures can help to limit such problems. GermanJoe (talk) 12:52, 6 October 2017 (UTC)
          • Alright. I think in this case, I oppose granting the right but support making that filter public. I don't think the need here rises to the level it should for edit filter helper, which is really not intended for log patrolling/counter-vandalism. This is a point I was assured on by many people championing the proposal when I had reservations. On the other hand, looking at this filter, there's really no way to get around it, so I don't see an issue in making it public. ~ Rob13Talk 13:17, 6 October 2017 (UTC)
  • Oppose I tend to agree with BU Rob13, and I was already thinking that filter 711 should be public and possibly even tag. Samwalton9 any opinion on that?
    762 tags as "possible link spam", so you already can track those hits. Meanwhile 793 disallows. 752 should probably be public too, and seems to be very much prone to false positives, so frankly I question its usefulness to begin with. Overall I think EFH is chiefly about tracking sockpuppetry and long-term abuse, not spam detection and counter-vandalism. In most cases any filter that isn't targeted at specific user(s) should be public, and you should feel free to question the visibility of any filter you think might qualify as general-use — MusikAnimal talk 15:47, 6 October 2017 (UTC)
Straying a bit off-topic and probably better discussed in a separate thread: if WP:EH ("There are three groups of editors for whom this is is useful:") is meant to exclusively limit this access to the listed three use cases (and not as an incomplete list of common examples), the phrasing should be clarified. However, the RfC closure to establish EFH doesn't mention such a strict limitation. Atleast for me it wasn't clear that these changes aren't meant to help anti-spam contributors or other editors with potentially beneficial but unlisted usages. Regarding public 711 filter: the filter is mostly targetted against repeated and/or organized spammers. Some of these spammers may have the motivation to research the filter to improve their methods. Admittedly a very small risk, but a risk nonetheless. GermanJoe (talk) 21:03, 6 October 2017 (UTC)
@MusikAnimal: re: 711, I think I made it private because it seemed like some users had figured out how to avoid the filter, but I forget the details, so it can probably go public. Sam Walton (talk) 10:51, 7 October 2017 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Filter 881

I tried making an edit filter – would someone like to sanity check Special:AbuseFilter/881? It should perhaps be set to deny, if there's no risk of collateral. Κσυπ Cyp   14:13, 8 October 2017 (UTC)

I've trimmed it down to be a little less complicated. That IP range has a lot of good edits but is not super busy. I suspect false positives will be slim to none. I'll monitor and if all goes well we'll put it in disallow — MusikAnimal talk 01:22, 9 October 2017 (UTC)
Thanks – I tweaked it a bit more, and removed rmwhitespace, since it doesn't seem to be compatible with \s and \b. Κσυπ Cyp   12:48, 9 October 2017 (UTC)
Looks good, I think we're ok to disallow — MusikAnimal talk 15:10, 9 October 2017 (UTC)

Filter 384

Possibly make the regex for "fag" less inclusive to prevent these kind of false positives. --QEDK (愛 • 海) 17:44, 8 October 2017 (UTC)

Should be fixed! — MusikAnimal talk 00:33, 9 October 2017 (UTC)
@MusikAnimal: Change fag(g[ao]t) to fag(g[aio]t) to prevent faggit from not tripping the filter? --QEDK (愛 • 海) 08:30, 9 October 2017 (UTC)
Sure — MusikAnimal talk 15:12, 9 October 2017 (UTC)

Filter 680

A false positive came through on 680 when someone was trying to add ♩ to Romanian Folk Dances. I believe the may be a tad strict since the musical notes (♩♪♫♬) do have some encyclopedic value like the pitch symbols ♭♮♯ (U+266D/E/F) that were removed recently. Can we change the range ♃-♬ (U+2643-U+266C) to ♃-♨ (U+2643-U+2668)? Thanks. (I also looked through the last couple hundred of hits and found nothing nefarious with these symbols.) Nihlus 14:09, 6 October 2017 (UTC)

Can we also take out ☉ (U+2609), as it is now used in the name of an instrument on the Parker Solar Probe. See this false positive. Thanks. Nihlus 19:09, 9 October 2017 (UTC)
@Nihlus: Not sure if this is such an edge case it can be left, but I did add the content to the page. — xaosflux Talk 19:40, 9 October 2017 (UTC)

Request for Edit Filter Helper - Dane

 Done General support has been gathered below and checkuser There'sNoTime has offered to provide mentorship and guidance. A more general discussion of expanding the selection criteria can be held here at WP:EFN. — xaosflux Talk 15:51, 10 October 2017 (UTC)

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.

Closure available for this EFH nomination. (refresh)

Hello,

I am requesting the Edit Filter Helper right so I can view hidden logs. I am a Tool Administrator at the ACC tool and run across tripped filters occasionally that I am unable to view/evaluate in the course of my work there currently and this would help me in processing those requests. Thank you! -- Dane talk 03:50, 4 October 2017 (UTC)

A: Yesterday, I worked a request for example that showed an Edit Filter was tripped but only had a number specified. When we defer requests for CheckUser, we've been asked by CU to supply as much information as possible to assist in their processing of the requests. Because I did not have that information available I wasn't able to properly defer even as a tool administrator and I had to find an on-wiki administrator to research the specific request and write up the summary for CU which can add a delay in processing. In some cases, having the EFH right may even allow a bypass for CU if it's clear that it's the target for a filter created for specific LTAs. -- Dane talk 19:43, 4 October 2017 (UTC)
Expanding on the above, I don't believe being an ACC tool administrator is a sufficient reason to grant, and given the fact you were able to find an administrator to assist there's no real issue.. However, do you posses sufficient understanding of regex/AbuseFilter syntax to be able to reliably make the call on if a specific LTA filter was indeed targetting the request IP you're looking at? -- There'sNoTime (to explain) 19:47, 4 October 2017 (UTC)
It is true that I was in one instance able to find an administrator who holds sysop on en-wiki as well to evaluate it, however there have been times where there is a delay in that. In asking for the right i'm looking to be able to avoid this delay to resolve the issue myself. I do have a basic understanding of regex and I would defer any case that was in question or unclear to me per the existing operating guidelines. I do not have intent on authoring any filters now or in the future. -- Dane talk 20:20, 4 October 2017 (UTC)
  • Oppose No real on-wiki need for the tool if other, more trusted editors administrators and EFMs are easily available via the mailing list or on IRC. There's a reason we have private filters and granting access solely for off-wiki tools is not a good precedent to set, given there is a real risk of sharing details of private filters with unauthorised parties on mailing lists we would not have access to. EFH was not created for this purpose -- There'sNoTime (to explain) 20:59, 4 October 2017 (UTC)
This was the wrong place to bring up my concerns about criteria #1 -- There'sNoTime (to explain) 08:47, 5 October 2017 (UTC)
    • Commenting in my capacity as one of the ACC project leads, this seems like an odd objection to make against a group of users who are specifically vetted for their ability to comply with privacy restrictions and are indeed required to sign the Access to nonpublic information policy. --FastLizard4 (talk•contribs) 22:08, 4 October 2017 (UTC)
      • The signing of that document doesn't come into it - I've signed multiple NDAs for WMF, but they don't make me more or less suitable for access. The reason for my objection is as I detailed above - there's no need for this right to be granted -- There'sNoTime (to explain) 07:05, 5 October 2017 (UTC)
        • Your own argument is "No real on-wiki need if other, more trusted editors are easily available". With all due respect, if your argument for suitability for access doesn't involve user trust, then why did you literally put those words in your argument? --FastLizard4 (talk•contribs) 07:33, 5 October 2017 (UTC)
        ...Expanding on my above comment, @There'sNoTime:, your argument can be easily rephrased from "No real on-wiki need for the tool if other, more trusted editors are easily available" to "No real on-wiki need for the tool since Dane is not as trusted as other editors." I believe that it is fair to ask you to expand on the reasons for this distrust in response to my original comment that it seems odd to object on a trust basis to one of the more vetted and trusted groups on Wikipedia, or that you use another basis for your argument that there is no demonstrated need here. --FastLizard4 (talk•contribs) 07:43, 5 October 2017 (UTC)
        Rephrased perhaps, but that was not the intended meaning - it's clear Dane is a trusted individual as he's been accepted to the lofty position of a tool administrator, but he's not a "trusted editor" in way of advanced permission. I use the phrase "trusted editors are easily available" to refer to the enwp admins who are active at ACC (not counting the many many active admins on IRC). As Crow rightly points out below it seems like an email with the regex would cover 99% of the issues and I'll add a !admin can you help me with filter X in #wikipedia-en connect would solve the rest. You explain below you have an outsider perspective with respect to edit filters, so perhaps you're not familiar with the days people have sunk into creating and maintaining our LTA filters? -- There'sNoTime (to explain) 08:06, 5 October 2017 (UTC)
Rephrased the above for clarity, additions in green -- There'sNoTime (to explain) 08:19, 5 October 2017 (UTC)
@There'sNoTime: Again though, I don't feel like you're addressing my argument - my argument is that you have no reason to consider Dane untrusted, yet you continue to make your case as if that's a given (you state "he's not a 'trusted editor' in way of advanced permission"). I would like you to expand on the specifics for why you are arguing this or abandon the premise. Also, though I appreciate the labor that goes into writing effective filters, I don't see how stating that fact has any bearing on Dane's request - unless of course we take as a given that Dane is untrusted and is thus a risk for undoing all that work, which is the point I am contesting here. --FastLizard4 (talk•contribs) 08:17, 5 October 2017 (UTC)
Outsider perspective here too. I don't have a strong opinion on this, but I was wondering, this is a new user group, I am getting an impression that this is being vetted as if it were a WP:EFM request rather than EFH? Just a thought. Alex ShihTalk 08:24, 5 October 2017 (UTC)
This isn't a hill I want to die on, but my point is being misunderstood. Dane is perfectly trusted, I think he should have passed RfA and that isn't the issue I have. Granting criteria #1 highlights a requirement for "need". I don't see a need here when other trusted editors (read "Administrators, EFMs" as I clarified above - that was my poor wording) are available on IRC and through a mailing list. Perhaps I am using this as a point to highlight the inadequate definition of "need" (the major concerns from the RfC were creep), and that's not fair on Dane, so I apologise there. Consider my oppose struck, but a discussion needs to happen over things like this. This was the wrong place to have that discussion -- There'sNoTime (to explain) 08:41, 5 October 2017 (UTC)
@There'sNoTime: Okay, I see the point you're making now. After our discussion on IRC, I can see the question of need itself being valid even when trust is disregarded, but that's an area where I'm thoroughly unqualified to comment, so I'll leave it to others to decide. --FastLizard4 (talk•contribs) 08:54, 5 October 2017 (UTC)
  • I'm still not sure that ACC yields enough of an ongoing need for the access. The logs won't tell you why a filter was tripped, just that it was... you'd need to dig into the regex to determine why. And since the number of EFs dealing with ACC is small compared to the total (Meta prefers to handle name blocks now), it seems like an email with the regex would cover 99% of the issues, with that 1% being new additions to the filter. CrowCaw 22:33, 4 October 2017 (UTC)
  • @Crow: I think this argument can be reversed and be equally as valid - even if there isn't a hard ongoing need, if there aren't any specific issues that lead to the candidate user to be considered untrusted despite their long-time status on Wikipedia, as long as they are competent in regular expressions and know not to break things, and as long as there are even potential gains to be had, is there harm in granting the user group? To me, the potential usefulness of this access is at least some kind of positive factor, and there don't seem to be any negative factors beyond lack of precedent which seems like should it should be a relatively minor factor - though this is admittedly very much an outsider perspective (with respect to edit filters). --FastLizard4 (talk•contribs) 07:51, 5 October 2017 (UTC)
  • Support - this is a perfectly reasonable request IMO. This is such an inconsequential right that I can't imagine why we would turn away anyone with a potential use for it. -- Ajraddatz (talk) 00:19, 5 October 2017 (UTC)
    • As for this being an inconsequential right, I draw your attention to the closing caveats, namely community and/or the granting administrator are adviced to carefully evaluate the candidates before granting the flag due to the huge fallouts of any misuse. -- There'sNoTime (to explain) 07:23, 5 October 2017 (UTC)
      • There is almost no fallout for misuse. The absolute worst-case scenario is that an LTA is able to figure out what the filter conditions are, so they can bypass it a few minutes earlier than they could by trial and error. And when any sort of trusted editor is the one requesting the right, we can be pretty sure that the worst-case scenario won't happen. -- Ajraddatz (talk) 08:31, 5 October 2017 (UTC)
Pinging BU Rob13.Any comments?I am sure he could address your point lot better than me!Winged Blades of GodricOn leave 17:34, 5 October 2017 (UTC)
  • Support - Per Ajraddatz. Perhaps the demonstrated need (#1) is not strong enough, but I would be satisfied if there are potential uses (indicated in the response above) by a trusted editor. Alex ShihTalk 06:44, 5 October 2017 (UTC)
  • @Dane: Can you comment on how your use case exceeds that of a typical vandal fighter who could perhaps be benefited by viewing private logs? We decided rather resoundingly that such editors should not receive access to this right, and I am very worried about precedents being set with this user right. ~ Rob13Talk 10:19, 6 October 2017 (UTC)
    • I hope to hear from Dane before committing one way or another, but put me down as oppose until I'm convinced further. I'm not sold on this use case, mostly because there are many admin ACC volunteers and this isn't frequent in the ACC workflow. (I hope no admin will close this until I get a response.) ~ Rob13Talk 19:32, 6 October 2017 (UTC)
@BU Rob13: Sorry for the delay, i've been mobile most of the day. In regards to my usage vs. a typical vandal fighter, my usage of EFH will allow me to identify potential issues prior to giving someone a way to access en-wiki via an ACC request. On requests that do get deferred, our CU's have requested as much information as possible when we defer to them (they typically have a large backlog at ACC and a very detailed comment is helpful to their research) and this will allow me to present more robust comments to them regarding tripped filters. In my most recent example, I would have deferred a request without any idea why I was deferring and thus unable to give additional information to the CU - whereas with this right I could've supplied an explanation that would be helpful. -- Dane talk 20:22, 6 October 2017 (UTC)
@Dane: At the risk of sounding like a judge: Is it your contention that all ACC volunteers automatically qualify for this right? If not, how are you distinct from the general group? If so, I have other questions. PLEASE DON'T CLOSE THIS FOR ANOTHER 24 HOURS. I think it's important to get the ACC precedent right. ~ Rob13Talk 01:37, 7 October 2017 (UTC)
@BU Rob13: I am not attempting to set any sort of "precedent" here and think that the discussion regarding whether ACC volunteers do or do not automatically qualify for the right is best fit for an RfC and not my individual request for the permission. Until that RfC, I think it should be evaluated based on individual need as demonstrated until any such RfC happens, and I believe i've covered my individual need above a few times. -- Dane talk 02:37, 7 October 2017 (UTC)
@Dane: Well, at least in my opinion, your need does not exceed that of a typical ACC volunteer. It's hard to separate your case from a potential precedent, as if we say yes to you, I see us saying yes to all ACC volunteers. That's a somewhat large group – certainly larger than who I anticipated getting this right. While I may not be opposed to expanding the use cases to include ACC, I think we need a larger discussion surrounding that with more time to ask questions and probe your recruiting process to determine if we can justify giving this highly-sensitive right to a potentially large group of people. Until such a discussion is held, and without seeing how your need exceeds that of a typical ACC volunteer, I must oppose. (I would support an RfA, as a side note. You are clearly qualified.) ~ Rob13Talk 03:20, 7 October 2017 (UTC)
  • Unsure Crow thoughts and seeking more discussion. On the positive side, I see zero issues with trust, and the Nonpublic data agreement is a huge plus. On the flip side, I'm still having trouble with the ongoing need for the right. This may very well be due to my not understanding the ACC workflow, which is (to me): a user sends a request in to ACC because they were blocked from creating an account. They likely will state the name they tried to submit. ACC volunteer looks at the EF log for their IP (is it always going to be the same?) and sees that an EF blocked it. Without EFH that's as far as you can go. With EFH, you check the specific filter, pour through a huge ugly regex, see the match and say "Yep, you were blocked alright." There's not going to be much more context than that to tell you what to say to a CU other than "This guy tripped a filter and might be a sock of any of a hundred different people or could just be a troll, or might just be an innocent user." (Please elaborate or correct me on any of this).
So even with that degree of utility, the ongoing need still eludes me. Those few EFs don't change often, and (again from my own POV), it would seem easier to copy the huge ugly regex to a text document and sort/alpha/annotate/de-regex/etc to make it an easier lookup than opening the huge ugly regex every time. (I keep saying that, you'll see what I mean!). In fact that's what I do to a couple of the larger aggregated ones... I often get lost parsing the H.U.R. so keep offline copies sorted into a much easier format. Thus my point above about a periodic dump of the handful of filters that would be of any use in ACC would be just as meaningful.
I did support the EFH permission creation, (and may have had some part in kickstarting the RFC) but I respect and concur with the concerns expressed during it. As Rob alluded to, "ease of access" was a huge concern, as was "real ongoing need", which is where I'm stuck at the moment. I don't think access to the data itself is problematic, but that data being fairly static, the ongoing need for tool is the hangup. Free discussion welcome! CrowCaw 15:33, 6 October 2017 (UTC)
  • @Crow: Just a comment regarding "a user sends a request in to ACC because they were blocked from creating an account. They likely will state the name they tried to submit. ACC volunteer looks at the EF log for their IP (is it always going to be the same?) and sees that an EF blocked it": I've handled a few ACC requests and I haven't come across one that was disallowed due to 527. 579 isn't disallow and afaik there are no other account creation-related filters. Dat GuyTalkContribs 16:16, 6 October 2017 (UTC)
  • Regretful oppose In the absence of further discussion to my concern, and with the timer expired.Striking default qualifier as discussion followed. As DatGuy mentioned, there doesnt seem to be efs of concern to ACC that are both Private and Disallow. Since Meta handles username blacklisting now, it looks like we let them to free the cycles. To the initial use case given, if an action only gave a filter number then that filter was already public as are all its logs. So I land as oppose due to still not seeing the ongoing need wrt ACC. I'm still open to discussion to help me see something that I'm not understanding. Crow On The Go! Caw 16:22, 8 October 2017 (UTC)
@Crow: In regards to the ACC use need, providing checkusers with a summary similar to "Request XXXXXX had an IP that tripped filter X correctly" is where this comes in handy to me. Just yesterday I was speaking with a CU who reiterated this would be way more helpful than "IP X tripped X", as we can actually confirm whether it was a positive (correct) trip of the filter. -- Dane talk 16:33, 8 October 2017 (UTC)
  • Thanks for replying. The thing in that scenario is, all youre going to get with efh is the regex that tripped the filter. Without getting too beansy, youre unlikely to get much guidance to what spi it is from. I kno you cant use a real world case for privacy reasons but can you give an example of an actual filter trip leaving out the pii? As i mentioned i think most of the acc filters are public already. Crow On The Go! Caw 19:38, 8 October 2017 (UTC)
@Crow: Abuse Filter 855 is an example of one that has tripped that I was unable to view/evaluate properly to give additional information. As you said, I know all about the WP:BEANS involved in this so I don't want to say much more - but viewing the filter to give the additional data behind what it's stopping/whether it appears valid or invalid trip. Without that, basically my only comment can be "IP X tripped filter XXX" instead of "IP X tripped filter XXX; appears to be a valid trip according to the details of XXX". -- Dane talk 19:51, 8 October 2017 (UTC)
  • Interesting, 855 has nothing to do with account creation. It covers specific editor(s) against a small set of pages (and not their own) so should not be showing up at ACC. Unfortunately I'm still not seeing the need vis. ACC given the lack of private-&-disallow filters here, and that Meta now handles username blacklisting so we're likely to defer any future EF requests along those lines to Meta. — Preceding unsigned comment added by Crow (talk • contribs) 16:22, 9 October 2017 (UTC)
@Crow: Without sharing too much, I can tell you that the data from 855 is relevant to our checks at ACC when deferring to a CU as previously discussed. -- Dane talk 16:43, 9 October 2017 (UTC)
  • I can probably guess why, but in this particular case the only question is whether the filter is too broad, which only a CU can answer anyway. EFH/EFM can only add the specific consideration which brings it to CU's attention in the first place, and leave it to them to see if its a FP/Valid. It saves CU or SPI clerk a click or 2, and while I'm not one to push more work on them, a SPI clerk needs to endorse before a CU will look, and that is the main use-case that was driving the EFH creation. CrowCaw 17:01, 9 October 2017 (UTC)
  • Support - Dane is a trusted user and I can see how this would be beneficial for ACC purposes and having more eyes on things will be useful from an SPI standpoint. CHRISSYMAD ❯❯❯¯\_(ツ)_/¯ 03:51, 10 October 2017 (UTC)
  • Oppose per lack of demonstrated need and per Crow. Users above who voted merely because a user is trusted are reminded of the concerns raised during the EFH RfC. This cavalier attitude to hat collecting and ease of access is problematic. Nihlus 04:03, 10 October 2017 (UTC)
@Nihlus: With all due respect, Chrissymad is active on the ACC tool and an existing edit filter helper, so she likely is able to relate to the statements i've made above for need/usage of this right. Your comment overlooks her statement regarding how she see's the benefit for use for the ACC tool and implies she voted simply because she see's me as a "trusted user". -- Dane talk 04:29, 10 October 2017 (UTC)
My comment was not directed at her, but rather, all the users above me who voted support. Nihlus 08:58, 10 October 2017 (UTC)
I would counter by saying that the whole concept of requiring a "need" for the tools is problematic. Nobody needs any advanced permissions here. Nobody needs to be here at all. Instead, we have thousands of volunteers spending their time here, and the least we can do is give them the technical access necessary to fully do the jobs they've signed up for. We should look for whether a candidate has a potential use for the tools, without going near language as strong as "need". The candidate has clearly defined how he will use this permission - looking at filter tripping by IPs when evaluating certain ACC requests. As someone who formerly volunteered at ACC, I can attest to giving these users as much view access as possible so they can have the full picture when handling requests. All that remains is figuring out whether I trust the candidate to use the tools properly. In this case, proper use means looking at private filter logs from time to time, and not revealing the contents of the filters to long-term abusers who would then be able to bypass the filters 10 seconds faster than their usual trial-and-error method. I think I can make that leap of faith here. -- Ajraddatz (talk) 08:51, 10 October 2017 (UTC)
  • The reason "need" keeps coming up is that it is the first consideration when considering the grant. See also the archives at RFPERM where "no need for" is often given when declining. And I won't even bring up RFA (though I guess I just did). Need was an important consideration and sticking point during the RFC as well. Now that all said, thanks to Dane for continuing to explain... it's not obvious to one outside the ACC environment, and it's really hard to explain things completely with a mouthful of WP BEANS, but I do now see the relevant use case where this is useful outside of action=accountcreate in EFs. So one more question if I may: when you defer a request to CU, how is that done? A button in the tool, mailing-list, SPI, an "on-call CU", etc? CrowCaw 14:57, 10 October 2017 (UTC)
There's basically a 'defer to checkusers' button, that when pressed moves the request to a CU queue. Dat GuyTalkContribs 15:19, 10 October 2017 (UTC)
@Crow: We don't have an SPI process (like clerks) and in my time at ACC we haven't ever discussed a CU case in the mailing list. We have a CU queue in ACC that we defer to using the tool and when we get a request that requires CU intervention, we make a note in the tool (a note can be set to "Tool User" or "Tool Admin" for visibility). The note usually contains a description of why we are deferring the request for CU (e.x. "What sock does it match? Is the IP CU Blocked without an ACC Ignore note? Did an Edit Filter trip? Is there something suspicious that needs to be evaluated?") and then CU processes the requests. The feedback from CUs has been that the descriptions with more information cut down the time for the CU to process (especially when the CU queue on ACC is frequently in the 40s to 60s with a couple weeks backlog). In evaluating a normal request that doesn't appear to be directly CU, for example, recent vandalism and edits within a certain timeframe goes into the CU queue. Filter trips are looked at as well when we evaluate requests, so this doesn't limit the use case to just CU-Blocked IPs. I hope this helps clarify a bit more. -- Dane talk 15:32, 10 October 2017 (UTC)
  • Thanks and yes this does fill in a huge gap in my understanding about the use case and associated need. I shall ponder this, but for now I've struck through my oppose. CrowCaw 15:40, 10 October 2017 (UTC)
  • Comment I fear this request is derailing slightly into overall comments on ACC volunteers having EFH. I've discussed this extensively off-wiki with Dane, and having recently become a checkuser I can appreciate where his comments and need comes from. Not having even a basic "looking at the filter I can see this was caught because X" adds significant time onto processing a request (not to mention trying to weigh up if a check is a good idea). I'm mindful of seeming insincere if I now support after my heated oppose above, but my sentiment remains one of supporting this request. Regardless of how this request ends, I'd like to propose we have a proper discussion on EFH for ACC (perhaps it could be dealt with in a similar way to SPI clerks?). Additionally, I would like to offer Dane mentorship should he be granted this right, as a compromise against the wholly valid concerns brought up regarding access and understanding of syntax -- There'sNoTime (to explain) 15:47, 10 October 2017 (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.

New function available for use

We have added ccnorm_contains_any. It is a convenience function 'cause it literally translates to contains_any(ccnorm(param1), ccnorm(param2), ...)

It can be used when we need to find multiple strings within another string and we want to use their canonical representation for comparison.

Here are some examples

Code Result
ccnorm_contains_any( "w1k1p3d14", "wiKiP3D1A", "foo", "bar" ) true
ccnorm_contains_any( "w1k1p3d14", "foo", "bar", "baz" ) false
ccnorm_contains_any( "w1k1p3d14 is 4w3s0me", "bar", "baz", "some" ) true


DMaza (talk) 02:40, 14 October 2017 (UTC)

@DMaza (WMF): for the examples above, what is the reference string? — xaosflux Talk 02:56, 14 October 2017 (UTC)
@Xaosflux: You would use it like this ccnorm_contains_any(added_lines, 'foo', 'bar') . Just like contains_any it will search for 'foo', 'bar' in added_lines, only that in this case it will ccnorm everything. Makes sense? DMaza (talk) 05:08, 14 October 2017 (UTC)
@DMaza (WMF): In the example table above - why is row 2 false? What was the example added line? — xaosflux Talk 09:32, 14 October 2017 (UTC)
@Xaosflux: ccnorm_contains_any("w1k1p3d14", "foo", "bar", "baz") is equal to contains_any("WIKIPEDIA", "FOO", "BAR", "BAZ"), which is always false (for any edit) since "WIKIPEDIA" doesn't contain any of "FOO", "BAR" or "BAZ". And similarly, if someone adds a line saying "w1k1p3d14" so that added_lines == "w1k1p3d14", then ccnorm_contains_any(added_lines, "foo", "bar", "baz") would be false for that particular edit, but would be true for an edit where someone adds a line saying "tw0 ducks w3nt t0 th3 b4r!!!!". Κσυπ Cyp   14:17, 14 October 2017 (UTC)
@Cyp: Thank you, so in the examples above the first value is compared against all subsequent values correct? That is what I was missing. — xaosflux Talk 14:31, 14 October 2017 (UTC)
@Xaosflux: Yes, that's correct. Κσυπ Cyp   14:56, 14 October 2017 (UTC)

What can edit filters on en.wp know about Commons images?

In a discussion (not on Wikipedia) about images used for vandalism, it was noted that edit filters are a good way of preventing some vandalism. This got me wondering what edit filters here can know about Commons images? Obviously they can know the filename of the image added, but is that it? Can it know what categories it is in? What other pages it is used on? Anything else?

This is not a request for an edit filter, it is a request to learn what an edit filter could theoretically do. Any questions about how it would be used, and whether using it for that is a good idea or not are for much later. Thryduulf (talk) 15:24, 14 October 2017 (UTC)

Far as I know, local edit filters only get information from local wiki. So not Commons categories wouldn't be included, nor usage. Jo-Jo Eumerus (talk, contributions) 15:28, 14 October 2017 (UTC)
This. We can also usually know the display size. To explain a bit further, we can detect uploads, and we can detect page edits. When you upload an image locally we can check file size, height, MIME, etc. When you make an edit we know basically nothing about anything linked in that edit, including local files, only the text being added. -- zzuuzz (talk) 16:05, 14 October 2017 (UTC)

Filter 384 2

Can we add !(added_lines rlike "[A-Z][a-z]\s\bDick\b") & to 384 to prevent this type of false positive? Nihlus 02:53, 9 October 2017 (UTC)

Done – I assume you meant "\b[A-Z][a-z]+\sDick\b". Κσυπ Cyp   12:48, 9 October 2017 (UTC)
Yep. Lazy copy paste on my part. :/ Thank you! Nihlus 13:13, 9 October 2017 (UTC)
@Cyp: Another false positve. Can we exclude cases of "Dick's Sporting" as it's both a franchise name and on some stadiums/arenas? !(added_lines rlike "\bDick\s[A-Z][a-z]|\b[A-Z][a-z]+\sDick\b|\bDick\'s\s[A-Za-z][a-z]") & Should also catch false positives of the possessive Dick's when referring to someone's name. Nihlus 20:25, 15 October 2017 (UTC)
@Nihlus: Ok, added ('s)?, which should be equivalent. Κσυπ Cyp   05:44, 16 October 2017 (UTC)
That will work for the "Dick's Sporting" but won't work for any possessive form of "Dick's". See examples such as "Dick's works" and "Philip K. Dick's poetic". Nihlus 14:05, 16 October 2017 (UTC)
Sorry, hadn't seen the a-z in your [A-Za-z]. How about now; John Q. Dick and Dick Q. Johnson should be able to take Dick's kitten Mr. Dick to Dick's Vet to be checked by Dr. Dick, without triggering 384. Κσυπ Cyp   08:58, 17 October 2017 (UTC)

Filter 680 (again)

Could someone exempt ✰ (shadowed white star)? The jpop stars demand it. FP: https://wiki.riteme.site/wiki/Special:AbuseLog/19529628 What's the deal with stars tho... --QEDK (愛 • 海) 16:36, 18 October 2017 (UTC)

@Cyp, MusikAnimal, and Rich Farmbrough: If it's alright. --QEDK (愛 • 海) 05:41, 20 October 2017 (UTC)
 Done All the best: Rich Farmbrough, 11:55, 20 October 2017 (UTC).

Filter 812 didn't disallow edits

Tracked in Phabricator
Task T175933

Hatebread (contribs) (a non-autoconfirmed user) made 5 edits, each increased page sizes by 2.7 million bytes, and for some reason filter 812 didn't disallow any of them. Is there any reason why? Do filters sometimes miss edits? —MRD2014 Talk • Edits • Help! 00:37, 14 September 2017 (UTC)

If I had to guess, it was because the edit was commented out? Other than that, I have no idea. Seems to be working properly everywhere else. Primefac (talk) 00:48, 14 September 2017 (UTC)
It's enabled and hasn't been changed since December 2016. —MRD2014 Talk • Edits • Help! 01:18, 14 September 2017 (UTC)
Sorry, I meant that the edits themselves were inside of comments. My second comment was regarding the fact that the filter was tripped 2-3 days ago, and about once a week since it was implemented. In other words, "it's working, and this is my only theory why it missed these edits". Though I do notice that they were all "new section" edits - maybe that threw it off? Primefac (talk) 01:22, 14 September 2017 (UTC)
According to the filter, it doesn't matter what the edit summary says. —MRD2014 Talk • Edits • Help! 02:42, 14 September 2017 (UTC)
Another major AbuseFilter bug...??? It should definitely 100% have stopped this, and indeed I can test the filter against that user at Special:AbuseFilter/test and it matches. I think there was some breaking change that happened a while back, because we've had several filters malfunction, where apparently the variables being read have the wrong values, are for the wrong edits, other weirdness. I'll create a task and propose rolling back the extension to a stable version — MusikAnimal talk 16:30, 14 September 2017 (UTC)
Created phab:T175933 — MusikAnimal talk 17:04, 14 September 2017 (UTC)
Bit off topic suggession. I suppose a specific warning message that has links about copyright issue, referencing and encyclopedic writing style to this filter may benefit users who are unaware off copyright issues.
Mahitgar (talk) 12:21, 1 October 2017 (UTC

Looks like a new filter is needed. I'll go and request one.TomBarker23 (talk) 10:40, 19 October 2017 (UTC)

Nothing wrong with the filter as far as I know. There is a bug with this filter that is being tracked at phab:T175933, as shown at the top of this thread. —MRD2014 Talk • Edits • Help! 02:56, 23 October 2017 (UTC)

Request for EFH bit for Nihlus

 Done With endorsement of a checkuser and no objections, acccess has been added. — xaosflux Talk 02:36, 25 October 2017 (UTC)

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

I'd like to have Edit Filter Helper assigned to Nihlus. They clearly meet the "requirements for granting" #2 through #5. For criteria #1, need, I would like to highlight his work in finding false positives over at WP:EF/FP and the improvements he has suggested (such as the threads above). The Edit Filter Helper page describes one of the groups of editors the right will be useful to as Those interested in helping with edit filters but who do not meet the thresholds required to be able to modify them - Nihlus shows a clear interest in helping out with our filters. His contributions to the noticeboard, mailing list, the regex used in his bot (NihlusBOT (talk · contribs · count)) and countless personal conversations with myself (which I can attest to) has show he has the required competence with syntax and regex. -- There'sNoTime (to explain) 20:57, 20 October 2017 (UTC)

@Nihlus: do you "want" this? — xaosflux Talk 21:46, 20 October 2017 (UTC)
@Xaosflux: I believe it will allow me to be more productive while also saving the EFM's time, so I accept the nomination. Nihlus 22:30, 20 October 2017 (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.

Slow filters

Community Tech set up a new log to record cases where specific filters take longer than half a second to execute. It's only been running for a few hours, but here are some early results:

Filter # of times it's taken longer than 500 ms
Filter 12 1
Filter 80 5
Filter 149 2
Filter 180 4
Filter 755 22
Filter 765 15
Filter 777 2
Filter 871 4

Clearly, filters 755 and 765 are the most laggy. Looks like MusikAnimal has already disabled 765 :) Anything we can do to optimize 755? Kaldari (talk) 20:03, 25 October 2017 (UTC)

755 has been disabled as well. Nihlus 20:21, 25 October 2017 (UTC)
@Kaldari: Is it feasible to build a "test" feature into the abuse filter extension that takes the most recent 500 edits to the wiki, runs them through the filter (possibly with pauses in between to prevent performance issues, if that's a concern), and returns the average, median, and maximum time the filter took to process for those edits? This may help edit filter managers (especially new ones) to ensure their filters aren't too expensive before enabling them. ~ Rob13Talk 22:39, 25 October 2017 (UTC)
Way back when we had something like this, but it was ironically removed because it was hurting performance. Times have changed, and I think we might soon get it back. The Anti-Harassment Tools team is currently testing this on ptwiki (phab:T177641) and if all goes well, it hopefully will make it's return to enwiki (phab:T177017). As for the data you see above (logging of slow filters), there are hopeful plans to surface this within AbuseFilter, too (phab:T176895) — MusikAnimal talk 02:50, 26 October 2017 (UTC)
Sorry I missed the "test" part. That's a good idea, and probably feasible, since the current batch testing tool essentially does the same thing minus performance measuring. As a workaround, once per-filter profiling is back you could just put your filter in log-only and test it that way — MusikAnimal talk 02:56, 26 October 2017 (UTC)

Weird filter trigger

The filter log for this user shows a trigger that I haven't seen before - "CheckUser Sock block" with no filter number shown. Is this normal? Home Lander (talk) 21:55, 30 October 2017 (UTC)

@Home Lander: That filter is hidden, so the log won't tell you which filter number it hit, but that's the name of the filter. Sam Walton (talk) 22:22, 30 October 2017 (UTC)
@Samwalton9: OK, should have figured as much. Is there any particular reason why that edit triggered the filter, or is that not publicly releasable either? (Just trying to determine whether triggering of that filter should generally be reported or not.) Home Lander (talk) 22:25, 30 October 2017 (UTC)
That filter is being used by a specific admin/checkuser - who will already be monitoring it as needed. — xaosflux Talk 23:08, 30 October 2017 (UTC)

Filter 384 3

This filter seems to be catching a few false positives with words that contain the word bitch in them. Some songs and anime have it in their title. Can we add something like \b([A-z]{2,3}bitch|bitch[A-z]{3,4})\b to permit false positives such as this and this? That should still disallow words like bitches. Nihlus 21:10, 27 October 2017 (UTC)

We could just wrap it in \b and that would help. I should mention filters like this one will never be free of false positives. It is simply the nature of the disruption it is designed to prevent, where there will always some good-faith addition that would trigger it. E.g. many songs outright have the word "bitch" in them. I would first investigate how much vandalism resultantly would get through with this proposed change, and also note each clause to prevent false positives adds more complexity to the filter and its effect on runtime performance. I suspect many new editors are not surprised their edits containing profanity don't go through. Another thing to consider is showing a more informative warning that explains how to request the edit be made on their behalf — MusikAnimal talk 17:50, 30 October 2017 (UTC)
That might be the preferred method. Perhaps we should guide them to make an edit request with a warning since, as you said, it should make sense to new editors that it would be filtered out. My only hesitation is that spammers would then just go to the talk page and make a mess there, but we can cross that bridge when we get to it. I can work on the message as I think that would be more productive (since more people watch the talk pages of the articles and are more likely to have familiarity with the topic). Nihlus 18:02, 30 October 2017 (UTC)
@MusikAnimal: See a drafted warning message at my sandbox. I would recommend MediaWiki:Abusefilter-profanity as the sensible choice for its location. However, I don't know if we should expand WP:EDITREQ to include an "edit filter" variant or if a simple request on the talk page would suffice. Nihlus 20:01, 30 October 2017 (UTC)
MediaWiki:Abusefilter-warning-profanity, you mean, I think. --QEDK (愛 • 海) 18:25, 31 October 2017 (UTC)

874 changed and disallowing again

Pretty evident from the filter + comments as to why. I believe its a good temporary alternative, hopefully you can agree given the issues at hand. Pinging Crow as the primary editor of the filter before I changed it -- There'sNoTime (to explain) 08:32, 1 November 2017 (UTC)

Disallowing CSD removal by article creator

I was wondering if 29 is a filter we can upgrade to Warn or possibly create an additional filter to go with it. I honestly think we should disallow CSD removals by the creator of the article (article_first_contributor) since my recent experience has consisted of them edit warring and constantly removing it until they get blocked. I see that as more bite-y than something like a stern warning or just a Disallow that advises them of the proper avenue of disputing CSDs (pointing to the talk page). It will also save other users time so they don't have to play games with them by reverting and warning and reverting and warning etc. Nihlus 04:05, 11 November 2017 (UTC)

It used to issue a warning, back in 2009. See the discussion at Wikipedia talk:Edit filter/Archive 2#Special:AbuseFilter/29 - prevention of removal of deletion templates. The closer of that discussion was User:Xeno. I can see the argument for restoring the warning, at least as an experiment, because the filter gets 5-15 hits per day. EdJohnston (talk) 05:41, 11 November 2017 (UTC)
Just for clarity, the filter in 2009 was disallowing all non-confirmed editors, not first contributor (wasn't possible). –xenotalk 16:22, 12 November 2017 (UTC)
Since the conclusion of that discussion, the edit filters tool has added article_first_contributor. It's been discussed since, see Wikipedia:Edit_filter_noticeboard/Archive_2#Special:AbuseFilter.2F29. – Train2104 (t • c) 13:17, 11 November 2017 (UTC)
There's a bot (Cyberbot, I think) that restores the AfD templates, so this process is already automated. Even so, I don't see a problem with at least upping the filter to show a warning. We do however need to allow them to blank the page, as that would qualify as G7 — MusikAnimal talk 05:27, 12 November 2017 (UTC)
Yeah, I'm not too worried about AfD, since as you said, a bot assists there. I would want, at minimum, a warning that directs them to the talk page. I really think we should create a new filter to disallow, but I would be satisfied with trialing a warning first to see if that makes any improvement. Nihlus 06:31, 12 November 2017 (UTC)
I'd say a constructive warning with suitable advice is the only idea I'd support. A CSD tag can be added by anyone but not removed by the creator of the article, it's only suitable to let them have their IAR and taggers will more than often have the chance to point out when an article qualifies under CSD through AfD or otherwise. Either way, even if an article creator is proving to be disruptive (just wrt the CSD tags), I'd say the content is mostly salavageable (my personal experience). --QEDK (愛 • 海) 14:17, 12 November 2017 (UTC)

Filter 384 4

Is \bwas here\b intended to catch "Kilroy was here" and variants type of additions? Think we should streamline it — while the edit I'm referring to is not the pinnacle of what you can probably call a false positive, I was just thinking. --QEDK (愛 • 海) 08:25, 13 November 2017 (UTC)

We've had several recent false positive reports for Filter 225 hits (Vandalism in all caps), where the only ALL CAPS present was in the URLs of external pages. Is there any practical way to fix the filter in such a way that it will allow these URLs, but which won't allow users to get around the filter with plain text? עוד מישהו Od Mishehu 09:37, 14 November 2017 (UTC)

Wouldn't be perfect, but maybe something like "(THE|VERY|LONG|LIST|OF|BAD|WORDS)(?![-_+/%:?&#A-Za-z0-9]*+\.(html?|php|aspx|</ref)\b)" would reduce the false positives a bit. Κσυπ Cyp   11:03, 14 November 2017 (UTC)

Filter 885

Why is this filter public? Normally, filters that target specific sockpuppeteers and LTAs should be private per WP:BEANS. —MRD2014 Talk • Edits • Help! 16:07, 14 November 2017 (UTC)

Good question. Don't know why, but now it's not… Κσυπ Cyp   17:08, 14 November 2017 (UTC)
@MRD2014:Per BEANS, please email the main author of the filter (in this case, Special:AbuseFilter/history/885; in other cases, just replace the number - this page is visible to anyone authorized to see the filter) and leave a simple {{You've got mail}} message on their user talk page. עוד מישהו Od Mishehu 07:32, 15 November 2017 (UTC)

More per-filter statistics now available

We have re-enabled per-filter metrics (run-time and number of conditions) on English Wikipedia. Check it out as part of the Statistics on each filter's edit page. As a side-effect, the link to the recent actions graph has been moved to the subtitle above the Edit form. DMaza (talk) 20:06, 13 November 2017 (UTC)

Ooooh, so that's what is causing the new Of the last x actions, this filter has matched 0 (0.00%). On average, its run time is 0.07 ms, and it consumes 1 condition of the condition limit. thing - awesome work! -- There'sNoTime (to explain) 10:20, 15 November 2017 (UTC)

Type casting

I thought I'd share a new revelation that I somehow overlooked all this time: You can do type casting! A prime example is when checking a set of namespaces. Currently in many filters, to reduce condition count we're doing something like article_namespace rlike "^(1|8|11)$" (because we want to capture namespaces 1, 8 and 11, but not 118). You could instead do contains_any(int(article_namespace), 1, 8, 11)) which I think is cleaner. Neat-o — MusikAnimal talk 06:51, 10 November 2017 (UTC)

According to mw:Extension:AbuseFilter/Rules_format#All_variables the data type of article_namespace is already integer, did you perhaps mean contains_any(string(article_namespace), "1", "8", "11")) for your example? However, contains_any("118", "1", "8", "11")) would return true, which is not what you want. Or have I misunderstood you, and you are saying that the contains_any() function has an undocumented integer matching feature when all arguments are integers? —RP88 (talk) 17:47, 10 November 2017 (UTC)
Testing with the debugging tools, contains_any(1234, 23) (and contains_any(int(1234), 23) too) returns 1, even though it might be more useful if it didn't. Κσυπ Cyp   18:42, 10 November 2017 (UTC)
Aw shucks, actually yes I've got this wrong. What I think happens here is contains_any casts to an iterable (string in this case), so indeed my above example does not work. However we could do contains_any([1, 8, 11], article_namespace), or even cleaner article_namespace in [1, 8, 11] — MusikAnimal talk 22:23, 11 November 2017 (UTC)
While article_namespace in [1, 8, 11] seems like a good idea, testing 23 in [1234, 5678] & contains_any([1234, 5678], 23) unfortunately evaluates to true. Κσυπ Cyp   17:08, 14 November 2017 (UTC)
Okay so it just does't know how to handle arrays at all, even though it supports the syntax. I've created phab:T181024. Feel free to edit if anything I said is wrong. Making arrays act like arrays will cause massive regressions, I think, but anyway to me that's how it should work — MusikAnimal talk 04:49, 21 November 2017 (UTC)
The report seems fine. Testing, "\n1\n" in ["", 0, 11, 20] ⇒ false, "\n11\n" in ["", 0, 11, 20] ⇒ true, actually seems to work (but would break if array handling is fixed), but I think it's probably better just to fix it to handle arrays sanely. Κσυπ Cyp   07:19, 21 November 2017 (UTC)
In all probability, they did it to reduce complexity but that just made handling it more difficult. :/ --QEDK (愛 ☃️ 海) 14:52, 30 November 2017 (UTC)

Filter 650 and disambiguation pages

I just triggered filter 650 by creating the Bachvarov disambiguation page. Could the filter be tweaked to ignore pages with {{disambiguation}} and more specific variants thereof, e.g. {{surname}} and {{geodis}}? I expect the point is to find pages that should get categories, not pages that need no categories other than what a template transcludes. Nyttend (talk) 01:31, 13 December 2017 (UTC)

How can we better surface performance data about AbuseFilter

Hello Edit filter managers;

Over the past few months the Anti-Harassment Tools team at the Wikimedia Foundation has added some additional forms of performance measurement to AbuseFilter to better understand the impact it is causing on users’ edits.

  • We are measuring both runtime in milliseconds for the 75th and 99th percentiles on the AbuseFilter profiling Grafana dashboard.
  • We are measuring the total count of conditions being hit and the number of filters hit on the AbuseFilter profiling Grafana dashboard.
  • We are logging slow filters that take over 800 milliseconds on Logstash (which is unfortunately permissioned, but some EFMs have permissions to view.)
  • We measured the impact of and determined the per-filter statistics do not cause a performance impact, so we’ve reenabled them on the filter parameters page. These statistics show the average runtime of each filter, but do not often show anomalously slow incidents, which is why we've added the Logstash logging.

Now that this data is being measured, I’d like to talk about how we can make it more easily available to you as you manage filters. We can make this minimally intrusive (e.g. just add links) or could make some more significant changes with your approval and permission. Here are a few ideas to start the discussion:

  • Expand the “Of the last N actions…” sentence to include the average condition count.
  • Add a “Statistics” section on Special:AbuseFilter and show all the existing statistics as well as new data from Grafana and Logstash.
  • Display an icon by the slow filters on the All filters list
  • On the Filter parameters page, indicate if the filter is taking over 700 milliseconds.
  • …something else?

Would any of these be helpful to you? Or do you have any suggestions? We won’t make any changes without your consensus, but I want to make our team available if these changes (or similar) would be helpful.

Thank you! — Trevor Bolliger, WMF Product Manager (t) 21:52, 7 December 2017 (UTC)

Trevor is already aware of my thoughts, but to share with others -- the things I'd like to see the most are bullets 3 and 4 (exposing slow filters in the interface). I have access to the logstash dashboard, so I've been working with some filter authors here to improve performance. The main issue obviously is they don't have logstash access and can't tell if the changes helped performance or not, since the "average" run time is still reasonably low. So basically on the filter parameters page, I'd like it to say something like "In the past hour, this filter took over 700ms to execute for N actions". That message would only show if N is greater than zero. Perhaps it'd also link to the Statistics page (bullet #2 above), that would list each individual action for which the filter took over 700ms to run. If it linked back to the Special:AbuseLog entry, we could then debug and find out why it took so long for that particular edit, etc. That'd be pretty amazing, but again for me the priority is just exposing which filters are frequently "slow", regardless of the average run time — MusikAnimal talk 22:14, 7 December 2017 (UTC)
Random question about performance – if two filters use the exact same expensive subexpression, is the result from the first filter cached for the second filter? Κσυπ Cyp   06:17, 8 December 2017 (UTC)
@Cyp: I don't believe so, because the most expensive subexpressions are evaluating long pieces of wikitext (e.g. the previous revision of a long page vs. the submitted revision.) These aren't cacheable. — Trevor Bolliger, WMF Product Manager (t) 19:53, 13 December 2017 (UTC)

Article age variable

Moved from Wikipedia:Village pump (technical) § Edit filter question

Hi. On edit filters, is there some way to use the article's age as a variable? I'm not only talking about new page creation; suppose that for some reason, you wanted to restrict your filter to articles less than an hour (or 3,600 seconds) old. I don't see any such variable listed on the documentation page, but could there be a work-around of some sort? Just wondering. Thank you. Biblio (talk) 17:15, 27 December 2017 (UTC)

@Biblioworm: There's an edit filter noticeboard that I would guess has the people to answer that question. --Izno (talk) 17:41, 27 December 2017 (UTC)

Hi. I was just wondering if there's some way to use an article's age as a variable. Suppose, for instance, that you wanted to restrict your filter to articles less than an hour (or 3,600 seconds) old, or to articles older than a month. The documentation page doesn't really address that, but is there some way to do this? Thank you. Biblio (talk) 18:54, 27 December 2017 (UTC)

@Biblioworm: Sorry no, however if you wanted to hardcode it for a specific time you could hit most pages by examining the article_articleid as it is an integer and newer pages get a higher number. — xaosflux Talk 19:45, 27 December 2017 (UTC)
Eg pick a page made a month ago, then if the article id is less than it, it is older than that - unfortunately this is not dynamic, but you could use it to say include/exclude all pages made before 2017 for example (and could update the comparison value in the future to move it forward). — xaosflux Talk 19:53, 27 December 2017 (UTC)

Desysopping edit filter managers under a cloud

Following a January 2016 discussion, if the Arbitration Committee desysop an admin who has self-granted edit filter manager rights then the clerks will leave a note here (EFN) for review. I've just request that 'crats do the same if they desysop someone under a cloud who has self-granted the EFM permission. Comments about this request should probably be left at WP:BN rather than here.

The January 2016 discussion was not formally closed, but there was consensus against automatically removing the right from all desysopped admins, but a review did find favour explicitly and implicitly. I don't see a need to revist that, but if anyone else does then here or Wikipedia talk:Edit Filter is the place to do so (link from whichever venue you don't choose).

AFAICR no such review has yet needed to take place, Salvidrim! would have been the first had he not resigned his bit before the arbcom case with a passing desysop remedy closed. Following a discussion between him and xaosflux at user talk:Salvidrim! the EFM permission was replaced with EFH, negating the need for a review here. Thryduulf (talk) 12:29, 6 January 2018 (UTC)

Filter Descriptions in messages

A discussion is open at Wikipedia_talk:Edit_filter#Variable_in_disallowed_message regarding the possible addition of filter names to the disallow warning (MediaWiki:Abusefilter-disallowed). — xaosflux Talk 01:00, 7 January 2018 (UTC)

Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia:Edit_filter_noticeboard/Archive_3&oldid=1147972480"