Requests for Comment/Meta usergroups reform

In 2020, the autopatrolled and patroller groups were split through community vote in an RfC, resulting in two distinct limited-permissions roles alongside the already-existing rollbacker. With 3 years of history to review, it's clear that the three limited-rights roles (autopatrolled, patroller and rollbacker) on Meta today are not meeting the project's needs.

These groups are frequently requested by inexperienced users (sometimes as a matter of hat collection) without adequate understanding or intention to use the permissions effectively and positively contribute to the Meta community. While these permissions *can* be useful, they should be awarded based on discretion and intent, not as titles that users are pursuing because they think they "deserve" it.

Determining who should have these rights without any established criteria can also be a challenge -- If one user requests rollbacker, why not give it to everyone else? This RfC will propose changes to the current system to help codify criteria and consolidate duplicative roles into ones more helpful to the community.

Thank you to NotAracham for his assistance with drafting.

Note: This request applies to Meta only.

Proposed by:

Proposal 1 (Elimination of rollbacker)

 * The rollbacker group is eliminated and  permissions are given to the Patroller group

Rationale: Rollbacker only contains one right ('rollback'). Vandalism is rare on Meta and there's few ways users can really prove that they need this role. There are few dangers to give rollback to Patrollers, as worst case rollback can easily be rolled back with a Javascript script. There's no need to have this extra role on Meta and have users constantly request it after helping once or twice to revert vandalism. All rollbackers are currently patrollers so in terms of a transition wouldn't make any difference currently and also serves as proof that it's not needed as a separate role.

Support (1)

 * 1)  Per rationale provided. All rollbackers are currently patrollers and it's clear that there's simply not enough vandalism on Meta to justify having a separate group in either case. Alternatives such as Twinkle also demonstrate that there's no need to have such a minor group that is separately requested and for which it is very difficult to decide whether someone needs it or not. Reception123 (talk) ( C ) 05:48, 2 June 2023 (UTC)
 * 2)  Since vandalism rarely occurs at Meta, I do not believe that permissions specific to dealing with vandalism are necessary at this time. The Patroller flag is only granted to users who understand Meta's policies, so it is unlikely that rollback permissions will be used inappropriately. Incidentally, this is what is actually done on Wikimedia-Metawiki. --1108-Kiju /Talk  07:52, 2 June 2023 (UTC)
 * 3)  I agree with the rationale that has been presented and do not think there is a usefulness to this role being separate and granted to individual users. If misuse can easily be rolled back with the use of a script I do not see an issue in being more trustworthy with this permission instead of it being necessary to assign it individually and go through a "process" for such a minimal right. If it somehow transpires that it is frequently misused this change can also naturally be reversed so there is little harm in having a go at this change. --DeeM28 (talk) 14:36, 2 June 2023 (UTC)

Draft-phase Comments (1)

 * 1) Conditionally  this as Proposal 4 is currently written. If the   and autopatrolled groups are retained as separate user groups, with different purposes and "barriers to entry," as it were, then I would conditionally  combining   into , but we would also need to inform some guidelines for revocation, the guidelines for which I drafted and continue to be used by Meta administrators. Dmehus (talk) 16:09, 21 May 2023 (UTC)
 * 2)   Can the rights be tiered?  Continue to have 3 groups, Autopatrolled, Patroller, Rollbacker, such that Autopatrolled group has only the Autopatrolled right, the Patroller group has the Patroller and Autopatrolled rights, and the Rollbacker has all 3 rights? ---Imamy (talk) 16:33, 21 May 2023 (UTC)
 * Imamy, we could certainly do that, and that is sort of the idea already with the  group. We could expand the   group to include certain other permissions, perhaps the   and   permissions, for example. If   includes additional user rights like that, given that the   contains only user right, there would arguably be little need or purpose to retain that user group separately. But certainly, tiered user groups, as you seem to be asking about and potentially propose, would help to eliminate the eliminate the collection of multiple hats, which seems to be the main impetus behind this RfC. Dmehus (talk) 16:38, 21 May 2023 (UTC)
 * 1) . Why would we remove it when there are qualified users that could use the rights to help the wiki. No reason to remove the group. Globe - (Talk • Contributions • CA) 12:52, 24 May 2023 (UTC)

Proposal 2 (Elimination of autopatrolled)

 * The autopatrolled group is eliminated and merged with the patroller group.

