Requests for Comment/Meta usergroups reform

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

More than seven months have passed since this RfC was initiated. While usually it is highly desirable for an uninvolved Bureaucrat to close RfCs in this case it doesn't seem right to leave an RfC unimplemented for months where an uninvolved Bureaucrat is unfortunately not available for a close. If there are any complaints or concerns about how this RfC was closed they can be made on my talkpage. I will review such complaints and if the user who made them is still not satisfied an uninvolved Bureaucrat can review them and make any changes that may be necessary. Due to the exceptional circumstances, I have asked User:Agent Isai to review this close and he agrees with it. The RfC is closed as follows:

• Proposal 1: Successful.
• Proposal 2: Unsuccessful.
• Proposal 3: Successful.
• Proposal 3.1: Successful.
• Proposal 3.2: Successful. Even though some doubts were expressed, there is still consensus for the proposal passing. Reception123 (talk) (C) 08:09, 14 January 2024 (UTC)

---

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: User:Reception123

Proposal 1 (Elimination of rollbacker)

The rollbacker group is eliminated and rollback 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.  Support 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.  Support 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.  Support 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)
4.  Support My thoughts per points made by other supporters: Sounds like rollbackers right is mainly for combating vandalism for which is unlikely at Meta. Also, giving the right to all Patrollers will eliminate a request for Rollbacker rights. And, also, any mistakes made in rollbacks are reversible.
   ---Imamy (talk) 15:11, 2 June 2023 (UTC)
5.  Support as a sensible consolidation. If a user is trusted to approve edits from others, they should also have sufficient judgement to identify and remove unconstructive or malicious edits. --NotAracham (talk • contribs • global) 17:42, 2 June 2023 (UTC)
6.  Support This would make sense. Patrolling edits is normally used to approve legitimate edits by new users, but the opposite can also be true, and if we're granting them the rights for one, it makes sense to include the other. BrandonWM (talk • contributions • global • rights) 21:09, 6 June 2023 (UTC)
7.  Support Per above. HeartsDo (Talk / Global / Wiki Creator) 09:05, 8 June 2023 (UTC)
8. This is great idea.--MrJaroslavik (talk) 09:55, 8 June 2023 (UTC)
9.  Support It makes sense to me to reduce duplication of effort. The redundancy of the rollbacker role is made all the more obvious by the statement all current rollbackers are patrollers as well. Jph2 (talk) 15:44, 12 June 2023 (UTC)
10.  Support User talk:Anpang 08:43, 10 October 2023 (UTC)

Draft-phase Comments (1)

1. Conditionally  Oppose this as Proposal 4 is currently written. If the patroller and autopatrolled groups are retained as separate user groups, with different purposes and "barriers to entry," as it were, then I would conditionally  Support combining rollback into patroller, 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 patroller group. We could expand the patroller group to include certain other permissions, perhaps the delete and suppressredirect permissions, for example. If patroller includes additional user rights like that, given that the rollbacker 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)

3.  Strong oppose. 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.

Support (2)

1.  Support I must begin by pointing out that I did have a few doubts when I first read this proposal but surprisingly enough the single oppose so far is what convinced me to support this. The reason is that I do not appreciate certain minor groups being awarded solely based on discretion and a subjective "trust". How is an administrator able to know who should get patrolled as opposed to autopatroller and who they can "trust"? It seems to me to be an excessively subjective exercise and mainly depend on whether a user seems "friendly" to administrators rather than it being based on criteria that is related to the actual role. Another aspect that relieved my doubts is that looking into the activity of patrolling it does not seem to be of great importance or help as far as I can see things. Where can a person say that the action of unpatrolled/patrolled pages made a huge difference in administering Meta? If that is the case I may wish to reconsider but I do not think it is. I therefore believe that it is best to cut down the number of minor and discretionary hats and go for a more simple system rather than having so many hats that achieve so little. --DeeM28 (talk) 14:46, 2 June 2023 (UTC)

Oppose (2)

