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 1: Stewards

 * The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
 * Consensus seems to be trending towards being against this proposal. Nevertheless, as this RfC was proposed as a local Meta Wiki RfC, and, indeed, the remaining proposals of this RfC read this way, this is thus out of scope of a local Meta Wiki RfC and would require a global discussion, to be closed by Stewards, not bureaucrats. Additionally, before re-initiating this discussion, the proponent should consider the previous discussion Agent Isai linked to and also consider this guidance, in which the community strongly feels proponents should first draft their RfC, especially something as major as this. Dmehus (talk) 23:19, 12 February 2022 (UTC)

The Steward group is almost fine but I'd like to create some process of confirmation like they do on Wikimedia Meta-Wiki to hold stewards more accountable and make a way for the community to !vote on a steward's over-all performance and activity. Presently there is no way to remove the steward other than starting a vote of no confidence, if the rights aren't misused.

The proposal is that every December, all stewards will be listed at Community noticeboard and the community will be given the opportunity to discuss about the Steward's activity and performance. If the consensus will be to remove, the steward will be removed otherwise the rights will be kept. To remove the rights from a steward there should be more than 50% removal support ratio. The structure of the CN thread will be simple:

Steward confirmations



 * Highly active. Keep. --User:Example


 * Inactive and behaviour is unacceptable. Remove. --User:Example

The process will start on first December every year and will be open for discussion for two weeks. Any user, preferably a steward, will start the CN thread and any user who holds either admin, bureaucrat, or global sysop on meta rights may close the confirmations.

