Requests for Comment/Miscellaneous RfGR and WC rules

What we've often done at Miraheze over the years is create procedures and rules for global groups separately. What has happened in some instances is that rules between the global groups are inconsistent for no particular reason. In addition, similarly to the Requests for Comment Policy that was recently implemented, there's some rules regarding voting that should also be applicable to permission requests. This request proposes to make some of these rules consistent and also adds a few new ones or modifications. Reception123 (talk) ( C ) 16:33, 14 June 2022 (UTC)

Note : If 'This proposal also applies to wiki creator requests.' is not included, that proposal does not apply to wiki creators.

Note to closing Steward: If proposals are successful, preferably there wouldn't be a new policy page that documents these points but instead they would be integrated in the current pages for the respective groups (Reception123 (talk) ( C ) 16:33, 14 June 2022 (UTC))

Proposal 1 (Voting)

 * Users may not participate in requests for global rights with more than a single account, in accordance with the user accounts policy. Only registered users may vote in requests for global rights. Unregistered users (IPs) may participate in requests for global rights by way of comments, but these will not ultimately be taken into account when deciding consensus, will not count as 'votes' and should not be present in the sections dedicated to voting.
 * This proposal also applies to wiki creator requests.
 * This proposal also adds the 'should not be present in the sections dedicated to voting' to the Request for Comment Policy. This is in order to clarify the position.

Support (1)

 * 1)  For the same reasons I gave in the RfC policy proposal previously. Reception123 (talk) ( C ) 16:33, 14 June 2022 (UTC)
 * 2)  IP editors should not be able to vote in permissions requests. If that's the case then what stops someone from voting with their account and the logout and vote again as an IP? One could argue that you can create multiple accounts to vote but at least with an account, that adds a potential deterrent against that and by creating additional accounts, information such as IPs, user-agents, etc., are logged in CheckUser which helps crackdown on abuse.  Agent Isai  Talk to me! 17:49, 14 June 2022 (UTC)

Oppose (1)

 * 1)  There's nothing inherent that prevents IP users from making good votes. I understand the concerns regarding the strict ratio requirements, but the answer there lies in revising the ratio requirements, not prohibiting IP users from voting. — Chrs (talk) 17:37, 14 June 2022 (UTC)

Proposal 2 (Voting)

 * Users who created their accounts after a request for global rights has been opened may not vote in that request for global rights. Such users may participate in requests for global rights by way of comments, but these will not ultimately be taken into account when deciding consensus, will not count as 'votes' and should not be present in the sections dedicated to voting.
 * This proposal also applies to wiki creator requests.
 * This proposal also adds the 'should not be present in the sections dedicated to voting' to the Request for Comment Policy. This is in order to clarify the position.

Support (2)

 * 1)  For the same reasons I gave in the RfC policy proposal previously. Reception123 (talk) ( C ) 16:33, 14 June 2022 (UTC)
 * 2)  It is important to ensure integrity in an election and to ensure sockpuppetry does not tip the balance, especially during close calls.  Agent Isai  Talk to me! 19:01, 14 June 2022 (UTC)

Oppose (2)

 * 1)  As per my above argument, while I understand the concerns regarding the strict ratio requirements, the answer to sockpuppetry concerns in that regard is to revise the ratio requirement in grant more discretion to the closing Steward. — Chrs (talk) 17:39, 14 June 2022 (UTC)

Proposal 3 (Support ratios)

 * A support ratio of 80% is required for all requests for global rights.

Note: This doesn't change the position for Stewards and Global Sysops, but introduces a ratio for Interwiki Administrators

Support (3)

 * 1)  I don't see any particularly good reasons for why Interwiki Administrators have no support ratio requirement. Reception123 (talk) ( C ) 16:33, 14 June 2022 (UTC)
 * 2)  I see no reason why this shouldn't be added. All successful global Interwiki Administrator requests to date have had over 80%. Global Interwiki Administrators also act as quasi-representatives of Miraheze in the eyes of some so we want to ensure that they have the community's trust and backing.  Agent Isai  Talk to me! 17:51, 14 June 2022 (UTC)

Oppose (3)

 * 1)  I would expect any successful interwiki admin request to garner 80% support (and would agree with Agent Isai's point about IWA's being quasi-representatives of the community), but I generally dislike formalized, strict ratio requirements on the grounds that they constrain Steward discretion in edge cases such as sockpuppetry, especially when you don't have an overwhelming number of voters. — Chrs (talk) 18:14, 14 June 2022 (UTC)
 * The issue with not having support ratios would be the fact that the result could be variable depending on the Steward and would potentially lead to inconsistent results. In terms of sockpuppets, unless they are confirmed (either technically or by circumstances) I don't think it would be fair either way to discount votes (if there were no ratios) simply based on a hunch that someone might be a sockpuppet. Reception123 (talk) ( C ) 18:40, 14 June 2022 (UTC)

