Requests for Comment/Miscellaneous RfGR and WC rules

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

There is consensus here for some of the proposals, and this RfC is closed as follows:

• Proposal 1: There is consensus here, with no opposition, so this is successful in the sense of creating an additional policy requirement that is somewhat redundant to user accounts policy. User accounts policy already prohibits using accounts in a deceptive or duplicitous manner, and using multiple accounts, or !voting while logged out, if not reverted or corrected, multiple times would count as deceptive or duplicitous use of multiple accounts. As such, duplicate !votes can or could have already been struck or reverted on that basis. Nevertheless, nothing in policy prohibits Miraheze from having wholly duplicative or redundant policies. In other words, had this proposal not been successful, the status quo is such that !voting with multiple accounts would've already been effectively prohibited per user accounts policy. Likewise, where it was clear a user had !voted twice, once logged in and once logged out, that too would've been prohibited.
• Proposal 2: Successful. Users may !vote in requests for global permissions (including wiki creator) requests provided they created an account prior to the global permissions request in question. Some confusion exists as to "This proposal also adds the 'should not be present in the sections dedicated to voting' to the Requests for Comment Policy. This is in order to clarify the position," so that is stayed until the proponent clarifies to me what he means by that.

  Post-Closure Note: Following clarification from the proponent regarding what he meant by "This proposal also adds the 'should not be present in the sections dedicated to voting' to the Requests for Comment Policy. This is in order to clarify the position," he said it relates to being permitted to procedurally move non-permitted !votes to the correct (i.e., "comments") section from the section(s) related to !voting. That seems quite minor, but nonetheless clearly passes from the proposal. Dmehus (talk) 05:25, 20 June 2022 (UTC)

• Proposal 3: Successful, with a note to Chrs' point on strict ratios. In assessing consensus, Stewards and Meta bureaucrats will have different criteria and methodology in assessing the arguments presented. It is not enough to just !vote with a !vote icon. Similarly, it is not enough to make an argument that goes refuted, or partially refuted, by one or more other users, with supporting evidence to back up a claim. Likewise, users making arguments not about the candidate but may carry less weight than users making substantiated arguments about a candidate's suitability for the given permission. Finally, there may be cases where, based on the number of participants, a clear 80% ratio is not possible, so some rounding up, or rounding down, needs to occur.

  As well, though wiki creator is also a global permission, since the proponent has not specifically mentioned it in the list of permissions with a fixed minimum support ratio requirement and, indeed, this is evidenced by his explicit note that the aim of Proposal 3 is for this to extend to interwiki administrator permissions, that is indeed the outcome of this proposal. As interwiki administrators is a global policy governing both global and local interwiki administrators, and though I believe the intent of Reception123's proposal is for this to apply to global interwiki administrators, there is some ambiguity here that would be worthy of further discussion.

