Requests for comment/Creating abusefilter-manager global group

From Meta, a Wikimedia project coordination wiki

The following request for comments is closed. Closing request for comment as closed (resolved) after nearly a year and a half of discussion. Closing statement: While most of the goals of this request for comment were sufficiently met (refer to #Action items), this request for comment was setup in a discussion format and did not carry over into a format that allowed for voting on a specific proposal to achieve the consensus needed to create this usergroup. There is no consensus at this point in time for the creation of this usergroup, however, there is consensus of approximately 75% support to move forward with creating a global request for comment to allow voting on this group. The vote should be appropriately communicated at minimum through relevant newsletters (i.e. Tech News) and relevant noticeboards (i.e. village pumps) to ensure it is a global discussion that all shareholders are invited to vote on. It is recommended that the vote be setup in a multi-section format (i.e. proposal #1 - all wikis & no opt out, proposal #2 - all wikis & opt out, proposal #3 - etc.) as there is clearly differing opinions on the parameters and restrictions of this group. ~riley (talk) 01:56, 17 January 2020 (UTC)[reply]


Per earlier discussion on Meta, there is interest in creating a global group called abusefilter-manager, the members of which have the ability to edit abuse filters on all public WMF wikis. This should be a very restrictive group, and its members should be selected from highly trusted members of the community who are actively engaged in the development of AbuseFilter. They will use the permissions associated with this group to revise those filters that may be malfunctioning, or might be affected by an upcoming change in the AbuseFilter code.

Context[edit]

A global group called abusefilter-helpers currently exists (see Meta and Gerrit ). This group is a view-only group. Its members can see the abuse log for public and private filters, and see the definition of public and private filters, across WMF wikis. Membership in this group does not allow them to edit those filters. They also cannot see those abuse logs that are suppressed (typically, by a local Oversighter).

  • Of note, this group is not subject to any opt-out process, i.e. members of this group have those permissions on all WMF wikis without exception.
  • This group was not formed through an RfC (or at least I cannot find an RfC about its creation).
  • Members of this group also have an unrelated right, which is to view the spam blacklist log.

A global group called global-sysop currently exists. With respect to #AbuseFilter, its members have only two rights: abusefilter-modify and abusefilter-log-detail. They currently do not have the right view non-public filters, or logs associated with them.

  • This group was formed through an RfC
  • Its effects are subject to an opt-out (e.g. English Wikipedia has currently opted out of this feature, while Persian Wikibooks has not)

Lastly, a global group called abusefilter-modify-global used to exist but was deleted in 2015. (Indeed, it seems the global group was actually named as abusefilter, and not abusefilter-modify-global.) That group had probably the most relevant set of rights, globally (see table below), was not formed through an RfC and was not subject to an opt out. Obviously, we can reuse this group. But because of that naming conflict and to keep a clean history, it might make sense to just create a brand new global group (hence the proposed new name abusefilter-manager).

In the table below, I am listing all the relevant permissions, indicating which current/former/future group has/had/should have those rights. I am happy to provide justifications about the rights of the proposed group

User Right Description Abusefilter Helpers Global Sysops Abusefilter Modify Global Proposed Group
abusefilter-hidden-log View hidden abuse log entries
abusefilter-hide-log Hide entries in the abuse log
abusefilter-log View the abuse log YES YES YES
abusefilter-log-detail View detailed abuse log entries YES YES YES YES
abusefilter-log-private View log entries of abuse filters marked as private YES YES
abusefilter-modify Modify abuse filters YES YES YES
abusefilter-modify-global Create or modify global abuse filters§ YES YES
abusefilter-modify-restricted Modify abuse filters with restricted actions§§ YES YES
abusefilter-private View private data in the abuse log
abusefilter-private-log View the AbuseFilter private details access log
abusefilter-revert Revert all changes by a given abuse filter YES§§§
abusefilter-view View abuse filters YES YES YES
abusefilter-view-private View abuse filters marked as private YES YES
spamblacklistlog View the spam blacklist log YES

§ Global abuse filters are filters defined on Meta that apply to all projects.
§§ By default, restricted actions include "degroup", "rangeblock" and "blockautopromote". A user who can otherwise edit filters is not allowed to edit filters that take those actions, unless they have this right as well.
§§§ It is unclear why the historical group had abusefilter-revert rights; I do not think the newly proposed group should have that right. Reverting a filter's action is something only sysops should be able to do.

Requirements[edit]

To become a member of this proposed group, the candidate must:

  • Have extensive experience with AbuseFilter: This can be demonstrated in one of two ways:
    • Be an AbuseFilter developer: They should either have a patch that was approved and merged into the AbuseFilter code, or hold +2 rights on Gerrit and have approved and merged someone else's patch into the AbuseFilter code
    • Have notable experience with AbuseFilter as a user: They should have created or edited several filters as a sysop on WMF wikis.
  • Be a sysop on their home wiki: Home wiki is defined as the wiki in which they are most active historically and/or recently.
  • Be a trustworthy member of the community: Requests should be placed on Steward requests/Global permissions. The request will be approved by a steward if there is a consensus for the user to become a global abusefilter-manager after a period of discussion of no less than two weeks. The discussion is not a vote; comments must present specific points in favor of or against the user's approval.
  • Be identified to the WMF: Because private filters or their comments may contain nonpublic information, and considering the wide number of wikis to which members of this group will have additional access, they should sign the Confidentiality agreement under the Access to non public information policy.

By default, appointment will be temporary, lasting any time up to a year, and will be added to Steward requests/Permissions/Approved temporary. Requests for renewal can be done by placing a new request on Steward requests/Global permissions#Requests for other global permissions.

Action items[edit]

  • Discuss the cons and pros of having an opt-out for the newly proposed group
  • Decide the name of the new group (abusefilter-manager, abusefilter-global-editor, or global-abusefilter-manager or something else)
  • Determine the set of rights the new group should have
  • Finalize the set of requirements that users of this group must meet
  • Gain community consensus for the creation of this group via this RfC on Meta

Discussion[edit]

  • I'll go ahead and answer on a per-point basis. Opt-out: it depends on how we want to use this group. If we only plan to use it to make "technical changes" (i.e. new syntax after a code change) or unbreak filters which clearly cannot work, then I don't feel the opt-out as necessary, especially for technical changes. Instead, if group members will be able to make other types of edits, then I guess the opt-out will be mandatory. Name: the "abusefilter-helper" group doesn't have a really clear name, so I guess it should be changed as well. At the moment, "abusefilter-manager" seems fine. Rights: the ones proposed in table above should be fine. --Daimona Eaytoy (talk) 10:09, 13 August 2018 (UTC)[reply]
    Which "other types of edits" are you talking about? Huji (talk) 18:45, 13 August 2018 (UTC)[reply]
    Basically, whatever doesn't fit in the two criteria above. I would also include uncontroversial edits, as far as they're not necessary. For instance, changing a long series of contains joined with ORs to a single contains_any. This would be a useful change, and also not controversial, but it's not really necessary (unless of course the conds limit is being constantly hit) and thus we shouldn't "impose" it. --Daimona Eaytoy (talk) 10:09, 14 August 2018 (UTC)[reply]
    Agreed. I think a modification like what you described (replacing many contains statements with one contains_any) is an aesthetic change, unless the condition limit is reached. Aesthetic changes do not fall under the purview of this proposed group. The group should only perform changes that would otherwise render a filter dysfunctional or inaccurate, or significantly affect the overall performance of AbuseFilter as a whole.
    One additional safeguard can be to say that this proposed group needs to have at least two members, and each change should be approved by at least one other member (other than the person performing the change) before it is done. The changes can be discussed in non-public Phab tasks, to keep documentation on the approval by the peer. This is all things we would already do, so no big deal. Huji (talk) 13:22, 14 August 2018 (UTC)[reply]
  • I think an opt-out is not a great idea for this new group. Instead, we should devise a process similar to that used by Stewards, i.e. members of this group would not intervene in projects with an active community of sysops, or at least they won't intervene unless the community of sysops fails to address an issue in a timely fashion. For instance, on wikis with more than 5 (or 10?) active sysops, Abusefilter Managers should post on the wiki's WP:ANB equivalent page a request, stating that a filter needs to be changed and why (performance reasons, preventing it from malfunctioning due to an upcoming code change, etc.) and ask one of those sysops to reach out, via Special:EmailUser, to receive instructions about what to change (keeping the details private to ensure it is not abused by malicious users). If no one reaches out within 4 days, or if someone reaches out but is unable to perform the necessary change within 7 days, then the Abusefilter Manager can perform the change themselves. The ability to view private filters should also not have an opt-out; it is needed both to be able to replicate a filter on another private test wiki and find the appropriate fix, and also to monitor the change being applied by local sysops per the process above. Huji (talk) 19:06, 13 August 2018 (UTC)[reply]
  • First of all, global groups are created either through small-scale requests for access (the common law model, used for smaller permissions like global rollback or abusefilter helper and larger permissions for temporary access like interface editors or Pathoschild's global group) or through large RfCs (the statute law model, global sysops and to a lesser extent new wikis importers). I think an RfC is the right approach here given the access. Some specific thoughts on this proposal: I think the rights you've proposed are appropriate for the group, and I think that not including an opt-out makes sense so long as the scope is non-controversial, as with interface editors. Regarding the naming of the group, I think global-abusefilter-managers works and fits our current naming conventions.
    The one other consideration here is what to do about length of access. Interface editor, the most analogous group to this one, is granted for up to a year at a time because the permissions are granted without the possibility of opting out. The intention here is that all truly global and sysop+ rights can only be granted for up to a year, including steward which is why we have confirmations. I don't like this system, and I think we should take the time to set up a new process for this group that could be used for interface editors and Pathoschild's global group as well. Maybe a short confirmation discussion during the steward confirmations, and removal for inactivity if no edits in six months or a year? Though the current process of requesting each year isn't very burdensome, and we could easily grant for two years to some of the long-term helpers (though we haven't in the past). – Ajraddatz (talk) 06:12, 14 August 2018 (UTC)[reply]
    The purpose of limiting access to one year is to avoid possibility of abuse. To that end, I think we should specify some requirements for a user to be part of this group, to ensure that only a purposefully selected group of users can gain this access. For instance, we could say that users must (a) have +2 access to the AbuseFilter code and/or have at least one of their patches merged in the last 12 months, (b) have sysop level access in at least one WMF wiki and have used it to create or modify a filter in the last 12 months, and (c) have gone through the identification process.
    The latter is necessary because, at least in theory, a wiki might create a filter that is applied only to a specific IP range, because it is associated with a long-time abuser. By gaining this access, one will have the ability to see that filter's definition, and thereby connect that IP to that person, which falls under ANIP.
    With all those in mind, we can also have an annual confirmation process; however, the permissions provided by this group are hopefully rarely used, so making a logged history of using this right a requirement for renewal might not be a great idea. Perhaps the default option should be to renew one's access as long as they continue to meet a, b and c above? Huji (talk) 13:29, 14 August 2018 (UTC)[reply]
    Fine, just a note about identification: I currently own the abusefilter-helper rights and thus I can view private details like the ones you mentioned. However, although I'm planning to request signing an NDA soon, I still haven't done it. So this requirement should apply to abusefilter-helper as well. --Daimona Eaytoy (talk) 16:06, 14 August 2018 (UTC)[reply]
    Coding related requirements (+2 or merged patches) sounds too much, and we definitely need a renewal (just like interface-editor, per Ajr), but prerequisite for their ability on abusefilter logics are good. — regards, Revi 16:30, 14 August 2018 (UTC)[reply]
    I think User:Daimona Eaytoy is right to say that the abusefilter-helper group should also require identification. Huji (talk) 17:18, 15 August 2018 (UTC)[reply]
    @Ajraddatz: for now, I added to the proposal above a clause that would enforce the same renewal process as that for interface editors. However, I am open to other ideas. Huji (talk) 17:24, 15 August 2018 (UTC)[reply]
    Thanks, that's probably the easiest option. Regarding identification, that is something for Foundation-controlled permissions (CU/OS/steward/OTRS) only, so that isn't needed here. It's also just signing an agreement, so not much value added. – Ajraddatz (talk) 17:27, 15 August 2018 (UTC)[reply]
  • Wikis, even large ones, often need help to use the AbuseFilter correctly. I've almost never opened Special:AbuseFilter on a wiki without finding something wrong, and probably unexpectedly so, especially in private filters because they are subject to less scrutiny. It's sometimes relatively time-consuming to help sysops in the menial task of applying changes they have agreed to or requested. So, I can definitely see a need for a group active on all wikis by default. --Nemo 20:46, 30 August 2018 (UTC)[reply]
  • Going off of previous discussions, I think the use-case for this user group is well-defined. It should be used solely to fix existing filters, not tweak them to deal with actual abuse or anything involving community process. As such the proposed permissions look good to me, and I don't think opt-out is necessary. Opt-out for global sysop, and so forth, makes total sense because admin actions are debatable and directly related to local process and policy. Abuse filter management on the other hand is highly specialized. Many wikis don't have the expertise to address issues with filters, and may not be able to understand why some changes are necessary. Throw in the language barrier, and you're looking a lengthy process to fix what are potentially major performance issues with a given filter, unless we're able to edit it directly. I only speak two languages, so for most wikis I have no means to communicate with abuse filter managers ahead of time. You could use Google Translate or the like, but it's probably not going to do a good job for technical jargon. Again, tweaking filters to prevent abuse, or do anything process-related, should be left to the community. Fixing filters isn't really controversial, or it shouldn't be. A lot of common sense should be applied as well. For instance, if you notice a broken filter, depending on what it is you might just disable it and attempt to inform the previous author, as the working variant might cause unforeseen problems. Working filters that are poorly implemented can simply be fixed, as the only change we've made is to improve performance (or remove deprecated variables, etc.). That's my 2 cents. By the way, I got here from the post at enwiki's technical village pump. If we want to move forward with this RfC, we might should post on more village pumps, ping active abuse filter managers across various wikis, or even invite input via Tech News? MusikAnimal talk 23:57, 3 September 2018 (UTC)[reply]
    "If we want to move forward with this RfC, we might should post on more village pumps, ping active abuse filter managers across various wikis, or even invite input via Tech News?" Exactly. In my opinion, it makes sense to have two phases: phase 1: discussion, phase 2: vote on the discussed proposal. I largely agree with what you have said above as well, though in my opinion it is not necessary to forbid opt-outs. Discouraging opt-outs is fine, but some communities do in fact react pretty dismissive, for example mrwiki is very restrictive with regards to almost any activities by non-Marathi speakers on their wiki even ("Kindly note official Marathi Wikipedia policy to not to allow non Marathi Wikipedians any edits other than interwiki links and dealing with interwikispams"). --Vogone (talk) 11:53, 1 October 2018 (UTC)[reply]
    @MusikAnimal and Vogone: We should definitely seek for more input. Would it be better to ask on Tech News, or on noticeboards? I guess with the former we could reach more people, and we should also keep in mind that not every wiki has an edit filter noticeboard (for instance, on itwiki we use village pump or WP:RAA for that). --Daimona Eaytoy (talk) 13:12, 21 October 2018 (UTC)[reply]
    I think Tech News would be sufficient, as it gets posted to many highly-visible noticeboards, and it gets translated. I take it this will still be part of the "discussion" phase, and we're not yet ready for a support/oppose survey? MusikAnimal talk 17:03, 22 October 2018 (UTC)[reply]
    Agreed. Yes, it'll be part of the discussion, as we still have to clearly define how this right should be used, eventual opt-outs etc. What about the following message to be sent via T/N?
    We're discussing about the creation of a new global user group with the right to edit abuse filters, in order to fix malfunctioning filters and make sure all filters will still work in case of software changes. You can join the discussion and express your opinions on meta-wiki.
    I guess there's much to improve, but this could be something to start with. --Daimona Eaytoy (talk) 08:19, 23 October 2018 (UTC)[reply]
  • While I do agree in principle, there's too much question on how far will this new usergroup allowed to act on local wikis. Because this usergroup is not a subject of opting-out then there must be a clear cut on how far will this usergroup will interfere on local wikis, what is the standard will be used? local admin activity? Current Local admin available to help? Numbers of admin in local wiki? Number of active admins in local wiki? Number of admin that understood how to edit the filter in local wiki? Number of articles in local wikis? Number of editors in local wikis?, then there's also a problem of probability of a local wikis already have set of policies regarding abusefilters, how do people who will have this usergroup notify them if user from this usergroup can't even speak the local wikis language?--AldNonymousBicara? 18:41, 7 March 2019 (UTC)[reply]
    IIRC what have been agreed above, this group would only perform minor, technical changes to filters. For instance, changing the syntax if we want to push a breaking change in the backend. Two good examples are phab:T202095 (replacing "OTRS-member" with "otrs-member") and phab:T209565#4942689 (updating throttle parameters). The process would be more or less the opposite of what happens now: instead of writing on the local village pump/EFN, the AF-manager would make the change, and then notify people either there or in each filter's notes. Depending on the situations, we may also keep asking people to fix their filters and do it ourselves only if there's no reply in a given amount of time. Under the conditions above, AF-managers will be able to perform maintenance on every wiki. As for local policies, they should try to act accordingly (although it's not easy to know the local policy of every project). But again, suppose that we need to change a filter on a wiki where the local policy would forbid edit by AF-managers. We could ask the community to fix the filter themselves, but if after say a month no-one replied and that specific filter being broken is blocking us to go on, then the change should be made all the same. --Daimona Eaytoy (talk) 17:16, 8 March 2019 (UTC)[reply]
  • Support Strong support Znotch190711 (talk) 10:34, 31 July 2019 (UTC)[reply]
  • @Huji, Ajraddatz, -revi, MusikAnimal, Nemo bis, Vogone, Aldnonymous, and Znotch190711: Boldly pinging all participants. It's been a year since this proposal was opened, and there's been almost no progress since then. Now and then we're still having the need to manually fix AFs across WMF wikis (e.g. T230263), so this group would really be of help. Any thoughts about how we can move on? --Daimona Eaytoy (talk) 12:18, 10 August 2019 (UTC)[reply]
    I wonder if we would get more traction if one of the more senior developers would support this? Maybe User:Brion VIBBER or User:Tim Starling would like to opine on this? Huji (talk) 19:59, 10 August 2019 (UTC)[reply]
    I went ahead and added a link to the RFC in Tech News, as proposed above. It can definitely be improved and/or moved to another section, but that's something to start with. Of note, re-reading this discussion I see that opt-out has been considered as a possibility. Well, personally I strongly disagree with that. If the development is blocked by the need to edit some filters on an opted-out wiki, that's not good. Especially if the wiki in question is small and/or has few active admins and/or opted out of GS, or anyway if we'll have to wait too much time for broken filters to be fixed. Personally, I'd accept an opt-out only for very good reason. In other words, if we don't want to completely prevent opt-out, it should at least be very, very, very discouraged. And I don't see any good reason to opt-out of a group that will only make technical changes. --Daimona Eaytoy (talk) 11:23, 12 August 2019 (UTC)[reply]
    Thanks for putting this in Tech News. Hopefully that will attract the attention it needs. I agree opt-out makes little sense. Any apprehension about introducing this user group should be alleviated by the fact it will rarely be granted. Basically what has been said above -- this is about technical assistance and maintenance, not making any sort of policy or community-based filter changes, even to deal with obvious abuse (leave that to the stewards, should the local community be unable to handle it). MusikAnimal talk 20:57, 12 August 2019 (UTC)[reply]
    FWIW, I also don't like the opt-out idea. I do, however, support an alternative approach in which certain wikis (i.e. large wikis with many active admins) would specify a page in which we should announce/request the desired filter modifications (or if the change cannot be explain publicly, we will invite admins to join a private Phabricator task) and allow the local admins to take it over. We can have a service-level agreement whereby if the desired change is not completed by a local admin within 14 days, we would proceed with it. This way, those wikis who want to be in control will have an opportunity to do so, so long as it doesn't tremendously delay our deployment processes. Lastly, we would reserve the right to bypass this courtesy process in times of emergency (of which, we should have none, because we are pretty good at foreseeing these types of changes). As for where to keep the list of these "courtesy-call" wikis, I don't think we need anything fancy; we can literally keep it on Phabricator. Huji (talk) 14:31, 16 August 2019 (UTC)[reply]
    I would say it is not so much about opt-out being a good or bad idea, it's more about local projects having autonomy on their own policies. If we reject opt-outs for this group we can of course do that, but there would be nothing preventing projects rejecting this user group from simply blocking users who make use of this permission on their wiki. Allowing opt-out is less confrontational, and would show users in the new group where their help is not appreciated (hopefully nowhere). Of course opt-outs should not be encouraged. --Vogone (talk) 12:36, 18 August 2019 (UTC)[reply]
    I hope we won't have situations like that. But as I said above, opt-outs are fine as long as they're *really* discouraged. Which is something everyone here seems to agree with, I believe. So we can proceed that way. --Daimona Eaytoy (talk) 07:39, 19 August 2019 (UTC)[reply]
  • Makes sense. Our main venue for communicating abuse filter changes is Tech News, but while Tech News is a good way to seed the information in the local communities ("Hey, what happened to this filter?" "Oh, there was a change, I read about it here"), it doesn't reach everyone. There's a clear use case. I also don't think opting out makes much sense, as long as we're careful about defining the situations when the user right may be used. /Julle (talk) 01:18, 16 August 2019 (UTC)[reply]
  • Support. I think the benefits of this new group clearly outweigh any disadvantages/risks. We should go ahead with the proposal; if it needs tweaks after it begins, that's fine too. Regarding allowing a wiki to opt-out, I don't thin that is a good idea, though I think it would be find to adopt a position something like "Wikis that have a good record of correcting abuse filter problems on their own, or have indicated a strong preference for fixing such problems themselves, should be given notification and reasonable time to make fixes before the global group takes action." John Broughton (talk) 16:20, 19 August 2019 (UTC)[reply]
  • Support (per John Broughton). --Patriccck (talk) 14:01, 20 August 2019 (UTC)[reply]
  • Oppose There are too many groups already, they already made interface administrators apply to, not just all wmf wikis but to ALL WIKIS RUNNING MEDIAWIKI. I think we need LESS groups and not more, what's next, "title blacklist log viewers"? Computer Fizz (talk) 06:12, 21 August 2019 (UTC)[reply]
    @Computer Fizz: Could you please constructively explain why this group is a bad idea in your opinion, instead of being unnecessarily snarky?
    That said, I believe there's a general consensus about the creation of this group, mostly without disagreements. I honestly don't know how this RFC is supposed to proceed: do we have to open a voting phase? And maybe summarize the agreed requirements and scope of the group? --Daimona Eaytoy (talk) 08:17, 21 August 2019 (UTC)[reply]
Well for Talk:IP_Editing:_Privacy_Enhancement_and_Abuse_Mitigation almost everyone on the page was opposing it with only two supporters, yet it's getting added anyway. So it is pretty reasonable to hold the conclusion that wmf is not as consensus-driven as they say they are.
And about this group being a bad idea, i explained why above. Maybe what would be good, is to add a feature that lets you directly assign permissions to members, instead of permissions to groups and groups to members. that would remove the need for about 2/3rds of all existing groups. Computer Fizz (talk) 10:32, 21 August 2019 (UTC)[reply]
None of your arguments relate to the merits of the proposed global group. This is not a proposal by the WMF (in fact they have nothing to do with proposing this, and will have nothing to do with implementing it), nor will this add another group to the list you see at Special:ListGroupRights. – Ajraddatz (talk) 10:57, 21 August 2019 (UTC)[reply]
  • Oppose if the usergroup will affect all wikis. Support if it only affects global-sysop wikis. 50.5.224.171 23:05, 21 August 2019 (UTC)[reply]
    I believe it was told several times along the whole discussion that this group will affect all wikis and opt-outs will be either not allowed or highly discouraged. If it were to only affect GS wikis we wouldn't need this new group at all, GSs can already edit abuse filters. And the fact that it has to affect most (or all) wikis should also be pretty obvious looking at how this group will be used (i.e. maintenance in case of backend changes). --Daimona Eaytoy (talk) 07:55, 22 August 2019 (UTC)[reply]
  • Support Support – I support the creation of a global group of "AbuseFilter managers" as described by Daimona above. I do not think it should have an opt-out. Instead, any controversial changes should be made explicitly out-of-scope by policy (similar to Global interface admins). --Krinkle (talk) 18:21, 24 August 2019 (UTC)[reply]
  • Support Support - I've been helping with abuse filters on phabricator, and I've seen how the ability for trusted developers to implement on-wiki changes would be helpful. I agree that there needs to be a high threshold though. I am neutral about the ability of a wiki to opt out --DannyS712 (talk) 08:48, 27 August 2019 (UTC)[reply]
  • Support Support - A real need is present here. I strongly support any form of implementation of such group. --Framawiki (talk) 16:49, 1 September 2019 (UTC)[reply]
  • Support Support with a prohibition on opt outs, no preference on temporary-ness. JoJo Eumerus mobile (talk) 12:33, 3 September 2019 (UTC)[reply]
    Reaffirming this in light of TonyBallioni's statement below. Given how highly technical abuse filters are, I think that in this case the technical arguments against having an opt out (might make maintenance more difficult) carry more weight than the social ones in favour of opt outs. Also, at least on enWikipedia abuse filters are sort of a niche environment that does not get much scrutiny by the wider community (on en:WP:EFN there are only a few regulars), so I would not consider any negative here "massive". With reference to the "hat collector" argument: The interface editor user right has attracted some hat collectors and the like in the past but the approval process has mostly filtered them out and the system has not blown up. Jo-Jo Eumerus (talk, contributions) 15:49, 7 September 2019 (UTC)[reply]
  • Strong oppose Sorry, but the type of people who are trusted for global rights are not the type of people who typically are trusted on large wikis, which is a huge issue as this permission would allow people to create and edit filters on the projects that serve most of our readers and editors without even being known to the local communities. This also would have the side issue of giving people accidental access to information that has been suppressed on wikis where they couldn’t pass an RfA, much less get appointed as an Oversighter, in their wildest dreams, as filter logs tend to be forgotten by oversighters until someone points them out. This is a major privacy risk, and sorry, I don’t trust the person who is really good at technology but who doesn’t know the culture of a major project to see that stuff.

    From a philosophical standpoint, I have been arguing for the last two years that the trend towards globalizing user rights and creating a clique of users who know each other on meta and can impact local communities without anyone knowing who they are is a bad thing. Thankfully, this trend has reversed and we are now starting to value the work of people who actually contribute positively to projects that the general public visits, whether they be small or large.

    This permission would be a massive step backwards towards the direction meta was heading two years ago: a place where people who have no connection to content projects go to get hats and congratulate themselves on their work while having no meaningful impact on anything. That would be a massive negative for everyone, so I must oppose this. TonyBallioni (talk) 02:13, 7 September 2019 (UTC)[reply]

    Just want to note that global abuse filter helpers (Abuse filter helpers) already have the same "accidental access to information that has been suppressed on wikis where they couldn’t pass an RfA, much less get appointed as an Oversighter, in their wildest dreams" - the only difference between this group and the current abuse filter helper group is the ability to actually affect filters; the global ability to view such information about filters is already available. Since the bar for granting this global permission would definitely be higher than the bar for Abuse filter helpers, I don't see the access to information as a factor here --DannyS712 (talk) 03:23, 7 September 2019 (UTC)[reply]
    I'm aware. No need to lecture. The difference is, in case you don't know, that this group allows people to edit local filters on large wikis without having the trust of the local community. As has already been pointed out, global sysop makes this pointless for small wikis, so the only reason to have it would be for large wikis. Additionally, no, I think this would functionally be easier to get than the supposedly lesser abuse filter helper right: tech people who don't care about actually reverting vandalism would canvass their friends to support them (allowed on meta), which is a problem we don't have with the helper right.

    To be more blunt, it would allow people who are not trusted on local projects for good reason but who have effectively created new personas on meta to go around their local communities in order to get something. I see absolutely no benefit to that unless you're a hat collector. TonyBallioni (talk) 03:55, 7 September 2019 (UTC)[reply]

    @TonyBallioni: I apologize for being repetitive, but I want to make sure to emphasize one thing: this group would edit abuse filters only in case of backend changes. For instance, T156096 or T153251. They would not be allowed to make any other kind of changes, let alone anything that would require community consensus. I wanted to make sure this is clear enough: you opened your statement with "would allow people to create and edit filters" but that's not true, because the creation of new filters is out of scope. Viewing private abuse log entries is also not specifical to this group per Danny, and the very specific goal of this group is to make changes that do not need consensus. --Daimona Eaytoy (talk) 08:52, 7 September 2019 (UTC)[reply]
    @Daimona Eaytoy: to help enforce such a requirement that no new filters be created, I filed phab:T232243 --DannyS712 (talk) 09:08, 7 September 2019 (UTC)[reply]
    I don’t think the social requirement of “no major changes” could be enforced, and that regardless of policy, which likely wouldn’t exist as we try not to have specific global policies, people would make the changes you say would never be made under IAR or some similar logic. TonyBallioni (talk) 14:33, 7 September 2019 (UTC)[reply]
    @TonyBallioni: Yes, it couldn't be enforced, I'm totally aware of that. However, from your words, I cannot understand how this wouldn't be similar to other global groups. I may be wrong, but to me, this sounds a little pessimistic. Something like "we can trust no-one" - and I don't usually see this on-wiki, where lots of things are built on trust. --Daimona Eaytoy (talk) 15:30, 7 September 2019 (UTC)[reply]
  • Oppose I was worried about some of the issues Tony brought up in terms of large wikis but saw editors I respect vote in favor so figured I was maybe off base. But given his oppose, I feel comfortable stating that at least on large wikis the idea of relatively anonymous global users having unfettered access to the edit filters is of concern to me. Best, Barkeep49 (talk) 02:19, 7 September 2019 (UTC)[reply]
  • Perhaps roll into another user group like Stewards While I do see the value of having a global abuse filter (for stuff that is technically vandalism like page blanking or adding repeating characters, without regards to what is offensive in a specific language), and perhaps smaller wikis aren't as well-equipped to handle such things, it seems like a niche enough area to not require a whole user group and the concerns brought up by Tony are important. Stewards are already trusted to have global rights and to have a presence on smaller wikis, so they should already know the customs and mores of Meta and are thus a natural choice of user groups to hold such power, but feel free to think of another usergroup that can handle this. As for larger wikis, perhaps local sysops or filter helpers can help with the global filter as it applies to a given wiki (if that's not already the case). John M Wolfson (talk) 03:01, 7 September 2019 (UTC)[reply]
    @John M Wolfson: I'd like to invite you to read my reply to Tony above. As I stated there, normal filter edits are not allowed. This group wouldn't have the authority to do anything that you mentioned, like fighting vandalism of any kind. They would mostly make rote changes which do not alter the behaviour of a filter, and do not need consensus; they'll just serve to ensure that no on-wiki filter will break due to backend changes. At this point, given that the discussion has started to grow, I wonder whether we should update the opening with more detailed info emerged during the talk.--Daimona Eaytoy (talk) 08:52, 7 September 2019 (UTC)[reply]
    @Daimona Eaytoy: You've mentioned "backend changes" several times here. It seems to be the major reason for creating this user group. So I would like to know how often that backend changes that'd require the action of this yet-to-be created group happen; twice a year? ten times? (this includes probability of it occurring; I know we cannot know with certainty.) I'd like to note we already have a global group with total global access that can deal with any emergency "backend changes" that only happen with manifest rarity. I've not made up my mind to oppose or support this as of now, but it surely looks this group is just unnecessary and as per as security/least-access principle is concerned, it's totally needless.
    Currently, the only benefit of this user-group is to provide (needless, in my view) convenience to few folks who would be waiting a whole year for "backend changes" to break Abuse Filter extension before they could use their user right to fix it on the few places where it's not already fixed. –Ammarpad (talk) 09:59, 7 September 2019 (UTC)[reply]
    @Ammarpad: Yes, IMHO it's the *only* reason to create it. I cannot really provide an estimate, but that's probably in the order of fewer than 5 times a year. Right now we have several tasks where we'd need to change filters across the wikis. There's actually a dedicated column ("Requiring manual fix of filters in production") in the AbuseFilter workboard on phabricator, so you can see exactly where we'd need to act right now. Those tasks were accumulated in a relatively long time, so I don't expect that column to have all of those tasks inside in the future. As for the sysadmin group, that sounds like an overkill... I'm also unsure whether non-WMF people can be part of that group, honestly. And yes, it would make things easier by speeding up the whole process a lot. Take for instance T209565#4942689, which was a relatively short list. It took more than two months to have everything fixed in production. I'm scared about what could happen with a list such as T153251#5464352. And for some of these changes, the sooner we get them done, the better it is. For instance, the last one I linked is a necessary step in switching the AbuseFilter to use the new parser. That would decrease the time it takes to run all abuse filters (and thus, also the time to save an edit) by roughly 70%. Do you think it's worth it to have such a changed blocked for months just because there aren't enough active members in small communities to fix affected filters? --Daimona Eaytoy (talk) 10:32, 7 September 2019 (UTC)[reply]
    Noting my concerns above that I don’t think this would work in practice like you’re saying, even if it did it would make this an entirely useless user right that only exists so people can pat themselves on the back for the good work they do, like I suggested in my initial oppose. You’ve managed to convince me that this is an even worse idea than it was before you posted. TonyBallioni (talk) 14:33, 7 September 2019 (UTC)[reply]
    Replied above to the concerns above. I don't deem it "entirely useless", but since you do, I'd like to know: who do you think should do the work of updating filters across all wikis whenever we plan a backend change? Because I don't see it stated in your comment. As for "that only exists so people can pat themselves on the back for the good work they do", I have a single reply in my mind: lol, are we kiddin'? Glad that I've at least been able to convince you about something, but then I'd like to receive some constructive criticism; for instance, I'm eager to hear what alternative solution you'd propose. I'm certainly open to alternatives, but I'm not seeing any in the comment above. --Daimona Eaytoy (talk) 15:30, 7 September 2019 (UTC)[reply]
    re: if I’m kidding: No. I’m 100% serious in everything I’ve said. There is a simple solution for your concerns on small wikis: get global sysop. It’s hardly a big deal to get. There’s a simple solution for large wikis with large sysop populations: get a local EFM to make the change. For 5 times a year max, this is hardly too much to ask. The negatives here are very large and the positives based on what you say are basically non-existent, since no one except people who know about this have even noticed it. TonyBallioni (talk) 17:16, 7 September 2019 (UTC)[reply]
    @TonyBallioni: Well, nice to hear you're not kidding. Although "people can pat themselves on the back for the good work they do" seems to be an unnecessarily detrimental sentence. Anyway: I'm afraid to say that your global solution doesn't work. User:Huji requested it for this very specific reason roughly a year ago. Sure, he can now make this kind of changes to several wikis, but not each of them. Non-GS wikis aren't necessarily small wikis. Take mrwiki: there are few sysops (some are also inactive), and the last time I asked them to fix a filter it took some time, see discussion. Hence, while GS might work for some wikis, it won't work for all. And, instead, I'd like to have something which works everywhere. As for big wikis: I'm not worried about them. I'm sure that this kind of tech changes would be made by local EFMs in a matter of a single day. We could also post lists of filters to be fixed on Tech News (like we do now), and have members of the proposed group kick in only after a week or so. Yes, 5 times a year wouldn't be much, that's true. But for those 5 times, we need a reliable way to get the work done on all wikis in a reasonable time. --Daimona Eaytoy (talk) 17:31, 7 September 2019 (UTC)[reply]
    It seems like you've described how you do it now, which seems to me to be a reliable way to do it in a reasonable time. I also don't think criticizing the culture that has evolved around global rights and cross-wiki tech is detrimental. We need people to help, but we also need people who are connected to local communities and care about projects beyond the abstract. Creating and expanding global rights further, without a significant reason to do so, does create a backslapping culture where people do work that they feel important but does not help local projects. The way of combatting this is to either restrict global rights to the GS wikiset, create an opt-in outside of that wikiset, or not create them at all. I would be fine with restricting it to GS wikis and allowing wikis outside of it to opt-in, but as you seem to not even be fine with an opt-out, much less an opt-in, I think this would be a huge negative for all WMF projects that isn't really needed. TonyBallioni (talk) 18:08, 7 September 2019 (UTC)[reply]
    Yes, that's what we've been doing. But as I said, it's not always reliable, especially for communities with few active admins. Anyway, we'll see the actual numbers this week. I honestly don't know what's the culture that's been growing about g-rights. Sure, there are ways to help people more, e.g. global sysops, I won't question it. But I don't either think that's a good reason to avoid creating new groups. The way I see it, everyone does what they can, and any help is appreciated - at least, that's my philosophy as a user. Or in other words, little help is better than no help. As for the opt-in: throughout this discussion, the ideas were to either forbid opt-out or only allow it for valid reasons, in virtue of the non-controversial nature of the changes. We could explore alternatives, for instance: 1-as I said above, we could make members of this group only kick in after a given time (1w) to do what's left; 2-(which could go together with 1) make this right *very* temporary. For instance, grant it only when needed and only for a very limited time (max 1w); 3-Start with having only big wikis opted-out; other wikis may opt-out if they're active enough to fix filters in a reasonable time, and big wikis may be opted-in if they fail to do the same. But restricting it to GS wikis and allowing opt-ins sounds like a long and painful process, which could waste a lot of time and end up with just having a duplicate of the GS group. --Daimona Eaytoy (talk) 15:08, 8 September 2019 (UTC)[reply]
  • Oppose without opt-out per TonyBallioni. Neutral with opt-out. · · · Peter (Southwood) (talk): 06:03, 7 September 2019 (UTC)[reply]
  • Oppose as written. If used only for technical changes required by backend changes, it may be OK, but, if one of these people makes a substantive change in a filter, without local approval or another (local or global) group membership authorizing the change, the bit must be removed quickly, especially since violations cannot be detected by software. No opinion on opt-out if the changes are really necessary to prevent filter failure, although notice should be given, regardless, in the form filter #nnn needs to be changed, without identifying it by name or subject. — Arthur Rubin T C (en: U, T) 17:47, 15 October 2019 (UTC)[reply]
    Comment Comment It's clear from the above discussion that the edits from this group will be strictly for (1) technical and (2) clearly uncontroversial changes. Something like changing page_namespace in [12, 13] to equals_to_any(page_namespace, 12, 13) because page_namespace in [12, 13] is actually doing string(page_namespace) in "12\n13\n", meaning when page_namespace is 1, 2, or 3, the filter will be incorrectly triggered as well. --Nullzero (talk) 20:01, 27 November 2019 (UTC)[reply]
  • Comment Comment I think we can refer to GIE policy: This permission is enabled on every public Wikimedia wiki that shares access via CentralAuth and SUL, and is only to be used for non-controversial maintenance, or by request of the local community.. --Catherine Laurence discussion 03:57, 19 October 2019 (UTC)[reply]
  • Oppose Oppose As a whole, I think there is too much difference between the proposal on one hand and my thoughts and the risks involved on the other.