Proposal 4.1 (Removal ratios)

 * In order to revoke a Steward or a Global Sysop, there must be at least 50% of votes in favor of removal

Note: This is currently the case for Stewards, but 80% is currently needed to remove a Global Sysop. This Proposal is mutually exclusive with 4.2 and provides for a consistent approach for the two groups.

Support (4.1)

 * 1)  I prefer this proposal because I think 80% is a too high threshold for removal. Since there's already requirements that a certain number of users participate and that a valid reason is provided, there's very little risk in there being a 'revenge vote' from people who didn't originally support the user in their RfGR or RfS. If more than 50% of active community members don't want someone to stay, they should probably go. Reception123 (talk) ( C ) 16:33, 14 June 2022 (UTC)
 * 2)  I don't see why the revocation ration for Global Sysops is so high but not for Stewards. A simple majority should suffice for Global Sysops too. If a removal is unwarranted in the eyes of the community, their overwhelming opposition is enough to counter a revocation vote.  Agent Isai  Talk to me! 17:55, 14 June 2022 (UTC)
 * 3)  If a majority of voters support revocation that is sufficient (and in fact is current policy for Stewards), owing to the procedural safeguards (elaborated above) that we have in place. — Chrs (talk) 18:17, 14 June 2022 (UTC)

Proposal 4.2 (Removal ratios)

 * In order to revoke a Steward or a Global Sysop, there must be at least 80% of votes in favor of removal

Note: This is currently the case for Global Sysops, but only 50% is currently needed to remove a Steward. This Proposal is mutually exclusive with 4.1 and provides for a consistent approach for the two groups.

Oppose (4.2)

 * 1)  Per my preference for Proposal 4.1. It doesn't seem right that if, for example, 75% of users don't want someone to be Steward or GS they can remain. Reception123 (talk) ( C ) 16:33, 14 June 2022 (UTC)
 * 2)  per my support for 4.1. — Chrs (talk) 18:17, 14 June 2022 (UTC)

Proposal 5.1 (Inactivity - Stewards)

 * Stewards who do not participate in the community in some form (responding to questions, dealing with issues facing communities, enforcing global policies, general administrative tasks as a minimum) for 6 months will be deemed inactive and have their steward rights revoked. All wikis as well as Miraheze-related platforms can be taken into account.
 * Once a Steward has their rights revoked for any reason, they must make a successful request that satisfies the criteria above in order to regain the rights.

Note: This proposal only has slight modifications and doesn't change the actual time period which is already at 6 months

Support (5.1)

 * 1)  as proposer, wording modifications only. Reception123 (talk) ( C ) 16:33, 14 June 2022 (UTC)
 * 2)  Minor word tweaks, don't see a reason to oppose these edits which make the section easier to read.  Agent Isai  Talk to me! 19:02, 14 June 2022 (UTC)
 * 3)  Reasonable term of and definition of inactivity. — Chrs (talk) 19:20, 14 June 2022 (UTC)

Proposal 5.2 (Inactivity - Global Sysops)

 * Global Sysops who do not participate in the community in some form (responding to questions, countervandalism, enforcing global policies) for 6 months will be deemed inactive and have their Global Sysop rights revoked. All wikis as well as Miraheze-related platforms can be taken into account.
 * Once a Global Sysop has their rights revoked for any reason, they must make a successful request that satisfies the criteria above in order to regain the rights.

Note: This proposal only has slight modifications and doesn't change the actual time period which is already at 6 months

Support (5.2)

 * 1)  as proposer, wording modifications only. Reception123 (talk) ( C ) 16:33, 14 June 2022 (UTC)
 * 2)  Minor word tweaks which make the section easier to read; doesn't change the time period.  Agent Isai  Talk to me! 18:58, 14 June 2022 (UTC)
 * 3)  Reasonable term of and definition of inactivity. — Chrs (talk) 19:20, 14 June 2022 (UTC)

Proposal 5.3 (Inactivity - Interwiki Administrators)

 * Interwiki administrators who do not participate in the community in some form (responding to questions, adding interwiki prefixes) for 6 months will be deemed inactive and have their Interwiki Administrators rights revoked. All wikis as well as Miraheze-related platforms can be taken into account.
 * Once an Interwiki Administrators has their rights revoked for any reason, they must make a successful request that satisfies the criteria above in order to regain the rights.

