Requests for Comment/User rights changes

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

The RfC is closed as follows:

• Proposal 1: As closed by a Steward
• Proposal 2: Unsuccessful, consensus remains that it may be kept.
• Proposal 3: Unsuccessful, consensus is to keep the group as named.
• Proposal 4: Unsuccessful, consensus is against expanding the access for the group.
• Proposals 5: Both are unsuccessful.
• Proposal 6: Successful from an advisory perspective, one oppose mentions the process is currently discretionary - this is not the case, we only remove based on user request currently. This proposal therefore adds removal grounds that can be clarified as a later RfC if required.
• Proposal 7: As closed by a Steward

John (talk) 18:53, 17 February 2022 (UTC)

---

Proposal 2: Administrators

Remove translation admin rights from the meta administrators but keep them the ability to grant the user group to others and one's own account. This is because every user is not aware of how the translate extension works. If admins want to help out, they may add the group to their account at their discretion. For clarity's sake, the rights to be removed are listed at Special:ListGroupRights#translationadmin.

Discussion (2)

1.  Oppose Overly bureaucratic in my opinion and since they can grant the right to themselves, it defeats the purpose of removing the rights from the account if they can just assign themselves translation administrator even if they don't possess the knowledge needed for the bit. Agent Isai ^{Talk to me!} 14:49, 11 February 2022 (UTC)
2.  Oppose Bureaucratic and administrators must be experienced users to have the hat. --YellowFrogger (talk) (✔) 22:03, 11 February 2022 (UTC)
3.  Oppose likewise to above and initial comment in particular, not necessary. I think admins should also be able to perform at least some degree of TA task where able/necessary outright rather than jump a hoop, even if it is not the focus by any means of the particular admin. --Raidarr (talk) 22:39, 11 February 2022 (UTC)
4.  Oppose Unnecessary bureaucratic bloat, I would expect an admin to either understand how to use the translation tools, or to understand that they need to learn how they work before using them. — Arcversin (talk) 17:51, 12 February 2022 (UTC)
5.  Oppose Unclear and overly bureaucratic per above. Perhaps equally, if not more importantly, Meta translation administrators are granted and revoked by Meta administrators, so even if we removed the translation administrator user rights from Meta administrators, they could just re-add the translation administrator group to themselves. Personally, I'd rather have fewer hats than more. Dmehus (talk) 23:21, 12 February 2022 (UTC)
6.  Oppose per above, seems to be a solution to something that isn't really an issue as far as I'm aware and overly bureaucratic. Reception123 (talk) (C) 11:37, 13 February 2022 (UTC)
7.  Oppose I agree with the comments above. Translation administrator is a minor and not sensitive right so I do not see why it should be subject to a process similar to the one where Stewards must add and remove CheckUser and Oversighter from their accounts. Administrators are in principle users who are trusted by the community and who will not participate in things that they do not know and therefore I do not feel like this limitation on their abilities because "not every user is aware of how the translate extension works" is appropriate. I myself have no idea about how this Translate extension works but I cannot believe that it is rocket science and requires a special expertise. Therefore the explanation advanced for this change does not convince me. --DeeM28 (talk) 18:06, 14 February 2022 (UTC)

Proposal 3: Autopatrolled users

Rename the group to 'autopatrollers' because:

• There is no need from for the 'users' in the name of the group. It is clear that every user is a user.
• Shortening the name to keep consistency with Patrollers as they are somewhat similar.

Discussion (3)

