Requests for Comment/Global bans

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 1s: While both 1 and 1.1 both have 100% community support, the wording used in 1 seems more concise and having the greatest number of actual votes, will be the successful one to be implemented.
• Proposal 2s: 2.0.1, 2.1 and 2.3 have sufficient support to be considered as successful. 2.2 is not successful as legitimate concerns around block counting and the criteria to determine what is legitimate are well explained. Further, local policies could determine "a user may be blocked for not being a part of x project" and this would be counted towards criteria for a global ban as it would be done in accordance to local policy, despite not disruption existing.
• Proposal 3s:

• Proposals 3.1, 3.2, 3.3 all pass without any opposition comments.
• Proposals 3.4 and 3.4.1: 3.4 passes and amendments made in 3.4.1 shall apply.
• Proposals 3.5 and 3.5.1: As they are counter proposals to eachother, based on consensus 3.5 is the successful one.
• Proposals 3.5.2 and 3.5.3: Both early closure clauses pass.
• Proposal 3.6: This has been done in a rather awkward way in terms of determining consensus - A user should only have voted for 1 and not multiple as the standard of "a vote for x is an oppose for the rest" can not be applied - so based on this, it is impossible to determine consensus for 3.6. Therefore, no quorum will exist. 15 accounts which has the greatest number of supports would not meet reasonable consensus threshold as the oppositions make 3 against, plus 3 others who did not support this one but supported others.
• Proposals 3.7 and 3.7.1: As these are counter proposals, 3.7 is the successful one.

• Proposal 4s: 4 is successful, but 4.1 and 4.2 are not.
• Proposal 5s: All proposals under 5 pass except 5.1.2.

John (talk) 18:25, 20 August 2022 (UTC)

---

As you all may be aware of, we have seen a recent influx of requests for global bans. Community global bans are something very ill-defined, they exist in a de facto state but there are no official policies governing them, only some loose conventions and practices from Wikimedia. This RfC seeks to formally clarify the procedure on them and establish a policy around them.

• Proposal initiated by: Agent Isai ^{Talk to me!} 17:35, 23 July 2022 (UTC)

• Proposal co-sponsored by: Reception123 (talk) (C) 17:43, 23 July 2022 (UTC)

• Proposal co-sponsored by: Dmehus (talk) 02:15, 2 August 2022 (UTC)

Proposal 1 (Global bans)

A community-imposed global ban is a full revocation of all privileges for a user who has caused issues across multiple communities. It is a measure of last resort, reflecting broad community consensus should other measures fail. Other measures include multiple specific advisories based in policy or best practice to the user and contacting Stewards or Trust and Safety as appropriate to resolve the problem.

Support

1.  Support Solid wording, no issues with this. Agent Isai ^{Talk to me!} 17:35, 23 July 2022 (UTC)
2. Wording fine as expected. MacacoKouhai (talk) 17:56, 23 July 2022 (UTC)
3.  Strong support No issues with rationale and wording provided. Thanks - BrandonWM (talk • contribs • global • rights) 01:48, 24 July 2022 (UTC)
4.  Support Makes clear that community bans aren't the go-to solution but can be used if everything else doesn't work. Reception123 (talk) (C) 07:22, 24 July 2022 (UTC)
5.  Support The definition proposed is appropriate and will help prevent the tyranny of the majority. --DeeM28 (talk) 11:55, 27 July 2022 (UTC)
6.  Support I actually agree here. --DarkMatterMan4500 (talk) (contribs) 13:43, 30 July 2022 (UTC)
7.  Support I agree. ZeusDeeGoose (talk) 23:24, 30 July 2022 (UTC)
8.  Support Universal Omega (talk) 18:15, 31 July 2022 (UTC)
9.  Support — Chrs (talk) 18:09, 1 August 2022 (UTC)
10.  Support as co-sponsor. As I said in Proposal 2 of the companion Meta bans RfC, but it bears repeating as it adds to what this proposal aims to articulate, global community bans must not be a substitute for a Steward globally locking a long-term abuse case, a user with crosswiki conduct issues, or even a user extremely lacking in crosswiki competence, merely to add community support to their actions. As part of their mandate and their own election process, as Stewards, the community has duly elected them to be fair, ideally neutral and impartial in all decisions, but, crucially, to not be afraid to make the tough decisions. Globally locking a single-purpose vandalism only account or likely sockpuppet is not what I'd consider a "tough decision." Dmehus (talk) 02:59, 2 August 2022 (UTC)
11.  Support a policy for the de facto highest form of sanctions was long overdue, as these have been actioned for a while without any formal policies regarding when, how, and requirements for them to be applied. The rationale provided is appropriate and the wording is clear. No issues from me. -- Bukkit^{[cetacean needed]} 08:11, 2 August 2022 (UTC)
12.  Support It is what can be done. — Pixial ^[Talk] 15:44, 10 August 2022 (UTC)
13.  Support --小美粉粉 (T - C - S) 1004065811 bytes of data NOTE: Do not {{ping}} me! 08:58, 17 August 2022 (UTC)

Proposal 1.1 (Global bans)

A community-imposed global ban is a last resort measure for cases where a user's global behavior is not singularly extreme enough to be locked by Stewards or Trust and Safety for policy violations, but has caused significant damage to the community environment or demonstrates an extreme inability to fit the culture of Miraheze. Examples include global delinquents which the community feels Stewards have not adequately addressed, users who create stressful environments across multiple communities they participate in, or users who demonstrate an incredible lack of competence, lack of growth and no signs of integrating well on the platform.

Support

1.  Support If Proposal 1 fails, don't have any issues with this wording. Agent Isai ^{Talk to me!} 17:35, 23 July 2022 (UTC)
2. Wording fine as expected. MacacoKouhai (talk) 17:56, 23 July 2022 (UTC)
3.  Support Cool. Thanks - BrandonWM (talk • contribs • global • rights) 01:49, 24 July 2022 (UTC)
4.  Strong support I don't see a problem with this, in all honesty. --DarkMatterMan4500 (talk) (contribs) 13:44, 30 July 2022 (UTC)
5.  Support I agree with this one as well. ZeusDeeGoose (talk) 23:24, 30 July 2022 (UTC)
6.  Support Universal Omega (talk) 18:15, 31 July 2022 (UTC)
7.  Weak support per above, though I'm not sure how this proposal differs. My quibble would be in terms of the language and reference to delinquents. I find that to be too much of a pejorative term for my liking. As I said in Proposal 2 of the companion Meta bans RfC, but it bears repeating as it adds to what this proposal aims to articulate, global community bans must not be a substitute for a Steward globally locking a long-term abuse case, a user with crosswiki conduct issues, or even a user extremely lacking in crosswiki competence, merely to add community support to their actions. As part of their mandate and their own election process, as Stewards, the community has duly elected them to be fair, ideally neutral and impartial in all decisions, but, crucially, to not be afraid to make the tough decisions. Dmehus (talk) 03:01, 2 August 2022 (UTC)
8.  Support — Pixial ^[Talk] 15:45, 10 August 2022 (UTC)
9.  Support --小美粉粉 (T - C - S) 1004065811 bytes of data NOTE: Do not {{ping}} me! 08:58, 17 August 2022 (UTC)

Proposal 2 (Criteria for a global ban)

The following are all proposals regarding what the criteria for a global ban should be. Each proposal in this section is independent and is not reliant on any other proposal within this section.

Proposal 2.0.1

For the following sections in Proposal 2, 'Phabricator' can be counted along with 'wiki' when determining whether criteria is met. So for example, Proposal 2.1 can include disruption on Phabricator as helping towards meeting the criteria of 'disruption on various Miraheze wikis', Proposal 2.2 can count blocks on Phabricator as helping towards meeting the threshold of 'multiple wikis' where someone is banned, etc.