• Proposal 4.1: Successful. The minimum threshold of 50% now extends to Global Sysop revocation requests, for consistency with Stewards. A minimum of ten (10) people must have expressed a view or commented in some way for it to be successful, consistent with a minimum of twenty (20) people having commented or expressed a view for Stewards.
• Proposal 4.2: Moot by Proposal 4.1 passing. If Proposal 4.1 had failed, this would indeed be mutually exclusive of Proposal 4.1.
• Proposal 5.1: Successful, though this also seems to be moot as it appears to be the same as the status quo. Additionally, as Stewards have responsibilities taken up by the former Code of Conduct Commission and in non-wiki channels that have subjected themselves to the Code of Conduct (i.e., Discord, GitHub, Phabricator and IRC), a further community discussion or RfC may be necessary to clarify as to whether take those platforms into consideration for the purposes of assessing Steward inactivity globally.
• Proposal 5.2: Successful.
• Proposal 5.3: Successful.
• Proposal 5.4: Successful. In the past, some Stewards assessed only Meta Wiki activity, while other Stewards assessed global activity. From my perspective, this was confusing because one former Steward and one current Steward seemed to assess only Meta Wiki activity, while another current Steward assessed global activity when I asked him. So this is good to have clarified. For greater clarity, activity considered will be Meta Wiki activity directly related to the wiki creator role (i.e., answering questions on noticeboards or talk pages, approving or declining wikis, etc.).
• Proposals 6.1 and 6.2: No consensus and insufficient participation, so not successful.
• Proposal 6.3: Successful. As I understand it from Universal Omega, mandating two-factor authentication for global groups it not possible. In other words, a Steward without two-factor authentication enabled would still be able to login; however, one alternative would be to restrict the Steward's (or Global Sysop's) ability to use certain Steward and/or Global Sysop restricted user rights. We will leave that up to Stewards to discuss which user right(s) to use, or whether to use the same user right(s) for both groups or different user right(s) for both. The proponent seems to prefer centralauth-lock and that is fine, though we may want to use userrights for Stewards and centralauth-lock for Global Sysops. Note that Miraheze Limited's Accounts Policy, approved by the Board of Directors, already requires this of SRE and Trust and Safety team members.
• Proposal 7.1: Successful.
• Proposal 7.2: Successful.
• Proposal 8: Successful, though as the proponent notes that permissions requests can be closed early if the request is unlikely to be successful, should the inverse not be true (i.e., in cases where a request is unlikely to be unsuccessful (so-called SNOW requests)? This may be worthy of a further discussion/RfC. Dmehus (talk) 23:23, 19 June 2022 (UTC)

---

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: For proposals which 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 Requests for Comment Policy. This is in order to clarify the position.

Support (1)

1.  Support For the same reasons I gave in the RfC policy proposal previously. Reception123 (talk) (C) 16:33, 14 June 2022 (UTC)
2.  Support 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)
3.  Weak support per above. -- Bukkit^{[cetacean needed]} 19:56, 14 June 2022 (UTC)
4.  Strongest support I've said this multiple times, and I'll say it again. User accounts policy should be looked at. --DarkMatterMan4500 (talk) (contribs) 22:59, 14 June 2022 (UTC)
5.  Support As already stated above it is a large risk to give unregistered IP editors the ability to vote in requests for global permissions as it would mean that a single person could access different internet networks around their city and vote multiple times in a request with no consequence. --DeeM28 (talk) 06:46, 15 June 2022 (UTC)
6.  Support per Agent and DeeM28. Startus (talk) 10:21, 15 June 2022 (UTC)
7.  Support Per points raised by others above, especially Agent's. Bawitdaba (talk) 11:16, 15 June 2022 (UTC)
8.  Weak support per my now-struck oppose, I don't consider it to be impossible for an IP editor to be capable of making informed voters, and I don't believe that "ease of sockpuppetry" should disqualify one from voting, but, in the context of the currently-established strict ratio requirements and the apparent emerging consensus in favor of Proposal 3, I will support this and Proposal 2 on the grounds that a potential sockpuppeter would have to prepare socks prior to a request being made. — Chrs (talk) 00:04, 16 June 2022 (UTC)
9.  Support--城市酸儒文人挖坑 (talk) 05:17, 17 June 2022 (UTC)
10.  Support Per what already has been said above Universal Omega (talk) 16:14, 18 June 2022 (UTC)

Oppose (1)

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

   The issue isn't IPs not being able to vote properly. The main issue is that it's easy for a single person to use multiple IPs and therefore it would be easy for someone to vote twice. People who vote should probably be members of the community, not just some random IP editor. Reception123 (talk) (C) 17:42, 15 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 Requests for Comment Policy. This is in order to clarify the position.

Support (2)

1.  Support For the same reasons I gave in the RfC policy proposal previously. Reception123 (talk) (C) 16:33, 14 June 2022 (UTC)
2.  Support 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)
3.  Support This proposal assists in decreasing the possibility of users using multiple accounts to vote in permission requests since once the request is created a user can no longer create a new account to vote in it. Another argument in favour is the fact that a person who creates their account after the permission request can be said to not have enough knowledge about Miraheze or the user in order to start making such assessments. --DeeM28 (talk) 06:46, 15 June 2022 (UTC)
4.  Support. Startus (talk) 10:26, 15 June 2022 (UTC)
5.  Strongest support It should be obvious by now. --DarkMatterMan4500 (talk) (contribs) 10:42, 15 June 2022 (UTC)
6.  Weak support per my statement in Proposal 1. — Chrs (talk) 00:06, 16 June 2022 (UTC)
7.  Support Per what is already said above here, as well what is mentioned throughout proposal 1. Universal Omega (talk) 16:14, 18 June 2022 (UTC)