Users who have Autopatrolled rights but aren't already Patrollers will not automatically receive the combined Patroller role. Meta Administrators will use discretion during the elimination process as to whether upgraded permissions are warranted and appropriate.

Rationale: Some have argued for this and believe that the function of patrolling isn't really that "high risk" or important to deserve its own group.

Oppose (2)

 * 1)  I believe keeping patroller and autopatrolled separated helps local sysops to maintain a way of giving out rights based on level of trust and need, we may not need to patrol a user’s edits, but that same user may not be fully trusted to patrol another’s edits either. Zppix (Meta &#124; talk to me) 12:57, 2 June 2023 (UTC)

Draft-phase Comments (2)

 * 1)  It is interesting to me that the proposer themselves in 2020 suggested that "it doesn't really make sense for the "Autopatrollers" group to also be able to patrol others edits as that defeats the purpose of its name.". While I cannot say that I would be decidedly against this proposal and while I do not particularly appreciate lengthy debates regarding names rather than substance I must agree with the proposer's original assertion and say that it may be preferable to search for another name for this new user group that would combine two or three current existing groups. I would suggest that in case all three permissions are combined into one group the new group is simply named patroller as patroller can encompass autopatroller but autopatroller hardly can encompass patroller. --DeeM28 (talk) 14:30, 21 May 2023 (UTC)
 * 2)  I would not be in favour of this proposed combination, for several reasons. For one thing, the   is meant to be a low-barrier user group given to users who have demonstrated little need to have their edits patrolled and, so, to reduce the backlog of patrollers and administrators. Patrolling, on the other hand, requires knowledge and awareness of Meta's policies and conventions, which take some time to learn, as well good judgment and common sense. In short, one user right reduces the patrol backlog, while the other assists Meta administrators in patrolling the unpatrolled edits queue (and there are still a lot of those). Unless we're proposing to significantly lower the barrier for   to something like , where it's granted in an automatic and systemic way based on a certain number of edits, which I wouldn't be in favour of, or significantly increase the number of Meta administrators, which I also do not believe is necessarily the best idea, this will actually have the opposite effect of increasing the unpatrolled edits queue, to an even smaller number of volunteers, most of whom already wear multiple hats. As well, I would also just note the utility of the separate   group in several ways. Firstly, it's user group that can be revoked, as RhinosF1 did with me, but also one that can be re-added, or added, and help to promote additional volunteerism, such as my election as Meta administrator two months later and, as steward, roughly five months later. A similar story unfolded when I granted Agent Isai that user group a year later. He had been mainly lurking in our IRC channels only, not being involved on-wiki until that act. His edits on-wiki were few at the time, so it may not necessarily have been appropriate to give him   right away, though in his case, I'm fairly certain I recruited him for that role within a few weeks. We could potentially combine the   group into the   group; that is something I would be more warm to now, given my comments here. Dmehus (talk) 15:47, 21 May 2023 (UTC)

Proposal 3 (Appointment & Revocation criteria)
OR
 * Meta administrators will generally grant autopatrolled on request if a user:
 * has been a user on Meta for at least 30 days and
 * has made at least 50 edits (excluding edits to their own userpage or other minor edits)
 * has been a user on Meta for at least 15 days and
 * has made at least 150 edits (excluding edits to their own userpage or other minor edits)

'''A Meta administrator may use their discretion and refuse to grant autopatrolled even if the criteria is met and may also use their discretion in deciding whether to revoke autopatrolled. Reasons for revocation or refusal may include (but are not limited to):'''
 * Violations of Meta or global policies
 * User edits frequently needing correction or removal by other users
 * Demonstrating a lack of understanding about how Meta functions

Rationale: As mentioned in the preamble, this group is frequently requested by inexperienced users (sometimes as a matter of hat collection) without adequate understanding or intention to use the permissions effectively and positively contribute to the Meta community.

This proposal establishes specifics that don't exist publicly today around grant and removal of the Autopatrolled group while still giving Meta administrators significant discretion in their decisions.

Note: If Proposal 2 is successful, any references to Autopatrolled are replaced with Patrollers and instead update the Appointment and Revocation criteria for the Patroller group.

Support (3)

 * 1)  This proposal preserves Administrator discretion while also giving some more clear criteria for users as otherwise it's very unclear who gets the rights and who doesn't. It also makes it easier for administrators to make that determination and prevents users from requesting the right early. Reception123 (talk) ( C ) 05:48, 2 June 2023 (UTC)