1. -er suggests one is doing an action while -ed suggests one has a certain quality. As autopatrolled users cannot patrol and there is no action called "autopatrolling", I think we should leave the name as it is or just removing the "users" suffix at most. Agent Isai ^{Talk to me!} 15:20, 11 February 2022 (UTC)
2. Per Agent Isai, the current name is correct and this change would be introducing a factual error. Naleksuh (talk) 18:48, 11 February 2022 (UTC)
3.  Comment: Could you dig deeper into why? In my opinion incorrect views may occur as stated by users above, and by default in MediaWiki wikis display the bit name as autopatrolled users. --YellowFrogger (talk) (✔) 21:46, 11 February 2022 (UTC)
4.  Oppose <-- I'm going to go ahead and use this, as the above comments illustrate well why the change would be a serious misnomer and 'autopatrolled' has nothing to do with 'patrolling'. A revision that just drops the 'user' bit could be considered, but wouldn't be necessary. It's not that current implies anyone isn't a user. It's indicating that the particular user is an autopatrolled user. A harmless statement and overall, I think the rationale behind this is unnecessary. --Raidarr (talk) 22:41, 11 February 2022 (UTC)
5.  Oppose as grammatically incorrect. On Miraheze Meta Wiki, autopatrolled users cannot patrol other users' edits. Their edits are simply automatically patrolled, and they can't autopatrol their own edits. Dmehus (talk) 23:23, 12 February 2022 (UTC)
6.  Oppose Per the comments above. --DeeM28 (talk) 18:06, 14 February 2022 (UTC)

Proposal 4: Patrollers and rollbackers

Include the rollback right in the patroller user group. Patrollers are the users who pretty much need this right. Rollbacker group will be kept there for the users who aren't necessarily active and interested in patrolling but anti-vandalism.

Discussion (4)

1.  Comment: While I trust all rollbackers with the ability to patrol, I do not trust all patrollers with the ability to rollback. Rollbacker is a right seldomly granted by administrators for a reason, it requires a higher level of competence and not all patrollers may want the ability to rollback. I've talked to a few people who all share the same sentiment. As such, I don't think the bit should be included in the patroller toolset. Agent Isai ^{Talk to me!} 15:04, 11 February 2022 (UTC)

   To add to what Agent said, please see Requests for Comment/Autopatroller group split,--MrJaroslavik (talk) 15:19, 11 February 2022 (UTC)

   I'm a patroller and have needed to rollback edits a few times but it hasn't come up that much, and more importantly, patrollers are called patrollers for other reason, and that's what they should be. I could think of plenty other rights that patrollers could use, like deleting pages. Should those be added too? Patrollers patrol, rollbackers rollback. I also don't really agree with the sentiment that all rollbackers should be trusted with the ability to patrol, I think patrol is a more trustworthy permission than rollback, but it is different, and stuff like this would create a "hierarchy" of sorts which I don't want Naleksuh (talk) 16:23, 11 February 2022 (UTC)