Support

1.  Support Phabricator is an extension of Miraheze and counts as a project too. If a user is disrupting Phabricator, this should definitely count towards meeting any criteria. Agent Isai ^{Talk to me!} 17:35, 23 July 2022 (UTC)
2. MacacoKouhai (talk) 17:56, 23 July 2022 (UTC)
3.  Support It seems fair to include Miraheze-run platforms in this. Reception123 (talk) (C) 07:22, 24 July 2022 (UTC)
4.  Support The community should be allowed to determine a user's actions and character based on other Miraheze spaces and not exclusively wikis. --DeeM28 (talk) 11:55, 27 July 2022 (UTC)
5.  Support As others have said, Phabricator is a part of Miraheze and should be included. ZeusDeeGoose (talk) 23:24, 30 July 2022 (UTC)
6.  Strong support I see no problem with this ruling. --DarkMatterMan4500 (talk) (contribs) 12:12, 31 July 2022 (UTC)
7.  Support Universal Omega (talk) 18:17, 31 July 2022 (UTC)
8.  Support Phabricator disruption is certainly relevant. — Chrs (talk) 18:10, 1 August 2022 (UTC)

Oppose

1.  Weak oppose. Thanks - BrandonWM (talk • contribs • global • rights) 01:50, 24 July 2022 (UTC)
2. Procedural  Oppose While Phabricator is like a wiki in many respects, the community, other than technically-involved community members (i.e., with GitHub commits and PRs), do not have a say in matters related to Phabricator. It seems procedurally wrong to me to consider Phabricator activity in a proposal to globally ban someone through the community when the community itself has no say in the Phabricator administrative decision making. Moreover, if a user is sitewide blocked on Meta Wiki, they are effectively prohibited from using Phabricator, so I'm not sure this is necessary either. In other words, if a user is blocked on Meta Wiki, they're prohibited from using Phabricator (i.e., they cannot login to Phabricator, unless they already have a Phabricator account and have linked their GitHub account, of course). Dmehus (talk) 03:08, 2 August 2022 (UTC)
3.  Oppose No need for a block on Phabricator because someone got locked on Miraheze. They are different projects. — Pixial ^[Talk] 15:50, 10 August 2022 (UTC)
4.  Oppose per Doug Mehus --小美粉粉 (T - C - S) 1004065811 bytes of data NOTE: Do not {{ping}} me! 08:59, 17 August 2022 (UTC)

Proposal 2.1 (Disruption of various wikis)

The following criteria must be met in order for a global ban to be requested:

The user has persistently disrupted various Miraheze wikis.

Note: This is cumulative. If any other criteria are passed, they must also be met in order to satisfy the requirements for a global ban.

Support

1.  Support This is important to stop frivolous global ban requests from being made. "Disruptive behavior" shouldn't be hard to discern or evaluate, so I have no issue with this as all successful global ban RfCs meet this criteria. Agent Isai ^{Talk to me!} 17:35, 23 July 2022 (UTC)
2. MacacoKouhai (talk) 17:56, 23 July 2022 (UTC)
3.  Support This should be left up to the community to decide if they meet this criteria. Thanks - BrandonWM (talk • contribs • global • rights) 01:52, 24 July 2022 (UTC)
4.  Support If someone is to be banned globally it's only fair that their actions have been global, otherwise local bans are enough. Reception123 (talk) (C) 07:22, 24 July 2022 (UTC)
5.  Support While this seems to be quite evidently required for a global ban I have no issue with codifying this. --DeeM28 (talk) 11:55, 27 July 2022 (UTC)
6.  Strongest support I don't see an issue with this preventative measure, if it holds true. --DarkMatterMan4500 (talk) (contribs) 13:46, 30 July 2022 (UTC)
7.  Support I agree. ZeusDeeGoose (talk) 23:24, 30 July 2022 (UTC)
8.  Support Universal Omega (talk) 18:17, 31 July 2022 (UTC)
9.  Support — Chrs (talk) 18:13, 1 August 2022 (UTC)
10.  Support --  Joseph  TB  CT  CA  22:42, 1 August 2022 (UTC)
11.  Support as co-proposer and per my comments above. Dmehus (talk) 03:18, 2 August 2022 (UTC)
12.  Support Obviously. Mainly cross wiki abuses. — Pixial ^[Talk] 15:51, 10 August 2022 (UTC)
13.  Support per Doug Mehus --小美粉粉 (T - C - S) 1004065811 bytes of data NOTE: Do not {{ping}} me! 09:01, 17 August 2022 (UTC)

Proposal 2.2 (Blocked on multiple wikis)

The following criteria must be met in order for a global ban to be requested:

The user must have bona fide blocks on multiple (3+) Miraheze wikis (this may include Phabricator). These blocks must have been done in accordance with any local community-endorsed blocking policies (if they exist) and/or global policies.

Note: This is cumulative. If any other criteria are passed, they must also be met in order to satisfy the requirements for a global ban.

Note: Should this proposal pass, the community empowers Stewards to discount any local blocks which they construe, in their determination and discretion, to have been made in an unfair or unjustified manner or which were made contrary to any global policies, broadly interpreted.

Support

1.  Support This is important to stop frivolous global ban requests from being made. All successful global bans to date have met this criteria so thus I have no issues with this. Agent Isai ^{Talk to me!} 17:35, 23 July 2022 (UTC)
2.  Support Per Agent. While this requirement may be strict I think it's important to have a high bar in order to prevent frequent requests. Reception123 (talk) (C) 07:22, 24 July 2022 (UTC)
3.  Weak support This can be made possible to an extent. --DarkMatterMan4500 (talk) (contribs) 13:48, 30 July 2022 (UTC)
4.  Strong support per above and as co-proposer. I do not understand the current opposing viewpoints, as global bans are meant to be a last resort (many of those opposing this sub-proposal even supported that in the main proposal). As such, I cannot square the circle, or dot the "i," when it is generally accepted Steward and Global Sysop convention/practice that disruption should/must be occurring on multiple wikis with the notion that someone could be globally banned by the community for disruption on a single wiki, particularly when there is also this companion Meta Wiki community ban proposal for Meta Wiki community bans, which has wide support. Dmehus (talk) 03:23, 2 August 2022 (UTC)
5.  Weak support per above. Kourouklides (talk) 00:58, 5 August 2022 (UTC)
6.  Support per above. Also in accordance with Fandom's Wiki Rules and Blocking Policy --小美粉粉 (T - C - S) 1004065811 bytes of data NOTE: Do not {{ping}} me! 09:00, 17 August 2022 (UTC)

Oppose

1. This is grounds for abuse and doesn't really stop anything. For one, Wikimedia is currently considering removing their requirement for local blocks, on the basis that 1) most successful global bans were based on disruption on a single project, and being blocked on multiple is just a coincidence 2) You can damage multiple wikis or the project as a whole without being blocked on multiple. Also, this requirement is both number creep and incites an idea that a user should be globally banned for being blocked on 3 wikis. Reception123 is blocked on six wikis and is a steward (though I did oppose the RfS, the 6 blocks had nothing to do with that). Naleksuh (talk) 17:48, 23 July 2022 (UTC)

   Regarding the last point about Reception123 being banned on 6 wikis, I wouldn't count those as bona fide blocks as they're all made without any valid reason backing them and thus they wouldn't count for the purposes of meeting the criteria. Agent Isai ^{Talk to me!} 17:51, 23 July 2022 (UTC)

   Okay, so how will the policy determine which are "valid" and which are "invalid"? During the last RFC one of the ideas was blocks in which the user has no local edits, but that wouldn't work on its own (for people like CVT etc). Also, the block criteria is bad for other reasons as well. Naleksuh (talk) 17:55, 23 July 2022 (UTC)

   There can potentially be some complicated cases but usually it's quite clear if a block is "valid". It would have to either follow a local policy or otherwise clearly be done as a result of a user's inappropriate behavior as determined by local admins. The bar doesn't need to be set high (as in asking ourselves whether we would've done that block) but the 'bona fide' part is there to ensure that baseless blocks aren't included (such as ones for no reason or because the local admins have something against the user, etc.) Reception123 (talk) (C) 18:03, 23 July 2022 (UTC)