Support (5.3)

 * 1)  makes sense for Interwiki administrators to be treated the same and to have to be active in order to keep their role. Reception123 (talk) ( C ) 16:33, 14 June 2022 (UTC)
 * 2)  As a global Interwiki administrator, I strongly support this. There is no other global role that does not have an inactivity clause (apart from Global IP Ban Exemptions but even then, there is precedent for Stewards to remove it if the user is completely inactive for a very long amount of time). Interwiki administrators, like basically all other groups, should have an inactivity clause to ensure housekeeping of the role and to make sure users who have moved on from the project don't retain rights indefinitely for eternity.  Agent Isai  Talk to me! 18:07, 14 June 2022 (UTC)
 * 3)  Reasonable term of and definition of inactivity, adding an inactivity clause makes sense for housekeeping purposes. — Chrs (talk) 19:17, 14 June 2022 (UTC)

Proposal 5.4 (Inactivity - Wiki creators)

 * Wiki creators who have not contributed to the community in any form for at least three months, may have their rights removed. The only activity which is relevant is edits or log actions on Meta.

Note: The current situation as interpreted by Stewards is that all activity (including non-Meta wikis) is counted.

Support (5.4)

 * 1)  If a wiki creator isn't active on Meta for 3 months but only on other wikis that's probably an indication that they're no longer very interested in participating in global community matters (and creating wikis) and that should be considered inactivity for global community purposes. Reception123 (talk) ( C ) 16:33, 14 June 2022 (UTC)
 * 2)  We currently have 15 wiki creators (18 if you include Stewards who can create wikis but aren't wiki creators). Out of these 15 wiki creators, how many have created a wiki in the past month or two? How many have contributed to the community in the past few months? Under half of the current wiki creators have. In fact, in my time as wiki creator, I have not seen some of the users on the wiki creators list ever contribute to Meta or create a wiki. It is important for these users to be active locally and not just be hanging on by a thread for a contribution or two that they did on a wiki that's unrelated to Meta or Miraheze in general.  Agent Isai  Talk to me! 18:18, 14 June 2022 (UTC)
 * 3)  Reasonable term of and definition of inactivity, adding an inactivity clause here makes sense for this role due to the nature of the position (i.e. maintaining an involvement with the community and an understanding of the Content policy). — Chrs (talk) 19:19, 14 June 2022 (UTC)

Proposal 6.1 (Eligibility criteria - All global groups)

 * A candidate must:


 * Have at least 1000 total global edits on Miraheze
 * These edits may not consist of directly copy/pasting content from other wikis, they must be edits done by the user;
 * There should be edits on more than a single wiki, unless the single wiki is Meta
 * Have had their Miraheze account for at least 2 months; and,
 * Be involved in some way in community matters (in discussions on noticeboards, off-wiki chats, etc.)

Note: There is currently no eligibility criteria for Stewards or Global Sysops, only for Interwiki administrators

Support (6.1)

 * 1)  To the best of my knowledge, all users who have ever occupied the roles of Stewards or Global Sysop have had over 1000 edits made, have had an account older than 2 months and contributed to the community in various ways. I think this can help to prevent potential NOTNOW or SNOWBALL requests from relatively new users from being opened and wasting the community's time. It is also codifying an unwritten principle that users should be involved in Miraheze before being elected to a role.  Agent Isai  Talk to me! 18:51, 14 June 2022 (UTC)

Oppose (6.1)

 * 1)  I don't see any good reason to impose strict edit count, account age, or community involvement limitations on candidates, however reasonable they may be, as, philosophically, these things should be left up to the voters. — Chrs (talk) 18:29, 14 June 2022 (UTC)

Proposal 6.2 (Eligibility criteria - Wiki creators)

 * A wiki creator must have:


 * Have at least 300 total global edits on Miraheze
 * These edits may not consist of directly copy/pasting content from other wikis, they must be edits done by the user;
 * There should be edits on more than a single wiki, unless the single wiki is Meta
 * Have had their Miraheze account for at least 2 months; and,

Note: This is different than Proposal 6.1 as it doesn't apply to wiki creators. There is currently no additional eligibility requirements for wiki creators

Support (6.2)

 * 1)  Since it's a bit difficult to judge whether someone is fit to be wiki creator, I think it's fair to require a certain number of criteria to be met which demonstrate that the prospective creator at least has spent some time on Miraheze. This would also prevent most NOTNOW requests from even taking places. Reception123 (talk) ( C ) 18:15, 14 June 2022 (UTC)
 * 2)  per my support of 6.1.  Agent Isai  Talk to me! 18:55, 14 June 2022 (UTC)

Oppose (6.2)

 * 1)  As per my opposition to 6.1, I believe, philosophically, that decisions should be in the hands of the voters, even if the proposed set of criteria is quite reasonable. — Chrs (talk) 18:35, 14 June 2022 (UTC)

