Requests for Comment/Global rollback group

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

Proposal 1 does not pass, therefore the rest of this RfC becomes moot. John (talk) 17:32, 21 August 2020 (UTC)

---

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.  Weak support 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} - (on) 14:04, 23 July 2020 (UTC)
2.  Support, possibly weak, per @RhinosF1: 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 autopatrol, suppressredirect and rollback 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 patrol backlog on those wikis. Dmehus (talk) 14:44, 23 July 2020 (UTC)
3.  Weak support 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 Dmehus 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)
4.  Strong support I think rollback is more convenient than twinkle and is the easiest tool for users of any language. Can be get more easily than GS. GS are too many permissions available and the requirements for being trusted are strict.

   Most trolls I've seen don't continue to troll for many hours or days before being blocked, and after a while they get tired of trolls and stop them. I think GR is very useful for revert such troll edits. If the local admin takes time to discover the trolls, the quality of the wiki remains poor. I think that it is not good to be crawled by Google etc. in that state. --そらたこ (talk) 15:32, 23 July 2020 (UTC)

5.  Support I believe that one of the primary reasons for Miraheze's lack of advanced users is that there isn't a good way for interested volunteers to build the necessary skills and prove their trustworthiness for more advanced permissions. This group will allow newer volunteers a chance to experience while also providing support to our wikis. Sario528 (talk) 19:53, 23 July 2020 (UTC)
6.  Support As my time on Miraheze has progressed since my initial oppose, I have begun to see the need for a group like this. User:Universal Omega/Sig  20:25, 11 August 2020 (UTC) ］ |

 Support I like this proposal. Could be useful. GondorChicken (talk) 23:43, 12 August 2020 (UTC)

Oppose

1.  Oppose 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.  Strong oppose 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)

   I absolutely agree that we should never infringe on the autonomy of our wikis. The lack of an opt-out was a simple oversight on my part. As I stated above, I feel that the main reason that we *don't* have more Global Sysops and Stewards is because we don't have lesser groups like Global rollback. Advanced permissions require advanced skill levels and greater levels of trust from the community. How are interested volunteers supposed to develop those skills, and prove their trustworthiness if we don't have a lesser group for them to start off in? Sario528 (talk) 20:19, 23 July 2020 (UTC)

3.  Strong opposeLets start from here i think it is not really worth making for a few reasons i mean anyone could go and rollback an edit globally we have CVT's. If this group had more to it such as Global Content Moderator i would support it but this group i just do not fell is worth making. Cocopuff2018 (talk) 17:10, 23 July 2020 (UTC)
4.  Weak oppose 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)

5.  Strong oppose As per Amanda Catherine 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)
6.  Weak oppose per Amanda Catherine, however I am doing a weak oppose per Reception123's reply. User:Universal Omega/Sig  07:28, 24 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.  Support Helpful ~ RhinosF1 - _(chat)^{· acc· c} - (on) 14:09, 23 July 2020 (UTC)
2.  Support per RhinosF1 above. Dmehus (talk) 14:47, 23 July 2020 (UTC)
3.  Support User:Universal Omega/Sig  17:47, 12 August 2020 (UTC) ］ |

Proposal 2.2

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

Support

1.  Support Useful ~ RhinosF1 - _(chat)^{· acc· c} - (on) 14:09, 23 July 2020 (UTC)
2.  Weak support 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.  Support Reception123 (talk) (C) 15:18, 23 July 2020 (UTC)
4.  Support User:Universal Omega/Sig  17:47, 12 August 2020 (UTC) ］ |

Proposal 2.3

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

Support

1.  Support so they can revert quickly ~ RhinosF1 - _(chat)^{· acc· c} - (on) 14:09, 23 July 2020 (UTC)
2.  Support Yup...what RhinosF1 said above. Pretty self-explanatory. This user right is essential. Dmehus (talk) 14:50, 23 July 2020 (UTC)
3.  Support Reception123 (talk) (C) 15:18, 23 July 2020 (UTC)
4.  Support User:Universal Omega/Sig  17:47, 12 August 2020 (UTC) ］ |

Proposal 2.4

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

Support

1.  Strong support 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.  Oppose 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} - (on) 14:09, 23 July 2020 (UTC)
2.  Oppose Mostly per RhinosF1 above User:Universal Omega/Sig  17:47, 12 August 2020 (UTC) ］ |

Proposal 2.5

Edit pages (edit)

Oppose

1.  Oppose If a wiki has editing disabled, it's probably not going to need Global Rollback intervention. ~ RhinosF1 - _(chat)^{· acc· c} - (on) 14:09, 23 July 2020 (UTC)
2.  Oppose 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.  Oppose 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)
4.  Strong oppose per RhinosF1 and Reception123. An archived wiki should not be edited, and GR is inheriting the User and * groups. — Preceding unsigned comment added by ThesenatorO5-2 (talk • contribs) 2020年8月8日 (土) 08:55
5.  Oppose User:Universal Omega/Sig  17:47, 12 August 2020 (UTC) ］ |

Proposal 2.6

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

Support

1.  Weak support It might allow them to help more. ~ RhinosF1 - _(chat)^{· acc· c} - (on) 14:09, 23 July 2020 (UTC)
2.  Weak support 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 support 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)
4.  Support User:Universal Omega/Sig  17:47, 12 August 2020 (UTC) ］ |

Proposal 2.7

Mark rolled-back edits as bot edits (markbotedits)

Support

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

Oppose

1.  Weak oppose 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 autopatrol (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)
2.  Oppose User:Universal Omega/Sig  17:47, 12 August 2020 (UTC) ］ |

Proposal 2.8

Mark edits as minor (minoredit)

Support