Discussion (1)

 * 1)  The community has previously voted against yearly elections in this RfC. In that RfC, it's mentioned that we're not Wikimedia and I agree with that, we shouldn't try and mimick Wikimedia and be a faux, psuedo-Wikimedia Foundation. What works there may not necessarily work here. I am leaning oppose as I think that we're not big enough for yearly Steward reconfirmations and if trust is not lost in a Steward, what's the need to remove them? While some may have little visible activity, they work in the backend and do great work and handle things actively behind the scenes. The policy on activity for Stewards is lenient for a reason, we understand that Stewards may not necessarily have time all the time to devote to Miraheze and we accept that. Additionally, we always have votes of no confidence and Stewards have present that they must follow the Code of Conduct which states that one must step down if they cannot devote time to their roles anymore. Revocation votes have been done before and 1 has resulted in a resignation; another Steward, in a venue other than Requests for Stewardship, conceded that they weren't very active and resigned gracefully. As such, while I am not voting just yet, I am leaning oppose but will recuse myself from voting until I have considered all arguments, including any follow-up posted by Magogre.  Agent Isai  Talk to me! 16:12, 11 February 2022 (UTC)
 * I agree that stewards will not have time all the time for MH and some are doing their good work in the backend that keeps the project running. I didn't added support and oppose sections because I thought this would merely be a discussion whether we should have it or not, but there seems to be unanimous opposition to the change. I think I have myself changed my mind per "we are not big enough to hold confirmations" and I am in oppose to this proposal. --Magogre (talk) 10:09, 12 February 2022 (UTC)
 * 1) If there is going to be reconfirmations just like Wikimedia, why not have annual elections just like Wikimedia? Instead, people can just request stewardship wheneever they feel like it. Also, reconfirmation at Wikimedia is ineffective and I have no reason to believe it'd be any different here. I also don't like the idea that meta sysops/bureaucrats close the request. For one, I believe it's overly bureaucratic to require user groups to close it. Secondly, why meta groups? Global groups would make more sense. Naleksuh (talk) 16:18, 11 February 2022 (UTC)
 * Perhaps, you got me wrong. I am not saying we must copy the Wikimedia way, I am proposing to create a process where community can vote on a steward's performance and activity. When I said "like thy do on Wikimedia Meta-Wiki", I was trying to give an idea of what I am proposing. I don't know why would we copy the Wikimedia way of yearly elections if RfS works well for us. Whether reconfirmations are ineffective on Wikimedia or not, it is none of interest for us. Meta groups were chosen to close, because (a) immature closures will be avoided, and (b) stewards would have a COI though I am fine with stewards or global sysops confirming the results. --Magogre (talk) 10:09, 12 February 2022 (UTC)
 * 1)  The scale of this and of the following proposals (especially since this has serious global ramifications and the following proposals do not) make me think they shouldn't necessarily be together, or that this should not be marked as a local proposal. Aside from that I agree with Agent on pretty much all counts, and Nale's point is reasonable that this proposal is only part of a larger system, and a system that is not necessarily appropriate or even helpful here. That said, I'd welcome further Steward-community discussions, such as a Steward acting as a liaison in Miraheze Meetings  to discuss things at that operational level. It would be interesting to consider, pending availability of course. --Raidarr (talk) 22:37, 11 February 2022 (UTC)
 * Indeed, I agree that this proposal should've been introduced in a separate RfC as this impacts a global group versus the local groups mentioned on all other sections. Agent Isai  Talk to me! 22:58, 11 February 2022 (UTC)
 * 1)  I'm seeing a trend throughout this entire RfC. It would appear that all the points raised are rooted in some sort of distrust of the current users holding specified permissions, such that there should be a system to revoke their permissions by default unless they fight to defend their current access. It seems that there is also the fear that the community would not agree with (a|the) proposing user(s) if a vote of no confidence or revocation vote were to be initiated for any user. I am worried if this RfC is simply a way to enact political change in currently established systems because they are inconvenient to personal goals.  dross  (t • c • g) 01:14, 12 February 2022 (UTC)
 * Thanks for the comment, . There is no point of distrust or similar that I mentioned. It is a proposal and I requested you to share your views about it. There is no need to talk about personal things, especially when they don't exist. --Magogre (talk) 10:09, 12 February 2022 (UTC)
 * In the spirit of good faith I think this proposal can largely and reasonably be interpreted a) as an idea that at least works well in the Wikimedia Foundation and is worth considering, though not necessarily implementing here and b) continuity as far as revocation clauses for activity, and one of the proposals by default grants more users (if on the 'ground level' with more rights off the bat. Can't say for TA as an elected role though. --Raidarr (talk) 10:32, 12 February 2022 (UTC)
 * 1)  I see this as unnecessary bureaucratic bloat, given that we already have formalized policies regarding recall votes and revocation for inactivity. — Arcversin (talk) 17:49, 12 February 2022 (UTC)


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

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.

Discussion (2)

 * 1)  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)  Bureaucratic and administrators must be experienced users to have the hat. --YellowFrogger  ( talk ) ( ✔ ) 22:03, 11 February 2022 (UTC)
 * 3)  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)  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)  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)  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)  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)  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)  <-- 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)  as grammatically incorrect. On Miraheze Meta Wiki,   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)  Per the comments above. --DeeM28 (talk) 18:06, 14 February 2022 (UTC)

Proposal 4: Patrollers and rollbackers
Include the  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)  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)
 * 1)  and  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)  --YellowFrogger  ( talk ) ( ✔ ) 02:40, 13 February 2022 (UTC)
 * What do you mean by "missing the chance of  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)
 * 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)
 * 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)
 * 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)
 * 1) 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)
 * 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)
 * 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)
 * , . 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)
 * 1)  per dross, per a previous RfC on the subject, and because not all Meta patrollers need the   toolkit, which should carry with it a higher level of trust. Additionally, if a user misuses the   permission, but is otherwise a decent patroller, the former can be removed without affecting the latter. Dmehus (talk) 23:25, 12 February 2022 (UTC)
 * 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  button is easy to fat finger click, so adding an extra user right would actually increase the number of inadvertent rollbacks when   was intended. Dmehus (talk) 23:47, 12 February 2022 (UTC)
 * 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)
 * 1)  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.1: Granting