2.  Weak oppose This isn’t really necessary as it easily can be circumvented. Thanks - BrandonWM (talk • contribs • global • rights) 01:54, 24 July 2022 (UTC)
3.  Weak oppose I have considered this proposal and have decided to oppose. While it seems reasonable to require a number of blocks in principle it is my belief that there are too many inconsistent practices across the wiki farm in order to make this a reality. The bona fide rule might be a good idea but even so it invites a very subjective level of interpretation from Stewards which does not seem right in my opinion and is likely to cause issues and more questions of community and Stewards. I weakly oppose this as I do not wish for there to be no requirement but for an alternative that does not require such a subjective belief. In the absence of that I would prefer there being no extra requirement. --DeeM28 (talk) 11:55, 27 July 2022 (UTC)
4.  Oppose Per DeeM28. Universal Omega (talk) 18:20, 31 July 2022 (UTC)

Abstain

1. I don't know because there might be cases of extreme bigotry and perversion, so I don't think x-wiki blocks matter. MacacoKouhai (talk) 17:57, 23 July 2022 (UTC)
2.  Neutral I like the bona fide rule, but I'm not completely convinced of the need for a hard quantitative bar. — Chrs (talk) 18:16, 1 August 2022 (UTC)
3. I find myself echoing Chrs here. I would like to see a policy recognizing and affirming these bona fide blocks, but without the quantitative value. Something along the lines of "user has a history of bona fide blocks on Miraheze projects" would be ideal. dross (t • c • g) 22:27, 16 August 2022 (UTC)

Proposal 2.3 (Conduct issues)

The following criteria must be met in order for a global ban to be requested:

The user must exhibit conduct issues and remediation attempts to address such conduct have failed.

Note: This is cumulative. If any other criteria are passed, they must also be met in order to satisfy the requirements for a global ban.

Support

1.  Support Per my support of 2.1. This is very important in order to have a solid, valid basis for a global ban, as per Proposal 1 which mentions that this should be sought as a last resort. Agent Isai ^{Talk to me!} 17:35, 23 July 2022 (UTC)
2. MacacoKouhai (talk) 17:56, 23 July 2022 (UTC)
3.  Support by default. Thanks - BrandonWM (talk • contribs • global • rights) 01:54, 24 July 2022 (UTC)
4.  Support Makes sense and similar to 2.1. Reception123 (talk) (C) 07:22, 24 July 2022 (UTC)
5.  Support This proposal seems logical for similar reasons to 2.1. --DeeM28 (talk) 11:55, 27 July 2022 (UTC)
6.  Support Per above. ZeusDeeGoose (talk) 23:24, 30 July 2022 (UTC)
7.  Support I don't even need to explain why I am supporting this. It should be obvious by now. --DarkMatterMan4500 (talk) (contribs) 12:14, 31 July 2022 (UTC)
8.  Support Universal Omega (talk) 18:21, 31 July 2022 (UTC)
9.  Support Uncontroversial. — Chrs (talk) 18:16, 1 August 2022 (UTC)
10.  Support --  Joseph  TB  CT  CA  22:43, 1 August 2022 (UTC)
11.  Support as co-proposer and per my comments above, this is essential. Dmehus (talk) 03:26, 2 August 2022 (UTC)
12.  Support per above --小美粉粉 (T - C - S) 1004065811 bytes of data NOTE: Do not {{ping}} me! 09:03, 17 August 2022 (UTC)

Proposal 3.1 (Procedure)

To begin the process of requesting a global ban for a user, a Request for Comment must be filed on Miraheze Meta. Criteria, as established, must be met:

Support

1.  Support This is already the de facto standard so I see no issue in codifying it. Agent Isai ^{Talk to me!} 17:35, 23 July 2022 (UTC)
2. MacacoKouhai (talk) 17:56, 23 July 2022 (UTC)
3.  Support Already done. Thanks - BrandonWM (talk • contribs • global • rights) 01:55, 24 July 2022 (UTC)
4.  Support --DeeM28 (talk) 11:55, 27 July 2022 (UTC)
5.  Support Isn't this already required though? ZeusDeeGoose (talk) 23:24, 30 July 2022 (UTC)
6.  Support Universal Omega (talk) 18:22, 31 July 2022 (UTC)
7.  Support This is the current de facto standard, I see no reason for it to be otherwise. — Chrs (talk) 18:18, 1 August 2022 (UTC)
8.  Support as obvious, but, as co-proposer, I would've preferred to the sub-proposal(s) bundled into this one for greater clarity and less ambiguity. Dmehus (talk) 03:28, 2 August 2022 (UTC)
9.  Support --小美粉粉 (T - C - S) 1004065811 bytes of data NOTE: Do not {{ping}} me! 09:06, 17 August 2022 (UTC)
10.  Strongest support As always, I absolutely 100% agree with this. --DarkMatterMan4500 (talk) (contribs) 15:44, 17 August 2022 (UTC)

Proposal 3.2 (Notice)

Once a Request for Comment for a global ban has been filed on Miraheze Meta, the nominator must post a notice on all wikis where the user is active informing them that a Request for Comments regarding that user has been stated. This notice should be posted in a high-visibility venue such as a central discussion forum or the talk page of the main page if none exists.

When posting the notice, the user should remain neutral in tone and should refrain from extra, unnecessary commentary on the notice.

Note: For greater clarity, active is defined as any attached wiki where the user had at least one edit (1) contribution according to their Special:CentralAuth.

Support

1.  Support This is a standard on Wikimedia so I see no issues with this happening as this allows all affected communities to have a voice in the process. Agent Isai ^{Talk to me!} 17:35, 23 July 2022 (UTC)
2. MacacoKouhai (talk) 17:56, 23 July 2022 (UTC)
3.  Support per above. Reception123 (talk) (C) 07:22, 24 July 2022 (UTC)
4.  Support Because a lot of users I am sure do not regularly check Meta this is necessary for a fair process. --DeeM28 (talk) 11:55, 27 July 2022 (UTC)
5.  Support Per above. ZeusDeeGoose (talk) 23:24, 30 July 2022 (UTC)
6.  Support Universal Omega (talk) 18:22, 31 July 2022 (UTC)
7.  Support It's important to keep communities in the loop. — Chrs (talk) 18:19, 1 August 2022 (UTC)
8.  Support as co-proposer. Dmehus (talk) 03:40, 2 August 2022 (UTC)
9.  Support --小美粉粉 (T - C - S) 1004065811 bytes of data NOTE: Do not {{ping}} me! 09:05, 17 August 2022 (UTC)

Proposal 3.3

If the nominated user is locally blocked on Meta, they may be temporarily unblocked to defend themselves. If the user begins to engage in disruptive behaviors or behavior that goes against the Code of Conduct, they will be re-blocked.

Support

