Requests for Comment/Global rollback group

As the RfC for CVT reform was ambiguous on the creation and rights for the proposed Global rollback group, I am creating this RfC to try and nail down the issue. This RfC will break down the proposals to their individual pieces, to allow the community to specifically support or oppose each aspect. While I will endeavor to be comprehensive in my initial list of proposals, I welcome new proposals to cover anything I miss. Sario528 (talk) 11:54, 19 May 2020 (UTC)

Proposal 1: Global rollback
The base proposal; should the group exist?
 * The creation of a new group called "Global rollback". It is clarified that a Global rollback should only act where there is clear vandalism or spam and should leave any more complicated matters to Stewards and Global Sysops as well as alert them of any offending users that need to be locally blocked or globally locked.

Support

 * 1)  I think it might bridge the gap between advanced rights and if people are willing to develop our anti spam tools could work.  ~ RhinosF1 - (chat)· acc· c -  14:04, 23 July 2020 (UTC)
 * , possibly weak, per and because we do need more global counter-vandalism groups on wikis with less active or inactive administrators. Global Sysop and Stewards have much more and the most advanced tools, respectfully, and so the requirements to obtain those rights are stricter. As a result, Miraheze is seeing huge growth, but doesn't see the comparable growth in users with global tools to combat that. Plus, currently, we have no way to demonstrate one's counter-vandalism efforts globally if one is interested in those more senior roles. Applying for the administrator tool locally on 1,000 or so wikis one wants to monitor seems like far too much work. It is weak because of the way in which the permissions were broken down individually. I personally don't think some of the user rights are needed, but the essential ones like ,   and   must be given. As well, an understated if not unstated purpose of the rollback group is that they can contribute constructively to cross-wiki improvement and editing, without contributing to the   backlog on those wikis. Dmehus (talk) 14:44, 23 July 2020 (UTC)
 * 1)  Per the above comments, I feel I should weakly support this. While I do believe that right now I don't see which users would be interested in getting this right (and we rather need more volunteers than more rights!) and how they would be able to help considering the lack of tools to spot vandalism, I don't think it's a bad idea to have the group exist for the future. I agree with Dmheus that it would be good to have a global group that has less rights than Global Sysops and Stewards as I stated in the initial RfC on this topic (among other things) that didn't pass. Reception123 (talk) ( C ) 15:18, 23 July 2020 (UTC)

Oppose

 * 1)  Not now. We don't have any tools for cross-wiki patrolling and rollback is equivalent of undo, only faster. Also twinkle can be installed globally. Why more unnecessary groups? Maybe i can support it if there will be tools for x-wiki patrolling. But not now.--MrJaroslavik (talk) 13:31, 23 July 2020 (UTC)
 * 2)  I am strongly against the creation of more global user groups than are absolutely necessary. It is important to retain the autonomy of wikis/communities which want to be autonomous, and the more global groups that exist (especially global groups that cannot be opted-out of), the less autonomy that exists. We already have Global Sysops which can revert vandalism/spam on inactive wikis, and they can also block the offending users, which is usually more effective than just mass reverting. –  AmandaCath  ( talk ) 13:53, 23 July 2020 (UTC)
 * I have added a proposal to ensure that opting out of global rollback rights is possible, as I do agree that wikis may choose to opt-out from this group, but smaller wikis who don't have active administrators may find this right useful. As for the global sysops and Stewards argument, there are obviously not nearly enough users in these groups. Reception123 (talk) ( C ) 15:18, 23 July 2020 (UTC)
 * 1)  The user group is now unnecessary, because we have twinkles.  CircleyDoesExtracter  ( Circley Talk  |  Global   |  Email the Cloud ) 13:58, 23 July 2020 (UTC)
 * While Twinkle is also useful in reverting vandalism, the actual revert button does make it easier (especially with a lot of vandalism). Reception123 (talk) ( C ) 15:18, 23 July 2020 (UTC)
 * 1)  As per  above. This group would prevent autonomy of the wikis. That makes since, and I agree completely with her. The global sysop and stewards already take care of that. --TFFfan (talk) 15:11, 23 July 2020 (UTC)

Proposal 2: Rights

 * If Proposal 1 is passed, the following rights are given to members of the Global rollback group:

