Requests for comment/Creating abusefilter-manager global group

From Meta, a Wikimedia project coordination wiki
Jump to navigation Jump to search
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.

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 sysop 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.
  • Symbol question.svg 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 [[<tvar|sr-temp>Steward requests/Permissions/Approved temporary</>]]. Requests for renewal can be done by placing a new request on [[<tvar|sr-global>Steward requests/Global permissions#Requests for other global permissions</>|Steward requests/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)
    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)