Proposal 6.3 (Eligibility criteria - 2FA for Stewards and Global Sysops)
A candidate for Steward or Global Sysop must have two-factor authentication enabled on their account and at all times if their request is successful.

All current Stewards and Global Sysops must enable two-factor authentication if this proposal succeeds.

Note: This proposal is independent of Proposal 6.1 and 6.2 and whether they pass or fail does not affect this proposal.

Reasoning: Stewards and Global Sysops wield a great amount of power and this can be destructive if it falls into the wrong hands, especially tools such as CheckUser for Stewards and locking for both Stewards and Global Sysops.

Support (6.3)

 * 1)  While in practice as far as I'm aware everyone in these groups has 2FA enabled, I think it's important to safeguard accounts with such powers against possible misuse by imposing a very easy thing to enable. Reception123 (talk) ( C ) 16:33, 14 June 2022 (UTC)
 * 2)  Current de facto standard is for all users in high global roles, including Stewards and Global Sysops, to enable 2FA. I don't see any reason why they shouldn't have it enabled. Both have a great amount of power across the entire farm so the security of their accounts is extremely important.  Agent Isai  Talk to me! 18:46, 14 June 2022 (UTC)
 * 3)  2FA is a reasonable safeguard to expect given the broad level of global access available to such users. — Chrs (talk) 19:22, 14 June 2022 (UTC)

Proposal 7.1 (Wiki Creators: Revocation)

 * A wiki creator's rights may be removed by a Steward in the following circumstances:
 * The wiki creator has repeatedly created wikis which violate the Content Policy;
 * The wiki creator has mainly created wikis for their own use and has not focused on their role of creating wikis for other users;
 * The wiki creator has violated any other global policies or the Code of Conduct repeatedly
 * The rights may also be removed by a system administrator if the wiki creator (potentially) causes damage (from a technical view) or creates unreasonable workload for System administrators. If you feel a wiki creator is misusing their privileges, please contact a Steward.

Note: This proposal contains some criteria that already exists but also adds to it.

Support (7.1)

 * 1)  I think that the current criteria is too limited and makes it difficult to remove wiki creators in certain situations. For example, someone who has violated global policies repeatedly has no place evaluating the Content Policy and creating wikis. Reception123 (talk) ( C ) 16:33, 14 June 2022 (UTC)
 * 2)  Arguably this sort of situation might be best handled via a removal vote, but this is a reasonable specific expectation to have of wiki creators under the current procedures that call for removal by a Steward. — Chrs (talk) 19:29, 14 June 2022 (UTC)

Proposal 7.2 (Wiki Creators: Revocation)

 * In addition to the reasons above, this additional reason is added:
 * The wiki creator has repeatedly created wikis with inadequate descriptions which could not possibly have allowed them to determine whether they would violate the Content Policy and/or which have caused an excessive amount of work for Stewards and/or Global Sysops as a result.
 * Prior to being removed, the wiki creator in question should be warned.

Note: This is different from Proposal 7.1 as in that case the wikis must have been found to violate the Content Policy. In this case, the wiki creator will fall under this reason even if the wikis ended up not violating the Content Policy but they could've potentially done so. This reason mainly concerns wiki creators who approve wikis indiscriminately without requiring proper descriptions.

Support (7.2)

 * 1)  While the current rules already provide for a wiki creator who creates wikis the violate the Content Policy repeatedly, the case may very well be that wikis never actually end up violating the Content Policy but the wiki creator was careless and approved wikis where there was a real risk that they would. Therefore I think it's important to also take this into account. Reception123 (talk) ( C ) 16:33, 14 June 2022 (UTC)

Proposal 8

 * In order for a request for global permissions to be successful, the request must have stayed open for at least seven days.
 * Requests may be closed before if it is clear that there is no chance of consensus in favour or if no valid reason/rationale has been given for the request.

Note: There is currently a one week requirement for Global Sysops but not for Stewards or Interwiki administrators.

Support (8)

 * 1)  for consistency reasons. In general, it's fair to give time for users who aren't able to monitor Meta every day to be able to participate in requests and express their views. Reception123 (talk) ( C ) 16:33, 14 June 2022 (UTC)
 * 2)  Reasonable proposal. Requests should be left open for a while to allow people who don't visit Meta on a frequent basis to be able to see them. Additionally, the latter clause will allow for the immediate closing of malformed requests made by new users who probably don't know what they're doing or are getting into this too fast.  Agent Isai  Talk to me! 18:53, 14 June 2022 (UTC)
 * 3)  This would give a reasonable amount of time for users who aren't as active on Meta every day to participate in requests and make their views heard. — Chrs (talk) 19:23, 14 June 2022 (UTC)