Proposal 2.1
View the abuse log (abusefilter-log)

Support

 * 1)  Helpful  ~ RhinosF1 - (chat)· acc· c -  14:09, 23 July 2020 (UTC)
 * 2)  per RhinosF1 above. Dmehus (talk) 14:47, 23 July 2020 (UTC)

Proposal 2.2
View detailed abuse log entries (abusefilter-log-detail)

Support

 * 1)  Useful  ~ RhinosF1 - (chat)· acc· c -  14:09, 23 July 2020 (UTC)
 * 2)  It's useful, but it's not essential for this role, in my view. What's essential for global rollback is to monitor Special:RecentChanges and Special:NewPages and rollback unconstructive vandalism or disruptive edits. Dmehus (talk) 14:49, 23 July 2020 (UTC)
 * 3)  Reception123 (talk) ( C ) 15:18, 23 July 2020 (UTC)

Proposal 2.3
Not be affected by IP-based rate limits (autoconfirmed)

Support

 * 1)  so they can revert quickly  ~ RhinosF1 - (chat)· acc· c -  14:09, 23 July 2020 (UTC)
 * 2)  Yup...what RhinosF1 said above. Pretty self-explanatory. This user right is essential. Dmehus (talk) 14:50, 23 July 2020 (UTC)
 * 3)  Reception123 (talk) ( C ) 15:18, 23 July 2020 (UTC)

Proposal 2.4
Have one's own edits automatically marked as patrolled (autopatrol)

Support

 * 1)  I get RhinosF1's comments below, but I think what's needed here is either one of or both things, and that is that (1) we improve our requirements for granting by adding a requirement that the requestor has a demonstrated track record of understanding local content policies and/or (2) we possibly include a wiki opt-out mechanism (like Global Sysop) whereby local wikis can opt out of global rollback entirely. As an alternative to, or in addition to, the second point, we should include a requirement that if a local bureaucrat or administrator asks a global rollbacker to not use their rights on this wiki, the global rollbacker must comply and must log that notification in a centralized area. Dmehus (talk) 14:54, 23 July 2020 (UTC)

Oppose

 * 1)  Good at Counter Vandalism doesn't equal good at complying with every wikis content creation policies. I think they might be a user right that only auto patrols rolllbacks.  ~ RhinosF1 - (chat)· acc· c -  14:09, 23 July 2020 (UTC)

Proposal 2.5
Edit pages (edit)

Oppose

 * 1)  If a wiki has editing disabled, it's probably not going to need Global Rollback intervention.  ~ RhinosF1 - (chat)· acc· c -  14:09, 23 July 2020 (UTC)
 * 2)  per RhinosF1 above, who articulated my thoughts perfectly. This is a standard user right for all logged in users on most wikis. If it's not available, the wiki is essentially like a fishbowl wiki that can be edited by only select (probably local administrators or above) users. Dmehus (talk) 14:56, 23 July 2020 (UTC)
 * 3)  Per the comments above, if someone has vandalized the wiki and has more permissions that global rollbackers on said wiki, they are probably not the right group to handle that anyway. Reception123 (talk) ( C ) 15:18, 23 July 2020 (UTC)

Proposal 2.6
Edit pages protected as "Allow only autoconfirmed users" (editsemiprotected)

Support

 * 1)  It might allow them to help more.  ~ RhinosF1 - (chat)· acc· c -  14:09, 23 July 2020 (UTC)
 * 2)  Was originally going to be essential and full support, but if a page is semi-protected, it's probably going to be harder to vandalize as only experienced users on that wiki will be able to edit it. However, RhinosF1's comments above have caused me to lower my support to weak here because there can still be "sleeper" users that quietly build up their edits to become autoconfirmed and allow them to vandalize semi-protected pages. So this user right is potentially useful in that regard. Dmehus (talk) 15:00, 23 July 2020 (UTC)
 * 3)  Weak because it's a bit similar to the case above, only I guess it's not that hard to get autoconfirmed. Reception123 (talk) ( C ) 15:18, 23 July 2020 (UTC)

Proposal 2.7
Mark rolled-back edits as bot edits (markbotedits)

Support

 * 1)  No need to flood RC.  ~ RhinosF1 - (chat)· acc· c -  14:09, 23 July 2020 (UTC)
 * 2)  Reception123 (talk) ( C ) 15:18, 23 July 2020 (UTC)