Changing the majority of the abusefilter rules or disabling filters are not entirely uncontriversial changes in my book, even though the filter is faulty, depending on the exact action used for each filter. I agree with posting an notice beforehand, but 4 days is not ok (its more of an top10 wikipedias waiting period, really). 2 weeks is the accepted practise on meta for requests and it should also apply to this group.

Any member of the group should report any intrusions of their account and be temporarily banned while the issue is resolved. This group would have rights to creating global abuse filters with blocking actions, since meta allows that (phab:T54681). That is mainly an fault of the permission system, as that was intended to be changed for meta locally, but never intended for the global abuse filter. If I remember correctly there are 12 (wmf) wikis in total with the rights to create banning abuse filters.

I'm not entirely sold on the idea that an member can figure out from the code alone what an severely broken filter was supposed to do. Since the banning abuse filters would have the greatest effect, I think there should be an page on banning practises for the wikis with banning abuse filters, just like there is Rename practices.--Snaevar (talk) 15:01, 23 November 2019 (UTC)[reply]

  • Comment Comment
    1. I also agree with posting a notice beforehand, but two weeks is an absurdly long time for uncontroversial technical fixes. Fixing a filter is not something that should involve the entire community, especially when the filter is private. People who should be involved are only administrators and edit filter managers (if this group exists in that wiki), especially the ones that edited the filter in the past. Therefore, I agree with User:Huji's proposed 4 days. Note that in order to roll out bug fixes or new features of the AbuseFilter extension, it is sometimes necessary to fix faulty filters in WMF projects first. Blocking the extension developers for two weeks is unreasonable in my opinion.
    2. From the above discussion, I understand that this group is not allowed to create a new filter, let alone a filter that can block. This group will only be allowed to modify existing filters for only one purpose: uncontroversial technical fixes.
    3. I agree that it might not be possible for some filters to figure out what their originally intended semantics should be. But in many cases the semantics is clear. For instance, it is clear that page_namespace in [12, 13] is meant to match changes on namespace 12 and 13. As the pattern is in fact incorrect (it would match changes on namespace 1, 2, and 3 as well), users in this proposed group should be able to uncontroversially change the pattern to equals_to_any(page_namespace, 12, 13), which fixes the problem (but again, only when local sysops are unresponsive for 4 days). On the other hand, when the originally intended semantics is not clear, users in this proposed group should not make an edit, but instead either (1) continue to wait for clarification from local sysops; or (2) disabling the filter. The latter action should be employed very sparingly and only when it is really necessary. E.g., if it is clear that the filter is actively causing a large scale harm (e.g., disallowing all edits) or if it's blocking a very high priority bug fix deployment. --Nullzero (talk) 20:25, 27 November 2019 (UTC)[reply]
  • Support Strong support with the following conditions:
    1. To reaffirm the discussion above, the edit should strictly be uncontroversial technical fixes.
    2. A request to edit/disable a filter should be posted to a noticeboard first and it should mention everyone that edits the filter in the past.
    3. The filter edit is only allowed after 4 days of no response from local admins/edit filter managers (if the group exists in that wiki), or 7 days of no action (this is the same condition that User:Huji proposed).
    4. Only allow users in the proposed group to modify and disable, not create or enable.
    5. To edit a filter, the users in the proposed group must be able to figure out the intended semantics of the code fragment that s/he is going to edit.
    6. The modification must preserve the intended semantics. That is, do not change the meaning of the filter.
    7. When a faulty filter is discovered but it is not clear what the fix should be, the users in the proposed group should not make an edit. Instead, either
      1. wait for clarification from local sysops, or
      2. disable the filter. This action should be employed very sparingly and only when necessary. E.g., if it is clear that the filter is harmful at large-scale or if it's blocking a very high priority bug fix deployment. --Nullzero (talk) 20:56, 27 November 2019 (UTC)[reply]