1.  Support This is very important so that the user can defend themselves instead of having to reply via proxy to the request or to comments. Meta admins are active enough to monitor any misbehaving users and swiftly reblock them if they disrupt Meta. Agent Isai ^{Talk to me!} 17:35, 23 July 2022 (UTC)
2. A voice is needed. MacacoKouhai (talk) 17:56, 23 July 2022 (UTC)
3.  Support It wouldn't be fair to not give a user who will be indefinitely banned a say. Reception123 (talk) (C) 07:22, 24 July 2022 (UTC)
4.  Support No objections. A user should be allowed to exclusively edit the community ban request page and have a chance to give their point of view. --DeeM28 (talk) 11:55, 27 July 2022 (UTC)
5.  Support I agree, they should be given a chance to potentially defend themselves. ZeusDeeGoose (talk) 23:24, 30 July 2022 (UTC)
6.  Support Universal Omega (talk) 18:23, 31 July 2022 (UTC)
7.  Support This is a basic element of due process; if the user engages in Meta disruption as a result of such an unblock, let that act speak for itself. — Chrs (talk) 18:20, 1 August 2022 (UTC)
8.  Support --  Joseph  TB  CT  CA  22:44, 1 August 2022 (UTC)
9.  Support as co-proposer, per my comments above and here, which are in line with Chrs' comments most closely. To his last comment, if the disruption continues, I would even say Stewards should feel empowered to lock the user as long-term abuse on the spot. Dmehus (talk) 03:48, 2 August 2022 (UTC)
10.  Support --小美粉粉 (T - C - S) 1004065811 bytes of data NOTE: Do not {{ping}} me! 09:07, 17 August 2022 (UTC)
11.  Strong support I would be in favor of this, if I'm saying this publicly. --DarkMatterMan4500 (talk) (contribs) 18:29, 17 August 2022 (UTC)

Proposal 3.4 (Accounts)

In order to file a request for a global ban, the nominator must have:

• A Miraheze account which is at least 6 months old
• At least 500 global edits. These edits may not consist of directly copy/pasting content from other wikis, they must be edits done by the user.

Support

1.  Support To prevent frivolous global ban requests that will waste our time. Agent Isai ^{Talk to me!} 17:35, 23 July 2022 (UTC)
2. MacacoKouhai (talk) 17:56, 23 July 2022 (UTC)
3.  Support In order to try to prevent grudges and users trying to ban others. A user with less edits and account age can always discuss with a more senior user and have them open the global ban if it has merits. Reception123 (talk) (C) 07:22, 24 July 2022 (UTC)
4.  Weak support While it does seem a bit strict and could undoubtedly limit valid requests I understand that the reasoning behind this is to prevent community bans being opened by users who have an "enemy" so it is reasonable to keep this. --DeeM28 (talk) 11:55, 27 July 2022 (UTC)
5.  Weak support per Reception --小美粉粉 (Talk) (Contribs) (Sandbox) (My Wiki) (Global Contribs) 1004065811 bytes of data NOTE: Do not {{ping}} me! 03:30, 30 July 2022 (UTC)
6.  Support Seems fair. ZeusDeeGoose (talk) 23:24, 30 July 2022 (UTC)
7.  Weak support 500 global edits is not many, considering we require 1,000 global edits as a prerequisite to be eligible to run for interwiki administrator. As such and as co-proposer, I preferred the original 1,000 edit requirement, which was quite reasonable. That said, with the other conditions, including being blocked on multiple wikis, the quorum, and notification requirements, and per this being a last resort, I can support this, albeit in the weakest way possible. Dmehus (talk) 03:53, 2 August 2022 (UTC)
8.  Weak support Universal Omega (talk) 04:20, 2 August 2022 (UTC)
9.  Support Per above. --DarkMatterMan4500 (talk) (contribs) 15:45, 17 August 2022 (UTC)

Proposal 3.4.1 (Accounts)

The last requirement mentioned in proposal 3.4 is amended to say "1,000" global edits instead of "500",

Support

1.  Weak support The nominator MUST have large number of experiences. --小美粉粉 (Talk) (Contribs) (Sandbox) (My Wiki) (Global Contribs) 1004065811 bytes of data NOTE: Do not {{ping}} me! 03:27, 30 July 2022 (UTC)
2.  Strongest support as co-proposer, per my comments here. Dmehus (talk) 03:55, 2 August 2022 (UTC)
3.  Support This is much better. I prefer 1,000 over 500, it makes more sense to me. Universal Omega (talk) 04:21, 2 August 2022 (UTC)
4.  Support ZeusDeeGoose (talk) 14:42, 2 August 2022 (UTC)

Oppose

 Weak oppose Nah, that's a bit too high in my opinion. 500 edits takes a long time to get to. ZeusDeeGoose (talk) 23:24, 30 July 2022 (UTC)

1. ZeusDeeGoose, it's 1,000 global edits, not 1,000 Meta Wiki edits (which, even I agree, would be too high a bar). You can see my additional comments here. Dmehus (talk) 03:57, 2 August 2022 (UTC)

Proposal 3.5 (Duration of Global ban RfC)

Request for Comments dealing with a global ban proposals must stay opened for a minimum of seven (7) calendar days, beginning after the notification process in accordance with Proposal 3.2.

Note: This proposal is an alternative to Proposal 3.5.1

Support

1.  Support This is important so that the accused user can have due process, so that all users can see the request and so that all sides can get their argument in to allow users to vote in an informed manner. Agent Isai ^{Talk to me!} 17:35, 23 July 2022 (UTC)
2. MacacoKouhai (talk) 17:56, 23 July 2022 (UTC)
3.  Support I agree. ZeusDeeGoose (talk) 23:24, 30 July 2022 (UTC)
4.  Support I agree in case Proposal 3.5.1 does not pass. Kourouklides (talk) 03:53, 2 August 2022 (UTC)
5.  Weak support per Kourouklides as my preference would be for proposal 3.5.1 per due process and procedural fairness. Proposal 3.5.2 allows for early closure should either of Proposal 3.5 or 3.5.1 pass, so no concerns there. Dmehus (talk) 04:02, 2 August 2022 (UTC)
6.  Weak support I support the minimum open day 's limitation proposal, but I support 30 days, not 7 days. --小美粉粉 (Talk) (Contribs) (Sandbox) (My Wiki) (Global Contribs) 1004065811 bytes of data NOTE: Do not {{ping}} me! 13:12, 2 August 2022 (UTC)
7.  Weak support Depends on the context that a global ban falls under. If it takes more than 7 days, then that would be an exception. --DarkMatterMan4500 (talk) (contribs) 15:46, 17 August 2022 (UTC)

Oppose

1.  Oppose That bar is too high in my opinion. --DeeM28 (talk) 11:55, 27 July 2022 (UTC)
2.  Oppose For consistency I don't think it's necessary to deviate from the regular RfC rules and I doubt two days of extra mandatory open time would really add anything. It's better to stay consistent as to not introduce too many different rules inside the RfC process since technically global bans are considered RfCs. Reception123 (talk) (C) 19:51, 16 August 2022 (UTC)

Proposal 3.5.1 (Duration of Global ban RfC)

Request for Comments dealing with a global ban proposals must stay opened for a minimum of thirty (30) calendar days, beginning after the notification process in accordance with Proposal 3.2.

Note: This proposal is an alternative to Proposal 3.5

Support

1.  Strong support - I agree. Kourouklides (talk) 04:00, 2 August 2022 (UTC)
2.  Strong support as co-proposer, per due process and procedural fairness, and per Kourouklides. Dmehus (talk) 04:04, 2 August 2022 (UTC)
3.  Strong support Me too --小美粉粉 (Talk) (Contribs) (Sandbox) (My Wiki) (Global Contribs) 1004065811 bytes of data NOTE: Do not {{ping}} me! 13:04, 2 August 2022 (UTC)

Oppose