Oppose

 * 1)  because I don't think this user right is required. I've noted RhinosF1's comments above, but think this could be alleviated by (a) granting   (most people have their RC preference settings set to list only unpatrolled edits, I would think) and/or (b) marking edits as minor (which can be filtered out of RC). Also, how often is a global rollbacker going to need to flood RC when rolling back edits? If on top of things right away, they shouldn't need to rollback more than a few edits, so that's not going to be flooding. It's easily managed. I'd say, let's revisit this user right in a few months or a year, assuming the proposal passes, and, if required, we can grant it later. Dmehus (talk) 15:04, 23 July 2020 (UTC)

Proposal 2.8
Mark edits as minor (minoredit)

Support

 * 1)  seems fine to mark a (partial) revert a minor edit.  ~ RhinosF1 - (chat)· acc· c -  14:09, 23 July 2020 (UTC)
 * 2)  Yup, no problem with this, and per both RhinosF1 and my comments to the precenting user right. Dmehus (talk) 15:06, 23 July 2020 (UTC)
 * 3)  Reception123 (talk) ( C ) 15:18, 23 July 2020 (UTC)

Proposal 2.9
Move pages (move)

Support

 * 1)  to revert move vandalism.  ~ RhinosF1 - (chat)· acc· c -  14:09, 23 July 2020 (UTC)
 * 2)  Reception123 (talk) ( C ) 15:18, 23 July 2020 (UTC)

Oppose

 * 1)  Procedural oppose because, while I agree 100% with RhinosF1 above, leaving a trailing redirect leaves more local cleanup. So, I'm procedurally opposing this unless bundled with , as with Wikimedia's global rollbacker group. Dmehus (talk) 15:08, 23 July 2020 (UTC)

Proposal 2.10
Not have minor edits to discussion pages trigger the new messages prompt (nominornewtalk)

Support

 * 1)  in case of TP vandalism.  ~ RhinosF1 - (chat)· acc· c -  14:09, 23 July 2020 (UTC)
 * 2)  per above. Dmehus (talk) 15:10, 23 July 2020 (UTC)
 * 3)  Reception123 (talk) ( C ) 15:18, 23 July 2020 (UTC)

Proposal 2.11
Not be affected by rate limits (noratelimit)

Support

 * 1)  speed up mass reverting.  ~ RhinosF1 - (chat)· acc· c -  14:09, 23 July 2020 (UTC)
 * , possibly weak, as I'm not sure how often there will be a need to mass revert more than, say, 10-25 edits per minute (or whatever the configuration is set to). Dmehus (talk) 15:11, 23 July 2020 (UTC)
 * 1)  Reception123 (talk) ( C ) 15:18, 23 July 2020 (UTC)

Proposal 2.12
Quickly rollback the edits of the last user who edited a particular page (rollback)

Support

 * 1)  self explanatory.  ~ RhinosF1 - (chat)· acc· c -  14:09, 23 July 2020 (UTC)
 * 2)  per the title of this RfC and per RhinosF1. Dmehus (talk) 15:12, 23 July 2020 (UTC)
 * 3)  Reception123 (talk) ( C ) 15:18, 23 July 2020 (UTC)

Proposal 2.13
Perform CAPTCHA-triggering actions without having to go through the CAPTCHA (skipcaptcha)

Support

 * 1)  also can agree with.  ~ RhinosF1 - (chat)· acc· c -  14:09, 23 July 2020 (UTC)
 * 2)  Though this is commonly included within the autoconfirmed implicit group, it's essential because many global rollbackers won't be autoconfirmed on most wikis. Dmehus (talk) 15:14, 23 July 2020 (UTC)
 * 3)  Reception123 (talk) ( C ) 15:18, 23 July 2020 (UTC)

Proposal 3: Appointment and Revocation

 * If Proposal 1 is passed, the appointment and revocation criteria for the Global rollback group is the following:

Proposal 3.1
If Proposal 1 is passed, the appointment criteria for the Global rollback group is the following:
 * To be appointed Global rollback a request needs to be made at Requests for global rights. The community can discuss (support/oppose/abstain/comment) the request. The request will be considered successful if:


 * at least 5 users share their view
 * there is a support ratio of at least 80%
 * a period of one week has passed since it started