Oppose (2)

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

Abstain (2)

 Abstain -- Bukkit^{[cetacean needed]} 19:56, 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.  Support 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.  Support 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)
3.  Support Per above. -- Bukkit^{[cetacean needed]} 19:56, 14 June 2022 (UTC)
4.  Support While on one hand ratios can be constraining overall I would agree with this principle. Without ratios for permission requests there is a real risk that Stewards choosing the outcome based on their personal preferences, both in terms of the ratio to be used or if they like or dislike a user. Without ratios a one Steward could close a request with 60% support as successful and another could close one with 75% as unsuccessful. --DeeM28 (talk) 06:46, 15 June 2022 (UTC)
5.  Support I can see reasons why there wouldn't be a high requirement from some groups that are less sensitive but overall I do think this is a good idea. In addition, as already mentioned above all successful interwiki administrator requests to-date have had such support, and it would be good to set an actual policy for this. Universal Omega (talk) 16:16, 18 June 2022 (UTC)

Oppose (3)

1.  Weak oppose 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.  Support 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.  Support 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.  Support 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)
4.  Support the ratio for removal is too high. -- Bukkit^{[cetacean needed]} 19:56, 14 June 2022 (UTC)
5.  Support 50,50 makes sense and it balances the equation here; they are both global groups afterall. --  Joseph  TB  CT  CA  22:53, 14 June 2022 (UTC)
6. It has always been my perspective for positions of trust that appointment be relatively difficult and removal be relatively easy. This 50% requirement supporting removal paired with the 80% support requirement for appointment does just that. dross (t • c • g) 00:46, 15 June 2022 (UTC)
7.  Support I agree with the comments given above. It is clear to me that if a majority of users support removal they should not be denied that right and required to meet the high 80% threshold. The procedural safeguards are enough in my view to prevent spurious attempts to revoke any users with global rights. --DeeM28 (talk) 06:46, 15 June 2022 (UTC)
8.  Support. Startus (talk) 10:30, 15 June 2022 (UTC)
9.  Support 80% is to high for removal so I prefer this over that. Universal Omega (talk) 16:18, 18 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.  Oppose 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.  Oppose per my support for 4.1. — Chrs (talk) 18:17, 14 June 2022 (UTC)
3.  Oppose per my support for 4.1 -- Bukkit^{[cetacean needed]} 19:56, 14 June 2022 (UTC)
4.  Oppose This is tricky, as 80% could help protect some from being unjustly outed, but then ones who misuse their power need to be demoted as soon as possible. Overall, I think if a minimal of 80% needed -- there's more negatives to this than positives. Bawitdaba (talk) 21:58, 14 June 2022 (UTC)
5.  Oppose --  Joseph  TB  CT  CA  22:54, 14 June 2022 (UTC)
6.  Oppose As I support Proposal 4.1. --DeeM28 (talk) 06:46, 15 June 2022 (UTC)
7.  Oppose. I prefer 4.1 above and 80% is too high. Startus (talk) 10:31, 15 June 2022 (UTC)
8.  Oppose per 4.1, I prefer 50% over this. Universal Omega (talk) 16:19, 18 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.  Support as proposer, wording modifications only. Reception123 (talk) (C) 16:33, 14 June 2022 (UTC)
2.  Support 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.  Support Reasonable term of and definition of inactivity. — Chrs (talk) 19:20, 14 June 2022 (UTC)
4.  Weak support Since this is only a wording change this is perfectly acceptable but as others have pointed out I would have very much preferred 3 months. --DeeM28 (talk) 06:46, 15 June 2022 (UTC)
5.  Support. I would like to add that I think it is fine to remove the rights if a steward isn't active on-wiki but I don't think inactivity on discord, IRC or phabricator should be a reason to remove the rights. They should not be compelled to use the platforms (discord and IRC) either, if they don't want to use. Startus (talk) 11:06, 15 June 2022 (UTC)
6.  Support I don't think I can really add much more here. Already said above. Universal Omega (talk) 16:20, 18 June 2022 (UTC)