1.  Oppose In my opinion there is no need for such a long timeline and the current rules set out for Requests for Comment are perfectly acceptable here. --DeeM28 (talk) 11:55, 27 July 2022 (UTC)
2.  Weak oppose per above, 30 days is a bit long. ZeusDeeGoose (talk) 23:24, 30 July 2022 (UTC)
3.  Oppose I don't think there's a need for this extra safeguard and I think especially if not banned on Meta it could potentially cause the user to be able to continue to damage the project and there could be an awkward situation where a discussion is stale after a few days and the user is all but banned but they'd be able to freely edit until the 30 days are done. If 15 users have participated and there is consensus on a ban I don't see why there is a need to wait 30 days. If there's still ongoing discussions I'm sure Stewards won't close the discussion prematurely. Reception123 (talk) (C) 19:49, 16 August 2022 (UTC)
4.  Weak oppose That would make any RfC focusing on global bans linger longer. --DarkMatterMan4500 (talk) (contribs) 15:48, 17 August 2022 (UTC)

Proposal 3.5.2 (Early closure)

A Request for Comments with a global ban proposal can be closed by a Steward before the timeframe outlined in Proposal 3.5 or 3.5.1 (depending which passes) has passed if it is malformed or if it there is overwhelming consensus against the proposal.

Note: This is dependent on proposal 3.5 or 3.5.1.

Support

1.  Support This will allow Stewards to close frivolous requests that will only waste the community's time which will clearly fail/malformed requests. Agent Isai ^{Talk to me!} 17:35, 23 July 2022 (UTC)
2. MacacoKouhai (talk) 18:00, 23 July 2022 (UTC)
3.  Support per the RfC policy, makes sense. Reception123 (talk) (C) 07:22, 24 July 2022 (UTC)
4.  Support In accordance with the RfC rules. No issues. --DeeM28 (talk) 11:55, 27 July 2022 (UTC)
5.  Support I agree. ZeusDeeGoose (talk) 23:24, 30 July 2022 (UTC)
6.  Support Yes, it will allow Stewards to close, or delete, frivolous community ban requests early, but they always could. That's obvious. More importantly, this and Proposal 3.5.2 moot any opposing arguments made in Proposal 3.5 and 3.5.1 about it being too long, as it allows for early closure in so-called "SNOW" requests (i.e., twenty (20) supports, no opposes). Dmehus (talk) 04:08, 2 August 2022 (UTC)
7.  Support --小美粉粉 (T - C - S) 1004065811 bytes of data NOTE: Do not {{ping}} me! 09:09, 17 August 2022 (UTC)

Abstain

1.  Abstain Didn't this become an issue later on this year? --DarkMatterMan4500 (talk) (contribs) 15:49, 17 August 2022 (UTC)

Proposal 3.5.3 (Early closure)

A Request for Comments with a global ban proposal can be closed before the timeframe outlined in Proposal 3.5 or 3.5.1 (depending which passes) has passed if there is overwhelming consensus for it and the nominated user agrees to be globally banned.

Support

1.  Support No need to drag out a process if a user agrees that they're guilty Agent Isai ^{Talk to me!} 17:35, 23 July 2022 (UTC)
2. MacacoKouhai (talk) 18:00, 23 July 2022 (UTC)
3.  Support As demonstrated by the most recent community ban, this is a good idea. Reception123 (talk) (C) 07:22, 24 July 2022 (UTC)
4.  Support Per above. There is no need to keep a request open if the user who is subject of the request agrees to it, it is like pleading guilty. --DeeM28 (talk) 11:55, 27 July 2022 (UTC)
5.  Support Same as before. ZeusDeeGoose (talk) 23:24, 30 July 2022 (UTC)
6.  Support per above as co-proposer, though I quibble with Agent Isai's choice of phrasing that the user agrees they're 'guilty'. It's not about necessarily, nor is this a court of law. It's whether or not the user agrees that their participation is not conducive for a social community-oriented environment. Dmehus (talk) 04:10, 2 August 2022 (UTC)
7.  Support --小美粉粉 (T - C - S) 1004065811 bytes of data NOTE: Do not {{ping}} me! 09:11, 17 August 2022 (UTC)

Proposal 3.6 (Quorum)

In addition to meeting the requirements of Requests for Comment Policy requirements, a global ban request must also include (choose) accounts expressing a view (in favour, opposed, or neutral).

Support (10 accounts)

1.  Support only if the 15 accounts proposal fails; per my support of the following proposal. Agent Isai ^{Talk to me!} 17:35, 23 July 2022 (UTC)
2.  Support If 10 accounts are trusted to elect a Global Sysop which has considerable power and is able to globally lock accounts as well as perform many functions across all wikis I find it difficult to believe that banning a single user should require 15 accounts. --DeeM28 (talk) 11:55, 27 July 2022 (UTC)

Support (15 accounts)

1.  Support It's important for multiple users to express their views in order to ban someone and for this process to truly be a 'measure of last resort' and not just an overly blunt instrument used to kick someone off who a few users have a grudge against. Agent Isai ^{Talk to me!} 17:35, 23 July 2022 (UTC)
2.  Support It is quite important that a global ban should only be imposed when all remediation attempts failed. Cheers, Matttest (talk | contribs) 04:36, 24 July 2022 (UTC)
3.  Support Per above, while admittedly the last community ban didn't have 15 votes I think it's important to prevent users teaming up to get rid of someone they don't like. Reception123 (talk) (C) 07:22, 24 July 2022 (UTC)
4.  Support per above, though I prefer 20 users as the co-proposer. Per my comments around procedural fairness and due process, it's essential. Ten participants for a global community ban is too low. If the user is truly abusive or disruptive, though, nothing precludes a Steward or Global Sysop from globally locking a user as such, regardless of the level of community support. This is, after all, meant to be the absolute last resort. Dmehus (talk) 04:20, 2 August 2022 (UTC)

Support (20 accounts)

1. MacacoKouhai (talk) 18:00, 23 July 2022 (UTC)
2.  Strong support per my comments around due process and procedural fairness, notably here, and since this is meant to be a last resort, the bar needs to be high. We require twenty (20) unique users to participate in Requests for Stewardship; it holds the same requirement should be true for a global community ban discussion. Dmehus (talk) 04:16, 2 August 2022 (UTC)
3.  Support per Doug Mehus --小美粉粉 (Talk) (Contribs) (Sandbox) (My Wiki) (Global Contribs) 1004065811 bytes of data NOTE: Do not {{ping}} me! 13:14, 2 August 2022 (UTC)
4.  Weak support Any of these numbers could do just fine. --DarkMatterMan4500 (talk) (contribs) 18:23, 17 August 2022 (UTC)

Oppose (any)

1.  Oppose I oppose 15 and 20 accounts per my comment in supporting 10. --DeeM28 (talk) 11:55, 27 July 2022 (UTC)
2.  Oppose per ten (10) per my comments here. I feel that ten (10) unique users is far too few participants when we require twenty (20) users to participate in a Requests for Stewardship; it holds we should require at least that in a global community ban discussion. That said, if there was clear crosswiki disruption, vandalism, or extreme competency issues, and there were not 15 or 20 unique users participating but there were ten (10) users, I feel that Stewards would feel empowered to use that support to globally lock the user for crosswiki abuse or even extreme competency issues anyway. But as to a full global community ban, it needs a stricter requirement. Dmehus (talk) 04:24, 2 August 2022 (UTC)
3.  Oppose per Doug Mehus, I oppose 10 & 15 accounts, support for 20 accounts. --小美粉粉 (Talk) (Contribs) (Sandbox) (My Wiki) (Global Contribs) 1004065811 bytes of data NOTE: Do not {{ping}} me! 13:15, 2 August 2022 (UTC)

Comments & Abstain

1.  Abstain Depends on the RfC, but 15 seems best. ZeusDeeGoose (talk) 23:24, 30 July 2022 (UTC)
2. I conditionally  Support (20 accounts) for this proposal. Otherwise, if Support (20 accounts) is not successful, then I Support (15 accounts). In any other case, I would  Abstain. Kourouklides (talk) 00:40, 5 August 2022 (UTC)