Support

 * 1)  Should encourage people to apply.  ~ RhinosF1 - (chat)· acc· c -  14:12, 23 July 2020 (UTC)
 * 2)  Has way less permissions than GS or Steward so this makes sense. Reception123 (talk) ( C ) 15:18, 23 July 2020 (UTC)

Oppose

 * 1)  The requirements are not too onerous, but I prefer, firstly, to have some mention of the requirement demonstrating by diffs, contribution history, and log actions their counter-vandalism experience and, secondly, some steward discretion here to assess whether the candidate met the requirements. It's conceivable the candidate could meet the participation level and support ratio, but still not have demonstrated that experience, so in that case, this is an example of a legitimate close by a steward that prevents the user from being promoted. Also, I think the same participation level and support ratios are too high relative to the participation we get on Meta. As I say, I would rather have additional requirements, beyond merely supporting or opposing, that require the candidate to demonstrate their experience. Dmehus (talk) 15:21, 23 July 2020 (UTC)

Proposal 3.2
If Proposal 1 is passed, the criteria for removing some from the Global rollback group is the following:


 * The global community can initiate a vote of no confidence or a request of removal at any time. In order for it to pass it needs to:


 * at least 5 users share their view
 * there is a support ratio of at least 50%
 * a period of one week has passed since it started

A vote of no confidence or request for removal must include a reason for why users are requesting the removal of a Global rollback, and it is not determined solely by the number of votes.

Support

 * 1)   ~ RhinosF1 - (chat)· acc· c -  14:12, 23 July 2020 (UTC)
 * 2)  makes sense, is in line with other policies. Reception123 (talk) ( C ) 15:18, 23 July 2020 (UTC)
 * 3)  because I think we're looking at our permissions granting requirements too quantitatively by merely nosecounting. I would rather see a more qualitative analysis and some subjective determination by an eligible closer (i.e., a steward). Dmehus (talk) 15:25, 23 July 2020 (UTC)

Proposal 3.3

 * In the case of a blatant misuse of rights or an abuse of power, a Steward may remove a user from Global rollback at their discretion without a community vote. If this happens, the user must undergo a no-confidence vote while their rights are temporarily removed, and their rights may only be added back if the no-confidence vote does not pass. This should only be used in extreme cases and should not substitute a no-confidence vote in non-urgent situations.

Support

 * 1)   ~ RhinosF1 - (chat)· acc· c -  14:12, 23 July 2020 (UTC)
 * 2)  Reception123 (talk) ( C ) 15:18, 23 July 2020 (UTC)

Oppose

 * 1)  Per my comments above, a steward should have the power to remove the rights permanently, but in keeping with my comments above about having lower and participation levels and support ratios, it holds that a steward with the ability to subjectively determine eligibility for granting should be able to permanently revoke the rights in blatant misuse. There's no need for a community vote to permanently remove the tools; we trust stewards, rightfully so, to make that rare determination to remove the tools. If a global rollbacker wants their tools back, they can reapply through the normal process (i.e., a community vote). Dmehus (talk) 15:28, 23 July 2020 (UTC)

Proposal 4

 * Wikis can choose to opt-out of Global rollback intervention if they wish to do so

Support

 * 1)   Wikis should be given that freedom, as they are with the global sysop permission. Reception123 (talk) ( C ) 15:18, 23 July 2020 (UTC)
 * 2)  My preference would be for a truly global rollback global group, but this seems likely to achieve community buy-in. It also seems likely this RfC probably will not pass and we'll have to have another RfC in a few months. Dmehus (talk) 15:32, 23 July 2020 (UTC)