Oppose (3)

 * 1)  I believe admin discretion should remain status quo, as sometimes certain situations may dictate that a right may be given at different points, and considering the rights this RfC are about aren't fairly advanced rights, I don’t believe we need criteria set in stone. Zppix (Meta &#124; talk to me) 13:00, 2 June 2023 (UTC)
 * Admin discretion isn't removed and this isn't criteria that is set in stone, as it says "will generally grant". The idea behind it is mostly to make clear that as a general rule users shoul fumfill this criteria but there may be exceptional situations and admin discretion can still be used. Similarly, even people who meet it may not be approved. Reception123 (talk) ( C ) 13:21, 2 June 2023 (UTC)

Draft-phase Comments (3)

 * Similar to my comments elsewhere, firstly, I would not be favour of combining the  and   user groups because they serve different purposes and have different competency standards and requirements. Secondly, this seems too prescriptive and limiting, which combined with my concerns with respect to the revocation criteria, may end up making it much "easier" to obtain a group, with expanded permissions, and more difficult to revoke. In short, the opposite of what one intended. While systemic edits can help to serve as a baseline, they should never be a replacement for granting of the group. Similarly, there are also cases where users demonstrate competency with fewer numbers of prescribed edits, and I believe Spike has spoken to that in that the past (perhaps others have as well). In short, activity != competency and, so, while I wouldn't necessarily be opposed to having systemic edits inform the baseline of a proposed guideline, as written, this does not allow that, and it's also written as to codify something into policy, when I think the existing community-endorsed guideline has worked, and will continue to work, best. Dmehus (talk) 16:04, 21 May 2023 (UTC)
 * The reason why it says "will generally grant" is to allow for a discretion to exist. The main idea is to prevent users from constantly asking for autopatrolled and to be able to refer them to the more strict criteria in most cases. Exceptions could potentially made where necessary. Reception123 (talk) ( C ) 18:39, 21 May 2023 (UTC)

Comments (3 - related to previous separate proposal)
 * This is already the status quo. This looks a bit like creating a policy for the sake of policy. This guideline has already received the community's endorsement through at least one CN discussion and perhaps an RfC comment as well. As well, I'm a bit concerned by trying to codifying it in such as a way as to be more prescriptive, to having violated Meta's policies or Miraheze's global policies may unduly hamstring or handcuff some Meta administrators' ability to use that generally good judgment and common sense and not revoke the permission when it might be warranted (i.e., a user who has backtracked and again displayed CIR tendencies). It's deliberately kept vague, principally because we've elected Meta administrators to use that judgment, and I would rather continue to have this be a guideline, which we can evolve, as needed, by involving the community in subsequent discussions on the user group's companion talk page, but necessarily via an RfC for the sake of having an RfC. Dmehus (talk) 15:56, 21 May 2023 (UTC)
 * It is certainly the status quo but it just makes it more clear to users why they would be removed so they don't act surprised or think that a particular removal is unfair. If we add criteria for approval it makes sense to also make a more explicit mention of removal. Reception123 (talk) ( C ) 15:19, 27 May 2023 (UTC)

Proposal 3.1 (Transition)

 * Autopatrolled users who do not meet the requirements set out in Proposal 3 will be revoked, with limited exceptions at Meta Administrator discretion.

Note: If Proposal 2 is successful, references to Autopatrolled are replaced with Patrollers and apply to this role instead.

Support (3.1)

 * 1)  Makes sense. Reception123 (talk) ( C ) 05:48, 2 June 2023 (UTC)
 * 2) Conditional  I support this, under the impression that if they do not meet criteria it will be a consensus of local sysops, and/or crats that determine that the right(s) would be removed, not a decision by a single person. Zppix (Meta &#124; talk to me) 13:03, 2 June 2023 (UTC)

Draft-phase Comments (3.1)

 * As with below, this is already the status quo, and when I was a administrator, I have already supported removing  from long inactive Meta users. As with most things on Meta and Miraheze, there should be necessity to the user group. A user who has not edited on Meta in over a year, for example, has little need to retain the user group. In short, the existing guideline, and the community's endorsement of that guideline, not to mention the community's trusting their judgment, already provide the support necessary to remove this group on a discretionary basis. Dmehus (talk) 16:12, 21 May 2023 (UTC)