Proposal 3.7 (Level of consensus)

While Stewards will assess and weigh arguments and counter-arguments presented, as in the case of all RfCs and global permissions requests, the community advises that, all else being equal, the level of consensus should be 70-80%, in keeping with our global permissions requests support ratio and to ensure the level of consensus in favour is very strong. Additionally, this helps to provide a level of due process that has not always existed in past community bans.

Note: This is an alternate proposal to Proposal 3.7.1.

Support

1.  Strong support As Proposal 1 says, global bans should reflect broad community consensus. A global ban with 51% support should not be considered as successful, only requests with overwhelming community support should, in order to allow for a fair and due process. If a user is truly disruptive and causing lots of issues, I'm sure that there'll be no issues in getting to that support ratio. Agent Isai ^{Talk to me!} 17:35, 23 July 2022 (UTC)
2. MacacoKouhai (talk) 18:00, 23 July 2022 (UTC)
3.  Support Basically the current status quo for RfCs. Reception123 (talk) (C) 07:22, 24 July 2022 (UTC)
4.  Support This is a logical way to proceed. --DeeM28 (talk) 11:55, 27 July 2022 (UTC)
5.  Support I agree. ZeusDeeGoose (talk) 23:24, 30 July 2022 (UTC)
6. Agreed. Dmehus (talk) 04:34, 2 August 2022 (UTC)
7.  Support Also agreed. --小美粉粉 (T - C - S) 1004065811 bytes of data NOTE: Do not {{ping}} me! 09:13, 17 August 2022 (UTC)

Proposal 3.7.1 (Level of consensus)

While Stewards will assess and weigh arguments and counter-arguments presented, as in the case of all RfCs and global permissions requests, the community advises that, all else being equal, the level of consensus should be 70% to ensure the level of consensus in favour is very clear. Additionally, this helps to provide a level of due process that has not always existed in past community bans.

Note: This is an alternate proposal to Proposal 3.7.

Support

1.  Support only if Proposal 3.7 fails; per my support of 3.7. Agent Isai ^{Talk to me!} 17:35, 23 July 2022 (UTC)
2. MacacoKouhai (talk) 18:00, 23 July 2022 (UTC)

Oppose

1. Per my agreement in Proposal 7, I feel the stricter consensus requirement in Proposal 7 is much better, as per my comments around due process and procedural fairness. At the same time, Proposal 7 allows for Steward discretion by applying a 70-80% banded range. Dmehus (talk) 04:35, 2 August 2022 (UTC)
2.  Oppose per Doug Mehus --小美粉粉 (T - C - S) 1004065811 bytes of data NOTE: Do not {{ping}} me! 09:15, 17 August 2022 (UTC)

Proposal 4 (Enforcement)

A global ban shall be enforced on-wiki via a global lock of the master account and all other alternative accounts. All accounts created subsequently will be automatically locked upon detection. Verifiable IP addresses may be blocked globally by global functionaries as part of global ban enforcement, in the same way global locks are enforced.

Support

1.  Support This is already the de facto standard but it doesn't hurt to codify it. Agent Isai ^{Talk to me!} 17:35, 23 July 2022 (UTC)
2. MacacoKouhai (talk) 18:00, 23 July 2022 (UTC)
3.  Support Makes sense. Reception123 (talk) (C) 07:22, 24 July 2022 (UTC)
4.  Support This is a logical way to proceed. --DeeM28 (talk) 11:55, 27 July 2022 (UTC)
5.  Support I agree. ZeusDeeGoose (talk) 23:24, 30 July 2022 (UTC)

Oppose

1.  Oppose I think we should only have basic global ban protection. --小美粉粉 (T - C - S) 1004065811 bytes of data NOTE: Do not {{ping}} me! 10:29, 17 August 2022 (UTC)

Abstain

1. Procedurally abstaining as co-proposer. This is one proposal that is worded so obviously, it could've been left out and reduced the relative size of this RfC. In other words, this is so obvious that it would've been an easy "fat trim" to cut the size of this RfC, as several participants have noted. Dmehus (talk) 04:39, 2 August 2022 (UTC)

Proposal 4.1 (Applicability to Discord)

Global bans will automatically apply to Discord.

 Note: Global bans do not currently apply to Discord automatically and are decided on a case-by-case basis by local moderators.

Support

1.  Support I don't see an issue with this. If the user is banned off the main platform for severe, irreparable issues, why not also get banned off of our ancillary platforms? Agent Isai ^{Talk to me!} 17:35, 23 July 2022 (UTC)
2. Also IRC Naleksuh (talk) 17:48, 23 July 2022 (UTC)
3. MacacoKouhai (talk) 18:00, 23 July 2022 (UTC)
4.  Support While usually it's best to separate Discord from on-wiki, if the community has voted to ban a user there's little reason to believe they'd be fine with them being around on Discord. Reception123 (talk) (C) 07:22, 24 July 2022 (UTC)

Oppose

1.  Strong oppose out of procedural fairness and due process, which I've spoke at length about here, as not everyone has, or uses, e-mail, and it's important to keep communication channel avenues of appeal open. If the user becomes disruptive on Discord, or IRC, local platform moderators can and should feel compelled to kickban the user (for a week or two, and re-kickbanning quickly should the disruption continue). Secondarily, procedurally, Stewards and Global Sysops have no moderation authority on Discord. Stewards do, through their assumed responsibilities as final appeal body from the former Code of Conduct Commission, have some jurisdiction as a final appeal body, on Discord and related to local moderator Code of Conduct kickbans; however, this is a unitary level of governance in that local platform moderators can revoke that jurisdiction at any time, should they opt to remove the Code of Conduct's applicability to Discord. As such, I don't feel, procedurally, this has any enforceability. It could, but it would require the Miraheze Discord community first having an RfC to allow on-wiki policies, beyond just the Code of Conduct, to apply to their Discord server. In other words, this is a case of putting the proverbial cart before the proverbial horse. Even if could apply this here, which I don't believe we can, I feel this would be like imposing global will on a local community (the Discord server), which is counter to the very Miraheze ethos or raison d'être (of local control and decision-making over global intervention). Finally, I would also note that the community has so far rejected applying Meta Wiki community bans to Discord and IRC, so even if this were procedurally okay, which I don't believe it, it holds that this proposal must not pass if the lesser proposal does not pass. Dmehus (talk) 05:14, 2 August 2022 (UTC)
2.  Weak oppose Per my opinion on proposal 4.2. -Cheers, Matttest (talk | contribs) 09:14, 4 August 2022 (UTC)
3.  Strong oppose per above. Kourouklides (talk) 00:46, 5 August 2022 (UTC)
4.  Strong oppose per above --小美粉粉 (T - C - S) 1004065811 bytes of data NOTE: Do not {{ping}} me! 10:30, 17 August 2022 (UTC)

Comments

1. @Reception123 and Agent Isai: Does this restriction applies to IRC as well? From Naleksuh’s vote it seems it does, but I want to get a clear confirmation from the proposers. Cheers, Matttest (talk | contribs) 04:34, 24 July 2022 (UTC)

   It does not. A section relating to the applying this to IRC bans used to exist in the early drafting stages but was removed somehow. Agent Isai ^{Talk to me!} 04:36, 24 July 2022 (UTC)

   Am I allowed to place a new proposal regarding this below (I.e. proposal 4.2) regarding this. IRC and discord are actually the same as it is the messages are bridged. Cheers, Matttest (talk | contribs) 04:38, 24 July 2022 (UTC)

   Not all channels are relayed to IRC but I agree that they're very similar. I have added the below section to address that. Agent Isai ^{Talk to me!} 04:41, 24 July 2022 (UTC)

