Per 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 and 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
|Right||Description||Abusefilter Helpers||Global Sysops||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.
- Discuss the cons and pros of having an opt-out for the newly proposed group
- Decide the name of the new group (abusefilter-manager versus abusefilter-global-editor)
- Determine the set of rights the new group should have
- Create an RfC to gain community consensus for the existence of the group