2.  Strongest support and  Comment: I agree with it. Patrollers are users who should be very much part of Miraheze in the Recent changes. There are vandals in Miraheze occasionally and Twinkle takes time to load the JS in the browser a lot of the time, missing the chance of rollback editing. The only downside to rollback is accidentally revert. Also, in response to the above ​user, patrollers are already trusted users as said by many users, and the rollback function has nothing more than the simple revert button. As it says on the patroller's own page "Patrollers on Meta help coordinate against spam and review all edits to make sure they're compliant with local policies." --YellowFrogger (talk) (✔) 21:57, 11 February 2022 (UTC)  Weak oppose --YellowFrogger (talk) (✔) 02:40, 13 February 2022 (UTC)

   What do you mean by "missing the chance of rollback editing"? Your comment suggests dismay at the fact someone else reverted the edit already. It shouldn't be a race to see who rolls back an edit first. Agent Isai ^{Talk to me!} 22:13, 11 February 2022 (UTC)

   @Agent Isai: I'm saying in the sense of the vandal (or user who committed the vandalism, to be exact) having their disruptive edit reverted in as little time as possible, especially since most of the time users put things too perjatives to articles, no matter who the user is. I never said it was to "revert first than others". --YellowFrogger (talk) (✔) 22:20, 11 February 2022 (UTC)

   @Agent Isai: To clarify the facts, admins only give rollback rights when users revert too much vandalism. This is pretty much complicated due to the low vandalism in Meta (and users taking the lead, but that's no problem), I wanted to talk along those lines as well. --YellowFrogger (talk) (✔) 22:23, 11 February 2022 (UTC)

   I hope you don't take this too personally, but users should learn to use the standard MediaWiki interfaces first. In my time on meta, I have found that most of our patrollers do not know how to mark a new page as patrolled, and I'm sure that even fewer would know how to manually revert to an old revision of a page, or merge a new edit with an old revision. Access to tools like rollback does not enable or replace these functions—it only increases their efficiency. dross (t • c • g) 01:23, 12 February 2022 (UTC)

   @Dross: I claim that I have been aware of this from editing wikis for 1 year: Special:CentralAuth/YellowFrogger. And, manually reversing is very simple, as simple as marking a new page as patrolled. Undoubtedly, having your own wiki helps with knowledge. --YellowFrogger (talk) (✔) 01:34, 12 February 2022 (UTC)

3.  Oppose Manual rollback is as effective, if not more so in most cases. For the vast majority of countervandalism, using standard editing tools like undo and editing old revisions is more appropriate than rollback. In addition to this, as has been a subject of discussion as of late, we should consider an expansion of the access that the rollback group has for countervandlism activities. Overall, patroller and rollback are distinct and separate toolkits which are not particularly intersecting and not always complements. If you feel that you would benefit from rollback, by all means, request it. However, understand that the editor is just as powerful, if not more so. It is also safer, and less accident prone. dross (t • c • g) 01:19, 12 February 2022 (UTC)

   @Dross: Manual rollback requires seconds. The rollbacker bit is very simple, it does not require anything other than the rollback button. I would even agree if it was 100% effective if you didn't need to put a summary, something you don't need in the rollbacker, which is special at reversing disruptive edits. The use of Manual Revert and Undo is recommended only for edits with a constructive purpose as it needs a summary. If you want to minimize rollback crashes, it doesn't hurt to trigger your personal CSS. Also, rollback is seen as a "useless" function in Miraheze Meta, which of course ends up in admins 90% of the time, especially the more serious ones, causing the request to decline, even if it's a function that just adds a button in edit history. Summary: vandalism = rollback. Removes non-constructive edits in seconds, removing likely disruptive content as quickly as possible. --YellowFrogger (talk) (✔) 01:30, 12 February 2022 (UTC)

   @YellowFrogger: Would you mind giving me an example of a Meta admin declining a request for rollback for anything other than lacking competency for the bit? I have personally never seen an admin give any reason indicating that they won't grant the bit because there isn't any vandalism. I've even considered having my rollback bit removed because I don't use it, and there are too many cases where rollback simply is not the best tool for the job. dross (t • c • g) 01:34, 12 February 2022 (UTC)

   @Dross: [1], [2]. Most arguments are citing or recommending Twinkle. I don't have any problem, but what I don't like is the delay in my browser's JS with TW. The only undo (script or gadget) I think is really good is Restorer, which I use to reverse vandalism at the moment. Also, the use of rollback would only be to reverse vandalism or something, I do not agree with using Rollback in constructive edits. --YellowFrogger (talk) (✔) 01:49, 12 February 2022 (UTC)

4.  Oppose per dross, per a previous RfC on the subject, and because not all Meta patrollers need the rollback toolkit, which should carry with it a higher level of trust. Additionally, if a user misuses the rollback permission, but is otherwise a decent patroller, the former can be removed without affecting the latter. Dmehus (talk) 23:25, 12 February 2022 (UTC)

   @Dmehus: I already explained to him, rollback is highly effective against vandalism and seen as not useful in Miraheze Meta, which is the only wiki in the world of all World Wide Web sites that finds rollback useless. I understand and do not agree to use rollback against constructive edits, but only vandalism. Also, as already stated by you, patrollers are trusted users, why not use a simple button added to history? There's nothing much to it. If rollbackers blocked users (as in some wikis), then yes it would be a trusted user bit, but there's nothing wrong with a simple button that doesn't need an edit summary, extremely useful against vandalism. No wonder Wikipedia has 6,000 rollbackers. I've already reversed several vandalisms here and I don't even have a rollbacker, after asking an administrator and being declined. Why not patrollers, who are users who must fulfill the role of seeing recent changes and controlling vandalism/spam? --YellowFrogger (talk) (✔) 23:39, 12 February 2022 (UTC)

   YellowFrogger, so is Twinkle. Also, the rollback button is easy to fat finger click, so adding an extra user right would actually increase the number of inadvertent rollbacks when undo was intended. Dmehus (talk) 23:47, 12 February 2022 (UTC)

   @Dmehus: I agree so I will take my support vote. Reversals are already enough even with 0.1% of users with this role. I like Twinkle, but I don't use it often, it takes a long time to load (Gadget browser/JS). Instead, there's an alternative, which is Restorer, a script, actually, that I use for hunting although it's not specifically designed to revert. I like it because it shows in edit history the revert button (unlike Twinkle) and doesn't need a summary. I wouldn't cite Twinkle as an alternative to rollback when a request is declined, instead it would suggest users to hunt for more vandalism. I'm certainly pretty damn terrible when it comes to voting. Imagine how much crash waves would create? (even more patrollers who don't know if they want to use the bit, and, one that has already done several vandalisms), would certainly not be good. Even so, to stay on point, it would have some negative effect if it is user-oriented (patrollers) if they have, probably, rollback, a CSS addition that decreases the rollback buttons in recent changes (in particular MinervaNeue, which has a large ) for the accident rate to fall? What would you think of it? --YellowFrogger (talk) (✔) 01:38, 13 February 2022 (UTC)

   YellowFrogger That's okay, and no problem. Your comments in discussions are generally appreciated. Please do feel free to formalize your withdrawal of your support !vote by striking through the support and, optionally, adding an {{oppose}} template (if you wish), the latter not being required. Dmehus (talk) 02:19, 13 February 2022 (UTC)

5.  Oppose I do not believe there is a pressing need for a combination of the two groups per the reasons given above. --DeeM28 (talk) 18:06, 14 February 2022 (UTC)

Proposal 5: Translation administrators

Proposal 5.1: Granting

Translation administrators group will only be granted after a request at Meta:Administrators' noticeboard and users will be given the adequate time to examine the standing candidate - their knowledge of the extension and community trust; not just admin discretion.

Discussion (5.1)

1.  Support Because Translate is complicated even for experienced users (you have to get used to it, as it complicates the page syntax) and the tags have to be used correctly. --YellowFrogger (talk) (✔) 22:09, 11 February 2022 (UTC)
2.  Neutral; reluctant to support as I don't think it has the gravity implied in the proposal, but I am not invested enough in the translation mechanism to take a stronger stance. On the other hand I'm not familiar with many members of the community who are and I would rather not see additional voting mechanisms that are only populated by few interested parties who effectively make the decision with about the same diversity as admin discretion. --Raidarr (talk) 00:15, 12 February 2022 (UTC)
3.  Oppose It's an editing tool. I would argue that there really isn't any community trust behind it, and it's a role with competency requirements just like patroller and rollback. Most users would argue that it would be ridiculous to apply the same proposed standard to patroller or rollback. I fail to see any need. dross (t • c • g) 01:06, 12 February 2022 (UTC)
4.  Oppose This is a relatively minor role assigned on the basis of competency, of which a formal voting process would be unnecessary bloat. — Arcversin (talk) 18:09, 12 February 2022 (UTC)
5.  Oppose per dross and Arcversin, and because it's overly bureaucratic to require someone to request the relatively minor, discretionary permission on a specific noticeboard. Dmehus (talk) 23:49, 12 February 2022 (UTC)
6.  Weak oppose it seems to be once again a solution to a problem that doesn't really exist. While I think generally requesting on-wiki is the preferred way to do things there isn't a need for a strict requirement. Reception123 (talk) (C) 11:39, 13 February 2022 (UTC)
7.  Oppose First of all this (as one of the earlier proposal) seems to once again put into question the trust in administrators and seek to limit their powers and discretion. While in some cases that can be justified I am once again not convinced at all that this translation administrator role is so important that administrator discretion must be curbed and confined in such a way. Second I agree with the comments above that 'community trust' for translation administrator does not seem to be that important. Therefore I do think that knowledge of the extension is certainly important and translation administrator should not be handed out to everyone I do not believe that this has to be mandated and imposed on administrators. --DeeM28 (talk) 18:06, 14 February 2022 (UTC)

Proposal 5.2: Revocation

Any administrator may remove the rights from a user if they have been inactive for 6 months.

Discussion (5.2)

1.  Support - I support housekeeping for groups to prevent hats from collecting dust. If a user wants the bit back, they can always re-request it from administrators. Agent Isai ^{Talk to me!} 15:48, 11 February 2022 (UTC)
2.  Support likewise as good housekeeping, and a principle I wouldn't mind seeing as standard. --Raidarr (talk) 00:12, 12 February 2022 (UTC)
3.  Support If this weren't already the case, it should have been the case long ago. dross (t • c • g) 01:07, 12 February 2022 (UTC)  Oppose considering the standard is already status quo. Administrator discretion as best standard. dross (t • c • g) 23:34, 12 February 2022 (UTC)
4.  Neutral I'm not seeing a particularly compelling reason why an inactivity policy would be necessary, as this right is an editing tool as opposed to a position of community trust, but I'm not necessarily opposed to it. — Arcversin (talk) 18:20, 12 February 2022 (UTC)
5.  Oppose per Arcversin and because Meta administrators can already remove the permission where the user is not active as a translation administrator. I don't see a compelling reason to codify a time limit for what is a discretionary user group. Dmehus (talk) 23:27, 12 February 2022 (UTC)
6.  Support It already can be done now but I don't mind having a codification of this rule so users know they can be removed if inactive. Reception123 (talk) (C) 11:41, 13 February 2022 (UTC)
7.  Weak oppose Even if there may be a benefit to having a specific time limit I believe that because this role is discretionary and minor there is no need to have a specific time and it should be able to be removed at will for users who are clearly no longer using the rights. There is also additionally not much harm that can be done if a user retains these rights so there is no pressing need to remove them.--DeeM28 (talk) 18:06, 14 February 2022 (UTC)

Proposal 6: Bots

The Removal section is added to Meta:Bots as:

The bot flag of any bot may be removed by bureaucrats if:

• the bot has made no edits or log actions for a year.
• the operator requests that the flag from their bot be removed.

Discussion (6)

1.  Support Reasonable. Bots should not maintain their flag if they're not using it though I would also like to see a clause for revocation should the bot exceed their scope repeatedly. Agent Isai ^{Talk to me!} 15:52, 11 February 2022 (UTC)

   @Agent Isai: Any bot that does things other than approved tasks may be blocked, although that wouldn't result in the removal of the group per w:WP:INDEFRIGHTS. Would there be a purpose in doing both? I don't see one, other than requiring another discussion to get the flag back instead of requesting unblock to one sysop Naleksuh (talk) 16:20, 11 February 2022 (UTC)

2.  Oppose Bots should only have their rights revoked when the tool is misused or malfunctions. --YellowFrogger (talk) (✔) 22:01, 11 February 2022 (UTC)

   Malfunctioning of bots is not a valid reason to revoke the flag and is a normal thing. There may be a small bug in the code. If a bot malfunctions, that should be blocked until the bug is resolved. --Magogre (talk) 10:14, 12 February 2022 (UTC)

3.  Support Due to security concerns regarding long-inactive bot accounts, and due to the fact that a bot generally shouldn't get restarted after such a prolonged period of inactivity before ensuring that its task is still current. — Arcversin (talk) 18:23, 12 February 2022 (UTC)
4.  Oppose Why twelve (12) months? I don't see sufficient need here. Meta bureaucrats can already remove the permission where the bot is not recently active. I'd prefer to keep it discretionary. Dmehus (talk) 23:29, 12 February 2022 (UTC)
5.  Support (Conditional) As opposed to Proposal 5.2 'bots' is a more significant group and is not discretionary and as such I believe it does indeed benefit by a codified clear terms. I do not think it is a good thing to allow administrators to arbitrary remove the bot group without there being a more clear limit. That being said, I oppose 12 months and support 6 months as is the case with other groups. --DeeM28 (talk) 18:06, 14 February 2022 (UTC)

Proposal 7: Interwiki administrators

---

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