Proposal 4.2 (Applicability to IRC)

Global bans will automatically apply to IRC.

 Note: Global bans do not currently apply to IRC automatically and are decided on a case-by-case basis by local moderators.

Support

1.  Support per my support of 4.1. Agent Isai ^{Talk to me!} 04:41, 24 July 2022 (UTC)
2. Naleksuh (talk) 05:34, 24 July 2022 (UTC)
3.  Support Per my support of 4.1. Reception123 (talk) (C) 07:22, 24 July 2022 (UTC)
4.  Support I agree. ZeusDeeGoose (talk) 23:24, 30 July 2022 (UTC)

Oppose

1.  Strong oppose out of procedural fairness and due process, which I've spoke at length about here, as not everyone has, or uses, e-mail, and it's important to keep communication channel avenues of appeal open. If the user becomes disruptive on Discord, or IRC, local platform moderators can and should feel compelled to kickban the user (for a week or two, and re-kickbanning quickly should the disruption continue). Secondarily, procedurally, Stewards and Global Sysops have no moderation authority on IRC; by SRE convention, Stewards are afforded moderation authority, but it is both conditional and unitary and could be revoked by SRE at any time. Stewards do, through their assumed responsibilities as final appeal body from the former Code of Conduct Commission, have some jurisdiction as a final appeal body, on IRC and related to local moderator Code of Conduct kickbans; however, this is a unitary level of governance in that local platform moderators can revoke that jurisdiction at any time, should they opt to remove the Code of Conduct's applicability to IRC. As such, I don't feel, procedurally, this has any enforceability. It could, but it would require the Miraheze IRC community first having an RfC to allow on-wiki policies, beyond just the Code of Conduct, to apply to their IRC server. In other words, this is a case of putting the proverbial cart before the proverbial horse. Even if could apply this here, which I don't believe we can, I feel this would be like imposing global will on a local community (the IRC channel(s)), which is counter to the very Miraheze ethos or raison d'être (of local control and decision-making over global intervention). Finally, I would also note that the community has so far rejected applying Meta Wiki community bans to Discord and IRC, so even if this were procedurally okay, which I don't believe it, it holds that this proposal must not pass if the lesser proposal does not pass. Dmehus (talk) 05:19, 2 August 2022 (UTC)
2. I think Dmehus has really brought a strong argument here. Until a user (if any) provided a satisfactory refutation towards this, I am voting  Weak oppose. As pointed out, (i) users should have the right to choose not to use email but IRC for appealing block, and they can be blocked if they are disruptive, (ii) the feasibility is challenged, though I believe the local platform moderators won’t change the ban easily. The reason why I am not voting (strong) oppose is because I think the a global ban is not imposed easily and only in a very severe case. All in all, I believe somehow a default global intervention on a local platform may be suitable considering the user must be very disruptive when they are globally banned, with a stronger thought that I still believe a user should not be banned on a local non-wiki platform if they didn’t attempt to vandalise. -Cheers, Matttest (talk | contribs) 09:11, 4 August 2022 (UTC)
3.  Strong oppose per above. Kourouklides (talk) 01:11, 5 August 2022 (UTC)
4.  Strong oppose per above --小美粉粉 (T - C - S) 1004065811 bytes of data NOTE: Do not {{ping}} me! 10:06, 17 August 2022 (UTC)

Proposal 5 (Appeals)

An appeal may be submitted by contacting Stewards. Stewards will then forward the appeal to the community by means of another Request for Comments. Stewards, as a group, may exercise discretion in appeals and choose not to forward an appeal if they feel that they lack merit and/or are frivolous in nature.

Support

1.  Strong support While the first part is already a de facto standard, the second part is very important so as to not further waste the community's time every day/month with a new appeal RfC. Can you imagine if a globally banned LTA made a new appeal every day and policy forced Steward to forward every single one of these? This proposal makes it clear too that the decision to not forward an appeal should not be taken unilaterally by one Steward but should be a majority vote within Stewards so as to allow a second pair of eyes to inspect the appeal too and to determine whether it lacks merit or not. Agent Isai ^{Talk to me!} 17:35, 23 July 2022 (UTC)

   Agent Isai Nothing in the proposed policy says what you're describing. This is one of those cases where common sense ought to apply. Moreover, the policy speaks to frivolous community ban requests; it holds its passage speaks to frivolous multiple appeals, including by obvious socks. As such, Stewards, collectively or on their own, could, or should discount such frivolous multiple appeals. In other words, I think this is a case of trying to be over-prescriptive and close a "loophole" that was not, in fact, "open" in the first place. Moreover, I would also note that in cases of appeals for clemency in death row cases, it's often a single United States Supreme Court justice that reviews the appeal and determines whether or not there is merit to the appeal. I'm not suggesting we adopt that approach here, but I'm just suggesting that this is pretty non-controversial. One, or multiple, Stewards should forward legitimate, bona fide appeals to the community. However, they should also work with the appellant on poorly formulated appeals with no or little chance of success and guide them to the best possible appeal, including on timeframes. Likewise, they should reject multiple appeals within a very short time period, so as not to waste the community's time or embarrass the appellant. Dmehus (talk) 05:28, 2 August 2022 (UTC)

2. MacacoKouhai (talk) 18:00, 23 July 2022 (UTC)
3.  Support Makes sense as a process, per above. Reception123 (talk) (C) 07:22, 24 July 2022 (UTC)
4.  Support Rather than having a user create accounts which evade their blocks which I believe has happened in past cases this procedure is much better. --DeeM28 (talk) 11:55, 27 July 2022 (UTC)
5.  Support I agree. ZeusDeeGoose (talk) 23:24, 30 July 2022 (UTC)
6.  Weak support as co-proposer, but quibble on the wording a bit. Dmehus (talk) 05:22, 2 August 2022 (UTC)
7.  Strongest support I couldn't agree more. --DarkMatterMan4500 (talk) (contribs) 18:30, 17 August 2022 (UTC)

Oppose

1.  Strongest oppose It is, to say the least, unnecessary. The appeal must be secret between stewards and the locked user. Involving community in this would greatly decrease the chances of a user being unlocked. If a user is asking for unlock, they are wanting to edit and it must be in good faith. — Pixial ^[Talk] 16:01, 10 August 2022 (UTC)

   @Pixial: You're not wrong there, otherwise, they wouldn't be getting it either way. --DarkMatterMan4500 (talk) (contribs) 18:34, 17 August 2022 (UTC)

   @DarkMatterMan4500: An example is me. They accepted my unlock request, it, only among stewards. Now if it's too obvious (LTA like Abigblueworld), then there's very little chance of being unlocked. — Pixial ^[Talk] 01:13, 18 August 2022 (UTC)

   @Pixial: I believe you're misunderstanding what this proposal does. This proposal states that if a user who was globally banned by the community wants to appeal, they can do it by contacting Stewards. This is so that they won't bypass their bans to appeal themselves and has nothing to do with normal appeals made to Stewards by users locked by Stewards. Agent Isai ^{Talk to me!} 01:15, 18 August 2022 (UTC)

2.  Strongest oppose per Pixial --小美粉粉 (T - C - S) 1004065811 bytes of data NOTE: Do not {{ping}} me! 09:51, 17 August 2022 (UTC)

Proposal 5.1 (Default appeals time)

If a global ban RfC doesn't specify a minimum time before appeals may be considered, the minimum time before an appeal can be considered will be of 3 months, so as to (a) allow the user sufficient time to reflect on their behaviour, (b) establish a good-faith initial attempt to illustrate to the community they have the capacity to exercise restraint (by not engaging in illegitimate sockpuppetry), and (c) not waste the community's time with repeated and frivolous requests.

Support