1.  Support seems fine to mark a (partial) revert a minor edit. ~ RhinosF1 - _(chat)^{· acc· c} - (on) 14:09, 23 July 2020 (UTC)
2.  Support 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.  Support Reception123 (talk) (C) 15:18, 23 July 2020 (UTC)
4.  Support User:Universal Omega/Sig  17:47, 12 August 2020 (UTC) ］ |

Proposal 2.9

Move pages (move)

Support

1.  Support to revert move vandalism. ~ RhinosF1 - _(chat)^{· acc· c} - (on) 14:09, 23 July 2020 (UTC)
2.  Support Reception123 (talk) (C) 15:18, 23 July 2020 (UTC)
3.  Support User:Universal Omega/Sig  17:47, 12 August 2020 (UTC) ］ |

Oppose

1.  Oppose 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 suppressredirect, 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.  Support in case of TP vandalism. ~ RhinosF1 - _(chat)^{· acc· c} - (on) 14:09, 23 July 2020 (UTC)
2.  Support per above. Dmehus (talk) 15:10, 23 July 2020 (UTC)
3.  Support Reception123 (talk) (C) 15:18, 23 July 2020 (UTC)
4.  Support User:Universal Omega/Sig  17:47, 12 August 2020 (UTC) ］ |

Proposal 2.11

Not be affected by rate limits (noratelimit)

Support

1.  Support speed up mass reverting. ~ RhinosF1 - _(chat)^{· acc· c} - (on) 14:09, 23 July 2020 (UTC)
2.  Support, 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)
3.  Support Reception123 (talk) (C) 15:18, 23 July 2020 (UTC)
4.  Support User:Universal Omega/Sig  17:47, 12 August 2020 (UTC) ］ |
5.  Support --そらたこ (talk) 08:24, 17 August 2020 (UTC)

Proposal 2.12

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

Support

1.  Support self explanatory. ~ RhinosF1 - _(chat)^{· acc· c} - (on) 14:09, 23 July 2020 (UTC)
2.  Support per the title of this RfC and per RhinosF1. Dmehus (talk) 15:12, 23 July 2020 (UTC)
3.  Support Reception123 (talk) (C) 15:18, 23 July 2020 (UTC)
4.  Strong support Obviously this is needed per the group name User:Universal Omega/Sig  17:47, 12 August 2020 (UTC) ］ |

Proposal 2.13

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

Support

1.  Support also can agree with. ~ RhinosF1 - _(chat)^{· acc· c} - (on) 14:09, 23 July 2020 (UTC)
2.  Strong support 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.  Support Reception123 (talk) (C) 15:18, 23 July 2020 (UTC)
4.  Support User:Universal Omega/Sig  17:47, 12 August 2020 (UTC) ］ |

Proposal 2.14

ipblock-exempt - Exempt from IP Blocks abusefilter-exempt Some wikis may have filters which prevent edit reverts

Support

1.  Support as proposer. ThesenatorO5-2 (talk) 08:46, 2 August 2020 (UTC)

Oppose

1.  Oppose Not needed User:Universal Omega/Sig  17:47, 12 August 2020 (UTC) ］ |

Proposal 2.15

apihighlimits: Higher API limits

Support

 Support as proposer, makes sense because some GR may use scripts. ThesenatorO5-2 (talk) at 08:49, 8 August 2020 (UTC)

Oppose

1.  Oppose Not needed User:Universal Omega/Sig  17:47, 12 August 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.  Support Should encourage people to apply. ~ RhinosF1 - _(chat)^{· acc· c} - (on) 14:12, 23 July 2020 (UTC)
2.  Support Has way less permissions than GS or Steward so this makes sense. Reception123 (talk) (C) 15:18, 23 July 2020 (UTC)
3.  Support User:Universal Omega/Sig  17:47, 12 August 2020 (UTC) ］ |

Oppose

1.  Weak oppose 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.  Support ~ RhinosF1 - _(chat)^{· acc· c} - (on) 14:12, 23 July 2020 (UTC)
2.  Support makes sense, is in line with other policies. Reception123 (talk) (C) 15:18, 23 July 2020 (UTC)
3.  Weak support 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)
4.  Support User:Universal Omega/Sig  17:47, 12 August 2020 (UTC) ］ |

Proposal 3.2.1 - New GR are exempt from NC votes

Depending on the support ratio and the count of people participated, new GRs are exempt from NC votes for a period of int(vote_count/support_ratio/5), > 4, < 16, in days

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.  Support ~ RhinosF1 - _(chat)^{· acc· c} - (on) 14:12, 23 July 2020 (UTC)
2.  Support Reception123 (talk) (C) 15:18, 23 July 2020 (UTC)
3.  Weak support User:Universal Omega/Sig  17:47, 12 August 2020 (UTC) ］ |

Oppose

1.  Oppose 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

 Proposer's Comment: I apologize for creating this proposal after the drafting period, I did not notice there was a draft before.

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

Support

1.  Support Wikis should be given that freedom, as they are with the global sysop permission. Reception123 (talk) (C) 15:18, 23 July 2020 (UTC)
2.  Support 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)
3.  Support Of course. (I actually didn't realize that I had missed this. Thanks for catching it.) Sario528 (talk) 20:02, 23 July 2020 (UTC)
4.  Support User:Universal Omega/Sig  17:47, 12 August 2020 (UTC) ］ |
5.  Support --そらたこ (talk) 08:26, 17 August 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. Spıke (talk) 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, @Sario528:, 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?" Spıke (talk) 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 move and markbotedits 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 editsemiprotected, 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 suppressredirect, patrol, and autopatrol. 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, @Dmehus:, 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. Spıke (talk) 10:37 27-Jun-2020

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

---

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