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

Note: If Proposal 4 is successful, this proposal is superseded

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.

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.1 (Appointment Criteria for autopatrolled)
1. OR 2.
 * Meta administrators will generally grant the autopatrolled right 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)

Comments (2.1)

 * 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)

Proposal 2.2 (Revocation Criteria & Discretion for autopatrolled)

 * 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. Examples of reasons for this would be: violating Meta or global policies, their edits having to be frequently undone by other users, demonstrating a lack of understanding about how Meta functions.

Comments (2.2)

 * 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 (Transition)

 * All autopatrolled users who do not meet the requirements set out in Proposal 2.1 will be revoked.

Comments (3)

 * 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)

Proposal 4 (Elimination of autopatroller)

 * The autopatroller group is eliminated and the patroller group will be the only group responsible for patrolling edits.

Support eliminating autopatroller (as well as the inclusion of 'rollbacker' in the new patroller group)
(Note: The effect of this is that there will be a single group remaining - "patroller")

Support eliminating autopatroller (but not the inclusion of 'rollbacker' in the new patroller group)
(Note: The effect of this is that there will be two groups remaining - 'rollbacker' and 'patroller')

Oppose
(Note: The effect of this will be that either all three groups remain or rollbacker is eliminated if you also supported Proposal 1)

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.

Comments

 * 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)