Oppose (5.1)

1.  Weak oppose I would prefer 3 months. -- Bukkit^{[cetacean needed]} 19:56, 14 June 2022 (UTC)

Abstain (5.1)

1. I would personally much rather see a community initiation of the removal process for inactive stewards, rather than a policy empowered one. I also do not believe that presumably uncontroversial clerical or clarifying edits to existing policy which maintain the spirit of the policy or precedent (such as this one in my opinion) require a community discussion or vote. dross (t • c • g) 00:53, 15 June 2022 (UTC)

   @Dross: It is already currently possible to open a community revocation for any valid reason. I believe the inactivity clause is more of a residual one. --DeeM28 (talk) 06:47, 15 June 2022 (UTC)

   The point I make here is that there should be no defined "valid reason", as stewards operate on community trust only, and nothing else. Any reason which leads to a successful vote for removal is valid. Stewards should be managed by the community alone. dross (t • c • g) 19:36, 16 June 2022 (UTC)

Comments (5.1)

•  Comment: Half a year is way too much though, very much time, a steward that refuses to edit/perform task in six months is literally not having Miraheze in mind --  Joseph  TB  CT  CA  22:56, 14 June 2022 (UTC)
• What are the Miraheze-related platforms? Startus (talk) 10:35, 15 June 2022 (UTC)
  • Miraheze-related platforms refers to things like Discord, IRC, Phabricator. The reason why it was proposed to call them 'Miraheze-related platforms' rather than specific names is in case at a later stage we use new ones, we wouldn't want to be limited. Reception123 (talk) (C) 10:46, 15 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.  Support as proposer, wording modifications only. Reception123 (talk) (C) 16:33, 14 June 2022 (UTC)
2.  Support 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.  Support Reasonable term of and definition of inactivity. — Chrs (talk) 19:20, 14 June 2022 (UTC)
4.  Support Per my comments in Proposal 5.1. --DeeM28 (talk) 06:46, 15 June 2022 (UTC)
5.  Support per my support to 5.1. Startus (talk) 11:09, 15 June 2022 (UTC)
6.  Support Universal Omega (talk) 16:21, 18 June 2022 (UTC)

Abstain (5.2)

1.  Abstain -- Bukkit^{[cetacean needed]} 19:56, 14 June 2022 (UTC)
2.  Abstain consistent with 5.1. dross (t • c • g) 00:54, 15 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.  Support 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.  Support 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.  Support Reasonable term of and definition of inactivity, adding an inactivity clause makes sense for housekeeping purposes. — Chrs (talk) 19:17, 14 June 2022 (UTC)
4.  Support Reasonable. -- Bukkit^{[cetacean needed]} 19:56, 14 June 2022 (UTC)
5. Administrative revocation is reasonable considering IA is a low-impact, largely discretional user group. dross (t • c • g) 00:57, 15 June 2022 (UTC)
6.  Support Per my comments in Proposal 5.1. --DeeM28 (talk) 06:46, 15 June 2022 (UTC)
7.  Weak support Interwiki administrators are non sensitive so I don't see an absolute hard need, but this does provide consistency with other groups, in addition prevents fully inactive users holding these global rights. Universal Omega (talk) 16:23, 18 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.  Support 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.  Support 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.  Support 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)
4.  Support Per above. -- Bukkit^{[cetacean needed]} 19:56, 14 June 2022 (UTC)
5.  Support this is okay --  Joseph  TB  CT  CA  22:58, 14 June 2022 (UTC)
6.  Support consistent with 5.3. dross (t • c • g) 00:59, 15 June 2022 (UTC)
7.  Support In my view it is very important that wiki creators are involved on Meta and with the community. If they are only active on their own personal wikis and do not participate in the Meta community even if such participation is limited to creating wikis there is not much reason for why they should keep their wiki creator role. As an additional but less convincing argument the global requirement imposes an unnecessary burden for Stewards to have to verify each wiki where the wiki creator has edits to view whether they are still active or not. --DeeM28 (talk) 06:46, 15 June 2022 (UTC)
8.  Support. I agree with the arguments made above. Wiki creators should be active on Meta. Startus (talk) 10:42, 15 June 2022 (UTC)
9.  Support Universal Omega (talk) 16:24, 18 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.  Support 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)
2.  Support Per Agent Isai Bawitdaba (talk) 22:02, 14 June 2022 (UTC)