1.  Support No issues with this, this will allow users time to cool off and reflect on what they did. Agent Isai ^{Talk to me!} 17:35, 23 July 2022 (UTC)
2. MacacoKouhai (talk) 18:00, 23 July 2022 (UTC)
3.  Support While I would've preferred 6, 3 months is acceptable. Reception123 (talk) (C) 07:22, 24 July 2022 (UTC)
4.  Support With the safeguards presented in Proposal 5 I have no issues with this limit as long as Stewards do exercise their discretion and not forward every single appeal if there are no new arguments or circumstances made. --DeeM28 (talk) 11:55, 27 July 2022 (UTC)
5.  Support as co-proposer and per DeeM28 and Agent Isai chiefly. Dmehus (talk) 05:37, 2 August 2022 (UTC)
6.  Support I don't see a problem with this to be honest. --DarkMatterMan4500 (talk) (contribs) 12:57, 18 August 2022 (UTC)

Oppose

1.  Oppose I think we shouldn't have too much limitations to globally banned users. --小美粉粉 (T - C - S) 1004065811 bytes of data NOTE: Do not {{ping}} me! 09:21, 17 August 2022 (UTC)

Comments

• Strongly suspect "so as not (a) allow the user sufficient time to reflect [...]" (emphasis mine) is meant to read "so as to (a) allow [...]". AddWittyNameHere (talk) 09:28, 1 August 2022 (UTC)

  AddWittyNameHere  Fixed. Thanks for your astute, and correct, observation. Dmehus (talk) 04:49, 2 August 2022 (UTC)

Proposal 5.1.1 (Number of appeals)

Unless otherwise defined in a global ban RfC, globally banned users are limited to one appeal every 3 months. This allows for globally banned users to not waste both the community and Stewards time by submitting yet another appeal in a short amount of time where the circumstances and the community's view of the user are unlikely to have changed.

Support

1.  Support No issue with this. Agent Isai ^{Talk to me!} 17:35, 23 July 2022 (UTC)
2.  Support In order to prevent banned users from constantly appealing with no changes this is necessary. Reception123 (talk) (C) 07:22, 24 July 2022 (UTC)
3.  Support Per 5.1 --DeeM28 (talk) 11:55, 27 July 2022 (UTC)
4.  Support I agree. ZeusDeeGoose (talk) 23:24, 30 July 2022 (UTC)
5.  Support as co-proposer and per my comments here and in Proposal 5 generally. Dmehus (talk) 05:39, 2 August 2022 (UTC)

Oppose

1.  Oppose I think we shouldn't have too much limitations to globally banned users. --小美粉粉 (T - C - S) 1004065811 bytes of data NOTE: Do not {{ping}} me! 09:22, 17 August 2022 (UTC)

Proposal 5.1.2 (Number of appeals, layered)

One year for both, 3 months is not a long period of time, does not show much change and also gets exhausting/tired quickly enough. 1 year is also the standard appeal time for most global bans.

Support

1. Naleksuh (talk) 17:49, 23 July 2022 (UTC)
2. MacacoKouhai (talk) 18:00, 23 July 2022 (UTC)

Oppose

1.  Oppose as awkwardly worded and unclear how this differs from the above proposal. Additionally, I think this would add unnecessary complexity. Dmehus (talk) 04:44, 2 August 2022 (UTC)
2.  Oppose Per above, I admit I find it a bit hard to follow the wording of the proposal. Proposal 5 which allows for Steward discretion in passing along appeals is enough to prevent frivolous attempts to appeal every 3 months and renders this proposal mostly unnecessary and as said above introduces too much complexity to an already complex enough process. Reception123 (talk) (C) 19:54, 16 August 2022 (UTC)
3.  Oppose Per above --小美粉粉 (T - C - S) 1004065811 bytes of data NOTE: Do not {{ping}} me! 09:17, 17 August 2022 (UTC)

Comments

Ping @MacacoKouhai: as I edited some parts of this proposal due to not reading the previous ones correctly when setting this up. Naleksuh (talk) 18:59, 23 July 2022 (UTC)

Proposal 5.2 (Applying Proposal 5.* to current global bans)

Any successful proposal passed in this section (Proposal 5, 5.1, 5.1.1, 5.*, etc., if any are passed) will apply retroactively to current global bans where possible.

Support

1.  Support This allows for ApexAgunimou's global ban to be appealed in ~2 months or more, as defined by whichever section passes, in order to prevent baseless appeals from being forwarded to the community during this time which she has attempted, sometimes in an abusive manner, which are likely to snowball anyway. Agent Isai ^{Talk to me!} 17:35, 23 July 2022 (UTC)

   If the idea here was to allow ApexAgunomu to appeal the global ban in 2 months, that's a problem. For one, this intentional malice had been going on for years (see the RFC itself) and two more evidence of problematic behavior arose over IRC, which led them to be banned, and then to evade that ban several times even just recently as a week ago. The global ban was intended to be permanent, there is no real reason to think there will be change ever. You don't go from intentionally starting shit for the last two years to immediately stop in two months, especially when they are continuing the behavior after being banned. I consider it "locked in" at this point, nor would any appeal be able to convince anyone otherwise, when they already got literally dozens of chances and failed all of them. There's no need to worry about them appealing. Naleksuh (talk) 17:53, 23 July 2022 (UTC)

   No, that is not the idea here. She has been rather abusive to Stewards via email and on IRC. I was just about to amend my comment to clarify what I meant as I realized that this sounded like I wanted for her to be unbanned quickly. Agent Isai ^{Talk to me!} 17:54, 23 July 2022 (UTC)

2. MacacoKouhai (talk) 18:00, 23 July 2022 (UTC)
3.  Support as co-sponsor prior to these amendments. Even with the somewhat watered down modifications, this is essential for procedural fairness, due process, and the global policies like these, per my comments here and, secondarily here. Dmehus (talk) 03:37, 2 August 2022 (UTC)
4.  Weak support I have changed my vote to Weak Support. See the strikethroughed text and the conversation below for details. Kourouklides (talk) 04:37, 2 August 2022 (UTC)
5.  Support I support applying the appeals process and related proposals to current community bans, but obviously any new procedural rules shouldn't apply. Reception123 (talk) (C) 19:40, 2 August 2022 (UTC)

Oppose

1.  Weak oppose I think we shouldn't apply to the global bans that has been enforced before now. --小美粉粉 (Talk) (Contribs) (Sandbox) (My Wiki) (Global Contribs) 1004065811 bytes of data NOTE: Do not {{ping}} me! 03:48, 30 July 2022 (UTC)

    Oppose It would seem unfair to apply anything retroactively and also, if people have previously done such a big damage, it should be relatively easy to pass new global bans against them. Kourouklides (talk) 03:25, 2 August 2022 (UTC)

   Kourouklides Since your argument is with regard to unfairness, since perhaps this proposal's wording could've been clearer, I thought I'd clarify that actually opposing this proposal would actually be counter to the notion of fairness. In the past, some global community bans were applied with inconsistent assessment criteria, term lengths, and other conditions. As such, by supporting this proposal, you're actually supporting the idea of notional fairness, to retroactively update prior community bans to this new, stricter standard and, equally importantly, due process. Dmehus (talk) 03:33, 2 August 2022 (UTC)

   Dmehus Fair enough. I have now changed my vote from Oppose to Weak Support and I have strikethroughed the text so others can still see the rationale behind this change of vote. Kourouklides (talk) 04:37, 2 August 2022 (UTC)

   Kourouklides No problem! Happy to help. :) Dmehus (talk) 05:40, 2 August 2022 (UTC)

Comments

These are way too many proposals. It would take me near an hour to go through these and vote. Moisty (talk) (CentralAuth) 02:59, 30 July 2022 (UTC)

---

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