1.  Oppose 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 | talk to me) 12:57, 2 June 2023 (UTC)
2.  Weak oppose Despite helping draft some of the language for this proposal based on community inputs, I'm sufficiently swayed by the arguments from Dmehus in the drafting page. Keeping Autopatrolled as a low-barrier group that helps reduce the number of edits that end up in patroller queue unnecessarily is enough to gain my weak oppose, though I'm open to changing this view if swayed by sufficient argument. --NotAracham (talk • contribs • global) 19:41, 2 June 2023 (UTC)
3.  Oppose I think that we should keep the two groups separated, I often use patroller marks for control new edits for new users on Special:RecentChanges and keep a track of who already see the edit or not. Removing this group would kill this purpose. HeartsDo (Talk / Global / Wiki Creator) 09:05, 8 June 2023 (UTC)
4. Not really. Not all (autopatrolled) users wants/needs/can_have "mark this edit as patrolled" and "rollback this edit" buttons/features. I would support giving autopatrollers "patrolmarks".--MrJaroslavik (talk) 09:55, 8 June 2023 (UTC)
5.  Oppose For the reasons Dmehus gave in comment 2 below. Jph2 (talk) 15:46, 12 June 2023 (UTC)

Abstain (2)

1.  Abstain I just don't know which way to vote. If it's a hat collection issue, then I'm all for eliminating Autopatrolled. However, I'm still more for keeping Autopatrolled separate. It's a good way to get users to become aware of expectations at Meta. Also, being Autopatrolled doesn't feel much different without the right.
   ---Imamy (talk) 15:08, 2 June 2023 (UTC)
2.  Abstain I have very mixed feelings with this. On one hand, users trusted to not make spam edits should be able to patrol others as well, but again, the opposite could also be true. There are a lot of users I would note though, that have autopatrolled but not patroller because they aren't trusted. So, abstain here. BrandonWM (talk • contributions • global • rights) 21:09, 6 June 2023 (UTC)

Draft-phase Comments (2)

1.  Comment: 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.  Comment: I would not be in favour of this proposed combination, for several reasons. For one thing, the autopatrolled 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 autopatrolled to something like autoconfirmed, 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 autopatrolled 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 patroller 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 rollbacker group into the patroller 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)

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)

OR

• 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.  Support 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)
2.  Support My comments from Proposal 2 are also relevant here so I do not wish to repeat them but I would simply summarize the fact that I believe it is beneficial to have some clear standards to be used at least as a starting point rather than a fully subjective discretion which can easily lead users to wonder what it actually takes to become an autopatroller or a patroller and to struggle to understand what the notion of "trust" can mean in an online wiki context. I believe that the introduction of criteria as well as the preservation of a level of discretion is a welcome addition. --DeeM28 (talk) 14:48, 2 June 2023 (UTC)
3.  Support ---Imamy (talk) 15:35, 2 June 2023 (UTC)
4.  Support as above. Administrator discretion is preserved (both for choosing to grant when criteria is not met, choosing not to grant even when criteria is met, and choosing to revoke), this simply provides clearer guidelines to Meta users on whether making a request is sensible. --NotAracham (talk • contribs • global) 18:37, 2 June 2023 (UTC)
5.  Support If this was ironclad, it would be an oppose as there should be room for discretion. But as it isn't, and there is, I can feel comfortable supporting this. BrandonWM (talk • contributions • global • rights) 21:09, 6 June 2023 (UTC)
6.  Support Seem reasonable. HeartsDo (Talk / Global / Wiki Creator) 09:05, 8 June 2023 (UTC)
7.  Partial support It makes a lot of sense to me to have a policy, especially when there's a discussion regarding transparency at Miraheze. That said, if autopatrolled and patroller are combined, then I think the existing criteria for patroller should apply or a new proposal with RfC should be made. I do not think this proposal should just be rolled over to the patroller role if it subsumes autopatrolled. Jph2 (talk) 15:56, 12 June 2023 (UTC)
8.  Support UltraOwen (talk) 19:36, 6 July 2023 (UTC)
9.  Support User talk:Anpang 08:40, 10 October 2023 (UTC)

Oppose (3)

1.  Weak oppose 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 | talk to me) 13:00, 2 June 2023 (UTC)

   @Zppix: 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)

•  Comment: Similar to my comments elsewhere, firstly, I would not be favour of combining the autopatrolled and patrolled 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)