Oppose (6.1)

1.  Oppose 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)
2.  Oppose per Chrs. -- Bukkit^{[cetacean needed]} 19:56, 14 June 2022 (UTC)
3.  Oppose There are some arguments in favor of this proposition and some opposed. In favor of this proposal are two arguments. The first one is that as pointed out above it prevents too early requests which have no chance of passing. The second argument is that it has been observed at times that some members of the community are quick to vote for users in high positions without the users being qualified. Against this proposition is the main argument that we should not be basing things on numbers for Stewards and Global Sysops and instead focus on what those edits are and the quality of the edits. As a personal example I currently have 328 edits across all wikis which would place me extremely far away from being able to be a candidate for either of these positions. The early requests argument is also less convincing as Stewards or even users are able to close such requests early on if there is clear opposition. --DeeM28 (talk) 06:46, 15 June 2022 (UTC)

Comments

1. For whatever it's worth, this has been a discussion I have thought about for some time. Problematically, neither edit count or account age are great indicators of either experience or competency. From a personal perspective, I'd rather see these standards implemented as guidance or framework to nominators, potential nominees, and the participatory community to these Requests. Consider even that Wikimedia projects generally do not require any length of time as a user, and edit count requirements—if present at all—tend to be much lower (e.g. 600 for stewards). Other metrics that prove experience with sysop tools may be more reasonable for proving competency, and could be easily fulfilled and recorded—PTW would be an excellent resource for this. It appears to me that creating required metrics and policy defining which users may stand a vote for appointment somewhat diminishes the "faith" that the community can effectively select its maintainers and representatives. dross (t • c • g) 02:08, 15 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.  Support 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.  Support per my support of 6.1. Agent Isai ^{Talk to me!} 18:55, 14 June 2022 (UTC)
3.  Weak support While I opposed Proposal 6.1 and supporting here may seem outlandish I have decided to support. The main reason is that there is a tendency to assume that wiki creator is a easy role to get and should not be subject to much scrutiny. While they may not have as many rights as Global Sysops or Stewards there is still a lot of power in deciding which wikis are created and which wikis are declined and this should not be taken lightly. As said above in my experience of voting for wiki creators I also have found it difficult to determine whether someone is ready for the position so in this particular case a global edits requirement would be helpful and prevent inexperienced users from getting wiki creator. The 300 rather than 1000 also makes this proposal more attractive and easier to attain for users. --DeeM28 (talk) 06:46, 15 June 2022 (UTC)

Oppose (6.2)

1.  Oppose 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)
2.  Oppose Per Chrs — Preceding unsigned comment added by Bukkit (talk • contribs)
3.  Oppose Wiki Creators are one of the few groups which should actually be required to be active off Meta for the sake of understanding the wider content and community of Miraheze. Considering Wiki Creators are essentially the first line of defense against content violations on Miraheze, it is important that they be exposed to existing content. dross (t • c • g) 02:17, 15 June 2022 (UTC)

   @Dross: This reads more like a support for this proposition rather than an oppose. Or am I mistaken? --DeeM28 (talk) 06:46, 15 June 2022 (UTC)

   Procedural oppose due to unless the single wiki is Meta. dross (t • c • g) 19:34, 16 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.  Support 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)

   2FA is far from "very easy"; infact it is the most common cause of locking account owners out of their accounts. But it's good to know that one user's account is someone else's responsibility, not theirs. Naleksuh (talk) 22:48, 14 June 2022 (UTC)

