Open main menu

Requests for comment/Creating abusefilter-manager global group

Dialog-information on.svgThis is a subpage; for more information, see the Requests for comments page.

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 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.



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.


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 itemsEdit

  • 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


  • 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)
    Which "other types of edits" are you talking about? Huji (talk) 18:45, 13 August 2018 (UTC)
    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)
    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)
  • 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)
  • 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)
    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)
    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)
    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)
    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)
    @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)
    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)
  • 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)
  • 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)
    "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)
    @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)
    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)
    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)
  • 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)
    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)
  strong Znotch190711 (talk) 10:34, 31 July 2019 (UTC)
  • @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)
    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)
    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)
    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)
    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)
    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)
    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)
  • 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)
  • 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)
  • I think, that it is very good idea. --Patriccck (talk) 14:01, 20 August 2019 (UTC)