Translation administrators group will only be granted after a request at 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)  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) ; 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)  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)  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)  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)  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)  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)  - 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)  likewise as good housekeeping, and a principle I wouldn't mind seeing as standard. --Raidarr (talk) 00:12, 12 February 2022 (UTC)
 * 3)  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)  considering the standard is already status quo. Administrator discretion as best standard.  dross  (t • c • g) 23:34, 12 February 2022 (UTC)
 * 4)  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)  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)  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)  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 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)  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)
 * 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)
 * 1) 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)
 * 1)  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)
 * 2)  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)
 * 3)  (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
<div class="boilerplate metadata discussion-archived" style="background-color: #F2F4FC; margin: 2em 0 0 0; padding: 0 10px 0 10px; border: 1px solid #aaa">
 * The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
 * by YellowFrogger. In addition, speaking as a Steward, this as out of scope of Meta administrators, who, by policy, cannot add or remove this restricted user group. Users also noted it's also unclear. Dmehus (talk) 00:08, 13 February 2022 (UTC)

Any administrator may remove the global interwiki administrators rights from a user if they have been inactive for 6 months. — Preceding unsigned comment added by YellowFrogger (User talk:YellowFrogger • Special:Contributions/YellowFrogger) 00:15, 12 February 2022 (UTC)

Discussion (7)

 * 1) to this until you see the community reception. --<span style="background:linear-gradient(90deg,#89005E,#89005E, #FF00AF); -webkit-background-clip:text !important; -webkit-text-fill-color:transparent;">YellowFrogger  ( talk ) ( ✔ ) 22:15, 11 February 2022 (UTC)
 * 2) What exactly do you want codified? An inactivity clause or what? This proposal's layout is a bit confusing.  Agent Isai  Talk to me! 22:23, 11 February 2022 (UTC)
 * Revocation of global interwiki administrators only. That above was a presentation about these rights. --<span style="background:linear-gradient(90deg,#89005E,#89005E, #FF00AF); -webkit-background-clip:text !important; -webkit-text-fill-color:transparent;">YellowFrogger ( talk ) ( ✔ ) 22:24, 11 February 2022 (UTC)
 * Alright, you amended your proposal but now it reads "administrators". I'm assuming your translator accidentally translated "Steward" as "administrator" but even so, as pointed out by Raidarr in Proposal 1, due to the magnitude of this change which would affect global groups, I would encourage you and Magorge to team up and make a new RfC which deals with global groups exclusively versus local groups. Agent Isai  Talk to me! 22:56, 11 February 2022 (UTC)
 * No, no, that was objective, the name of the rights is Interwiki administrators. I check all translations and I don't have a proprietary translator. --<span style="background:linear-gradient(90deg,#89005E,#89005E, #FF00AF); -webkit-background-clip:text !important; -webkit-text-fill-color:transparent;">YellowFrogger ( talk ) ( ✔ ) 23:01, 11 February 2022 (UTC)
 * Well, the interwiki administrator is an accountability group and has no inactivity policy. This RfC is only related to local groups (in Meta?), if so, I will remove this proposal. --<span style="background:linear-gradient(90deg,#89005E,#89005E, #FF00AF); -webkit-background-clip:text !important; -webkit-text-fill-color:transparent;">YellowFrogger ( talk ) ( ✔ ) 23:06, 11 February 2022 (UTC)
 * 1)  I think the principle of this has merit even if it is the most benign of global rights imo, noting the broader consequences which would put this outside a meta rfc's local scope. Ie, it's not something that meta administrators can manage, it would be a steward as IW is a global right. --Raidarr (talk) 00:11, 12 February 2022 (UTC)
 * I'm disconnected from this subject, but I already knew that stewards remove global rights, but I had forgotten about that. I also have no idea that we separate RfC. — "local, global, etc.". --<span style="background:linear-gradient(90deg,#89005E,#89005E, #FF00AF); -webkit-background-clip:text !important; -webkit-text-fill-color:transparent;">YellowFrogger ( talk ) ( ✔ ) 00:47, 12 February 2022 (UTC)


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


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