2.  Support 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.  Support 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)
4.  Support Per above. -- Bukkit^{[cetacean needed]} 19:56, 14 June 2022 (UTC)
5.  Support Very important, we can't allow the wiki host to be compromised. Bawitdaba (talk) 21:54, 14 June 2022 (UTC)
6.  Support As I supported this in relation to interface administrators there is no reason to oppose it here. I believe that requiring such a simple step is perfectly reasonable and allows for a high level of protection against account compromise. I also respectfully disagree with the argument advanced by Naleksuh in relation to the community opposing password policies and believe that the reason for this was because the policies would have been imposed to all users instead of a select few users that have a lot of high-level rights. --DeeM28 (talk) 06:46, 15 June 2022 (UTC)
7.  Strongest support We require it for some even less sensitive groups, we should definitely require for highly sensitive global groups. Universal Omega (talk) 16:28, 18 June 2022 (UTC)

Oppose (6.3)

1. I believe that the security of someone's account is their responsibility to protect. There is a reason why the community opposed password policies. There are also plenty of ways for account compromise to happen outside of 2FA Naleksuh (talk) 22:42, 14 June 2022 (UTC)
2.  Oppose Per Naleksuh. Cheers, Matttest (talk | contribs) 23:29, 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.  Support 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.  Support 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)
3.  Support Per above. -- Bukkit^{[cetacean needed]} 19:56, 14 June 2022 (UTC)
4.  Support I believe it is important to be able to remove wiki creators if their behavior is unwarranted instead of the only removal possibility being for creating wikis that violate the Content Policy which is very narrow and allows in a sense for wiki creator impunity. --DeeM28 (talk) 06:46, 15 June 2022 (UTC)
5.  Support Reasonable. Wiki creators too serve as representatives of Miraheze so unruly and Code of Conduct-violating behavior should not be tolerated. Equally, a wiki creator should be shrewd and while a slip up or two occur on occasion, their overall creations should never cause extreme issues. Agent Isai ^{Talk to me!} 20:25, 16 June 2022 (UTC)
6.  Support Universal Omega (talk) 16:28, 18 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.  Support 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)
2.  Support I believe that this addition to the requirements would be beneficial. This is because while Proposal 7.1 requires a 'result' to occur this proposal places focus on whether the wiki creator is careless in their duties. If a wiki creator is reckless in creating wikis just because these wikis do not actually end up violating the Content Policy it is no defence to the wiki creator because it could have happened because of their actions. --DeeM28 (talk) 06:46, 15 June 2022 (UTC)
3.  Support It is important for wiki creators to make good decisions based on the information available to them. If this means declining a wiki request and requesting more information then a wiki creator should do it to prevent undue burden on our teams later on if these wikis escalate to requiring CVT, SRE or T&S involvement. Agent Isai ^{Talk to me!} 20:27, 16 June 2022 (UTC)
4.  Support Universal Omega (talk) 16:29, 18 June 2022 (UTC)

Comments (7.2)

1.  Comment: Community revocation or steward? -- Bukkit^{[cetacean needed]} 19:56, 14 June 2022 (UTC)

   This would still be steward revocation, but any community member can get in touch with a Steward and ask them to review whether a revocation for a user is warranted. Reception123 (talk) (C) 10:48, 15 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.  Support 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.  Support 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.  Support 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)
4.  Support Stewards are supposed to be very trusted, so no requirement does not make since IMO. -- Bukkit^{[cetacean needed]} 19:56, 14 June 2022 (UTC)
5.  Support I believe that it is important to allow sufficient time for users to discuss the merits of a rights request. There is no reason to rush things and quickly close requests. --DeeM28 (talk) 06:46, 15 June 2022 (UTC)
6.  Support. Users should be given adequate time to comment on the candidates. There is no rush. Startus (talk) 10:54, 15 June 2022 (UTC)
7.  Support Makes sense for this to be a requirement. Can't think of a single reason against it. Universal Omega (talk) 16:30, 18 June 2022 (UTC)

Comments (8)

---

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

Note (post closure for SRE): We should be able to force 2FA for local groups definitely now as this was added in 1.38. I have no idea whether it works for global groups. ~ RhinosF1 - _(chat)^{· acc· c} - (on) 06:00, 20 June 2022 (UTC)