•  Comment: 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.  Support Makes sense. Reception123 (talk) (C) 05:48, 2 June 2023 (UTC)
2. Conditional  Support 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 | talk to me) 13:03, 2 June 2023 (UTC)
3.  Weak support This seems like a necessary consequence but I would have wished that completely inactive users were also included in this assessment. --DeeM28 (talk) 14:49, 2 June 2023 (UTC)

   That's an amendment with some interest from me. Is there a particular inactivity threshold you'd propose? 6 months, 1 year? --NotAracham (talk • contribs • global) 17:44, 2 June 2023 (UTC)

4.  Support If a user isn't meeting the low threshold set, there are sparingly few cases to be made for retention of rights barring significant off-Meta contributions. --NotAracham (talk • contribs • global) 17:46, 2 June 2023 (UTC)
5.  Support I agree with Clarification provided by User:NotAracham in Comments (3.1) ---Imamy (talk) 21:53, 2 June 2023 (UTC)
6.  Support This is reasonable. A grandfather clause doesn't seem necessary in this scenario. BrandonWM (talk • contributions • global • rights) 21:09, 6 June 2023 (UTC)
7.  Support Per above. HeartsDo (Talk / Global / Wiki Creator) 09:05, 8 June 2023 (UTC)

Oppose (3.1)

1.  Oppose If a user is already autopatrolled, I don't see why they should have that status revoked in the event the new policy on appointment is approved. If there is no current reason to revoke their status now, then they should keep the status until such time as there is a reason to revoke it. Jph2 (talk) 16:01, 12 June 2023 (UTC)

Comments (3.1)

1.  Comment: I don't think I understand this Proposal ---Imamy (talk) 15:41, 2 June 2023 (UTC)

   This proposal is saying that, if approved, existing Autopatrolled users will lose the group if they don't meet either of the account age and edit criteria (50 edits, at least 30 days old OR 150 edits,15 days old). The last bit gives Administrators leeway to let folks keep their rights if they're very active on wikis or in the community beyond Meta. If proposal 2 passes and the Autopatrolled role goes away, this removal instead applies to Patrollers.

   @NotAracham Thank you for clarification. I agree with having a criteria that must be actively met to have these rights.

Draft-phase Comments (3.1)

•  Comment: As with below, this is already the status quo, and when I was a administrator, I have already supported removing autopatrolled 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)

Amendment 3.2 (Inactivity)

Add the following revocation criteria to proposal 3, to be additionally implemented as part of the transition plan of 3.1

• No contributions to the community in any form (e.g. edit or log actions on Meta, involvement on non-Meta Miraheze Spaces) for at least 6 months

Rationale: A six month inactivity clause is standard practice for the majority of volunteer roles. It will also allow us to prune perennially-inactive users who no longer require these permissions. --NotAracham (talk • contribs • global) 20:50, 2 June 2023 (UTC)

Support (3.2)

1.  Support as proposer --NotAracham (talk • contribs • global) 22:03, 2 June 2023 (UTC)
2.  Support ---Imamy (talk) 02:59, 3 June 2023 (UTC)
3.  Support Makes sense and in line with other groups. Reception123 (talk) (C) 17:50, 5 June 2023 (UTC)
4.  Support To match all others. BrandonWM (talk • contributions • global • rights) 21:09, 6 June 2023 (UTC)

Oppose (3.2)

1. Inactivity 6 months for autopatrolled??? If this is about patrollers and i am missing something, then i will remove/strike this comment.--MrJaroslavik (talk) 09:55, 8 June 2023 (UTC)

Abstain (3.2)

1.  Abstain While I'm not opposed, I also don't really see the point. If they are inactive, they're not presently posting. If they were trusted to be given autopatrolled to begin with, is there a concern if, when they return, their posts might be problematic? Even if that turns out to be the case, someone is going to notice and their autopatrolled status could be revoked at that point. I guess I just don't see a need for someone to track activity status in this group for the purpose of revoking the role. I also am not sure there's a need for a previously trusted poster to have to have future posts checked. Yeah, I know people can change, but if they do, the role can be revoked then and with cause. Jph2 (talk) 16:11, 12 June 2023 (UTC)

Glossary

Term	Definition	Related Information
RfC	Request for Comment	Requests for Comment
CN	Community noticeboard	Community noticeboard
CIR	Competence is required	w:WP:CIR

---

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.