Comments during the draft review period

 * I don't have detailed comments as I didn't participate much in the RfC you're clarifying. But a ballot on each separate privilege to be given to group members will get tedious.  Propose a set of privileges, state your justification, and let's vote.  I don't know what the right set is.   02:08 25-Jun-2020
 * There were several attempts to find an agreeable set of rights during the original RfC, without success. Rather than going through multiple proposals of various combinations of rights again, I'd rather just go through all of them one by one to ensure a clear consensus. It may get tedious, but it was a lack of agreement on rights that killed the original proposal. Additionally, I am also unsure of what the exact set of rights should be. Sario528 (talk) 02:21, 25 June 2020 (UTC)
 * Well,, someone should get sure before the formal vote. It is clear what rights are required in order to be a Global Rollbacker.  There is perhaps one separate voting proposition:  "Shall we grant Global Rollbackers the following rights that are not required for their function, but seem to be warranted based on the implied level of trust?"   10:37 27-Jun-2020


 * I agree with Spike that voting on a separate proposal for each user right would get tedious. Propose the slate of rights in one proposal; if you want to make an alternate slate of rights should that not pass, propose an alternate slate in a sub-section of the main proposal on "rights." From looking at this, it's not clear that the  and   are needed for a Global Rollback permission. For the former, that's typically included in either the autoconfirmed local user group, and since you're proposing to add , should be included in that as well. In very rare instances of disruption does move vandalism occur; vandalism often occurs by editors who are not autoconfirmed users. The latter seems like a way to hide the edits from peoples' watchlists, which reduces transparency, so I wouldn't support that. Also, you should specify whether this is a truly global permission like on Wikimedia or whether it is opt-out based like Global Sysop. Personally, I think it should be truly global, but shouldn't have as extensive of rights. I also am not a fan of strict support ratios; it's not supposed to be a vote, and strict ratios encourage straw voting. There should be no minimum percentage, as someone should be able to pass with, in theory, as little as 45%, if there was one other participant who opposed on a weak rationale like "we don't need any more". Rationales, substantiated by diffs, should be given preference in closing. It also doesn't make sense to have the community revoke rights with only 50% support, but require the global rollbacker to obtain 80% support for a permission that is a lot less than Global Sysop or Steward. If an actual support ratio is included, make it a range, like 50-70% (80% is too high), with explicit instructions for the steward to consider at close.
 * As an aside, I'd like to know if you and/or Spike would support a separate global permission that I'm thinking of proposing. It would be a Global Contributor or Global Patrol group that would include less rights than Global Rollback, to reduce the local patrol backlog for constructive cross-wiki contributors. Main rights would be,  , and  . This would not have access to the abuse log detail and rollback permissions of Global Rollback, as it really isn't dealing with cross-wiki vandalism, but rather, provides an ability for cross-wiki contributors to constructively contribute and to volunteer by marking those edits needing patrolling as "good." They could also "undo" bad edits or revert by manually editing. In this way, it would be a good "feeder" for Global Rollback in the same way the latter would be a good feeder for Global Sysop. Requirements would be something like experience on a minimum of 3-5 Miraheze wikis and having at least 500 mostly unreverted edits across those wikis. Dmehus (talk) 13:10, 26 June 2020 (UTC)
 * Leaning against,, because I keep hearing about how Miraheze volunteering is at such a low level that we're getting undesirable cross between committees we'd want to be independent. Your idea is good brainwork, but could be slicing-and-dicing it too fine.   10:37 27-Jun-2020
 * I appreciate your reply; apologies for my delay in following up. I don't think that the reason to oppose should be because "Miraheze volunteering is at such a low level." One could probably argue one of the reasons cross-wiki volunteerism is because we've arguably set the participation level too high (thinking about Global Sysops). That's not to say I think the 80% ratio of relative support is too high or anything, but rather, the number of participants (i.e., 10) is too high relative to the participation we get on Meta. Look at poor Zppix; he's had to go through two Global Sysop confirmation votes (hopefully this one will pass this time). We probably need to take a second look, via another RfC, at our minimum level of expressions of interest in any candidate; otherwise, we could end up in a situation where the few stewards we have aren't replaced (let's say in 3-5 years, one of them is hired on full-time with a major software development company and they no longer have any time for Miraheze volunteering). One can, in theory, request additional user rights locally on each wiki on which they want to combat vandalism, fix wikilinks, fix lint errors, help categorize, correct spelling and grammar, and the like, but that's a lot of work, especially if they want to be involved in a lot of wikis. Though I'd prefer Global Rollback and Global Patroller to be truly global positions with no opt-out mechanism, if such global groups could gain your support with an opt-out provision (like Global Sysops), is that something that could at least move you to "leaning support" if not "support"? Dmehus (talk) 00:35, 12 July 2020 (UTC)