Wikipedia:Requests for adminship/2024 review/Phase I

2024 Requests for adminship review

Status as of 18:28 (UTC), Thursday, 16 May 2024 ()

• Phase II is open for discussion! Participants are invited to contribute towards improving and refining the proposals for a reminder of civility norms at RfA, administrator recall, designated RfA monitors, and an RfA mentoring process.

Note: this RfC was created with several already existing discussions that were initiated at the village pump; the section headings for proposals 1–4 have been edited for consistency. theleekycauldron (talk • she/her) 08:15, 20 February 2024 (UTC)

Update and table of contents

Hey there! This is to let you know that phase I of the 2024 requests for adminship (RfA) review is now no longer accepting new proposals. Lots of proposals remain open for discussion, and the current round of review looks to be on a good track towards making significant progress towards improving RfA's structure and environment. I'd like to give my heartfelt thanks to everyone who has given us their idea for change to make RfA better, and the same to everyone who has given the necessary feedback to improve those ideas. The following proposals remain open for discussion:

• Proposal 2, initiated by HouseBlaster, provides for the addition of a text box at Wikipedia:Requests for adminship reminding all editors of our policies and enforcement mechanisms around decorum.
• Proposal 3b, initiated by Usedtobecool, provides for converting the first two days into a discussion-only period, with no voting permitted.
• Proposal 5, initiated by SilkTork, provides for a trial of RfAs without threaded discussion in the voting sections.
• Proposals 6c and 6d, initiated by BilledMammal, provide for allowing users to be selected as provisional admins for a limited time through various concrete selection criteria and smaller-scale vetting.
• Proposal 7, initiated by Lee Vilenski, provides for the "General discussion" section being broken up with section headings.
• Proposal 9b, initiated by Reaper Eternal, provides for the requirement that allegations of policy violation be substantiated with appropriate links to where the alleged misconduct occured.
• Proposals 12c, 21, and 21b, initiated by City of Silver, Ritchie333, and HouseBlaster, respectively, provide for reducing the discretionary zone, which currently extends from 65% to 75%. The first would reduce it 65%–70%, the second would reduce it to 50%–66%, and the third would reduce it to 60%–70%.
• Proposal 13, initiated by Novem Lingaue, provides for periodic, privately balloted admin elections.
• Proposal 14, initiated by Kusma, provides for the creation of some minimum suffrage requirements to cast a vote.
• Proposals 16 and 16c, initiated by Thebiguglyalien and Soni, respectively, provide for community-based admin desysop procedures. 16 would desysop where consensus is established in favor at the administrators' noticeboard; 16c would allow a petition to force reconfirmation.
• Proposal 16e, initiated by BilledMammal, would extend the recall procedures of 16 to bureaucrats.
• Proposal 17, initiated by SchroCat, provides for "on-call" admins and 'crats to monitor RfAs for decorum.
• Proposal 18, initiated by theleekycauldron, provides for lowering the RfB target from 85% to 75%.
• Proposal 24, initiated by SportingFlyer, provides for a more robust alternate version of the optional candidate poll.
• Proposal 25, initiated by Femke, provides for the requirement that nominees be extended-confirmed in addition to their nominators.
• Proposal 27, initiated by WereSpielChequers, provides for the creation of a training course for admin hopefuls, as well as periodic retraining to keep admins from drifting out of sync with community norms.
• Proposal 28, initiated by HouseBlaster, tightens restrictions on multi-part questions.

To read proposals that were closed as unsuccessful, please see Wikipedia:Requests for adminship/2024 review/Phase I/Closed proposals. You are cordially invited once again to participate in the open discussions; when phase I ends, phase II will review the outcomes of trial proposals and refine the implementation details of other proposals. Another notification will be sent out when this phase begins, likely with the first successful close of a major proposal. Happy editing! theleekycauldron (talk • she/her) 10:53, 14 March 2024 (UTC)

Proposal 1: Impose community sanctions on RfA

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Should the requests for adminship process be placed under community sanctions (GS)? theleekycauldron (talk • she/her) 20:05, 14 February 2024 (UTC)

• The structure of this GS area would be modeled after the contentious topics procedure. It covers all participation in the requests for adminship (RfA) process, broadly construed. It does not cover mainspace editing about the request for adminship process, nor does it cover discussion of the same.
• Uninvolved administrators and bureaucrats are held responsible for enforcing civility and all other behavioral policies and guidelines through all remedies available under the contentious topics model, as well as the ability to strike or remove comments (up to and include the vote itself) that are judged to be disruptive, corrosive, or otherwise in breach of conduct policy. They are not empowered under this topic area to institute "enforced BRD" or "consensus required" restrictions on a page, or to institute revert restrictions on a single editor. No part of this GS can be made to empower administrators or bureaucrats to enforce any policy they are not already tasked with upholding.
• Requests for enforcement should be placed at the arbitration enforcement noticeboard (AE). An enforcement action can be overturned on appeal only with: a clear uninvolved editors at the administrators' noticeboard (AN); a clear consensus of uninvolved admins at AE; or (in more extreme cases) a clear consensus of uninvolved bureaucrats at the bureaucrats' noticeboard (BN). Standards of review for an appeal to uninvolved editors or administrators are listed here, and the same for uninvolved bureaucrats are listed here.
• Wikipedia:General sanctions/Requests for adminship is created as the log of enforcement actions and list of procedures. The appropriate awareness and sanction templates can also be created.

For the discussion of this failed proposal, see Wikipedia:Requests for adminship/2024 review/Phase I/Closed proposals#Proposal 1: Impose community sanctions on RfA

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 2: Add a reminder of civility norms at RfA

This is not a formal change in rules (and I do not see it as mutually exclusive with the above), but an encouragement for admins to use the tools available to them. Add something like this to WP:RFA (i.e. literally add it to the RfA page; wordsmithing more than welcome):

Editors are reminded that the policies on civility and personal attacks apply at RfA. Editors may not make allegations of improper conduct without evidence.

Uninvolved administrators and bureaucrats are encouraged to enforce conduct policies and guidelines, including—when necessary—with blocks.

Support (proposal 2)

1. Support as proposer. If we are not ready for GS, I think we should have a formal acknowledgement (importantly, one placed there by community consensus) that editors should be respectful, and disagree without being disagreeable. I will also note that if an admin uses the tools to silence civil comments that would be egregious WP:TOOLMISUSE; I have much more confidence in our ability to deal with tool abuse than with civility RfA. (Note that this is intended to apply equally to all participants, including opposers as well as those who badger opposers.) HouseBlaster (talk · he/him) 02:19, 15 February 2024 (UTC)
2. Support. This strikes me as a good idea. While a lot of the stress of RfA is caused by things other than outright incivility, a simple encouragement is unlikely to hurt. Eluchil404 (talk) 02:46, 15 February 2024 (UTC)
3. Support. The opposes above suggesting that we shouldn't discourage people from leaving personal attacks are disappointing. 0xDeadbeef→∞ (talk to me) 06:57, 15 February 2024 (UTC)
4. Support: I would've thought this would be common sense, but apparently people need to be reminded. — Callitropsis🌲[talk · contribs] 07:02, 15 February 2024 (UTC)
5. Support :) I think that, one way or another, what admins and 'crats have lacked is a clear mandate. This seems like a good first step towards a more healthy community. (Maybe another good first step would be disabusing ourself of the notion that a little trolling is good for the soul. A world in which no troll ever enters Wikipedia again is not a world where everyone on it grows soft, there's a real world too and people learn how to deal with hardship.) theleekycauldron (talk • she/her) 07:19, 15 February 2024 (UTC)
6. In light of the community's failure to do anything about the latter two pointy opposes even though it was blindingly obvious that they were pointy, perhaps this is actually a good idea. Therefore, I change my position to support. LEPRICAVARK (talk) 00:45, 18 February 2024 (UTC)
7. Support as plain common sense. Those saying "but but but but trolling an RfA lets us show how a candidate reacts!" miss the point that it also discourages candidates from standing in the first place. Ritchie333 ^{(talk) (cont)} 11:27, 15 February 2024 (UTC)
8. Support as a reminder of our existing conventions and rules rather than extra bureaucracy. RfA is not a welcoming environment, and I'm sure it deters many potential candidates who would make good admins. Certes (talk) 11:44, 15 February 2024 (UTC)
9. Support - The fact that we have to even vote on this and that it's not unanimous really is quite telling of how differently RfA is viewed across Wikipedia. But we need more civility, please. Not less. Particularly at a venue such as RfA. Believe it or not, we'd still like to encourage people to become admins. _{Duly signed,} ⛵ WaltClipper -(talk) 13:33, 15 February 2024 (UTC)
10. Support - Proven as necessary, even if it is redundant. Certes explains it well. — Ixtal ^{( T / C )} ⁂ Non nobis solum. 13:48, 15 February 2024 (UTC)
11. Moral support, but... I think we all know that we could already be doing this, admin or not. The problem with 'moderating' Wikipedia, compared to other places, is is that everything is out in the open and that everyone is on a level footing. Elsewhere, a mod sees a problematic comment and they remove it. Maybe the author can appeal, but it's going to be handled by other mods, and there certainly won't be a peanut gallery. If you remove a comment at RfA (or anywhere really), the author is very likely to publicly kick up a fuss, and that fuss is going to attract others to weigh in on both sides. There's a not-insigificant chance that, even if you're really sure that the comment was out of line, it's going to escalate to the point where you end up at ANI or ArbCom or wherever. I think admins are more aware of this than most, which is why you don't see us intervening unless the conduct is very obviously very bad. Encouragement or not. – Joe (talk) 14:05, 15 February 2024 (UTC)
12. Support. This issue is not merely something that happened recently. Repeated violations of WP:NPA and WP:CIVIL in RFAs have been problematic for a while - off the top of my head, I can name at least three users who were specifically topic banned from RFA in the last several years due to civility issues. If someone has a legitimate reason to oppose an RFA, there is no reason why it cannot be done civilly. Epicgenius (talk) 15:04, 15 February 2024 (UTC)
13. Support I'm ok with most of this. I don't think we need Editors may not make allegations of improper conduct without evidence. I can only see people using this to stop people from having votes and asking for evidence. Otherwise, it's a big win to explicitly remind people to be nice at RfA. Lee Vilenski ^{(talk • contribs)} 15:10, 15 February 2024 (UTC)
14. Support There's no way to prove it would help, but it certainly wouldn't hurt. Would it make sense to add something about how the 'crats are empowered to clerk? Sincerely, Novo Tape^{My Talk Page} 17:16, 15 February 2024 (UTC)
15. Support I will continue to support any little steps that will improve RFA until we get an RFA that isn't broken. If there's sufficiently detailed bigger steps, I will happily support them too. The community both needs a reminder of our civility policies and stronger enforcement of them in RFAs. Soni (talk) 06:01, 16 February 2024 (UTC)
16. Support (and yes, I know). A reminder never hurt. Plenty to gain (editors like Homeostasis07 will in future know they will be blocked for trolling before in advance, and admins will be reminded that their normal tools can still be used alongside any specific crat actions that may also be taken, and crats will hopefully be encouraged to keep a gimlet eye on proceedings safe in the knowledge that they have codified backing), and nothing to lose, except some of the toxicity which is an inevitable by-product of treating RfA where NPA, ASPERSIONs, etc, does not run (as a worrying number of admins and even crats seem to believe). ——Serial 19:55, 17 February 2024 (UTC)
17. Support RfA should at least have the same standards of user conduct as any other area of Wikipedia (not that our standards are that high). Maybe with an addition that explicitly states that votes that are aspersions/personal attacks can be struck/removed, since I think the often the issue is people being reluctant to enforce policies against oppose voters since they don't want to impugn people's "right to suffrage". Galobtter (talk) 06:52, 19 February 2024 (UTC)
18. Weak Support If there are admins and crats who feel as though they will be willing to enforce CIV and NPA, then this is a good idea. I'd consider it a pre-warning that editors should not make the type of comments they cannot make anywhere else on the project without sanction or summary removal. However if there aren't admins or crats willing to enforce those policies, then at best this is a fig-leaf sign that some can point to when telling others that their contributions are unacceptable per policy, and at worst this will just be some boilerplate text that editors ignore while violating the relevant conduct policies. Sideswipe9th (talk) 22:56, 19 February 2024 (UTC)

    Support: however, I'd just want Editors are reminded that the policies on civility and personal attacks apply at RfA.

    Uninvolved administrators and bureaucrats are encouraged to enforce conduct policies and guidelines, including—when necessary—with blocks. We don't need to specifically state what civility means, not do I think we should be making claims about people even with evidence. Those claims can be gamed. Lee Vilenski ^{(talk • contribs)} 11:57, 20 February 2024 (UTC)

    @Lee Vilenski: it appears you !voted twice :) HouseBlaster (talk · he/him) 17:42, 20 February 2024 (UTC)

19. Support in principle: the wording should be workshopped, and bureaucrats should be encouraged to enforce this more aggressively. Z1720 (talk) 14:41, 20 February 2024 (UTC)
20. Support This shouldn't be necessary, but it can't hurt. In my RfA, the problem wasn't specific uncivil comments, but instead it being difficult to watch tens of people each bringing all of your faults to bear, even if they do it reasonably civilly. * Pppery * _{it has begun...} 17:11, 20 February 2024 (UTC)
21. Support, because I don't see how it can hurt. My assessment of the problem we're trying to solve here, insofar as it is a problem, is there there's a handful of !voters falling somewhere on the spectrum of contrarian to troll; and another lot of participants who get worked up about these !voters and are just as nasty, or nastier, in response. We can, and should, do more to curb the worst of this behavior with the tools we already have: the rest of it, we need to learn to live with or ignore. Enforcing WP:ASPERSIONS would help, but that's not easy to do on a page that's inherently about discussing another editor. You cannot legislate against contrarianism, much as we would all like to. Vanamonde93 (talk) 17:52, 20 February 2024 (UTC)
22. Strong support. We ALL need reminders on civility and how to conduct ourselves with proper decorum on Wikipedia every now and then. In my opinion, this can only help, and all voters--myself included--would be prompted to "check" themselves before casting a vote or asking a question/posting a comment that may come off as caustic. I am with WaltClipper - we need to be encouraging our best editors to seek the mop and view RfA as a process of POSITIVE constructive criticism. Breaking down candidates to the point of withdrawal, regret, a Wikibreak, or any combination thereof is not helpful to this project. — That Coptic Guy^{ping me!} (talk) (contribs) 02:22, 21 February 2024 (UTC)
23. Support, as merely a reminder of the rules, not a new rule. Queen of Hearts (talk • stalk • she/they) 03:33, 21 February 2024 (UTC)
24. Support my car reminds me to put my seat belt on when I start it. I don't see that as a restriction on my choice of direction. Regards, --Goldsztajn (talk) 07:28, 22 February 2024 (UTC)
25. Support: negative feedback at RfA should be actionable, constructive criticism. No candidate has signed up to be personally attacked, threatened, harassed, insulted, embarrassed or publicly shamed. They have signed up to gain some technical and procedural rights that they can use to improve an online encyclopedia. Any admin has the ability to sanction an editor for violating civility norms, yet enforcement is exceedingly rare in RfA. This is a significant factor in the dearth of RfAs that cause chronic shortage in many areas that require admin intervention. — Bilorv (talk) 21:38, 22 February 2024 (UTC)
26. Conditional support if there are people actually willing to enforce this. —Kusma (talk) 11:55, 23 February 2024 (UTC)
27. Support - it never hurts to remind people of the need for basic civility. WaggersTALK 15:54, 23 February 2024 (UTC)
28. Support – There have been cases of personal attacks and civility in previous RfAs, and introducing this new proposal will reduce the likehood of personal attacks or incivility happening in future RfAs. Toadette ^{(Let's discuss together!)} 08:31, 25 February 2024 (UTC)
29. Support I will support any proposal that seems likely to have even the smallest impact on making RfA less unpleasant and/or will help good candidates be elected, and I will oppose or remain neutral on the ones that do not seem to be likely to make such an impact. I'm persuaded by the discussion that this measure may help. --Dweller (talk) Old fashioned is the new thing! 10:31, 26 February 2024 (UTC)
30. Support The process has a reputation for being unpleasant. I realize that we already have civility rules, but we need something more, and the proposed options that I have seen are this versus status quo. I prefer this. Bluerasberry (talk) 02:06, 27 February 2024 (UTC)
31. Support. RFA is not a PURGE. You can't forsake all the other values and guidelines of Wikipedia discussions during RfA period. The norms that apply to every other discussions must be enforced and followed here also, if not more. RfAs have turned into a battleground now with some recent ones being one of the most toxic discussions ever. Just because the editor had a bad day once and have acted irrationally once does not guarantee they can't be a great admin. Just because you had an argument or a disagreement with the editor in the past doesn't mean they can me trusted with the mop. We have entertained vandals and socks as admins (like Lourdes) and the toxicity and uncivil discussions are upto no good. Deserving editors will make it nonetheless and being civil won't hurt anyone. Also, per Richie333...it's just damn plain common sense. The Herald (Benison) (talk) 03:02, 27 February 2024 (UTC)
32. Support Absolutely reasonable, and isn't even a change rather than just reminding basic policies that are too often forgotten. Chaotıċ Enby (talk · contribs) 03:37, 27 February 2024 (UTC)
33. Support - Why dismiss the needed reminder? Civility is expected, especially from everyone of this project. Of course, there are WP:IAR and WP:NOTBURO, enforcing those policies just to ignore the longstanding civility policy requires proof that civiilty policy itself is detrimental to improving this project. Unfortunately, I've yet to see how the policy harms the project. George Ho (talk) 07:19, 27 February 2024 (UTC)
34. Support: a low-cost way of hopefully steering the culture in the right direction. UndercoverClassicist ^T·C 08:39, 27 February 2024 (UTC)
35. Support, basic guidelines are too often forgotten at RfA Yoblyblob (Talk) :) 18:09, 27 February 2024 (UTC)
36. Support - reminding people to behave is pretty much always warranted. Especially so at RFA. Ivanvector (^Talk/_Edits) 14:49, 28 February 2024 (UTC)
37. Weak support WP civility is often basically coaching on how not to get in trouble as you stick the knife in someone's back, or something to weaponize to stick the knife. So I don't think that this will be very useful. North8000 (talk) 22:29, 28 February 2024 (UTC)
38. Support, though I don't think it'll accomplish a great deal. Stifle (talk) 10:27, 1 March 2024 (UTC)
39. Support, even though saying this shouldn't be necessary. Dreamy Jazz ^{talk to me | my contributions} 15:06, 1 March 2024 (UTC)
40. Support We need to keep it civil --rogerd (talk) 19:42, 1 March 2024 (UTC)
41. Support A bit of a reminded to admins to enforce civility can't hurt, even though I believe enforcement with blocks risks fanning the flames. I do note that WP:RfA is already quite a wall of text. We may want to rethink more of the information given there. —Femke 🐦 (talk) 08:52, 2 March 2024 (UTC)
42. Semi-weak support If someone has a problem with the candidate, even if there's no evidence to support it, I'd like to know about it. That aside, however, I think that this would cut down on some of the toxicity at RfA. ‍ Relativity 05:59, 4 March 2024 (UTC)
43. Support, it's high time we did something about rampant incivility on this project. Sohom (talk) 03:08, 5 March 2024 (UTC)
44. Support This is not, as some learned opposes have suggested, "pointless" due to it being a standard requirement anyway. It is a timely reminder and is not without precedent (don't ACE elections carry a similar advisory?) It should be among the simplest suggestions to adopt in a programme of changes intended to improve tolerance and respect. [Anyone from some years ago reading this and saying "pot calling kettle black" - I agree, but people change]. Leaky caldron (talk) 12:53, 5 March 2024 (UTC)
45. Support Civility is always expected on Wikipedia, especially in RFAs, and this could help improve civility across the project. Rusty4321 ^{talk contribs} 21:09, 5 March 2024 (UTC)
46. Support. There's no harm in reminding people to stay civil, especially since RfAs can cause a lot of debate and editors might forget to be courteous while expressing their opinions. Furthermore, civility's already a guideline, so there's no reason for them not to be reminded of it. That Tired Tarantula^Burrow 05:36, 7 March 2024 (UTC)
47. Support seems like a small and reasonable change to me. The Wordsmith^{Talk to me} 21:23, 7 March 2024 (UTC)
48. Support This has the potential to be helpful. Cullen328 (talk) 23:08, 7 March 2024 (UTC)
49. Support It's sad that we need to say this, but apparently we do. RoySmith (talk) 03:18, 8 March 2024 (UTC)
50. Support. The oppose arguments that policies already apply so we shouldn't have a notice are unconvincing. It's already standard practice to add extra reminders of these policies in place they might be helpful e.g. {{Calm}} on contentious talk pages, or the recent consensus to add such a message at Wikipedia:Village pump (WMF). the wub "?!" 13:13, 10 March 2024 (UTC)
51. Support It's simply a reminder to be civil as eveyone should be across Wikipedia. I don't find the oppose reasons convincing, if someone has dirt then they should link to it so other people can see, and seeing how a potential admin deals with trolling is what looking through their past interactions is for. From my reading it would remind people that "XYZ edit warred" isn't ok without proof, but "I don't think XYZ has enough experience" is fine. Even if it only dissuades one person it would still have a positive effect. Shaws username . talk . 00:50, 15 March 2024 (UTC)

Oppose (proposal 2)

1. Oppose I want to know (a) if someone has some dirt; and (b) how the candidate reacts to trolling. Re (a): obviously any aspersions would be closely examined and dealt with appropriately if unsubstantiated. We can't put a header on every noticeboard with this information. Johnuniq (talk) 03:04, 15 February 2024 (UTC)

   With all due respect, are you really arguing that trolling is a good thing at RfA because we can see how the candidate reacts? HouseBlaster (talk · he/him) 05:21, 15 February 2024 (UTC)

   I haven't been following the details of recent RfAs but I have looked and the trolling I've seen has been very minor. The current fuss is not trolling in the sense of something outrageous: it's one oppose that might be misguided but does not warrant all the discussion IMHO. Are there any links showing trolling that really should be removed but hasn't been? Johnuniq (talk) 06:12, 15 February 2024 (UTC)

   Off the top of my head, since December we have one RfA where more than 50 revisions had to be suppressed because it took 48 hours for a wildly inappropriate comment to be removed and one neutral which literally cited the candidate's religion as a reason they would be uncomfortable if the candidate got the mop (see also Q6 and Q7 by the same editor). HouseBlaster (talk · he/him) 12:53, 15 February 2024 (UTC)

2. Oppose Johnuniq makes a good point. Until the FRA vote is private we will probably have this handwringing. Lightburst (talk) 04:55, 15 February 2024 (UTC)

   Oppose a lot of these concerns could be alleviated if someone would just p-block Lightburst from the RfA. We don't need to make community-wide statements in response to poor behavior from one editor (I realize there were two editors misbehaving at the current RfA, but the one !vote was already struck as a crat action, so evidently our current approach is not completely broken). LEPRICAVARK (talk) 07:05, 15 February 2024 (UTC)

   Plenty of other editors have recently engaged in problematic conduct at RfA. It's a systemic issue and admins and 'crats are way too reluctant to enforce community norms at RfA in my opinion. I'm not optimistic that this notice will solve all of RfA's problems, but hopefully it'll serve as a reminder to everyone that personal attacks and aspersions are just as unacceptable there as they are everywhere else and should be met with appropriate warnings or sanctions. — Callitropsis🌲[talk · contribs] 07:19, 15 February 2024 (UTC)

   @Lepricavark: it is true that if you block the minority voters or those who defend them, you can get a 100% result. In my experience, whoever dares to oppose the majority gets in trouble at RFA. The process is broken because it is public. Imagine going to the polls in the US, and they say who are you voting for? You tell them and they ask why? Now imagine having to declare your reasons to everyone in the polling center. And if they disagree with your reasons they strike your vote. If part of the Homeostasis07 rationale was an aspersion, strike it [[WP:RPA]]. But that is not what happened, first they poked at it, then they became outraged. Then they moved the entire rationale to the talk page. Then someone erased the vote entirely. I am just trying to stick up for the minority even though I voted with the majority. I guess FRAM struck my vote as well and that did not surprise me. Lightburst (talk) 14:45, 15 February 2024 (UTC)

   If you are going to ping me, then please have the courtesy to write something that it is worth my time to read. No, the process is not broken because it is public. The process is broken because of editors, such as yourself in this and other instances, who provoke needless disruption and drama instead of evaluating the candidate in a policy-compliant manner. To address one of your red herrings, this is not about getting a 100% result. The first oppose was removed because, despite your seeming wishes to the contrary, RfA is not a safe haven for innuendos against the candidate. Your !vote should be struck because it is admittedly irrelevant to the candidate. If someone were to subsequently draft a relevant oppose that did not violate basic policies, it should and would be allowed to stand. LEPRICAVARK (talk) 17:10, 15 February 2024 (UTC)

3. Oppose I know we're all trying to make RfA better, and I'm not for personal attacks. I'm just worried this will make it harder to oppose candidates who need to be opposed, since the "casting aspersions" line seems like it could cause problems if someone opposes an RfA without presenting evidence, and as Joe Roe notes, who is the arbiter here? For instance is opposing someone on religious grounds a personal attack or aspersions, or does it just say a lot about the person opposing? I think a better idea might be for there to be explicit moderators for RfAs instead of putting up a notice of something we all aspire to, but is in a situation where it's difficult to enforce. SportingFlyer T·C 14:29, 15 February 2024 (UTC)

   I'm really not seeing the connection between putting this notice and make it harder to oppose candidates who need to be opposed. If someone says I had off-wiki encounters with the user that do not make me believe they should be an admin or Some off-wiki observations that I cannot show have made me lost my trust in this candidate they would not be casting aspersions. People would definitely be curious at what it is, but if you can't provide any proof or evidence for your claim, you can't really specify anything other than how it made you feel without making an unsubstantiated claim.

   So my question is, if my understanding of what it means to cast aspersions is correct, in what way do we benefit from giving consideration to people making unsubstantiated claims where no evidence were sent to anyone? 0xDeadbeef→∞ (talk to me) 14:38, 15 February 2024 (UTC)

   Doesn't your question confirm my concern, though? If I say something like "I've interacted with RfA candidate in the past and over the course of numerous encounters don't feel they have the capacity to be an administrator," is that a validly held opinion/oppose, is that an aspersion, is that an unsubstantiated claim that should be disregarded? I think it's the former, but don't want it to be confused with an aspersion. SportingFlyer T·C 20:39, 15 February 2024 (UTC)

4. Oppose. As I mentioned in my oppose comment in the now-withdrawn proposal, I got a lot of heat for a comment I made in a fairly recent RfA. I put myself at neutral, and based it on something that I said I did not feel comfortable posting in public. I also said that I did not think my reasons were solid enough for me to oppose, which is why I chose to be neutral. The problem I have with this new proposal is that it seems to say that, without evidence, what I did would have been block-worthy. --Tryptofish (talk) 18:06, 15 February 2024 (UTC)
   • Please see also my comment in #Discussion (proposal 1), [1]. This proposal targets conduct that isn't really the problem that prevents good candidates from applying. --Tryptofish (talk) 18:27, 15 February 2024 (UTC)
   • Please also see the more recent discussions about Proposal 9b. Please note the change in language from something like improper conduct or misbehavior, to "specific policy violations". For the same reasons that were discussed there, I believe a corresponding change should be made here. --Tryptofish (talk) 21:09, 10 March 2024 (UTC)
5. Oppose As long as RFA comments are coupled with voting, I will have to oppose anything that could be used as a restriction on how people vote. Anyone should be able to vote how they want for any reason bar outright trolling. Now if voting and comments became uncoupled (see #Anonymous voting) and not everyone was forced to give a rationale, it would be a good idea. Pinguinn 🐧 19:56, 17 February 2024 (UTC)
6. Strong oppose with apologies to HouseBlaster because I'd love to believe this would make a difference. One way it won't is regarding disruptive editors because as we've seen recently, they will never back down, not one inch, from their assertion that their behavior is completely fine, they only went on the attack with great reluctance because of something someone else did, or whatever.
   If this has a positive effect, it'll be because it motivated editors who can actually enforce these policies to finally end their infuriatingly hands-off approach to disruption at RFA. And that won't happen, either. On the most recent request for adminship's talk page, two bureaucrats, User:Primefac and User:28bytes, said that they wouldn't remove two oppose votes that were blatant policy violations from the final account because the RFA was going to easily pass and besides, the community can rest assured that 'crats don't take such votes into account. That, to me, is incredible: two bureaucrats are on the record saying they flat-out won't enforce policy at RFA. (Everybody knows they didn't affect the vote! Everybody knows you wouldn't take them seriously! Toss them anyways!) No administrator or bureaucrat needs to be told that they're "encouraged to enforce conduct policies and guidelines, including—when necessary—with blocks." They know. The problem is that they still almost never enforce anything. (Change the word "encouraged" to "required" and I'd switch to strongest support possible.) City of Silver 00:01, 20 February 2024 (UTC)

   I think the reason that admins and bureaucrats are reluctant to enforce the rules at RfA is the fact that it feels like election interference. The reason I think we need a note like this is to make it clear that the community does not see enforcing behavioral policies/guidelines as election interference. (In other words, I think that it will have a positive effect because it motivated editors who can actually enforce these policies to finally end their infuriatingly hands-off approach to disruption at RFA.) HouseBlaster (talk · he/him) 00:29, 20 February 2024 (UTC)

   Yeah, the "election interference" angle is important here. And this becomes especially worse since most admins who see policy-violating behaviour have probably already voted in the RfA and so are involved. Galobtter (talk) 00:31, 20 February 2024 (UTC)

   You both might be right but then the reasons those two 'crats gave for sitting on their hands would be flat-out lies, wouldn't they? And what kind of enforcement can we expect from people who allow policy-violating disruption to stand because doing something about it means they'll get called out by the rulebreakers? City of Silver 04:17, 20 February 2024 (UTC)

   I don't see how those 'crats were lying: it didn't affect the outcome, and had it gone to a 'crat chat they would have been discarded. And I don't think admins are concerned about being called out by rulebreakers (if they were, vandals would never get blocked). I think admins are concerned they will be called out by "the community" for "interfering" with an "election". I see this as the community telling admins that enforcing behavioral guidelines will not be seen as interfering with an election. HouseBlaster (talk · he/him) 05:19, 20 February 2024 (UTC)

   @HouseBlaster: No, no. From the parenthetical in my message: "Everybody knows they didn't affect the vote! Everybody knows you wouldn't take them seriously!" I believe the lies came when those 'crats claimed these facts were why they wouldn't do anything when the real reason was that they were afraid of being accused of election interference. City of Silver 02:44, 21 February 2024 (UTC)

   If you're going to attempt to throw me under a bus, at least avoid grossly misrepresenting what I said (in this discussion for reference). The two !votes in question were POINTY, but were not "blatant policy violations", and as such did not require striking. Primefac (talk) 07:31, 20 February 2024 (UTC)

   With all due respect to you, as you do do the thankless task of clerking, Primefac – how does one square a vote being an example of "disrupting Wikipedia (to make a point)" and not a violation of policy? theleekycauldron (talk • she/her) 07:35, 20 February 2024 (UTC)

   WP:POINT and WP:DE are behavioural guidelines, not policies, so mischaracterising my statement in such a hyperbolic manner is why I felt compelled to comment. Primefac (talk) 10:33, 20 February 2024 (UTC)

   @Primefac: Regarding "The two !votes in question were POINTY, but were not "blatant policy violations", may I say? The two votes in question were lies. No gray area: they were lies. (Both! Voters! Supported! The! RFA! Where! They! Voted! Oppose!) You won't answer but I'll ask anyway: is lying not forbidden by policy? City of Silver 02:38, 21 February 2024 (UTC)

   Neither voter was lying. Both said they wanted to support but were opposing in protest. Where is the lie? Primefac (talk) 10:13, 23 February 2024 (UTC)

   @Primefac: Those two voters claimed they supported the candidate but voted to oppose. The word to describe their claim they supported the candidate when they knew their votes would count as opposition to the candidate is lying. If they supported the candidate, they'd have supported the candidate. If they opposed the candidate, their claims they supported the candidate were lies. I honestly can't believe that I have to explain this. City of Silver 00:42, 28 February 2024 (UTC)

   I'm pretty sure there's no policy against lying about one's current opinion anyways... Aaron Liu (talk) 01:15, 28 February 2024 (UTC)

   @Aaron Liu: If true, that sucks, doesn't it? City of Silver 01:34, 28 February 2024 (UTC)

   Nah. It doesn't do anything, did not do anything, and (seems like it) won't do anything. Aaron Liu (talk) 01:39, 28 February 2024 (UTC)

   This can't be a reply to what I just said. To quote myself for a second time: Everybody knows [the liars' votes] didn't affect the vote! Everybody knows [the bureaucrats] wouldn't take them seriously! Toss them anyways! City of Silver 02:13, 28 February 2024 (UTC)

7. Oppose It's too subjective and vague about what is meant by improper conduct and evidence. Consider some recent opposes such as "I have some concerns about experience and maturity."; "Pretty damning concerns about judgement."; "Insufficient emotional maturity for an admin."; "User takes themselves way too seriously...". No specific evidence was given for these comments but demanding this would result in more toxic drama rather than less. See also leopards. Andrew🐉(talk) 12:55, 22 February 2024 (UTC)
8. Oppose per Johnuniq and SportingFlyer. While this may seem innocuous, I'm concerned that it may make it harder to oppose and the salience of a notice may, at the margin, discourage a genuine oppose. Actual incivility can easily be taken care of by our normal processes. --RegentsPark (comment) 13:37, 26 February 2024 (UTC)

   Actual incivility can easily be taken care of by our normal processes. From the actual incidents that have happened at RfA, this clearly isn't the case. Galobtter (talk) 02:32, 27 February 2024 (UTC)

9. Oppose - unless it is to be suggested that policies on civility and personal attacks do not apply elsewhere, such a proposal is pointless. If there is civility-based disruption at RfA, deal with it by taking action (e.g. suspensions/bans). If one feels RfA is currently afflicted by civility concerns, that's an argument for stronger action, not for this reminder. Banedon (talk) 05:10, 27 February 2024 (UTC)
10. Oppose as pointless. The civility & NPA policies already apply everywhere on Wikipedia, if someone is breaking the rules, we have ANI for that -Fastily 07:14, 27 February 2024 (UTC)
11. Oppose we have exisiting civility and NPA policies - I worry this would facilitate blocking of any adverse comment outlined by preceding — Preceding unsigned comment added by Casliber (talk • contribs) 21:55, 27 February 2024 (UTC)
12. Oppose Per Fastily - saying they "apply at RfA" seems to imply that civility and personal attack rules don't apply elsewhere on Wikipedia. They should be enforced equally everywhere, people should be expected to read and understand the rules when making an account or risk being blocked. ᴢxᴄᴠʙɴᴍ (ᴛ) 20:10, 28 February 2024 (UTC)
13. Oppose per Fastily. Most people commenting at RfA already know the rules regarding incivility, they don't need a reminder. JML1148 ^{(talk | contribs)} 07:24, 8 March 2024 (UTC)
14. Oppose as counterproductive. Having a special reminder about civility norms implies that a somewhat special variant of civility is required at RfAs. Presumably the proposers mean it to be more civil than average, but the result may well be the opposite. Nemo 13:31, 10 March 2024 (UTC)
15. Oppose as meaningless. The community has spent nearly two decades carefully curating a bureaucrat corps of polite, uncontroversial admins who don't stick their heads above the parapet and make difficult decisions that will trigger a backlash (like sanctioning a long-term editor). Granted, the same community has decided that it wants this corps of mild-mannered, mostly semi-retired, admins to start proactively enforcing certain standards of decorum in one of our most heated venues, but that conflict is not going to be solved by a pale yellow box. HJ Mitchell | Penny for your thoughts? 14:13, 16 March 2024 (UTC)

Neutral (proposal 2)

1. Concern - I am concerned about how this will be applied when an editor leaves a good faith but bluntly worded comment at an RFA… situations where Incivility isn’t intended, but may perceived. Blueboar (talk) 18:24, 15 February 2024 (UTC)
   • It would be handled the same way we handle civility issues in the rest of the encyclopedia. That is, we WP:AGF and politely ask that the editor reword their statement. — HouseBlaster (talk · he/him) 19:51, 15 February 2024 (UTC)
     • Don't be so sure. Look at all the badgering of oppose comments that we have now. --Tryptofish (talk) 20:46, 15 February 2024 (UTC)
       • This proposal would apply to oppose-badgering, too (see WP:SAUCE). — HouseBlaster (talk · he/him) 13:58, 16 February 2024 (UTC)

     There is no one single way that we handle civility issues in the rest of the encyclopedia. It varies wildly depending on the particulars of any given situation. LEPRICAVARK (talk) 23:31, 16 February 2024 (UTC)

2. Support civility clerking, but Oppose it being done by self-appointed admins at their whim. Admins must not be allowed to be perceiveable as gatekeepers to adminship. A bureaucrat could clerk, but then that bureaucrat would be involved and unsuitable for being a closer. This is probably not a problem it is the same as with bureacrats who !vote. Ideally, the bureacrats will select/approve someone or some few to be clerks. The ideal clerk would be a bureaucrat with experience closing RfA, but maybe a respected nonadmin could do it at least as well. —SmokeyJoe (talk) 11:41, 2 March 2024 (UTC)

Discussion (proposal 2)

Let's say an editor makes an oppose comment like this:

• Oppose. I don't have any specific incidents in mind, but my interactions with the candidate leave me with the gut feeling that they will be too quick with the block button.

Supporters of the RfA candidate might believe sincerely that this is an aspersion made with the express statement that no specific evidence is going to be presented. It's possible to read the alternative proposal literally, as indicating that the community would authorize an administrator to sanction the editor who made the oppose. And yet it seems to me that this should be an allowable argument to make at an RfA. --Tryptofish (talk) 18:56, 15 February 2024 (UTC)

That's an absolutely reasonable thing to say at RfA. I almost never comment at RfA except when it's somebody I've known for a while because that's the only way to really get to know a person. If somebody who has interacted with the candidate over a period of time has a gut feeling one way or another, that's something I want to know. RoySmith (talk) 20:05, 15 February 2024 (UTC)

Yes @RoySmith: that makes sense to me! Lightburst (talk) 04:33, 16 February 2024 (UTC)

Yes, indeed it is. The alternative proposal says, however, Editors may not make allegations of improper conduct without evidence. I suppose that one could wikilawyer that "they will be too quick with the block button" is speculation about future conduct instead of an allegation of improper conduct that has already happened. And one would hope that admins would be clueful enough to know that the oppose isn't really what this proposal is trying to prevent. But the practical reality is that this proposal would put a chill on such opposes, and could well lead to attempts to game the language to make a mountain out of a molehill. (If anyone doubts that, just consider how some opposes get badgered.) And if admins are clueful enough to know not to block the opposer in this example, then they are clueful enough to deal with real problems without the need for the proposed language. I think this alternative proposal would end up being a net negative. --Tryptofish (talk) 20:45, 15 February 2024 (UTC)

The precise wording can be tweaked. In general, there is a difference between accusing a user of bad behavior in the past, accusing them of bad intentions for the future, and trying to project their future behavior. The first 2 necessarily need evidence, while the third can certainly be "gut feeling". I certainly would be unaffected by this third type of reasoning, but the voter had at least given some indication of why he/she is opposing the candidate. Animal lover |666| 00:05, 21 February 2024 (UTC)

• IMO what's actually wrong with RFA is the whole idea of it. There is no fixing it, because it's a stupid idea from the get-go. It's the same stupid idea as WP:RFC/U was. And for some reason that I don't understand, this community figured out that RFC/U was a stupid idea years ago and got rid of it, but maintains the same damn system for admin rights.

  What's stupid about RFA and RFC/U, fundamentally, is the very idea that we should publicly evaluate one of us. Has anyone reading this ever, in any other aspect of their life, seen anything like this happen? Ever gone to a school where the entire faculty and student body gets together and talks about you? Or had a job where an all-staff meeting is called and the subject of discussion is the performance of an employee? The closest thing I can think of is an intervention (counseling), and even then, that's close family and friends, not hundreds of strangers. (And that's without getting into real world elections, which are done by secret ballot.)

  Why do we do this? Because years ago WMF Legal said "community vetting" had to happen in order to give someone the viewdeleted permission. More recently, at one of the rounds of RFA reform discussion, WMF Legal backed off of that and said they'd consider alternatives. I think the community should tell WMF Legal tough cookies, we are not going to engage in public discussions of the job performance of editors, and WMF Legal is just going to have to figure out some other way. Because public performance reviews of editors are not healthy. It's way too easy, as we have seen time and time again, for such discussions to be derailed or to devolve into accusations, arguments, and so forth.

  You can't control hundreds of people... the more participation, the more likelihood that someone, somehow, will cause a problem. That's why in the real world we don't have public performance reviews in which hundreds of people participate. It's foolish to even attempt such a thing, even moreso on a website with hundreds of strangers, where almost literally anyone can participate. Yet Wikipedia continues the tradition. It's time for everyone to stop pretending that public performance evaluations are a normal thing to do. It's unhealthy. End it. Levivich (talk) 21:09, 15 February 2024 (UTC)

  All that WMF has ever said is that there should be some form of community process. It never specified what form that should take. A proposal to have an Arbcom style election had good support but failed only due to technical issues. Hawkeye7 (discuss) 21:25, 15 February 2024 (UTC)

  I have a draft to reignite that proposal somewhere, but I'm just a bit tired at the moment. theleekycauldron (talk • she/her) 23:14, 15 February 2024 (UTC)

  The supports were close to double the number of opposes, so I'm not sure "failed" is the right term. There isn't a technology-based technical issue at the frequency level that was being discussed. The concern is WMF staffing to support the vote. isaacl (talk) 05:16, 16 February 2024 (UTC)

  That RFC result was very unexpected. In my opinion, it should have been similar to the bot approval process: you get consensus first, then worry about technical details later in a separate step. That rfc should have been the consensus statement. It should have closed as "consensus to try some kind of RFA voting system, with technical details to be determined later". If someone were to rerun that rfc, with the correct closers, I'm pretty sure it would pass. –Novem Linguae (talk) 05:42, 16 February 2024 (UTC)

  +1. Wikipedia:Requests for adminship/2021 review/Proposals#Closed: 8B Admin elections actually passed by a vote of 72-39, nearly 2:1 in favor. Levivich (talk) 18:23, 16 February 2024 (UTC)

  English Wikipedia has a history of being influenced by libertarian views that underlie its adherence to consensus decision-making for almost everything. But consensus doesn't scale up to larger groups; it stalemates action. And yes, on top of that, evaluating people in a large, public group meeting isn't done outside of very specific professions. On a sidenote, RFC/U didn't end because of a consensus view that it was a bad idea to have public evaluation of editors. It ended because the commenters couldn't impose any sanctions through that process, so they thought it was ineffective. WMF Legal is not to blame for this. Those who like to participate in discussions about decision-making are loathe to give up the outsized-influence a small number of people can have to block changes they disagree with. So the community has been unable to agree on following approaches used by other organizations to make decisions more effectively. I understand and appreciate the advantages of consensus decision-making and letting everyone weigh in, but they come with an inherent cost that can't be avoided by tinkering with rules of behaviour. The community will have to shift towards other options for at least some things, which can include voting on certain decisions, delegating primary responsibility for certain tasks to designated subsets of the community, adopting some community hierarchy for interpreting policy, or some other commonly used option in the real world. Alternatively, the community can shrink down drastically back to a level where consensus might be more effective, but that's probably only going to happen if the site is abandoned by most of the existing community (and likely overrun by promotional editing at that point). isaacl (talk) 22:56, 15 February 2024 (UTC)

  @Levivich during WP:RFA2021, legal confirmed what Hawkeye says. There are any number of community processes which can work from their perspective. What wouldn't work is something like we do for ECR where we would give sysop to everyone with at least X years and Y edits or whatever. Best, Barkeep49 (talk) 23:00, 15 February 2024 (UTC)

  Since the discussion has broadened to RfA in general, I'd like to make a general comment that does get back to the proposal here, as well. If I try to think of two things where the community keeps trying to come up with proposals for improvement, and the proposals never get consensus, the top two might very well be civility and RfA. Everyone (including me) agrees that we ought to do better with civility, and we ought to do better with the RfA process. And year after year, proposals are made, and fail. Alas, the proposals here have hit the jackpot, by trying to deal with both civility and RfA. (What could possibly go wrong?) I've also been editing here for long enough that I well remember when the widespread concern in the community related to RfA was how to have a sort-of reverse RfA, where the community could have a mechanism to de-sysop admins who were acting like jerks. Gradually, over time, ArbCom got to be good at dealing with that. So now, the pendulum has swung back the other way, with concerns over RfA being unable to get enough new applicants. As I've said earlier in this discussion, the solution to that problem won't be found in the proposals here. The community just needs to decide not to pile on when reasons for oppose at RfA are not part of a pattern. Editors don't decline to be candidates because someone at the RfA is going to be incivil. It's because real people, including those who would make excellent admins, don't want to get hassled over the one or two times they did something genuinely regrettable. --Tryptofish (talk) 23:31, 15 February 2024 (UTC)

  Can we please not waste more words and time on these proposals? The community in its current state has shown itself that it wants RfA reform but cannot and will likely never agree with itself on how carry out that reform. If the community can't agree to come up with a system that is better than forcing people into public performances in front of hundreds of strangers, then so be it. What should be a cordial and basic exercise of governance can evolve into a poorly moderated jeering mass at a moment's notice. Not to mention the public nature of !votes means that people expressing their opinions are subject to badgering and drama. This discussion is particularly disappointing for me, a poor guy had his religion belittled amidst drama and attention from other editors he did not ask for. If we had an actual secret ballot both candidates and !voters would be spared of ridicule, but obviously nothing will be done because of technical infeasibility or people liking the current system more for their own personal reasons. Better to let them continue their talk of the lack of admins and just move on. Alright, that's enough words from a rando like me wasted on this topic. Time to step away from this and get back to cleaning up spam. The Night Watch (talk) 03:34, 16 February 2024 (UTC)

  This ^ Lightburst (talk) 04:19, 16 February 2024 (UTC)

  I think there are structural reasons for the pile-ons too. Notionally opposes at RfA carry more weight because success requires a 2:1 ratio of supports to opposes. But the reality is the reverse, because unless an RfA fails immediately as WP:NOTNOW, there's usually at least 100 or so supports before the first substantial oppose vote is made. So opposers feel like they have to overcome the momentum of the candidate's friends and those who just vote support for every RfA (as they're perfectly entitled to), leading to lengthy and repetitive rationales, which provokes badgering, which leads to more verbiage and repetition, and so on.

  The only ways I can think of addressing this involve making RfA either a secret ballot and/or having some sort of selections committee. As Levivich says, holding public elections-cum-performance-reviews is just a fundamentally odd thing to do. It produces all sorts of weird dynamics that can't be fixed by exhorting people to just be nice or not pile on or whatever, because individually they're already trying to. – Joe (talk) 08:53, 16 February 2024 (UTC)

  Alternatively, an RfA could start with some period of discussion before voting begins (and this could be combined with one of your other methods, as indeed was proposed in the elections one that almost passed in 2021). Barkeep49 (talk) 17:56, 16 February 2024 (UTC)

  Yeah, I still think an open discussion period followed by a closed ballot is the best model all-round, and still think the 2021 discussion showed a solid consensus to at least try that... – Joe (talk) 21:41, 16 February 2024 (UTC)

  The "community vetting" thing is an extremely low bar, and I think it only precludes things like automatic promotion based on edit count. I am mystified why this WMF comment has been used so successfully to argue for the broken and harmful status quo. —Kusma (talk) 09:25, 16 February 2024 (UTC)

  Yes, exactly. As I noted above (but which might have gotten lost in subsequent discussion) in 2021 WMF Legal commented (in part) The key point, per our previous commentary on the issue is to ensure that the process is one that can make sure that the selected candidates are overall trustworthy and responsible.. Best, Barkeep49 (talk) 19:09, 16 February 2024 (UTC)

  Perhaps it has been used, but offhand Levivich's comment above is the only one I can recall right now, so I don't agree that this concern has been used successfully to support the current RfA process. My recollection is that commenters understood the rationale from WMF Legal, as both Barkeep49 and Hawkeye have expressed, that in order to meet the responsibility of removing legally prohibited content, the privilege of viewing deleted content can't be handed out automatically through criteria that any editor can achieve. Other selection processes still meet the need of choosing "trustworthy and responsible" candidates. isaacl (talk) 19:44, 16 February 2024 (UTC)

  Not really an offhand comment :-) WP:RFA2021 is what I was referring to when I wrote "at one of the rounds of RFA reform discussion, WMF Legal backed off of that." One can read the Brainstorming, Phase 1, and Phase 2 pages to see the discussion surrounding WMF Legal (CTRL+F for "legal," for Phase 2 you have to uncollapse all collapsed boxes), and in Brainstorming is the discussion about BK reaching out to WMF Legal which results in WMF Legal "backing off" as it were, saying they'd be open to RFA alternatives.

  FWIW, there are good reasons not to have any kind auto-admin system (automatically given to all editors upon meeting some threshold like 2 yrs/20k edits), but WMF Legal's objections aren't among them. As I said in my post above, I think the community should devise whatever system works best for the community (discussion, secret vote, even auto-admin if that's what the community wants); any objections by WMF Legal, or technical challenges e.g. SecurePoll limitations, can be overcome. We shouldn't treat (as we have in the past) either an objection from WMF Legal or asserted technical limitations as if they created insurmountable obstacles. The obstacles are very surmountable. We should do what works best -- the technology and the lawyers will conform to the needs of the people creating the content, we don't have to do it the other way around. Levivich (talk) 20:35, 16 February 2024 (UTC)

  By offhand, I meant off the top of my head, I can't recall anyone successfully making the same argument you made. I've been following the discussions about this from long before the 2021 review; there hasn't been a consensus view that WMF Legal only supported keeping the RfA process as it existed at the time it issued its original opinion. But history doesn't matter for moving forward. I agree there seems to be an available consensus for anonymous voting that can be established. isaacl (talk) 22:53, 16 February 2024 (UTC)

  Levivich makes good points but there are repeated examples of such behaviour in history such as public humiliation, mutual criticism, and struggle sessions. On tech platforms, it's now online shaming. Of course, supporters want RfA to be more pleasant and so there's all this pressure to play nice but the purpose of the process requires it to be challenging. Andrew🐉(talk) 13:18, 22 February 2024 (UTC)

How to implement anonymous voting

As a practical matter, how would be implement anonymous voting? The available tool is meta:SecurePoll, but I think the community would find it rather onerous to use. It needs to be configured for each election, has some scheduling limitations, and requires WMF staff to get involved to set it up each time. RoySmith (talk) 23:28, 16 February 2024 (UTC)

I've talked to the WMF T&S team, and they say they'd be willing to do it on a limited scale. We couldn't hold monthlies, but it's doable. theleekycauldron (talk • she/her) 23:35, 16 February 2024 (UTC)

What do you mean monthlies, theleekycauldron? — ♠Ixtal ^{( T / C )} ⁂ Non nobis solum. ♠ 23:42, 16 February 2024 (UTC)

@Ixtal: We couldn't do monthly elections :) theleekycauldron (talk • she/her) 23:47, 16 February 2024 (UTC)

Oh, so we'd be batching RfA into quarterly (or whatever) tranches? I guess that would work, but wouldn't that mess with WP:BATON? RoySmith (talk) 23:42, 16 February 2024 (UTC)

We'd be leaving the old RfA system intact, so i guess the baton would live on for those who choose to do public RfAs. More to the point... I don't think it matters too much. theleekycauldron (talk • she/her) 23:47, 16 February 2024 (UTC)

Traditions are made for the participants, rather than the other way around, so I'm sure the community will find a way to adapt. isaacl (talk) 23:49, 16 February 2024 (UTC)

I'd say it goes in whatever order the 'crats implement the results. HouseBlaster (talk · he/him) 00:35, 18 February 2024 (UTC)

I don't think voters would find it unduly onerous. Staffing resources is a constraint. There is a Phabricator ticket open to track the task of allowing it be administered by local admins, so in the longer term, if the community is able to assume responsibility for configuration, it can ramp up usage. Initially I imagine that elections would be a supplementary path for selecting administrators. The community would be able to learn from the experience and decide how to proceed. isaacl (talk) 23:48, 16 February 2024 (UTC)

My favorite question when considering new and untried things is, "What's the worst that could happen?" In this case, the worst that could happen is we run an election and it goes badly. But we've got that already. So I say let's go for it. RoySmith (talk) 23:56, 16 February 2024 (UTC)

This 1000% — ♠Ixtal ^{( T / C )} ⁂ Non nobis solum. ♠ 00:38, 17 February 2024 (UTC)

"Allow local wikis to set up elections" is phab:T301180. SecurePoll is also very secure. Perhaps overly secure. Steps like scrutineering (checkusering every voter) can probably be dropped from the RFA voting workflow. The entire workflow of SecurePoll should be documented somewhere by someone knowledgeable, and then examined to see if other optimizations can be made to it. For example, is encryption overkill for RFA, and would turning that off help speed things up? etc. We should also consider if we want to institute minimum voting requirements such as extended confirmed, to prevent mass IP or throwaway account edits that could swing the vote. –Novem Linguae (talk) 00:01, 17 February 2024 (UTC)

I've worked up a lot of the details in a draft i've been writing over at Wikipedia:2024 administrative elections proposal, if we wanna kick that around? theleekycauldron (talk • she/her) 00:16, 17 February 2024 (UTC)

As I discussed previously on the Requests for adminship discussion page, votes are encrypted so no one with access to the underlying database (either directly or I suppose via a MediaWiki vulnerability) will be able to determine how people voted. Running an unencrypted election removes a bottleneck in administering the encryption, and would speed up the tallying process. I don't think the tallying process part is a big problem in the overall picture; scrutineering is the most significant delay. isaacl (talk) 00:23, 17 February 2024 (UTC)

• It is still quite an ordeal to run Secure Poll, but would be feasible if we wanted to do quarterly elections - perhaps in addition to having the existing RFA process for on-demand; candidates could choose which they prefer. The "big deal" would be that it is a vote. Something to decide would need to be if there is also an on-wiki "discussion" to go along with the vote or not. If no discussion is allowed, we could also have an on-wiki pure vote, and make a rule that the only contributions allowed are "support" or "oppose", without commentary. — xaosflux ^Talk 10:23, 17 February 2024 (UTC)

  I imagine there would still be discussion somewhere. Perhaps a week of q&a and discussion, and then a week of secret voting. Similar to how ACE is divided into the q&a phase and the voting phase. –Novem Linguae (talk) 11:47, 17 February 2024 (UTC)

  There could be ways to make sure that a SecurePoll is not a majority vote but rather just a tool to help surface consensus. For example, if a vote comes out as 99 % in support, it's hard to claim there's no consensus. On the other hand, if a 75 % majority were to be considered automatically enough, it would feel like a majority vote. Secret tally is useful if we think people are self-censoring in RfAs to avoid retaliation from sysops, and more generally to reduce quid-pro-quo votes in voting networks. By definition we can't tell whether it would make a given support threshold easier or harder to achieve, though in some cases it might be easy to guess (say if a former admin stands for re-election and dozens of users formerly blocked by them show up to vote... you could still find unusual voting patterns). Nemo 11:47, 9 March 2024 (UTC)

Anonymous voting

Wifione and a couple of other very problematic contributors have demonstrated that RfA needs to be in the open. With anonymous voting, no one would notice the waves of sock and meatpuppets that had been carefully prepared to control who gets to be an admin. Once the word gets around the paid-editing community, they will also set up a hundred dependable voter accounts. They would vote oppose for anyone with a record of opposing paid editing, and support for their candidates. Johnuniq (talk) 01:34, 17 February 2024 (UTC)

I think someone with your technical expertise should know about ACE and its rather robust scrutineering procedures. Also, everyone in the core community (and everyone who RfAs) virulently opposes paid editing, it's a cliché. Even if that conspiracy theory were 1. true and 2. technically viable, there's no pro-paid-editing faction to even boost. theleekycauldron (talk • she/her) 01:45, 17 February 2024 (UTC)

There is no pro-paid-editing faction now because everything is in the open and someone would notice dubious RfA votes. Three scrutineers under pressure to quickly check 2 or 3 hundred votes would find it very hard to investigate dubious voters. Scrutineers would more likely be bound by prescriptive rules that prevent an investigation based on a vague suspicion. We know that Wifione was successful in socking as Lourdes and becoming an admin (diff). We know that an RfA that looked like it was going to be successful was closed when someone decided the candidate was a sock of an LTA (I would have to remind myself where that was). Johnuniq (talk) 03:24, 17 February 2024 (UTC)

Wikipedia:Requests for adminship/Eostrix. –Novem Linguae (talk) 03:53, 17 February 2024 (UTC)

The current process, though, didn't stop either of these situations. If the community really wants to reduce the probability of this happening again, it's going to have to be willing to tradeoff some of its other views that it currently holds by consensus. isaacl (talk) 04:01, 17 February 2024 (UTC)

Those two cases involved talented individuals working alone. There has been compelling off-wiki evidence of two cases showing people organizing off-wiki to set up teams of editors to push their favorite POV in contentious topics. In addition, several similar cases of paid editing teams have been found. They get noticed because of the open nature of editing—someone sees unfamiliar user names arguing in a meat kind of way and uses Google to find a website where it is being arranged. It would be easy for these kind of groups to organize underground and create 100 hard-to-detect socks with 500/30 status. They could then sway an anonymous RfA. That doesn't matter for Arbcom because there are a very large number of voters and they elect a committee where it wouldn't be an enormous problem if there were one or two bad apples. Johnuniq (talk) 04:25, 17 February 2024 (UTC)

Any group willing to put in the long-term effort to build up a coterie of reputable editors is going to be able to influence the current RfA process as well. I'm not saying we shouldn't be concerned about the possibility. But any remedies to address that type of concerted effort are going to involve changing something from the current setup, and probably something creating some kind of hierarchy of trust. isaacl (talk) 04:37, 17 February 2024 (UTC)

You don't know if those two cases involved talented individuals working alone or groups of people working together. What those two cases prove is that the current system isn't good for vetting because it's easy to beat.

Also, admins are a bigger pool than arbcom (400+ active admins) so there is even less damage a single bad admin can do, which is another thing the Wifione case proved. What harm did he do with the Lourdes account? The Wiki is still here. Frankly, bad admins can and have done damage, but it's always fixable, and the current system has passed plenty of bad candidates (and failed good ones).

Above all, we don't know if another system would work better or worse than the current system because we've never tried any other system. Levivich (talk) 16:31, 17 February 2024 (UTC)

You don't know if those two cases involved talented individuals working alone or groups of people working together. What those two cases prove is that the current system isn't good for vetting because it's easy to beat. We don't know, but we have a pretty good idea. The fact that two people beat the vetting is not conclusive proof that the system isn't good or that it's easy to beat; it's a couple of pieces of anecdotal evidence. If we take a process already targeted by bad actors, and create a way in which they can manipulate it anonymously, they will take it. Grandpallama (talk) 18:30, 4 March 2024 (UTC)

I do not think it is prudent to dismiss something purely on the basis of containing a hypothetical conspiracy, since thousands of conspiracy theories are verifiably correct. "What if incandescent lightbulb manufacturers colluded to make shitty bulbs that burnt out prematurely", or "what if Bolsheviks conspired to depose the Tsar", for example, are things which actually happened.

More pointedly, "what if right-wing dudes took over the Croatian Wikipedia" is also a thing which actually happened, so the idea that conspiracies are simply impossible due to Wikipedians being too smart seems untrue. jp×g🗯️ 19:42, 17 February 2024 (UTC)

Definitely. Any time you start doing things in secret, there are people who will take advantage of it, and it's silly to offer a cursory dismissal of that concern. Especially when there is evidence it has happened in the past. Grandpallama (talk) 18:30, 4 March 2024 (UTC)

• With most configurations of the current Secure Poll setup, the "votes" are anonymous, but the "voters" are not. For example here is a list of everyone that voted in ACE last year, and if their vote was accepted. No one knows how they voted, but anyone can know if they voted. So traditional on-wiki methods can be used to investigate participants in secure polls. — xaosflux ^Talk 10:17, 17 February 2024 (UTC)
• Does this need to be anonymous, though? Would it be possible to set up a system exactly the same as the one we have now, but instead of !voting by posting in the article, you !vote by filling out a little form which gets revealed at the end of the RfA process, and the transcript of which gets sent to crat chat if it's close to the 66-70% threshold? The problem here is that we still need to discuss the RfA as a community, so there really may not be an easy fix. SportingFlyer T·C 10:38, 17 February 2024 (UTC)

  This is generally where I am at. I think there is great value in RfA !voters engaging in the discussion (whether reviewing the community questions or reviewing any general discussion) before casting a !vote (whether through a poll or in the current setup). Unlike others editors here, I think in a Secure Poll setup, there will be more "promote" votes because many editors won't notice any concerns that may exist. - Enos733 (talk) 17:46, 17 February 2024 (UTC)

  I think the community being able to assist in the scrutineering of votes in such a way would be positive. It might be a bit weird compared to know if we had a week of discussion followed by a week of votes and then untimed scrutineering, but it seems like a better alternative to now where you'll get a flood of 50-odd support votes before any concerns are even brought up followed by (usually) a shitshow for the 6 remaining days and a sudden closure. — ♠Ixtal ^{( T / C )} ⁂ Non nobis solum. ♠ 17:51, 17 February 2024 (UTC)

  As the arbitration committee elections demonstrate, discussion of the candidates can still occur while using an anonymous vote. Part of the confrontational nature of the current RfA process is that each person weighing in is potentially starting a new discussion thread. In addition to the candidate getting to witness the same debates play out repeatedly, those commenting have to consider their desire to participate in selecting an administrator versus their appetite for engaging in possibly a prolonged debate. I appreciate why some consider this to be a feature, but it also discourages certain personality types from wanting to participate, and I think the RfA process can benefit from getting input from those editors as well. isaacl (talk) 18:27, 17 February 2024 (UTC)

• I think it's perfectly possible to have our cake and eat it too per others in this thread. We can have a discussion section about the candidate where people can bring up potential concerns with a candidate combined with anonymous voting. If someone has a reason to vote one way or the other that they want to share with the community to convince others, they can put it in the discussion section. Otherwise everyone else would simply vote. Pinguinn 🐧 19:47, 17 February 2024 (UTC)
• I think the issue is that it is not anyone's business what a person's reason is for voting a certain way. It is none of the crat's business either. When we vote for ARBs we do not need to pontificate or satisfy someone else by providing a "valid" reason. If someone wants an issue or an experience that they had with a candidate to be known they can choose to share it on a talk page. This way everyone votes their conscience and nobody holds grudges over a vote. Primefac has said RFA is a consensus building, but that is not what it is, it is a vote. 75% is an automatic pass so where is the consensus in that? See this discussion where multiple editors said it is a straight vote. The cliff notes: In that discussion, HJ Mitchell said it was a straight vote, Vanamonde93, RickinBaltimore and Serial Number 54129 agreed. Lightburst (talk) 22:43, 17 February 2024 (UTC)

  The views of four editors can't be extrapolated to represent the views of the community at large. Many editors have more nuanced opinions on the matter. isaacl (talk) 23:13, 17 February 2024 (UTC)

Tangential discussion that involves a personal dispute Aaron Liu (talk) 21:31, 20 February 2024 (UTC)

Here is the broader context of HJ Mitchell's comment: If your vote (and it is a vote, RfA is about numbers, not discussion or consensus) is not based on the candidate's suitability for adminship, it absolutely should be struck. Given that you recently placed yourself at the center of controversy by casting a !vote that would be struck per HJ Mitchell's reasoning, it seems duplicitous for you to cite him as being in agreement with your position. I have taken the liberty of pinging him here since I'm sure you wouldn't want to misrepresent his position. LEPRICAVARK (talk) 00:41, 18 February 2024 (UTC) I am very concerned by your hostility toward me and I have left you a message on your talk page. I hope we can each discuss governance without sniping and parsing. The gist of the statement involved whether RFA is a vote or consensus. There seems to be this belief that we all have to agree on everything, including RFA candidates. And that leads to vote striking and other nonsense in an RFA. I want to ask you to please avoid following me as you did to Lilian's page, and avoid calling me out as you did here, and on other pages yesterday, and below. It is troubling and it feels like harassment. Thanks. Lightburst (talk) 02:55, 18 February 2024 (UTC) I like to call things what they are instead of what we think they should be (very un-Wikipedian of me!) so yes, it's clearly a vote. But I've always said that I'd prefer it to be a discussion of a candidate's suitability for adminship, like a (good) job interview and less like a popularity contest. I don't know if the outcomes would be different but I think it would make the experience more pleasant for all involved, which might attract a different kind of candidate and/or a different kind of voter. HJ Mitchell | Penny for your thoughts? 06:20, 18 February 2024 (UTC) and avoid calling me out as you did here, and on other pages yesterday, and below @Lightburst Unrelated to all your other comments, this feels unenforceable and a strong net negative. If you do not wish other people replying to you or calling you out, you should stop making statements. If you think someone is harassing you, please take it to ANI/another appropriate venue and get a formal IBAN. You assert bold claims that also require sufficient backing; undercutting any opposing arguments with harassment claims will not do any favours. Soni (talk) 04:29, 20 February 2024 (UTC) @Soni: Please AGF, you just accused me of hurling accusations to undercut opposition. Tsk tsk. You should read the details of the harassment. I do not ever want to go to ANI for anything and as you know discussion and conflict resolution should always come first. Anyway, read up in that link and see how the editor is following and harassing. I am trying to work it out with them rather than escalating. I asked the editor for an informal Iban and I think maybe they agreed. They snarled and deleted the message. Anyway, I did not want to let your bad faith accusation hang out there like a Matzah ball. Lightburst (talk) 15:08, 20 February 2024 (UTC) I had already read the details, found them lacking, and do not think your diffs supported your summary. But that's beside the point; this conversation, and 2-3 threads above, is already not for this venue. AGF is not a shield. And shaming others with a tsk tsk is usually not the way to prove your case. You seem to simultaneously believe there is an informal IBAN already agreed upon; and also need to reinforce it and request for it again in unrelated other venues. Either you both already have an informal IBAN, or you don't. Claiming harassment at unconnected conversations is the opposite of "dispute resolution", so I request you to take your diffs to an actually relevant venue please. Soni (talk) 19:56, 20 February 2024 (UTC) Thank much so much for enabling and shaming. I will always stick up for myself in all discussions. Now I have to ask you to leave me alone. Lightburst (talk) 21:21, 20 February 2024 (UTC)

• Consensus usually refers to general agreement among the members of a group or community. The community is in general agreement that any user receiving above 75% of the !votes at an RFA will be granted adminship, and any with 65-75% would be sent to a 'crat chat to find a general agreement amongst 'crats whether there was general agreement amongst the RFA participants whether the user should be an administrator. We do not need to go to a 'crat chat when a supermajority of participants finds general agreement to promote. So yes, it is a consensus-building exercise (see also the 2019 reaffirmation of this), and we use the votes to help determine that consensus. (please ping on reply) Primefac (talk) 08:56, 18 February 2024 (UTC)

  FWIW I was agreeing with what Harry said about the consequences of commenting at RFA. I don't think it's a straight vote. It's closer to a straight vote than many of our consensus-building discussions, and I would personally also agree with Harry that it should be more of a discussion, but if it was purely a vote then support percentage should predict whether someone gets the bit after a crat chat and it does not. Vanamonde93 (talk) 16:37, 20 February 2024 (UTC)

• My only thought here is that we should allow open community discussion so users can provide pieces of information (i.e. potentially problematic diffs). This way, some users that haven't seen a particular thing will be more likely to see it and will be more well-informed. And we should be able to ask the candidates questions, too. ‍ Relativity 01:28, 20 February 2024 (UTC)
• I agree entirely with Johnuniq above. Every behavior that we dislike in the current system would remain relevant in an anonymous vote; there would just be fewer consequences for being a jerk to your colleagues or for attempting to subvert the system. We have systems in place to stop people from being nasty to each other. We should use them. Vanamonde93 (talk) 16:50, 20 February 2024 (UTC)

Proposal 3: Add three days of discussion before voting (trial)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Following the passage of this RfC, for 5 Requests for Adminship (RFAs) which are not closed as SNOW or NOTNOW (or for six months, whichever happens first), RfAs will last 10 days. For the first 3 days (72 hours) no "Support", "Oppose", or "Neutral" comments/!votes may be made. Optional questions may still be asked and answered, and general comments may still be left. After 3 days, "Support", "Oppose", and "Neutral" !votes may be left for the remaining 7 days (same length as an RfA is now). This RfC does not change other RfA procedures/rules. 17:49, 17 February 2024 (UTC)

For the discussion of this failed proposal, see Wikipedia:Requests for adminship/2024 review/Phase I/Closed proposals#Proposal 3: Add three days of discussion before voting (trial)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 3b: Make the first two days discussion-only (trial)

Note I have just added an alternative, proposing a 2+5-day RfA trial instead of the 3+7-day trial originally proposed. Usedtobecool ☎️ 03:00, 20 February 2024 (UTC)

Pinging people who had commented/!voted already: @Barkeep49, Isaacl, Aaron Liu, Schazmjd, QuicoleJR, JPxG, Ahecht, Enos733, RoySmith, Lepricavark, Seraphimblade, S Marshall, SportingFlyer, NightWolf1223, Mach61, Lightburst, Thebiguglyalien, HouseBlaster, Relativity, Theleekycauldron, SilkTork, 0xDeadbeef, Rhododendrites, Leijurv, Femke, Bilorv, Retswerb, Kusma, Firefly, Serial Number 54129, Szmenderowiecki, Cremastra, AirshipJungleman29, Schierbecker, Voorts, WereSpielChequers, Compassionate727, Ixtal, WaltCip, Bruxton, Soni, MarioGom, Lulfas, Stanistani, Mackensen, and RunningTiger123: Usedtobecool ☎️ 03:00, 20 February 2024 (UTC) Also, @North8000, Novem Linguae, Lightoil, Lee Vilenski, Yngvadottir, Vanamonde93, Wbm1058, Galobtter, FOARP, Andrew Davidson, Tryptofish, Asilvering, Sideswipe9th, Hey man im josh, Fastily, and Schazjmd: Usedtobecool ☎️ 03:08, 20 February 2024 (UTC)

note: this was originally a subsection of the above section. I've moved it out here to match the format of the rest of this RfC :) theleekycauldron (talk • she/her) 08:15, 20 February 2024 (UTC)

Support (proposal 3b)

1. Support as this one does not extend the length of the RFA (per concerns expressed by many participants both supporting and opposing the original proposal and discussion in the general comments section). Usedtobecool ☎️ 03:00, 20 February 2024 (UTC)
2. Support (first choice) - no need to extend it. — Rhododendrites ^talk \\ 03:03, 20 February 2024 (UTC)
3. Support (first choice) 2 days for discussion and 5 days for voting seems to be the strictly superior version of the original proposal. It shortens the RFA's voting period as well, which I consider it to be a potential win. Soni (talk) 03:05, 20 February 2024 (UTC)
4. Support (first choice). Bruxton (talk) 03:08, 20 February 2024 (UTC)
5. Support (first choice) Leijurv (talk) 03:12, 20 February 2024 (UTC)
6. Strong support (first choice). If it's too little time then we can always adjust and extend. We can simply ask how grueling the candidates felt this process was. We don't have infinitely many RfA candidates to choose from in this year of experiments, and this doesn't introduce too many new factors either. Apaprently, my Waterfox browser really hates edit conflicts and basically hung when the edit conflict page appeared. Aaron Liu (talk) 03:18, 20 February 2024 (UTC)
7. Support (first choice) Lightburst (talk) 03:27, 20 February 2024 (UTC)
8. Support (first choice) Christ people, live a little. ~~ AirshipJungleman29 (talk) 03:31, 20 February 2024 (UTC)
9. Support per my initial !vote. I think this is arguably more similar to the current setup – yes, we're changing the voting window in addition to adding the discussion-only period, but 3+7 changes the overall window. RunningTiger123 (talk) 04:26, 20 February 2024 (UTC)

10. Support (first choice) per Aaron Liu. Namely, we can ask candidates how the process felt, so I don't see this as losing data.

    The first problem I see this solving is the rote +1 votes at the beginning. But more importantly, I see this as an opportunity for expressing concerns while allowing the candidate to respond to them. That way, there is no pile-on, and nobody feels wedded to a !vote they cast (i.e. you can easily express a concern without outright opposing). HouseBlaster (talk · he/him) 05:27, 20 February 2024 (UTC)

11. Support, mildly. I'm not sure if this is a good idea or not, but I really do want something to be tried in terms of RfA reform (I wasn't too happy about opposing the initial proposal, but the idea of extending RfA and the stress period was untenable for me), and I'm less concerned about additional stress for the candidate now that the total length of the period is the same. Galobtter (talk) 05:35, 20 February 2024 (UTC)
12. Support - striking my support above. Schierbecker (talk) 05:56, 20 February 2024 (UTC)
13. Support both – both are worth trying, I don't think we need to only pilot one :) theleekycauldron (talk • she/her) 07:33, 20 February 2024 (UTC)
14. Support either; i'm not sure it's worth trying both (one after the other? at the same time?), but it certainly is worth trying something new. Happy days, ~ Lindsay^Hello 07:36, 20 February 2024 (UTC)
15. Support (first choice): Not elongating the process is a big plus for me in terms of stress for candidates. Usually any concerns are expressed in the first 2/3 days, so that this gives the opportunity to respond without pile-on opposes. I'm also happy to try out both. —Femke 🐦 (talk) 08:13, 20 February 2024 (UTC)
16. First choice. NW1223<Howl at me•My hunts> 09:35, 20 February 2024 (UTC)
17. Weak Support (second choice) I am not sure about decreasing voting time, but both proposals are worth trying. QuicoleJR (talk) 14:21, 20 February 2024 (UTC)
18. Support, as I support the above. We can have a separate discussion on the exact time frame afterwards. Z1720 (talk) 14:44, 20 February 2024 (UTC)
19. Yup.—S Marshall T/C 14:45, 20 February 2024 (UTC)
20. Support Either of these options is fine by me. Ritchie333 ^{(talk) (cont)} 16:38, 20 February 2024 (UTC)
21. Works for me, possibly better than 3+7. —Kusma (talk) 17:28, 20 February 2024 (UTC)
22. Conditional support as second choice only if proposal 3 fails. Sdkb ^talk 19:49, 20 February 2024 (UTC)
23. Support (first choice) Either this or 3 would be good, this one is preferable as it does not increase the overall length. Pinguinn 🐧 20:17, 20 February 2024 (UTC)
24. Support per my neutral !vote on 3. Queen of Hearts (talk • stalk • she/they) 03:43, 21 February 2024 (UTC)
25. Support - I like the idea of discussion before the typical driveby voting starts. - jc37 05:36, 21 February 2024 (UTC)
26. Support for all the same reasons I supported 3a, although this would be a second choice. --Ahecht (TALK
    PAGE) 21:45, 21 February 2024 (UTC)
27. Excellent idea; first choice (over 3A). --JBL (talk) 22:34, 21 February 2024 (UTC)
28. Support first choice— don't need to stress valuable contributors out in their RfAs more than needed. ‍ Relativity 02:02, 22 February 2024 (UTC)
29. Support with 2+5 as first preference and 3+7 as second preference per my comments on proposal 3. — Bilorv (talk) 21:53, 22 February 2024 (UTC)
30. I have concerns regarding both non-voting proposals; of the two this has less impact and would cause less stress, so this would be the softer option to try, and the more likely to succeed. SilkTork (talk) 00:01, 23 February 2024 (UTC)
31. Support. Definitely worth a shot and could lead to real improvement. —Ganesha811 (talk) 00:39, 23 February 2024 (UTC)
32. Support (not a first choice or second choice) worth trying, could see if it helps with the toxicity. 0xDeadbeef→∞ (talk to me) 17:07, 23 February 2024 (UTC)
33. Support unconditionally whether we go with 3a or 3b. _{Duly signed,} ⛵ WaltClipper -(talk) 14:54, 24 February 2024 (UTC)
34. Going for support as the previous proposal appears to be too long than the historic. Also, it creates opportunities for people to always decide the best candidates before the voting phase begins given the questions and discussion, and to reduce users striking their votes upon changing their opinions. Toadette ^{(Let's discuss together!)} 08:39, 25 February 2024 (UTC)
35. As proposed by Barkeep49 in proposal 3. First choice over that proposal, though , as extending the length of RfA would potentially make it a less inviting process for candidates. ~ ToBeFree (talk) 12:32, 25 February 2024 (UTC)
36. Support I will support any proposal that seems likely to have even the smallest impact on making RfA less unpleasant and/or will help good candidates be elected, and I will oppose or remain neutral on the ones that do not seem to be likely to make such an impact. I'm persuaded by the discussion that this measure may make things worse. I am indeed persuaded by this. --Dweller (talk) Old fashioned is the new thing! 10:37, 26 February 2024 (UTC)
37. Support as first choice versus 3 days (option 3) ~Gwennie🐈｟💬 📋｠ 03:29, 27 February 2024 (UTC)
38. Support (first choice) Ivan (talk) 07:53, 27 February 2024 (UTC)
39. Support first choice - I have noticed some discussions have had things come up in the middle of them that could have changed the outcome of the final result. There should be a period for things like this to be brought up, and especially for the candidate to reasonable respond to them. Many people do not check the RfA page after their initial vote and this could encourage more research before a vote is placed. Yoblyblob (Talk) :) 14:06, 27 February 2024 (UTC)
40. Support with the addendum that this should be implemented with Proposal 89. 2 or 3 days of discussion, then 5 or 4 days of a straight vote. « Gonzo fan2007 (talk) @ 14:24, 27 February 2024 (UTC)

    I think you meant 8, and I think discussion should still be allowed (at least in the discussion area) during voting. Aaron Liu (talk) 14:31, 27 February 2024 (UTC)

41. Support I prefer Barkeep49's idea, but I think this will work fine too. SportingFlyer T·C 19:05, 27 February 2024 (UTC)
42. Support. I support along with P3a and P13 which are similar (my strongest preference is for P13). Aszx5000 (talk) 20:13, 27 February 2024 (UTC)
43. First choice to Proposal 3a Thebiguglyalien (talk) 01:01, 28 February 2024 (UTC)
44. Support, a very reasonable proposal,worth giving a try. Ratnahastin (talk) 02:30, 28 February 2024 (UTC)
45. Support. This system should give the voter more information to influence their vote before they cast their vote. Smallchief (talk) 20:52, 28 February 2024 (UTC)
46. Support (equally to 3 - I don' think a longer duration affects the benefit either way) Should allow in-depth discussion but reduce drawn-out bickering, and alleviate the current swingy mechanics. --Elmidae (talk · contribs) 06:41, 29 February 2024 (UTC)
47. Support, seems worth trying. Eddie891 ^Talk _Work 19:17, 29 February 2024 (UTC)
48. Support regardless of the exact numbers, trying out a change (in processes, in design, etc) with a defined trial period shouldn't be a big deal. —⁠andrybak (talk) 02:47, 1 March 2024 (UTC)
49. Support as a first choice, with the same reasoning used in my support vote for proposal 3. Dreamy Jazz ^{talk to me | my contributions} 17:05, 2 March 2024 (UTC)
50. Support I think this is better than the original, however, I also think both should be tried out. Fanfanboy (talk) 17:24, 4 March 2024 (UTC)
51. Support as a trial. See how it goes, though I predict this would just result in a slower turnout to RfAs, with everyone coming on day 3. Anarchyte (talk) 09:28, 5 March 2024 (UTC)
52. Support Think this is worth a try; 3+7 is too prolonged IMO. Spencer^T•C 10:37, 7 March 2024 (UTC)
53. Weak support Might help but adds a bit of complexity. As I understand it it would be an experiment with a sunset clause. On that basis, worth a try. North8000 (talk) 18:07, 7 March 2024 (UTC)
54. Support I wouldn't mind giving this a trial. The Wordsmith^{Talk to me} 21:25, 7 March 2024 (UTC)
55. Not sure how beneficial this will actually be, but it seems worth a trial. the wub "?!" 18:24, 11 March 2024 (UTC)
56. Support Worth a shot, shouldn't increase the pain level of going through RfA, and I think will improve everything. Lulfas (talk) 16:34, 14 March 2024 (UTC)
57. Support, certainly worth trying.-Gadfium (talk) 23:39, 15 March 2024 (UTC)
58. Support Agree it's worth a trial. -Kj cheetham (talk) 16:05, 16 March 2024 (UTC)
59. Support. It seems like it'll make the process less stressful for candidates during the last five days—due to most of the discussion likely having already taken place—and make discussion easier. That Tired Tarantula^Burrow 16:40, 16 March 2024 (UTC)

Oppose (proposal 3b)

1. Oppose as it makes it harder to tell if the discussion period is useful or not compared to the other factors this introduces. Best, Barkeep49 (talk) 03:09, 20 February 2024 (UTC)
2. Oppose. It is unclear to me what problem this is trying to solve. The only change is that voters have to wait to vote, correct? There will still be 7 days of questions and answers? Supports and opposes will still have rationales, correct? If the problem is opposers sometimes have rationales that the community doesn't like and some folks think these opposes aren't being policed enough and this makes all RFAs more toxic, I don't see how this proposal fixes that. I predict this proposal will just create impatience for support voters who are ready to vote but are not yet allowed to, and create a traffic jam of votes on day 3 of the RFA. In fact, it may even decrease RFA total votes because RFA is essentially only open for 5 days instead of 7. –Novem Linguae (talk) 03:26, 20 February 2024 (UTC)

   Novem Linguae, speaking for myself, I wanted to support the original proposal just because everyone says we need to do something, and this is something, but I could not bring myself to it because I see absolutely no potential benefit to making RFA even longer, because my reading is the same, things don't stop at the end of three days; if it is devolving, it will continue to do so the full 10 days. What brings me around to actually wondering that this might make things better is recollection that a discussion-first oppose was aired in a recent candidate's talk page and ended up not making it to the actual RFA, though I will not link it here as it is not a shining example of people coming together. — Usedtobecool ☎️ 03:42, 20 February 2024 (UTC)

3. Weak oppose. I believe users who are active on sporadic doses should be able to vote, and shortening the voting period disenfranchises them. Moreover, there's good reason to think the 7 days of the voting period under the proposed system will be less toxic than normal; most rationales will have already been discussed during the discussion period, and voters will be less likely to switch their positions because of that, lessening the need for persuasion. Mach61 (talk) 06:34, 20 February 2024 (UTC)

   As said above, adminship should be no big deal, or at least not much bigger than ANI. I agree with Bilorv's comment below. These sporadic users can also bring up points in discussion to influence votes. Aaron Liu (talk) 14:22, 20 February 2024 (UTC)

   If it wasn't a big deal we wouldn't have the watchlist notification, and would give out adminship at WP:PERM. Do not confuse aspirations with reality Mach61 (talk) 14:51, 20 February 2024 (UTC)

   WP:NOBIGDEAL is a policy. It's obviously a bigger deal than PERM as abuse would be much more catastrophic, but we're not electing a governor either. I see no reason for wanting everyone to vote. Five days plus arguments gives enough of a sample size. Aaron Liu (talk) 14:54, 20 February 2024 (UTC)

4. Weak oppose There is value in the seven day voting period. In many areas, seven days of discussion is standard. Removing two days of voting may mean that certain people are disenfranchised, because they only have time or ability to participate on particular days. I would rather have a full trial of 3+7 before considering changes to the length of the RfA.
   Secondly, and fundamentally, I don't think the community has a good grasp of why RfA is toxic. Certainly some of that could just be inherent in having 100-200+ editors scrutinize every edit and every interaction. If that is the case, then no reform based on community consensus will solve that issue. If the problem is how discussions devolve, then the only meaningful solution is likely more moderation. But, my two cents is that we need to start by understanding our values and our end goal when evaluating our processes and procedures. To me our values are consensus building and our goal is to have trusted administrators. --Enos733 (talk) 07:28, 20 February 2024 (UTC)
5. Oppose Seems too intense as the two days would be a vital campaigning period ahead of the formal voting. Candidates would agonise over their answers to every question and anxiety would make it difficult for them to sleep. Supporters would use the discussion to hold election rallies, declaring their support with endorsements which would make a farce of the voting embargo. Andrew🐉(talk) 09:11, 20 February 2024 (UTC)
6. Oppose this has the large presumption that the "general discussion" should not count towards determining the overall consensus (only having the enumerated discussion section be used for that purpose as is the general current practice), as such oppose limiting the time that editors can participate in the deciding discussion to only 5 days - this is not an urgent process and should allow for ample opportunity for community input - not all editors are active every day. — xaosflux ^Talk 11:30, 20 February 2024 (UTC)

   I am confused as to the point in the "discussion counts towards consensus" part. Wouldn't that mean that 2+5 gives equal time for community input, as the total time of evaluated input is 7 days either way? Aaron Liu (talk) 00:33, 21 February 2024 (UTC)

   @Aaron Liu when looking at results of RFA's in general the community is very focused on the S/(S+O) ratio - and this seems to be reinforcing that the discussion shouldn't count towards the conclusion (otherwise what is the point of splitting it?). This isn't trying to split QA period from feedback period - it is trying to split the feedback in to two classes (Day 1-2 discussion that isn't allowed to have numbered entries, and Day 3-7 discussion that is). — xaosflux ^Talk 10:20, 21 February 2024 (UTC)

   From my interpretation, RfAs have almost always never factored in discussion for cases above 75%, and have only factored them in when the ratio is between 60% and 75%. This change would allow the support ratio to better reflect community discussion by virtue of eyes. Aaron Liu (talk) 14:34, 21 February 2024 (UTC)

7. Opppose so all this does is prevent some users (who may only use Wikipedia on a single day per week) from being able to cast a !vote. In terms of closing, the discussion is worth as much as a !vote anyway. Lee Vilenski ^{(talk • contribs)} 11:50, 20 February 2024 (UTC)
8. Mild oppose, but let's not get stuck at no consensus closures. Let's just pass at least either of these options, OK? We will see if 3+7 is more stressful, that's why we have trials. But if 2+5 passes instead, it's worth a try too. My personal preference is 3+7 basically per Novem Linguae and Andrew Davidson, but let's just pass anything to see if it works, and not be mired in "no consensus" closures because no proposal will have 2/3 support that is by and large considered the threshold to rough consensus. If this proposal gains more traction, consider this a support. Szmenderowiecki (talk) 12:00, 20 February 2024 (UTC)

   That's a bit of a politician's syllogism; there certainly could be an even better idea. — xaosflux ^Talk 15:57, 20 February 2024 (UTC)

   My point is, if what is proposed for trial is not frivolous or obviously bad, it's worth investigating; otherwise we will never know if it's better. I prefer the 3+7 format, but if ultimately 2+5 prevails, I'm OK with it because the point here is testing if the !voting-free period makes sense and works. As a test, I'm all for it. If it's successful, I will support making it permanent, whether it's 2+5 or 3+7. Szmenderowiecki (talk) 19:03, 20 February 2024 (UTC)

9. Per Novem Linguae. * Pppery * _{it has begun...} 17:12, 20 February 2024 (UTC)
10. Weak oppose. I'm reluctant to oppose simply giving something a try. But the more that we discuss these things, and the more that I think about it, the more I'm convinced that the problem really is that qualified candidates don't want to have their every uncharacteristic mistake pored over and amplified, making qualified candidates less inclined to step forward. It's not incivility or personal attacks. It's that normal people occasionally do things that are legitimately things to bring up in RfA opposes. Actual mistakes. And the real issue then becomes whether the mistake was part of a pattern, or was so bad as to be disqualifying – or whether it was a one-off and should not be disqualifying. We can't make rules about this, because such opposes are not inherently disruptive conduct, and the only solution is discussion, and seeing whether or not the oppose rationale gets traction. The kinds of things being proposed here cannot address that; maybe individual editors being convinced not to reflexively pile-on out of laziness to closely evaluate the situation, or out of virtue-signaling, might. I also share, at least to some extent, the concern expressed by others that not everyone can participate seven days a week, and I'm also not persuaded that we can temporally isolate the difficult parts of RfA to just some days of the process. --Tryptofish (talk) 20:26, 20 February 2024 (UTC)
11. 'Weak oppose per @Xaosflux. voorts (talk/contributions) 22:27, 20 February 2024 (UTC)
12. Per xaosflux and Lee Vilenski. —Compassionate727 ^(T·C) 23:11, 20 February 2024 (UTC)
13. Oppose I'm not in favor of shortening the voting period. LEPRICAVARK (talk) 03:07, 21 February 2024 (UTC)
14. Oppose this for the same reason I oppose the 3-day version. Shortening the length from 3 to 2 days resolves none of my concerns. Steel1943 (talk) 01:47, 27 February 2024 (UTC)

    Steel1943, to clarify, the three in the first proposal is added to the current seven days; the two in this proposal is taken out of the existing seven. Best, — Usedtobecool ☎️ 02:00, 27 February 2024 (UTC)

    ...Then that leaves less days for voting (which I see as a negative), and the "discuss what" concern of mine would still apply. Steel1943 (talk) 02:03, 27 February 2024 (UTC)

    Steel1943, yes, it seems to be the concern of most opposes that we'd be reducing the number of voting days. Honestly, I do not know what will happen in the no-vote first days either, but I am willing to try and find out, per my support for 3a. Best, — Usedtobecool ☎️ 02:35, 27 February 2024 (UTC)

15. Oppose same as with proposal 3, longer RfA time is rather cruel to the candidate. Banedon (talk) 05:14, 27 February 2024 (UTC)

    Banedon, RFA is not extended. The seven-day RFA's first two days will be no-vote discussions. Best, — Usedtobecool ☎️ 05:34, 27 February 2024 (UTC)

    I see. Still opposed then, since if I make a decision now I want to be able to act on it, not show up in the remaining five days to act on it. Banedon (talk) 05:41, 27 February 2024 (UTC)

16. Oppose for the same reason I opposed 3a -Fastily 07:14, 27 February 2024 (UTC)
17. I agree with myself. Acalamari 15:03, 27 February 2024 (UTC)
18. Oppose prolongs the ordeal. It won't make people magically more diplomatic either. Cas Liber (talk · contribs) 21:56, 27 February 2024 (UTC)

    See the replies to Steel1943. Aaron Liu (talk) 22:08, 27 February 2024 (UTC)

19. Oppose. So this at least doesn't extend RFA and is better than the earlier proposal... but still is very questionable. If someone already knows that they're an enthusiastic "support", what are they expected to do, put the comment in general and then copy-paste it to Support 2 days later? Same with obvious problem candidates, who in general are spared trouble by getting quick and obvious feedback that they're not ready rather than holding out hope over 2 days before getting it crushed. Seems very difficult to clerk - if someone makes a general comment that is obviously an oppose in the first two days, is there anything to be done, or are we just going to let people do that? If we do something, what's the problem with such a comment? If we don't do anything in such a case, then is this proposal even achieving much? SnowFire (talk) 20:36, 8 March 2024 (UTC)

Proposal 4: Prohibit threaded discussion (trial)

Following the trial of the discussion-first RfA (provided the proposal is enacted), a second trial of threaded-discussion RfA will run for six months or 5 Requests for Adminship (RFAs) which are not closed as SNOW or NOTNOW, whichever happens sooner. A RfC to then be set up to see if elements of either or both trials should be made permanent. In the no threaded-discussion RfA trial, the rules and procedures are to be followed normally, except that, other than 'Crats, nobody is allowed to comment below another user's vote or comment. Each user, including the candidate, may address issues or respond to other comments either after their own vote comment, or by creating their own sub-section in the General comments area. SilkTork (talk) 11:33, 18 February 2024 (UTC)

Support (proposal 4)

1. I was going to wait until the above Discussion-first trial had concluded before suggesting this, but I think it would be more helpful to set it up now to see if there is traction for the idea, so that if there is traction, the trials can be set up to follow one another, and then we have a RfC to see what, if any, ideas can be taken forward. SilkTork (talk) 11:36, 18 February 2024 (UTC)
2. Support this as well, though I think it would be better for the two trials to run concurrently. The endless bludgeoning of opposes and neutrals has got to stop and this seems like the only way to stop that. NW1223<Howl at me•My hunts> 13:17, 18 February 2024 (UTC)
3. Something needs to be done to make RfA less toxic, and I think this is a good start. — Ingenuity (talk • contribs) 14:44, 18 February 2024 (UTC)
4. This is an interesting option. My initial reaction to this idea was a bit meh, but upon reflection I think this might help a bit and moves us closer to the standard democratic process organisations have for selecting individuals for tasks (which is closed voting with a discussion about the candidate, rather than about a vote). There is a social dynamics when there are two options (support or oppose), which pits people against each other. By moving the discussion to the discussion section, you make that dynamics less prominent. —Femke 🐦 (talk) 15:20, 18 February 2024 (UTC)
5. Support per the idea behind WP:Thank you for your vote. I'd also be fine with this running concurrently with the previous trial. Thebiguglyalien (talk) 17:22, 18 February 2024 (UTC)
6. Consolidating discussion about a given concern will reduce repetition, making it easier for new commenters to join in or for previous commenters to catch up. It will also mitigate the demoralizing effect on candidates from seeing the same criticisms being discussed repeatedly in separate threads. I think there remains social pressure against oppose voters, as they can still be challenged and engaged, and it also makes it easier for multiple challengers to engage. The convenience of the challenged and an initial challenger is traded off for the greater convenience of everyone else following the discussion about a common concern. isaacl (talk) 18:07, 18 February 2024 (UTC)
7. Support. As an implementation procedure, there could be language on the page or in the section to remind editors to respond in the general comments section or the talk page. --Enos733 (talk) 18:49, 18 February 2024 (UTC)
8. Worth a shot :) I would encourage future RfA candidates to mess with the template on their RfA – if you can add something interesting to your RfA's structure that doesn't impair the community's ability to find consensus, ask for forgiveness, not permission. People have done it before! I wish I'd thought to do so before my second RfA. theleekycauldron (talk • she/her) 23:01, 18 February 2024 (UTC)
9. Support as a trial: almost anything is worth trying. It's possible that preventing threaded discussion will reduce the overall number of words wasted at RfA, as one could argue applies at various ArbCom pages. RfA has a tendency to create ludicrous overemphasis of minor events or details, completely unrelated to whether the candidate will be a net positive as an admin. I'm not sure whether this would exacerbate or alleviate this but we could find out by testing.
   My concern would be that false information or BLP and civility violations may remain unchallenged under this format, as bureaucrats and oversighters typically refuse to enforce such policies and no-one else feels qualified to (it took six days for a very prominent BLP-violating comment to be removed at a recent RfA). But such things should be challenged with removal rather than badgering anyway. — Bilorv (talk) 23:08, 18 February 2024 (UTC)
10. Weak support, basically per Bilorv and Femke. If the 'crats and oversighters enforce civility and keep BLP-violatey stuff out, this will work well. If they don't, it won't. -- asilvering (talk) 21:22, 19 February 2024 (UTC)
11. Middling support - I really find the bashing on oppose !votes unproductive and serves to heighten and draw attention to drama rather than reducing it in any way. I'd be happy to see discussions without it. FOARP (talk) 22:03, 19 February 2024 (UTC)
12. Yup.—S Marshall T/C 08:24, 20 February 2024 (UTC)
13. Support. I'm going to put this in bold because some people opposing seem to have missed it - this is not shutting down discussion. It's just that I've found discussion about a candidate's suitability can happen in the General Comments area, or the RfA's talk page, or at WT:RFA, or on a user talk page, or (if appropriate at ANI), there are many, many, many areas where discussion is still open and welcome. The only thing that is being shut down is the worst possible place to put it. Ritchie333 ^{(talk) (cont)} 08:54, 20 February 2024 (UTC)
14. Until we can get to a private vote - this should be relegated to the talk page. Lightburst (talk) 22:38, 20 February 2024 (UTC)
15. Support only if 3/3b passes. Threaded discussion before the !vote. But oppose if neither 3 nor 3b pass. Queen of Hearts (talk • stalk • she/they) 03:47, 21 February 2024 (UTC)
16. Support, this would likely be a good idea for several other forms of discussion. It's stops the endless reply to replies chains that rarely add anything useful to discussions. -- LCU ActivelyDisinterested «@» °∆t° 00:16, 23 February 2024 (UTC)
17. Yes, independently of other proposals. Discussion is fine, but direct replies to votes usually lead to unnecessary drama. ~ ToBeFree (talk) 12:37, 25 February 2024 (UTC)
18. Support long threaded discussions make discussions harder to follow, so prohibiting them makes sense. If there is something substantial to discuss, a pointer to the talk page or similar page would work. Banedon (talk) 05:16, 27 February 2024 (UTC)
19. Support - far too much badgering is going on. Deb (talk) 09:43, 27 February 2024 (UTC)
20. Support (for a trial basis only). Most of the problems at ANI are down to a. 'bad' oppose !votes (ie, uncivil or unsupported accusations); and b. the inevitable badgering of oppose !votes. While this does not deal with the first point (although other measures are on offer that deal with this), this would stop the toxicity of pile-on badgering, which is normally more disruptive than the original uncivil !vote. - SchroCat (talk) 11:07, 28 February 2024 (UTC)
21. Weak Support I've rarely seen rebuttals and surrebuttals add anything meaningful to an RfA, but it does increase the swirl of tension surrounding it. Chetsford (talk) 16:36, 1 March 2024 (UTC)

Oppose (proposal 4)

1. This just makes the discussion impossible to follow. If replies to votes are outlawed, then voting comments should be restricted to seven letters instead of allowing the posting of out-of-context character assassination diffs without a right to highlight a reply. —Kusma (talk) 14:19, 18 February 2024 (UTC)

   This is the procedure used in ArbCom cases. It works there. SilkTork (talk) 15:20, 18 February 2024 (UTC)

   This is not at all comparable to an Arbcom case. Voters will not be added as parties whose behaviour is scrutinised and will not be subject to sanctions if they misbehave. —Kusma (talk) 16:03, 18 February 2024 (UTC)

2. I think this will make it easier for people who oppose while not offrring any benefit to candidates. I think the social pressure against opposing is, on the whole, a positive. For me, fixing RfA isn't an ends of its own but a means to the ends of getting more admin. Since I think this gets us farther from that I am oppoosed. Best, Barkeep49 (talk) 15:25, 18 February 2024 (UTC)
3. Per Barkeep. This will result in an increase in non-substantive opposes for reasons not relevant to the candidate's suitability for adminship. We should not be rewriting our procedures in a way that will primarily protect disruptive editors. LEPRICAVARK (talk) 18:29, 18 February 2024 (UTC)
4. Per above. This does much more than consolidating comments; it makes them harder to follow. Aaron Liu (talk) 19:58, 18 February 2024 (UTC)
5. Per Aaron and Kusma. Regarding the Arbcom comparison, Arbcom also has much lower participation than RfA. voorts (talk/contributions) 20:34, 18 February 2024 (UTC)
6. Agree with Kusma. * Pppery * _{it has begun...} 20:53, 18 February 2024 (UTC)
7. No, this just makes discussions harder to follow, and breaks anyone trying to use discussion subscriptions. — xaosflux ^Talk 21:43, 18 February 2024 (UTC)

   Does it break subscriptions? I'm under the impression that since only level-2 headings can be subscribed to, you can't subscribe in the first place. Aaron Liu (talk) 21:50, 18 February 2024 (UTC)

   @Aaron Liu thanks for note, so not yet then - but it is being worked on (phab:T275943). — xaosflux ^Talk 11:38, 19 February 2024 (UTC)

   At present the request is to implement subsection-specific subscriptions, though, and not individual numbered items in a list. While I imagine the same underlying implementation can be re-used for lists, I'm not sure the resulting tradeoff of additional markup would be worthwhile given the lesser frequency where subscribing to list items would be a preferable option. isaacl (talk) 18:35, 19 February 2024 (UTC)

   I've stricken the subsection related part, my primary concern is that I still think it makes following the overall discussion difficult. — xaosflux ^Talk 10:55, 20 February 2024 (UTC)

8. I agree entirely with Kusma. I think the core idea here is a good one: why not prohibited threaded discussion altogether? Any discussion consisting of more than one reply to a bolded !vote must happen on the talk page (or elsewhere). Vanamonde93 (talk) 23:07, 18 February 2024 (UTC)
9. I think threaded opposes are what RfA voters perceive as toxicity. But as someone who had a controversial RfA I don't think the endless RfA back and forths matter much to the candidate - the hard part really is having 200+ people scrutinizing you (and every response to every question asked) and many people writing negative things about you (and it seems often, being able to cast aspersions and make personal attacks without anyone doing anything about it), and this doesn't really help with that. In fact I mostly appreciated the people who defended me in the oppose section of my RfA.
   I wish honestly that people removed bad opposes if they are personal attacks/aspersions, rather than endlessly engaging with them, but I don't know if a rule can be made to solve this (other than encouraging more RfA clerking and enforcement of civility norms at RfA). Galobtter (talk) 06:42, 19 February 2024 (UTC)

   +1. I think many of these proposals, while well-intentioned, are conflating RFA heatedness with candidate stress, and that's not a valid equivalence. If there's a conduct problem with the opposition, we should deal with that directly; and if there's a conduct issue with responses to opposition, we should also deal with that directly. Vanamonde93 (talk) 06:05, 20 February 2024 (UTC)

10. Let's just focus on implementing one idea at a time. The better is the enemy of the good. _{Duly signed,} ⛵ WaltClipper -(talk) 13:33, 19 February 2024 (UTC)
11. Per Waltclipper and Vanamonde93. I think this proposal has "an" idea, but it's not sufficiently baked. It does not go far enough to remove threaded discussion (regardless of if those are positive or not) but also risks making following discussions impossible. Soni (talk) 14:36, 19 February 2024 (UTC)
12. Mainly per Kusma. It might accomplish what it's supposed to accomplish at ArbCom, but it absolutely makes many arb cases impossible for a passerby to follow. In an arbitration case, there are far fewer people talking and most of the discussion is for the sake of an even smaller number of people who have to judge what's said. At RfA, it's in every participant's interest to be able to understand what's being said, and most people aren't following the whole thing closely. — Rhododendrites ^talk \\ 16:29, 19 February 2024 (UTC)
13. As mentioned above, following a conversation would be near-impossible. This would probably decrease stress on opposers since they'll likely be badgered less but increase stress on the candidates by increasing the number of petty, POINTy, and poorly thought-out opposes. Sincerely, Novo Tape^{My Talk Page} 19:39, 19 February 2024 (UTC)
14. Maybe something like this could be made to work, but I really believe that we should go in the direction of more discussion, not less. (Yes, I know that may sound strange, in the context of feeling that RfA discussions veer towards unpleasant piling on, as well as there being far too many "optional" questions.) If we want to curtail spurious arguments, we need to give the crats a basis to weigh different comments differently. --Tryptofish (talk) 19:56, 19 February 2024 (UTC)
15. Oppose as premature. Let's let the other discussion play out first please -Fastily 01:29, 20 February 2024 (UTC)
16. Oppose. I feel this RFC is too early. I think it would make sense to use data from the first RFC and data from the first RFC's 5 RFAs to inform our decisions for the second RFC. –Novem Linguae (talk) 03:36, 20 February 2024 (UTC)
17. Oppose. RfAs should be more discussion and less vote, not the other way around. Seraphimblade ^{Talk to me} 07:17, 20 February 2024 (UTC)
18. Oppose. If you are willing to make a criticism of a candidate, you ought to be sure enough to stand some criticism yourself. I like to see opposes (and supports) discussed. JMCHutchinson (talk) 07:18, 20 February 2024 (UTC)

    As I said in my comment above, you can discuss in the General Comments area, or the RFA's talk page, or even the talk page of the editor who opposed. Lots of places to do it. Ritchie333 ^{(talk) (cont)} 09:07, 20 February 2024 (UTC)

    While having a separate area where users can comment on other users' votes is better than nothing, it still makes it harder to follow. If I want to get an impression about the candidate by looking at the votes, the replies being alongside the votes can help me see which votes are more relevant/accurate. Animal lover |666| 23:51, 22 February 2024 (UTC)

19. ArbCom discussions are already in a pretty unweildy format, but at least those have the justification of making it less likely people will go over the word limit. There is no word limit in RfA; all that's happened is making discussion harder to follow. I don't think this would make participants more civil, either. Mach61 (talk) 13:57, 20 February 2024 (UTC)
20. Oppose Any critique should be able to be rebutted if inaccurate or biased, though ideally not in a badgering way. The candidate themselves should also be able to respond, as seeing how a candidate responds to criticism could be potentially important in judging their temperament. Pinguinn 🐧 20:24, 20 February 2024 (UTC)
21. Per Kusma. —Compassionate727 ^(T·C) 22:59, 20 February 2024 (UTC)
22. Strong oppose - it's a discussion. - jc37 05:36, 21 February 2024 (UTC)
23. Oppose an unthreaded discussion is just !voting without a bold word at the front. --Ahecht (TALK
    PAGE) 21:47, 21 February 2024 (UTC)
24. Oppose - that sounds like a bad idea. If someone says "oppose because he is a serial killer", I think everyone would be fine with simply striking or removing that blatant falsehood. But what if someone says "oppose I don't like his attitude because he was mean to me and a bunch of other people"? We need a way that context can be provided. Maybe being "mean" just meant nominating their advertisement articles for deletion. Or maybe the candidate really is mean and some diffs need to be provided. But either way, context needs to be provided. --B (talk) 13:27, 22 February 2024 (UTC)
25. Oppose - I'm not keen on this format at ArbCom, it results in having to jump around the page in order to follow a conversation. I wouldn't like to see it adopted more widely. WaggersTALK 16:03, 23 February 2024 (UTC)
26. Oppose I will support any proposal that seems likely to have even the smallest impact on making RfA less unpleasant and/or will help good candidates be elected, and I will oppose or remain neutral on the ones that do not seem to be likely to make such an impact. Any unfair criticism made by a drive-through or intransigent editor will remain on the page unchallenged and influencing other, unless removed by a Crat. This, to me, does not meet the ambitions of the initiatives, though I do understand the drive behind it. --Dweller (talk) Old fashioned is the new thing! 10:40, 26 February 2024 (UTC)
27. Oppose: I agree with Kusma that this makes the conversation difficult to follow. I also agree with the rationale provided by Barkeep. I think it'll do more harm than good to prohibit threaded discussions. Hey man im josh (talk) 15:09, 26 February 2024 (UTC)
28. Oppose since preventing "threaded discussion" prevents discussion point blank. So, just a voting system, and we cannot respond to votes in the "support, oppose, neutral" sections and can only ask questions to do any type of discussion, and then still are subject to the 2-question limit? No thanks. Unproductive, regardless how toxic some of the threads can get. Allowing the threads is better than the alternative that basically silences participants. Steel1943 (talk) 02:02, 27 February 2024 (UTC)
29. As others have said, this would make discussion harder to follow. Also would concede - albeit not intentionally - to people who enjoy opposing but whine if their opposition is responded to in any way. Acalamari 04:04, 28 February 2024 (UTC)
30. Oppose - per preceding two commenters really Cas Liber (talk · contribs) 04:18, 28 February 2024 (UTC)
31. Oppose Most threaded discussion is useful. North8000 (talk) 16:44, 29 February 2024 (UTC)

    A few threaded discussions go bad, but even those are not a big RFA problem. And most are a plus.North8000 (talk) 19:30, 8 March 2024 (UTC)

32. Oppose Dreamy Jazz ^{talk to me | my contributions} 15:07, 1 March 2024 (UTC)
33. Oppose. Gut reaction is that this is a terrible idea. Threaded discussion is how discussions work most naturally. Discussion is essential for consensus decision making. SmokeyJoe (talk) 11:49, 2 March 2024 (UTC)
34. Discussion good! ~ Amory (u • t • c) 12:48, 2 March 2024 (UTC)
35. Oppose. When I read an RfA, I rarely learn much from the !votes. But I do learn from the threaded discussion – and sometimes what I learn influences my !vote. Maproom (talk) 16:47, 5 March 2024 (UTC)
36. Oppose. I really don't see how this will prevent incivility, and will make the discussion harder to follow. JML1148 ^{(talk | contribs)} 00:56, 10 March 2024 (UTC)
37. This works okay at arbcom cases where there are a more limited number of participants and there is active clerking, although as someone who doesn't follow cases often I still find it a bit confusing. At RfAs which regularly attract a couple of hundred people, I think the downsides of making the discussion harder to follow will be greater than the upsides. the wub "?!" 18:25, 11 March 2024 (UTC)
38. This makes it harder to know if someone's comment is responded to. Arbcom has a word count limit, but RfA has a lot of words. 0xDeadbeef→∞ (talk to me) 06:09, 17 March 2024 (UTC)

Neutral (proposal 4)

1. On the one hand, I agree with Bilorv that almost anything is worth trying, and since it is a non-frivolous idea, I can't oppose it. But the idea itself I think has little possibility of success. RfA is not ArbCom. This proposal does not see any restrictions on how much one can say in discussions, so I imagine there will be something like "Oppose, see diff" and a long tirade about all ills that that candidate allegedly caused.
   It may be a matter of bad taste to reply to that criticism, but the candidate should have that possibility regardless of customs around RfA. When there are 20-25 opposes to handle, it becomes too difficult to manage it in one section, plus, as commenters above said, the flow will be severely impaired. The structure is also incompatible with RfA's aims. It is important in ArbCom because it's easier to police individual users against excesses and it lets ArbCom understand what are the parties', amici and arb positions. RfA is more about discussing the way candidates would handle admin issues and not about the !voters or the positions of power users/accused parties/whatever. Structuring that by editors increases the risk of certain users "stealing the show" when what we should be doing is minimising it and making sure it's about assessing candidates on their merits. Szmenderowiecki (talk) 01:29, 19 February 2024 (UTC)
2. I would support a ban on threaded discussion under supports/opposes/neutrals, and ask that the discussion take place in a dedicated discussions section or on the RfA talk page. Z1720 (talk) 14:38, 20 February 2024 (UTC)
3. I would also support a ban on threaded discussion in the voting section only. Votes can be discussed in a discussion section. Might make things potentially worse though as things could get blown out of proportion more. SportingFlyer T·C 19:07, 27 February 2024 (UTC)

   Yes, that matches this proposal: Each user, including the candidate, may address issues or respond to other comments either after their own vote comment, or by creating their own sub-section in the General comments area. isaacl (talk) 00:54, 28 February 2024 (UTC)

General discussion (proposal 4)

Two quick questions: this will be a 7-day RfA vote with immediate voting but with comments grouped by editor or it will be a ten-day RfA? Secondly, will the candidate be able to reply to a user's remarks in the user's section? Because unlike ArbCom cases, RfAs are dynamic, particularly if the outcome is close, and realistically even if 10% of the usual 200-ish users start their own discussion subsections, replies to each of the users will be very hard to track. Szmenderowiecki (talk) 15:28, 18 February 2024 (UTC)

The intention is that this trial will utilise the usual seven days. If both these proposals are trialled, then the intention is that there would be a discussion on how each went, and the positive aspects utilised permanently, so we could end up with a 10 day RfA without threaded-discussions.

Candidates would comment in their own section. While candidates are currently not discouraged from responding directly to vote comments in their RfA, it is generally regarded as not a good idea. When it is seen that a candidate might benefit from responding to a negative criticism, the usual thing is that someone will write a question inviting the candidate to respond. I would expect that practise to continue, and for candidates to confine themselves to answering questions in the question section. SilkTork (talk) 16:38, 18 February 2024 (UTC)

Also, it may very well be that one change doesn't make much difference but two in conjunction will, so if the discussion-only trial is a success, maybe let's not revert back and just see if adding threaded discussions further improves RfA? Szmenderowiecki (talk) 15:32, 18 February 2024 (UTC)

I think it would be acceptable to set this trial up after the RfC following Barkeep's trial. I did consider that initially, but what gave me pause was that people can become RfC weary when it involves the same topic. I think there may be some benefit in having just the one RfC after both trials, rather than having two RfCs - one after each trial. But it could work either way, and people may indicate their preference when they comment. SilkTork (talk) 16:38, 18 February 2024 (UTC)

The Spanish Wikipedia does something similar: votes can only have a short comment (15 words max), and all questions to the candidate and extended discussion happen on the talk page. I am still undecided on its effectiveness (after all, there was only one successful RFA in all of 2023), but it's a point to consider, and I have certainly noticed that the discussion focuses more on the candidate than the voters. –FlyingAce^✈hello 16:02, 18 February 2024 (UTC)

Let's say that, in my own comment in an RfA of this sort, I want to say something about what another editor has said. If I understand the proposal correctly, I would say that within my own comment, as opposed to saying it in a threaded reply to the other editor. If I think about how this format has worked at WP:AE, where it is also used, it often leads to walls of text that end up being limited when admins enforce a word limit, but it doesn't reduce the back-and-forth sniping. At ArbCom, the format works better because, in part, editors are required to address their comments to Arbs or clerks, not one another, which would not be workable at RfA. Also, both ArbCom and AE use individual sections for each editor, whereas there would have to be a hundred-plus sections if we were to do actual sections at RfA. --Tryptofish (talk) 22:05, 18 February 2024 (UTC)

Conversation among editors can be held in the general comments section, much like is being done in this discussion. isaacl (talk) 22:34, 18 February 2024 (UTC)

Seems to me these proposals are all too complicated. The principle should be to discuss the candidate first and then vote after the discussion -- not during the discussion.

A sequence of events might be: (1) A nomination and seconds of the candidate to become an administrator followed by a statement by the candidate in which they tell us why they should be an administrator (with a maximum length of, say, 500 words). (2) Discussion of the candidate for, say, 5 days. Commentators may present pro or con evidence in favor of the candidate. "Evidence" is the key word here. You can't just say I don't like this candidate because they were mean to me; you have to present specific examples of said incivility or mistakes. Nor can you just say that the candidate is a good person; you have to present specific examples of what they have done that was good. The candidate and other people may respond, if they wish to address any of the comments. (3) Vote, for say 3 days. Support or oppose only. No comments allowed during the vote.

What that system would do would be to ensure that people have more information about the candidate before the vote begins. It would also encourage the candidate to participate directly in the discussion about their candidacy. Smallchief (talk) 00:14, 19 February 2024 (UTC)

I get the concerns about organization. I'm bothered by the arguments that it should be harder to oppose an RfA or that we should maintain a chilling effect on potential opposers. Thebiguglyalien (talk) 17:47, 20 February 2024 (UTC)

Proposal 5: Add option for header to support limited-time adminship (trial)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Following the passage of this proposal, candidates will have the option to include a header between Support and Oppose that will read Support adminship for a year. When closing the RfA, bureaucrats are to grant a year-long term of adminship only when there is no consensus to make a candidate an admin indefinitely, but the combined strength of both support sections does achieve consensus. After this has been tested on five RfAs that are not closed as SNOW or NOTNOW – or six months, whichever is sooner – this trial will end. No candidate may use this option twice.

For the discussion of this failed proposal, see Wikipedia:Requests for adminship/2024 review/Phase I/Closed proposals#Proposal 5: Add option for header to support limited-time adminship (trial)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 6: Provisional adminship via sortition

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Following the passage of this RfC the position of "Provisional Admin" will be created, to be selected by sortition at monthly intervals.

Provisional adminship

Provisional admins serve for a period of one year. During this year they may perform any activity a full admin performs, with the exception of enforcing discretionary sanctions or participating as an admin at WP:AE. In addition, full admins are permitted to revert the actions of provisional admins even when they would otherwise be forbidden from doing so by WP:WHEEL.

A provisional admin may at any point elect to go through WP:RfA; should they pass the process they will be permanently granted full adminship. Should they fail their provisional adminship will be revoked.

Provisional adminship may also be revoked at any time by a consensus of full admins at WP:AN, or by WP:ARBCOM.

Selection

Provisional admins are selected by sortition, with an editor who meets the following criteria being drawn once a month by the bureaucrats:

1. At least 10,000 total edits, including at least 5,000 in main space
2. At least 1,000 edits in the past year, including at least 500 in main space
3. Account registered at least three years ago
4. No sanctions within the past five years
5. At least one featured article or three good articles
6. Have never lost adminship under a cloud
7. Have never previously held provisional adminship

Following the passage of this RfC ArbCom may, as a one-time action, unilaterally alter these criteria before the process goes into effect. Future modifications to these criteria would need to be done through standard processes.

Prior to the drawn editor being announced, the bureaucrats shall inform ArbCom of the editors identity. ArbCom may, if they deem it necessary, silently veto the editor, in which case a new drawing shall occur.

A drawn editor may decline provisional adminship, in which case a new drawing shall occur. 10:54, 20 February 2024 (UTC)

For the discussion of this failed proposal, see Wikipedia:Requests for adminship/2024 review/Phase I/Closed proposals#Proposal 6: Provisional adminship via sortition

Notes (Proposal 6)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 6b: Trial adminship

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Proposal: If there is more than 60% support at RfA after three days from the start of voting and at least three admins willing to mentor an incoming admin, then the editor can get trial adminship. As a trial admin, they will get to participate in administrator activities and demonstrate that they have the technical expertise and understanding of policy to keep the tools. Trial adminship could last (extend the RfA) for up to three months (or some other arbitrary maximum), but can be as short as 3-14 days, depending on the level of community support and the finding of consensus by bureaucrats after the initial 7-day period; if there is no consensus above the passing mark but no major objections then a trial might be appropriate (added on 00:43, 23 February 2024 (UTC)). If a bureaucrat closes an RfA as "unsuccessful", if the candidate withdraws, if community support drops below 50%, or if the number of mentoring admins drops below 3, the trial ends as unsuccessful. On the other hand, if a bureaucrat closes an RfA as "successful" the trial ends with promotion to full-time adminship. Reverts of trial administrative actions by mentors would not count as wheel-warring, and reverts of trial administrative actions clearly not in policy does not count either. Awesome Aasim 21:47, 22 February 2024 (UTC)

For the discussion of this failed proposal, see Wikipedia:Requests for adminship/2024 review/Phase I/Closed proposals#Proposal 6b: Trial adminship

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 6c: Provisional adminship via sortition (admin nomination)

Following the passage of this RfC the position of "Provisional Admin" will be created, to be selected by sortition at monthly intervals.

Provisional adminship

Provisional admins serve for a period of one year. During this year they may perform any activity a full admin performs, with the exception of enforcing discretionary sanctions or participating as an admin at WP:AE. In addition, full admins are permitted to revert the actions of provisional admins even when they would otherwise be forbidden from doing so by WP:WHEEL.

A provisional admin may at any point elect to go through WP:RfA; should they pass the process they will be permanently granted full adminship. Should they fail their provisional adminship will be revoked.

Provisional adminship may also be revoked at any time by a consensus of full admins at WP:AN, or by any other process which provides for the revocation of adminship.

Nomination

Full admins may nominate any editor who meets the criteria for provisional adminship. If that nomination is seconded by three other admins, they shall be added to a list of candidates. A nominated editor must be informed of the nomination; they are free to decline the nomination.

Criteria

• Not subject to any current sanctions
• Never lost adminship under a cloud
• Never previously held provisional adminship

Selection

Provisional admins are drawn once a month by the bureaucrats, who may use any sufficiently random process they choose, which may include the development of a simple tool. The drawing shall not occur if there is less than five candidates on the list.

Prior to the drawn editor being announced, the bureaucrats shall inform ArbCom of the editors identity. ArbCom may, if they deem it necessary, silently veto the editor, in which case a new drawing shall occur. 00:00, 7 March 2024 (UTC)

Support (6c)

1. Part of the issue with our admin process is that many editors who would make excellent admins decline to run for various reasons; perhaps they are understandably apprehensive about the process, perhaps they just don't think they'll make good use of the tools. This will provide an avenue for admins to identify such users and nudge them in the direction of running, without giving admins the direct right to create other admins - even provisionally.

   I also believe that it will simplify the RfA process for those admins who do a good job as a provisional admin as I hope that we will be less critical of candidates who have already demonstrated they are competent with the tools.

   It's a still a bold proposal, but one that I think is worth considering, and one that should serve to boost the number of active administrators.

   As above, please don't oppose this solely based on concerns that the Foundation may not consider this sufficient process to grant advanced rights; if they don't they will tell us and there is no benefit in us guessing at what their response may be. BilledMammal (talk) 00:00, 7 March 2024 (UTC)

2. Weak support since there could reasonably be abuse, but informing ArbCom and other safeguards may leave open the possibility of a trial. Aaron Liu (talk) 02:53, 7 March 2024 (UTC)
3. Conditional support, otherwise oppose I strongly support the idea of an "entry level" admin but this needs a lot of refining because it has many problems in the details as written. So "support" only with an additional refinement phase. North8000 (talk) 18:33, 7 March 2024 (UTC)

So this is "Oppose as written" but support if a major revision could be derived from this concept during phase 2. North8000 (talk) 21:05, 16 March 2024 (UTC)

1. Sortition is a valuable model of democracy that is lightly used in modern political systems but that is well suited to a community like Wikipedia. The combination of a time-limit and the requirement to be deemed trustworthy by a small but informed group of people means that there is little reason for concern about harm caused by provisional admins. Creating pathways for editors to build experience as admins without the stress and awfulness of RfA will expand the pool of potential admins, and provisional admins running via RfA will have an actual record to examine. I think this is the most well designed of the sortition proposals, and am enthusiastic about its potential benefits. --JBL (talk) 19:31, 7 March 2024 (UTC)
2. Support - I think anything that allows people to become admins in a gradual manner is an absolute necessity. Once upon I time I had considered applying, but seeing the painful, never-ending process made me change my mind.  Mr.choppers | ✎  22:32, 10 March 2024 (UTC)
3. Support - I've long supported some form of limited time, limited power tryout for admins so we cn see how a candidate for full adminship performs, while reducing some backlogs. Why not a one year trial of the concept? If it is a disaster, the provisionals would be gone in another year.--agr (talk) 13:20, 11 March 2024 (UTC)
4. Seems reasonable. * Pppery * _{it has begun...} 23:07, 14 March 2024 (UTC)
5. Support the general idea, but dislike this particular rule: "Never previously held provisional adminship". If the provisional admin was effective, I don't see a good reason not to keep them on. Banedon (talk) 04:00, 15 March 2024 (UTC)

   I think the point is that if they were effective, they should hold an RfA, and give other candidates in the pool a chance . Aaron Liu (talk) 11:53, 15 March 2024 (UTC)

6. —Compassionate727 ^(T·C) 23:07, 17 March 2024 (UTC)

Oppose (6c)

1. Still no, for all the conveniently-hidden reasons from #6, now with the ones from #26 to back them up. —Cryptic 01:30, 7 March 2024 (UTC)
2. Oppose. This revises the current system of being (typically) nominated by admins and then being discussed by the community, to being nominated by admins and then chosen at random. There needs to be community input, not a random process. --Tryptofish (talk) 23:05, 7 March 2024 (UTC)
3. This is at least an improvement on the earlier sortition proposal, but any system that allows for people to become administrators without "the trust and confidence of the community" (even for only a year) is pretty much guaranteed to get an oppose from me. Extraordinary Writ (talk) 07:12, 8 March 2024 (UTC)
4. Oppose I strongly dislike sortition as a voting system. Particularly for a site like Wikipedia, there needs to be at least some community input into who is selected to be an admin. JML1148 ^{(talk | contribs)} 00:59, 10 March 2024 (UTC)
5. Oppose - there is no set of criteria such that all users who pass them automatically would be good enough administrators, even with the limited safeguards stated here. Becoming an administrator is primarily an issue of trust. Animal lover |666| 05:55, 11 March 2024 (UTC)
6. Oppose per the reasoning laid out by many users at the original Proposal 6. Regardless of the changes made to RfA, there should still be some sort of manual vetting by the userbase. ― novov (t c) 07:04, 11 March 2024 (UTC)

   The criteria for this one is manual vetting by admins, though Aaron Liu (talk) 11:27, 11 March 2024 (UTC)

   The userbase isn’t solely composed of admins; I meant the community as a whole. I should have been a bit clearer there, my bad. ― novov (t c) 18:48, 11 March 2024 (UTC)

7. Fails the foundation requirement that viewdelete access only be given following a community process. Stifle (talk) 11:47, 12 March 2024 (UTC)
8. Oppose there needs to be a review process before admin are promoted. Z1720 (talk) 14:31, 13 March 2024 (UTC)
9. Sortition is, in my view, not an appropriate process for gaining the mop. Less than five admins' approval is a rather low bar too, and hardly demonstrative of the community trust which I believe is necessary for holding the mop. JavaHurricane 17:47, 13 March 2024 (UTC)
10. Oppose Any form of adminship should be subject to approval by the community. Sweet6970 (talk) 13:00, 14 March 2024 (UTC)
11. Oppose - the principle that admins are selected by the community should remain in place, I don't think handing advanced permissions based on the opinions of a small handful of admins is sensible. I don't even think it really works that well for the less advanced permissions, and certainly those with the full powers of admins should be properly vetted.  — Amakuru (talk) 13:05, 14 March 2024 (UTC)
12. Oppose - Luck should not replace "community support".--☾Loriendrew☽ ☏(ring-ring) 23:21, 14 March 2024 (UTC)
13. Oppose. Sortition is an interesting idea, but I don't like the role of admins as nominators here, or ArbCom as gatekeepers. Tim Smith (talk) 00:43, 16 March 2024 (UTC)
14. Oppose per my notes in 6d. — xaosflux ^Talk 20:21, 16 March 2024 (UTC)
15. Oppose Profoundly opposed to any system that involves selection lottery, luck, chance and above all lack of critical scrutiny by the community as a whole. Leaky caldron (talk) 10:07, 17 March 2024 (UTC)

Discussion (6c)

As the nominations are determined by admins, this is really more akin to a vouch system and closer to Wikipedia:Requests for adminship/2024 review/Phase I § Proposal 26: Have the admin corps select its own members than the original proposal 6. isaacl (talk) 01:04, 7 March 2024 (UTC)

The numbering scheme has been a disaster almost from the beginning, it's far too late to do anything about it now. --JBL (talk) 20:53, 7 March 2024 (UTC)

My comment is not about the numbering. This proposal isn't actually one that chooses randomly from a pool of people meeting certain criteria, since the admins control the candidate pool. Thus it's not sortition, but a vouch system. isaacl (talk) 22:09, 7 March 2024 (UTC)

@Isaacl: it's both? The vouch system puts people into the pool; then sortition happens from that pool. If the pool is too small for meaningfully random selection, nothing happens. --JBL (talk) 22:16, 7 March 2024 (UTC)

That doesn't sound like sortition as described in its article: ... sortition is the selection of public officials or jurors using a random representative sample. Having a nominating group filter the pool for the sample works against the goal of having a random representative sample. isaacl (talk) 22:23, 7 March 2024 (UTC)

? A jury is selected by a random sample of people eligible to be jurors (according to the rules of the relevant legal system concerning what "eligible" means---in my state, that includes a citizenship requirement, an age requirement, a residence requirement, a language fluency requirement, a requirement that you not have been convicted of certain crimes or be currently involved in certain legal proceedings, and a requirement that you not suffer from a disqualifying disability). Here an admin is selected by a random sample of people eligible to be so selected (according to the rule that eligibility is granted by being four-times vouched and a few other things). "Being four-times vouched" is not particularly similar to "being a US citizen", but "being an ancient Athenian citizen" wasn't particularly similar to "being a US citizen", and what they did was still definitely sortition. --JBL (talk) 22:33, 7 March 2024 (UTC)

Everyone who meets the jury requirements are placed into the pool for selection; there is no selection committee filtering the eligible pool members. If jury pools required nominations from four previous jurors, this would work against getting a random representative sample. isaacl (talk) 22:39, 7 March 2024 (UTC)

The condition that jurors be literate "works against" selecting a random sample of people who are not required to satisfy this condition; similarly every other condition that defines the pool "works against" selecting a random sample of people who are not required to satisfy the condition. But that's irrelevant to whether or not this is sortition, because sortition is random selection from the pool of people who have met all eligibility conditions.

Since this all amounts to somewhat confused pedantry over a point that has no implications whatsoever for anything, I invite you to collapse all the discussion beginning with my first comment and including this one. --JBL (talk) 22:50, 7 March 2024 (UTC)

Proposal 6d: Provisional adminship via sortition (criteria to be determined)

Following the passage of this RfC the position of "Provisional Admin" will be created, to be selected by sortition at monthly intervals.

Provisional adminship

Provisional admins serve for a period of one year. During this year they may perform any activity a full admin performs, with the exception of enforcing discretionary sanctions or participating as an admin at WP:AE. In addition, full admins are permitted to revert the actions of provisional admins even when they would otherwise be forbidden from doing so by WP:WHEEL.

A provisional admin may at any point elect to go through WP:RfA; should they pass the process they will be permanently granted full adminship. Should they fail their provisional adminship will be revoked.

Provisional adminship may also be revoked at any time by a consensus of full admins at WP:AN, or by any other process which provides for the revocation of adminship.

Criteria

Upon the passage of this RfC a discussion will be held to determine potential criteria. Each criterion will then be voted on seperately, to determine the full criteria necessary to be met for eligibility.

Selection

Provisional admins are selected by sortition, with an editor who meets a specified criteria being drawn once a month by the bureaucrats who may use any sufficiently random process they choose, which may include the development of a simple tool.

Prior to the drawn editor being announced, the bureaucrats shall inform ArbCom of the editors identity. ArbCom may, if they deem it necessary, silently veto the editor, in which case a new drawing shall occur.

A drawn editor may decline provisional adminship, in which case a new drawing shall occur. 00:00, 7 March 2024 (UTC)

Support (6d)

1. In the initial proposal I attempted to create a list of potential criteria, with the possibility of ArbCom intervention to address any deficiencies in it. However, as can be seen from many of the oppose !votes, the specific criteria will be difficult to get right and will need considerable community work and engagement to determine; I hope that this alternative proposal will provide for this and address many of the oppose !votes.

   Apart from that, I support this because regardless of what the criteria ends up being I believe that it is worth doing because I believe the benefits will be significant:

   1. I believe it will result in us gaining excellent admins we would never have otherwise gained due to them having been unwilling to run for various reasons
   2. I believe that it will simplify the RfA process for those admins who do a good job as a provisional admin; I hope that we will be less critical of candidates who have already demonstrated they are competent with the tools.
   3. I believe it will provide a strong boost to the number of admins; even if only 50% convert from provisional to full that is still an extra six a year, and if sortition is discovered to be functional we can increase the number of editors selected each month.
   As above, please don't oppose this solely based on concerns that the Foundation may not consider this sufficient process to grant advanced rights; if they don't they will tell us and there is no benefit in us guessing at what their response may be. BilledMammal (talk) 00:00, 7 March 2024 (UTC)
2. I think the criteria in 6(c) are very well chosen, but I support this as a fallback position. --JBL (talk) 19:32, 7 March 2024 (UTC)
3. Same as 6c, I support the general idea. Banedon (talk) 04:01, 15 March 2024 (UTC)

Oppose (6d)

1. I disagree with drafting editors without prior discussion to see if they are interested in taking on administrative work. It's a thankless role with tedious tasks that makes you a target of criticism. Let's not put editors under scrutiny for their suitability to be an admin unless they've volunteered with full knowledge of the consequences. isaacl (talk) 01:08, 7 March 2024 (UTC)

   @Isaacl: This oppose seems wrongheaded in all its particulars. (1) Every admin I interact with seems to get thanked a lot. It's a volunteer position, and no one who accepts it is obligated to do any task they find tedious or otherwise unpleasant. (2) In this proposal, potential candidates are offered the opportunity to decline; this is precisely a "prior discussion to see if they are interested in taking on administrative work". (I'm sure BilledMammal would consider it a friendly amendment to replace the opportunity to decline with a requirement of affirmative acceptance---I don't think anyone imagines making people admins while they're on vacation or whatever if they don't respond.) (3) I don't understand your third sentence at all, admins are not "under scrutiny" as a general rule. --JBL (talk) 22:26, 7 March 2024 (UTC)

   Candidates undergo scrutiny. With the current system, they are aware of this and of the resulting consequences. Picking people randomly and asking them to be an administrator will place them under scrutiny from those who, like today, seek to determine if they feel the candidate is sufficiently trustworthy to be an administrator. This isn't a kind thing to do to those who haven't voluntarily requested consideration for administrative privileges. isaacl (talk) 22:31, 7 March 2024 (UTC)

   Ok I don't know who you think these admin police are you go around scrutinizing all the activities of every admin (????) but of course you are entitled to !vote here however you want. --JBL (talk) 22:37, 7 March 2024 (UTC)

   Well, I didn't say that; I said admin candidates undergo scrutiny, as can be seen from comments during RfAs. isaacl (talk) 22:42, 7 March 2024 (UTC)

   Yes but the whole point of this proposal is that the candidates don't go through RfA! --JBL (talk) 22:59, 7 March 2024 (UTC)

   Sure, but those who want to determine if, in their view, the latest admin candidate is sufficiently trustworthy will still want to examine the candidate's past record anyway. isaacl (talk) 23:08, 7 March 2024 (UTC)

   I think you should check the page history of any at least 6-month-old admin and filter for reverted edits. Aaron Liu (talk) 22:56, 7 March 2024 (UTC)

   The page history of that admin's talk page. Not sure how that snuck out Aaron Liu (talk) 15:59, 14 March 2024 (UTC)

   (I'm sure BilledMammal would consider it a friendly amendment to replace the opportunity to decline with a requirement of affirmative acceptance---I don't think anyone imagines making people admins while they're on vacation or whatever if they don't respond.) That change makes sense to me. BilledMammal (talk) 06:26, 8 March 2024 (UTC)

2. The issue is not the criteria. See opposition and discussion for #6. —Cryptic 01:30, 7 March 2024 (UTC)
3. Oppose. The more I think about sortition, the less I like it as a substitute for some sort of deliberative process. --Tryptofish (talk) 23:07, 7 March 2024 (UTC)
4. Per my comment on 6c, I can't see any set of criteria as being sufficient for this. Extraordinary Writ (talk) 07:13, 8 March 2024 (UTC)
5. Oppose per my comment on 6c. JML1148 ^{(talk | contribs)} 01:09, 10 March 2024 (UTC)
6. Oppose per the reasoning laid out by many users at the original Proposal 6. Regardless of the changes made to RfA, there should still be some sort of manual vetting by the userbase. ― novov (t c) 07:05, 11 March 2024 (UTC)
7. Oppose I like the idea of outreach / initiative, but not the randomness or lack of evaluation. North8000 (talk) 21:16, 11 March 2024 (UTC)
8. Oppose Any form of adminship should be subject to approval by the community. Sweet6970 (talk) 13:01, 14 March 2024 (UTC)
9. Oppose - the principle that admins are selected by the community should remain in place, I don't think handing advanced permissions based on the opinions of a small handful of admins is sensible. I don't even think it really works that well for the less advanced permissions, and certainly those with the full powers of admins should be properly vetted.  — Amakuru (talk) 13:05, 14 March 2024 (UTC)
10. Oppose - Luck should not replace "community support".--☾Loriendrew☽ ☏(ring-ring) 23:22, 14 March 2024 (UTC)
11. Oppose The community should be able to specifically evaluate candidates prior to promotions. — xaosflux ^Talk 20:20, 16 March 2024 (UTC)
12. Oppose Profoundly opposed to any system that involves selection lottery, luck, chance and above all lack of critical scrutiny by the community as a whole. Leaky caldron (talk) 10:08, 17 March 2024 (UTC)

Proposal 7: Threaded General Comments

Following this RfC, the General Comments section would become a threaded discussion

Threaded discussion

So, maybe a bit minor, but I do find the general comments section to be a bit weird. We have a discussion, which is almost always bulleted. These are almost always places to comment on either other people's !votes, individual questions or functionary issues with the RfC. Items that get too long get moved to the talk page.

I have seen users complaining about the talk page not being taken into account when closing (I certainly read it, but I can see why people have this reservation). My thoughts, use level 3 headers to thread the discussions in such a way to allow people to discuss items in a more controlled way. This would also run in parralel with deprecating replying to individual !votes. Lee Vilenski ^{(talk • contribs)} 12:13, 20 February 2024 (UTC)

Support (proposal 7)

1. Support, I guess? I don't think it really matters, but... Queen of Hearts (talk • stalk • she/they) 04:02, 21 February 2024 (UTC)
2. Ehhh, not sure where i should put this, but the proposal to add a simple edit notice to encourage section headings would be enough, without any actual rule changes. Aaron Liu (talk) 14:37, 21 February 2024 (UTC)
3. Support — PerfectSoundWhatever (t; c) 13:55, 27 February 2024 (UTC)
4. Support Anything that can give a bit more structure / organization to the crowd scene would be a plus. North8000 (talk) 18:37, 7 March 2024 (UTC)
5. Support Don't really think this will change much, but a good idea nonetheless. JML1148 ^{(talk | contribs)} 01:10, 10 March 2024 (UTC)

Oppose (proposal 7)

1. Oppose. If someone clerking an RFA takes issue with a general comments section's lack of tidiness, they're free to clean it up as they see fit. I'm not sure why the proposer, a bureaucrat, would be hesitant to do this. City of Silver 00:56, 28 February 2024 (UTC)
2. The restriction from replying to individual votes puts me here. We have a sleuth of editors who can determine when a vote discussion thread gets out of hand, and wholesale preventing discussion in this manner both silences the possibly-valid opinions and discourages the community participation aspect of Wikipedia itself. Steel1943 (talk) 13:34, 28 February 2024 (UTC)
3. Not seeing how this would improve RfA. Extraordinary Writ (talk) 03:51, 29 February 2024 (UTC)

Neutral (proposal 7)

1. Doesn't seem like this changes anything substantial. Banedon (talk) 05:30, 27 February 2024 (UTC)
2. This looks like something we can just do! Don't think we need a proposal to say so. theleekycauldron (talk • she/her) 21:05, 10 March 2024 (UTC)

General discussion (proposal 7)

• Threaded means "sorted" according to what? By topics, users, timestamps? There is no technical problem preventing discussions to be threaded, and I see nothing that prohibits threaded discussions by topic (which I assume is what this proposal is about). I think it can be done spontaneously without asking for special permission, just nobody cared enough so far. Szmenderowiecki (talk) 13:48, 20 February 2024 (UTC)
• Huh? @Lee Vilenski: would you perhaps make a mock up what this is trying to achieve (Perhaps reformat an old RFA GD section on a sandbox for demonstration). The GD is already a h5 so I don't think putting h3 sections in to it is a great idea. Regarding the talk page, conceptually I prefer the talk page be reserved for meta-issues (admin/crat reqeusts, discussion about contributors or their statements, etc). — xaosflux ^Talk 15:02, 20 February 2024 (UTC)

  Sure, sorry, this read a bit more obvious to me when I wrote it than how it came out. I hadn't realised it was level 5 headers, which is a bit of a shame. I have, however, moved some comments to User:Lee Vilenski/sandbox for the jist of the idea. The thing about the general comments is that they are often just a series of non-related comments about the RfA. I'd rather a discussion style, where we'd have a location to hold discussions about other people's !votes. Lee Vilenski ^{(talk • contribs)} 19:16, 20 February 2024 (UTC)

  That helps some and may not need any rule changes - perhaps just encourage discussion creators to start h6 sections? — xaosflux ^Talk 19:19, 20 February 2024 (UTC)

  Sure. I don't think we need any rules to be changed, but as we are looking for proposals, it's a good opertunity to gauge opinion. Lee Vilenski ^{(talk • contribs)} 19:26, 20 February 2024 (UTC)

  Oh for sure, if that is what you are going after, this can be about if that's a good idea - and perhaps do it with a comment on the preload. — xaosflux ^Talk 21:50, 20 February 2024 (UTC)

• I have no idea what this is asking to change. * Pppery * _{it has begun...} 17:27, 20 February 2024 (UTC)
• I'm with Pppery here, threads are started in the general discussion area all the time, I've started some of them myself. If you are proposing that back-and-forths get moved to the general discussion area instead of the talk page by default that needs to be made more clear. sub-sectioning within the general comments is unusual, perhaps because it requires h6 headers, but there's no prohibition against it and I'm not sure it adds much though I can't say I'm opposed to encouraging their use if people find them helpful. 184.152.68.190 (talk) 05:58, 26 February 2024 (UTC)

Proposal 8: Straight vote

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Following the trial of the discussion-first RfA (provided the proposal is enacted), a second trial will run for six months or 5 Requests for Adminship (RFAs) which are not closed as SNOW or NOTNOW, whichever happens sooner. During the trial, the main RfA page will consist exclusively of a numbered "support" and "oppose" section. The only thing participants will be allowed to type in those sections is their signature. If a candidate receives 65% of the vote, they are automatically given adminship, and there will be no bureaucrat chats. The talk page of the RfA may be used for any relevant discussion. 00:52, 21 February 2024 (UTC)

For the discussion of this failed proposal, see Wikipedia:Requests for adminship/2024 review/Phase I/Closed proposals#Proposal 8: Straight vote

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 9: Require diffs

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Require all support or oppose comments to also add unique diffs relevant to, and/or supportive of, their comments.

You can still say "also per so-n-so", but you still have to provide unique diffs of your own first.

If you support or oppose a candidate, you should be able to show why. If they are ready for adminship, this should be an easy thing to do. - jc37 05:43, 21 February 2024 (UTC)

For the discussion of this failed proposal, see Wikipedia:Requests for adminship/2024 review/Phase I/Closed proposals#Proposal 9: Require diffs

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 9b: Require links for claims of specific policy violations

Require any comment that claims any participant in the RFA, including the candidate, has engaged in specific policy violations or other misbehavior to provide evidence for their allegations* in the form of a link (preferably in the form of a diff) to the alleged misconduct in line with our no personal attacks policy. Claims of misbehavior or policy violations without links to where they occurred may be treated as casting aspersions and summarily removed by [any participant | any uninvolved editor | any uninvolved bureaucrat]**. If the aspersion is cast in the form of a vote, the vote itself may not be removed, but potentially all of the rationale may be. Any editor whose comment is removed must be notified of the removal. Editors who repeatedly cast aspersions without any evidence may be blocked in line with the no personal attacks policy and the blocking policy. Reaper Eternal (talk) 16:02, 4 March 2024 (UTC)

*This only applies to claims that someone violated a Wikipedia policy, such as "candidate is uncivil" or "candidate adds unsourced content". Personal adminship requirements like "didn't rollback enough vandals", "needs a higher edit count", or "should have written a GA" do not need links.

**Who actually may perform the removal will need to be decided in a phase II RFC. I simply included some examples of likely wording.

Updated to apply only to specific policy violations per discussion. Reaper Eternal (talk) 17:23, 10 March 2024 (UTC)

Support (proposal 9b)

1. As proposer. Reaper Eternal (talk) 16:02, 4 March 2024 (UTC)
2. I don't see any problems with this. Aaron Liu (talk) 18:01, 4 March 2024 (UTC)

   Changing to conditional support under the condition that only claims of policy violations require diffs, per Tryptofish below Aaron Liu (talk) 23:17, 6 March 2024 (UTC)

3. WP:NPA is codified policy, but is generally ignored at RFA: codifying that it applies there is a good call, though I think enforcement is going to be tricky. I agree with Tryptofish below that a civil oppose that doesn't make reference to misbehavior policy violation is acceptable, but I don't see that being affected by this proposal. Vanamonde93 (talk) 16:40, 6 March 2024 (UTC)
4. I support this on the condition that this only applies to claims that the candidate has violated a specific policy or guideline. QuicoleJR (talk) 17:11, 8 March 2024 (UTC)
5. Support on QuicoleJR's condition. Otherwise, I worry that there will be endless RfCs about what does and doesn't count as requiring a diff. JML1148 ^{(talk | contribs)} 01:12, 10 March 2024 (UTC)
6. Support. I switched to "support" now that the vague "misbehavior" has been struck from the proposal. My concern that a requirement for diffs and diffs are gameable in both directions remains. But now that the proposal has been narrowed, overall it's a good idea. North8000 (talk) 21:39, 11 March 2024 (UTC)
7. * Pppery * _{it has begun...} 23:08, 14 March 2024 (UTC)
8. I don't see why not, but would prefer to see some kind of change also to threaded discussions, since this will inevitably lead to lots of people analyzing the diffs (which makes the RfA harder to read). Banedon (talk) 04:03, 15 March 2024 (UTC)
9. Makes sense. Could also be redundant given we can already action upon those claims per ASPERSIONS. 0xDeadbeef→∞ (talk to me) 06:12, 17 March 2024 (UTC)

Oppose (proposal 9b)

Oppose. I opposed another proposal somewhere else on this wall of proposals, citing the possibility of someone opposing in an RfA on the basis of something like "My past experiences with the candidate make me worry that they will be too quick with the block button". I oppose this proposal, as written, for the same reasons. I suppose one could wiki-lawyer that this isn't exactly a specific allegation of wrongdoing, so it would be part of the exceptions that have been noted, but I have no doubt that, if adopted, the proposal would be construed as reason to attack such an oppose. Some editors may consider such an oppose to be an aspersion, but, tomayto, tomahto. The fact is that such opposes are entirely valid, and should not be discouraged, much less forbidden. And, as I have also said elsewhere on this page, genuinely aspersion opposes are easily discounted if they lack merit, and the real problem is that good candidates don't want to undergo RfA because they don't want to be pilloried over valid criticisms of things that they were actually wrong about, but which are atypical of their overall contributions and qualifications. --Tryptofish (talk) 23:53, 4 March 2024 (UTC)

Now that the wording has been changed, I'm no longer opposing. I believe that such a correction should also be made for similar proposals being considered, such as Proposal 2. --Tryptofish (talk) 21:00, 10 March 2024 (UTC)

Oppose I like the idea of someone being required to substantiate accusations of severe misbehavior, but this particular proposal has many problems. The biggest is nearly anything or any complaint could be viewed by someone as "misbehavior". And, for anything other than severe misbehavior, diffs or a requirement for diffs is too game-able in both directions. North8000 (talk) 18:52, 7 March 2024 (UTC) Struck North8000 (talk) 21:34, 11 March 2024 (UTC)

The requirement would be gameable to be worse than it was before, how? Aaron Liu (talk) 20:39, 7 March 2024 (UTC)

@Aaron Liu: The proposal has been modified (substantially narrowed) since my post and accordingly I'm planning on reversing my position. But I'll still answer as if it still said "misbehavior" why (a requirement for) diffs is gameable/gamed in both direction. On the "deprecate the complaint" side some complaints are due to the sum total of dozens of observations and can't be established by a few diffs, and so diffs not establishing is taken as something against the point. Closely related is that it modifies the person's argument.. often to a straw man or unintended weaker version. It switches it from "evaluate my argument as I gave it" to "these diffs establish my argument". The way that it is gameable in the other direction is manipulating with diffs via taking them out of context. So the 90% of editors that don't take a deep dive and review the context will be misled.North8000 (talk) 21:32, 11 March 2024 (UTC)

1. Oppose If I know a candidate does something untoward but I can't find the evidence for whatever reason, I don't want to be dissuaded from participating in the RfA. SportingFlyer T·C 15:04, 17 March 2024 (UTC)

General discussion (proposal 9b)

Tryptofish, I would argue that if someone has significant enough bad experiences with the candidate, they should be able to link at least one example. If no such link can be found, perhaps the rationale is more "I don't like them" rather than "Their behavior indicates that they would be a poor administrator." Reaper Eternal (talk) 01:20, 5 March 2024 (UTC)

Except that it's very much not the case that such opposes are typically just a matter of "I don't like them." I get where these proposals are coming from, I really do, but if we can allow supports that are based on "I agree with the noms" without requiring diffs or links to prove why you agree with them or what parts of the nomination you agree with, then this proposal, and the others, are just setting up roadblocks that will discourage good-faith opposes and reward those who badger the opposes. And in fact, badgering of opposes is arguably a bigger problem than weakly reasoned opposes. A single oppose presented without diffs isn't going to sink an RfA, but if a large number of other editors end up opposing because they agree with that initial oppose, then that's the consensus. And as I said above, this is the wrong way to fix the real problem, which is good potential candidates not wanting to bother because of things where there are diffs to be found.

But here's a suggestion for this proposal, and the others like it on this page. Instead of saying that there has to be a link or diff, say that there has to be a link, a diff, or an explanation. I could support that. Other editors can evaluate whether or not an explanation has merit. And we can agree that if there isn't even an explanation for an oppose, that's a valid reason to discount it. --Tryptofish (talk) 22:12, 5 March 2024 (UTC)

The proposal only applies to Claims of misbehavior or policy violations. Such would nearly always have diffs, and just "explanation"s would be too weak. Aaron Liu (talk) 17:15, 6 March 2024 (UTC)

Clarifying that would help a lot. I don't have a problem with a proposal like this for claims of policy violations by the RfA candidate (basically for claims of things that could have resulted in a block or ban). But "claims of misbehavior" casts a much wider net. One person might construe it to mean essentially the same thing as violating policy, but another person might construe it to mean being too eager to want people you disagree with to be blocked. And given the recent trend of badgering opposers, there's a significant likelihood of the latter occurring. --Tryptofish (talk) 19:59, 6 March 2024 (UTC)

I've updated the proposal to only apply to claims of specific policy violations. The crux of this issue was users who allege serious policy violations without evidence as a way to try to nuke an RFA. This isn't an attempt to stifle legitimate opposition. Reaper Eternal (talk) 17:23, 10 March 2024 (UTC)

Thanks, that makes me withdraw my opposition. --Tryptofish (talk) 21:00, 10 March 2024 (UTC)

Isn't this proposal almost the same thing as simply barring unexplained opposes? I always understood the badgering of unexplained signed opposes as kind of a reminder to adhere to WP:NPA (why else would someone sign an unexplained oppose instead of simply not participating in the RfA?) That is a proposal I could possibly get behind, seeing how much that kind of behavior has led to unnecessary drama and disruption at RfAs. StonyBrook _babble 03:18, 8 March 2024 (UTC)

No, and unexplained opposes shouldn't be barred. (They may be given low weight by the closing bureaucrat, but that's outside the scope of this proposal.) This simply reinforces that WP:NPA is a policy and applies to WP:RFA. Reaper Eternal (talk) 17:26, 10 March 2024 (UTC)

Proposal 10: Unbundling 90% of blocks

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Identifying vandals and spammers is easy, that's why we hand out rollback like candy. Blocking for incivility and pretty much any block involving goodfaith editors is difficult, and we need to vet candidates for that right very seriously. Uncontentious blocks of IPs and newbies for vandalism are the vast majority of the blocks we currently only have admins to issue. So it would be logical to create a new userright with the block/unblock button and also view deleted. This block/unblock button would only work on IPs and editors who are not yet extended confirmed. Admins would still have the full block and unblock power as at present.

For the discussion of this failed proposal, see Wikipedia:Requests for adminship/2024 review/Phase I/Closed proposals#Proposal 10: Unbundling 90% of blocks

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 11: Set some of the Admin criteria

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Much of the angst and disagreement at RFA isn't really about the candidate, it is about the criteria for adminship. Hence the critique of RFA as it being like taking your driving test whilst driving a minibus full of examiners who are arguing with each other about the criteria for the test. This also causes uncertainty among potential candidates as to what the criteria is. Part of the problem of RFA as opposed to Rollback, Autopatroller or other userrights is that we don't have defined criteria for adminship that potential candidates can look at. Some of those criteria, 12 months activity, no blocks in the last month, at least 3,000 edits and some experience could be set by consensus in individual RFCs per criteria.

For the discussion of this failed proposal, see Wikipedia:Requests for adminship/2024 review/Phase I/Closed proposals#Proposal 11: Set some of the Admin criteria

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 12: Abolish the discretionary zone and crat chats

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

RfA has a discretionary zone as part of its "not a vote" tradition. At some point (when RfAs had become rare), individual bureaucrats no longer wanted to exercise this discretion so crat chats were born, leading to additional days of bureaucrat scrutiny of the voters' arguments. This was a nice idea when it started, but now the community anticipates the crat chats. This means that during voting, people are inclined to make more and more lengthy arguments to ensure their vote is counted, further increasing the contentiousness of the discussion and the stress for the candidate. A simple hard pass/fail boundary would help to calm things down instead of inflaming things further like the anticipation of crat chats.

For the discussion of this failed proposal, see Wikipedia:Requests for adminship/2024 review/Phase I/Closed proposals#Proposal 12: Abolish the discretionary zone and crat chats

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 12b: Abolish crat chats and allow discretionary relisting

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Basically the same rationale as proposal 12: bureaucrat chats rarely produce a result contrary to the numeric result of a 7-day RFA discussion, thus they needlessly elevate the tension of an already-stressful process. In my analysis of RFA statistics, a review of the discretionary ranges showed that, since 2009, RFAs ending with a numeric result below 70% nearly always fail, despite having expanded the discretionary range down to 65% in 2015. This suggests that bureaucrat chats aren't meaningful in determining consensus. Thus I propose that we eliminate bureaucrat chats and replace with a discretionary relisting period. If after 7 days an RFA carries a numeric result between 70% - 75%, it is automatically relisted for an additional 7 days. If the result remains below 75% after one relist then the RFA fails. Ivanvector (^Talk/_Edits) 15:39, 28 February 2024 (UTC)

For the discussion of this failed proposal, see Wikipedia:Requests for adminship/2024 review/Phase I/Closed proposals#Proposal 12b: Abolish crat chats and allow discretionary relisting

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 12c: Lower the high end of the bureaucrats' discretionary zone from 75% to 70%

If an RFA candidate has 70% or more support, they have earned the community's trust and the 'crats should not be obligated to determine consensus. City of Silver 21:49, 1 March 2024 (UTC)

Support (proposal 12c)

1. Support as proposer. There have been 12 'crat chats on RFAs that had 70%+ support. Eight of those ended with promotions. Of the four that did not, two were on RFAs that should have ended with promotions. That means of 12 candidates, 10 either got promoted or should have. Hear me out and see the chart here for more.

   • The May 2007 'crat chat for User:Gracenotes was an outrage: it lasted five and a half damn days and got input from just four bureaucrats before the nominee waved the white flag. Even still, it clearly was going to end as no consensus. Gracenotes wanted to run again but never did and, sadly, hasn't been seen since 2010.
   • The October 2007 chat for User:Remember the dot ran its course but incorrectly determined there was no consensus to promote. I know that was a really different time but come on: this RFA got 73.8% support, only three 'crats voted, and the candidate's second try got 96.1% support three and a half months later. The 'crats, bless their hearts, got this one really wrong. Remember the dot remains an admin in good standing over sixteen years later.
   • The August 2012 'crat chat for User:Mlpearc ended unanimously. This was the right call given the periodic serious trouble they've gotten in since. Even still, they remain a prolific, fine contributor (under a different username) well over a decade later. This, from 11.5 years ago, was the last time a candidate with 70%+ support was rightfully not promoted.
   • User:Cyberpower678 withdrew during July 2015 'crat chat that was, incredibly, tied 5 to 5. That's the most bewildering one of these discussions I've reviewed: four of five bureaucrats who saw a consensus to promote gave strong rationales while four of five opposers did so weakly, which mirrored the support and opposition in the RFA. In January 2017, Cyberpower678 tried a second time and was promoted in a landslide. This weird discussion appears to have cost us a year and a half's worth of good tool use from this editor, who remains a trusted admin over seven years later. This, from 8.5 years ago, was the last time a candidate with 70%+ support was not promoted.

   tldr: The high end of the zone of support that requires a bureaucrat chat is 75% but it should be lowered to 70% since almost every candidate who's gotten above 70% is one that either got promoted or should have. City of Silver 21:49, 1 March 2024 (UTC)

2. Support. This is a fairly small change, and would move RfA in a slightly friendlier direction. And 70% support is enough support to be meaningful. It's barely different from the current 75%, and (in a different, private type of election format) we elect ArbCom members with less. --Tryptofish (talk) 22:39, 1 March 2024 (UTC)
3. Support Crat chats are one form of added stress which we can and should avoid when possible. 70% support is still very strong. I still like having a discretionary range though, so one vote doesn't tip the scales too much. Galobtter (talk) 23:39, 1 March 2024 (UTC)
4. Support per above. Mach61 22:06, 2 March 2024 (UTC)
5. Support. I think we should go for even more radical things, but this proposal does two good things: potentially increase number of candidates who pass, and reduce the potential for bureaucrat chats that make the process even more painful to candidates. —Kusma (talk) 13:59, 3 March 2024 (UTC)
6. Strong support 70% is still very strong support. It's a volunteer service, of course administrators need to be vetted but the process in place already accomplishes that. Its just added stress for everyone involved, and an especially undue amount on the candidate. If you get under 70%, they should probably go over the points raised. over 70% though, there's strong enough consensus. DarmaniLink (talk) 12:59, 6 March 2024 (UTC)

   Often, people between 70% and 75% need to make a promise, which crat chats would tell. Aaron Liu (talk) 17:19, 6 March 2024 (UTC)

7. Strong support 70% is enough, decreasing the discretion zone would make RfA more community and less 'crat. Rusty4321 ^{talk contribs} 03:41, 8 March 2024 (UTC)
8. Support per my comments at § Oppose (proposal 21). Passing candidates at 70% and minimizing the discretionary zone constitute a win/win. StonyBrook _babble 07:03, 8 March 2024 (UTC)
9. Support' 70%, to me, is already showing strong support for a candidate. A crat chat puts more pressure and stress on a candidate that often isn't necessary. — Preceding unsigned comment added by JML1148 (talk • contribs) 01:16, 10 March 2024 (UTC)

Oppose (proposal 12c)

1. No. Consensus is not determined by vote counting. —SmokeyJoe (talk) 22:24, 1 March 2024 (UTC). Bureaucrats should not be told that in the range of 70-75% their judgement and discretion is not wanted. SmokeyJoe (talk) 11:22, 2 March 2024 (UTC)
2. I am not convinced that the examples provided demonstrate a pattern needed for adjustment. Aaron Liu (talk) 02:57, 2 March 2024 (UTC)
3. Oppose. This would not affect candidates with more than 70%, who almost always already pass (you have to go back nine years to find a counterexample). But it would cause candidates in the high 60s (the new upper half of the discretionary range) to start passing more often, and I don't think that'd be a good thing, basically per my comment on 21b. Crat chats already reach the right outcome. Extraordinary Writ (talk) 08:59, 3 March 2024 (UTC)
4. Oppose because this is not the core of the issue. Also, in general, a "lower the bar" solution is never optimal. Grandpallama (talk) 19:48, 3 March 2024 (UTC)
5. Oppose per SmokeyJoe and basically per the proposal, which demonstrates that 'crat chats are working as intended. We probably shouldn't be looking at any stats before 2011 since reforms that year pretty much overhauled RFA, but if the stats highlighted show that 10 of 12 landing in the 70-75% range were promoted, then two weren't, and unless the proposal is suggesting that the 'crats are not accurately determining consensus, then the process is working exactly as it's intended to work. Or to look at it from the other side: if we had a lower discretionary threshold then we would have promoted two users to admin who did not have consensus. Ivanvector (^Talk/_Edits) 15:00, 4 March 2024 (UTC)
6. Oppose per Extraordinary Writ. LEPRICAVARK (talk) 22:57, 4 March 2024 (UTC)
7. Oppose, with the considerable amount of input RfAs get these days, anything less than "around" 80% usually indicates a sizeable number of opposition to a candidacy, while the current crat-chat format encourages further scrutiny if a candidate has at least 25% of participants !voting against. As Grandpallama says above, lowering the bar isn't solving a problem and I feel that 75% as an upper limit does not need compromising further. Bungle ^{(talk • contribs)} 18:13, 6 March 2024 (UTC)
8. Oppose Ivan (talk) 16:31, 7 March 2024 (UTC)
9. Oppose You are mistakenly assuming the current situation with mostly legit non-canvassed participation. This moves it towards a more gameable "just a vote" basis, and could push RFA overall more towards gaming such as canvassing. North8000 (talk) 19:06, 7 March 2024 (UTC)
10. Oppose per Ivanvector. Dreamy Jazz ^{talk to me | my contributions} 23:32, 8 March 2024 (UTC)
11. Oppose the only thing this would do is auto-pass problematic candidates. Alanscottwalker (talk) 11:31, 13 March 2024 (UTC)
12. Oppose per Bungle. Rather than lowering the upper end of the range, I would favor raising the lower end, restoring the 70-75% discretionary zone used before 2016. Tim Smith (talk) 01:05, 14 March 2024 (UTC)

Proposal 13: Admin elections

In addition to the existing RfA process, Admin elections are held every six months.

Candidates must sign up by a certain date, followed by two phases of debate:

1. Three days for discussion and questions - no bolded !votes.
2. If candidates choose to progress, a secret ballot for a full week. Voter suffrage would initially match Arbcom elections. Candidates who achieve 70% Support would pass and become administrators.

• Further explanation is at Wikipedia:Requests for adminship/2021 review/Proposals/Admin elections

Support (proposal 13)

1. Support. Copied almost word-for-word from Wikipedia:Requests for adminship/2021 review/Proposals#Closed: 8B Admin elections. Trying again since this was popular last time, with 72 supports and 39 opposes. I would encourage the closer to ignore all !votes that are based on technical reasons only. In my opinion, this RFC should only be to determine if community consensus exists to try some kind of admin election / secret voting system. The technical details should be worked out later. This is how it works at WP:BRFA: You get consensus for your mass edits first at a talk page, village pump, etc. Then a bot operator goes to BRFA with a technical plan and applies there in a separate process. Step 1 consensus and step 2 technical implementation are completely separated, as they should be. Honestly I am undecided if admin elections are a great idea, but I feel strongly that the close of Wikipedia:Requests for adminship/2021 review/Proposals#Closed: 8B Admin elections was incorrect. The numbers from that RFC clearly indicate that editors want to try admin elections. This proposal should be given the chance to move forward. –Novem Linguae (talk) 05:53, 23 February 2024 (UTC)
2. Support trial period: I'd written up something similar, and am glad to see this in action! Since this is Phase I, let's give it a try for an election cycle or two, and circle back in Phase II to see where we are. theleekycauldron (talk • she/her) 05:57, 23 February 2024 (UTC)
3. Support This is well thought out, had prior support from the community, and should be not impossible to implement, technicallly speaking. Making this a parallel process to adminship by the regular route also makes it perfect for not revamping the system from the bottom up. Soni (talk) 06:05, 23 February 2024 (UTC)
4. Levivich (talk) 07:30, 23 February 2024 (UTC)
5. Support The great merit of this is the safety in numbers which will encourage candidates as they will not suffer the ordeal alone. And having a variety of candidates to compare and contrast seems healthy too. The technical details are no obstacle as we just need to follow the existing Arbcom process. Perhaps 3 days is not enough time for discussion and voter guides to be prepared but that's a detail too. Andrew🐉(talk) 08:47, 23 February 2024 (UTC)
6. Strong support, voting is the right way to go for binary decisions about people. It works for Arbcom. —Kusma (talk) 08:54, 23 February 2024 (UTC)

   We should definitely revisit the support percentage needed to pass after the first one or two attempts at this. —Kusma (talk) 12:29, 25 February 2024 (UTC)

7. Strong support. I would love for this to be based on a trial (per leeky, 2 cycles). The two open questions are whether people start opposing more (and thus whether 70% is okay), and whether abolishing the discretiory area is a good idea. I think we'll see a drop in the support of popular candidates, where people don't want to be the first, second or third oppose. I suspect the same might happen for candidates with a lower support %, but good to test out.
   That said, I think this fixes the three elements that make RfAs unpleasant, or even toxic: the key one is that the candidate does not have to know which individuals didn't have confidence in them. I found that the most stressful bit of my RfA: are there people I respect a lot that would not have trust in my abilities as an admin? This avoidance of making it personal is a key reason why most of civil society has secret ballots. The second bit is that this prevents candidates from constantly feeling the need to drop in to see the state of their RfA. The second bit is the circus of arguing against non-convincing or silly opposes. It's a time sink that is quite unpleasant for the candidate. —Femke 🐦 (talk) 11:24, 23 February 2024 (UTC)
8. Support In part due to my comments below to WSC: I don't think permanent documentation of comments is a good thing for everyone, and this election process removes that. The discussion is what tends to create the heat, removing that just leaves potential candidates with: "I think I'd be qualified and have some use for the tools? Let's run and we'll see what happens" with a lot less permanent risk if you fail. It's an experiment worth trying. Secondly, despite my respect for the closers of the previous discussion, it's one of the most disagreeable closes I've read. This proposal already passed two years ago. I hope, if it attracts similar support this time, it is closed correctly. ProcrastinatingReader (talk) 12:27, 23 February 2024 (UTC)
9. Support Absolutely worth a try. Some tweaking may be required - I think another day of discussion wouldn't hurt - but radical changes are called for and this one is well thought out. —Ganesha811 (talk) 13:10, 23 February 2024 (UTC)
10. Support I know I'm an infrequent contributor, but I've looked at the RFAs that have occurred, and they seem to have a lot of hostility that could be reduced with a simple vote. If 70% of voters think someone could be an admin, then they deserve to be an admin. Senior Captain Thrawn (talk) 13:34, 23 February 2024 (UTC)
11. Support - I'm pretty sure this is the only way, short of scrapping RfA entirely, to deal with the problem of discussions being disrupted and the reputation of it being a toxic environment. _{Duly signed,} ⛵ WaltClipper -(talk) 13:51, 23 February 2024 (UTC)
12. Seems like a pretty good compromise that maximizes the benefits of the secret ballot while keeping the discussion-RfAs. Aaron Liu (talk) 15:07, 23 February 2024 (UTC)

    Conditional weak support while the link entails shutting down discussion during the voting period, which doesn't seem very productive. Aaron Liu (talk) 21:39, 27 February 2024 (UTC)

13. For the same reasons as my own proposal eight. Mach61 (talk) 15:08, 23 February 2024 (UTC)
14. I'm willing to give this a shot, only because it is written as a supplement to, rather than a replacement of, the current process. As a candidate I would not have chosen this; my RFA was made easier, IMHO, by the fact that the opposers were subject to scrutiny. But perhaps not everyone feels that way, and as long as we are limiting gaming by setting reasonable thresholds for suffrage, and allowing as many editors as pass the threshold to gain the tools, I think this is a decent option. Vanamonde93 (talk) 15:56, 23 February 2024 (UTC)
15. It works for arbcom, I don't see why it can't work for admins. WaggersTALK 16:21, 23 February 2024 (UTC)
16. Support trial I'd prefer Xaosflux's idea outlined in their oppose below, but if this gains consensus, an RfC may always be held to fine-tune the numbers. Sincerely, Novo Tape^{My Talk Page} 16:25, 23 February 2024 (UTC)
17. Support because we can always tweak things later. In particular, I suspect that the percentage for success might need to be lowered (the 2010 CUOS elections, which also used a 70% cutoff, resulted in a single successful CU and zero OS candidates). And a two-thirds supermajority is a landslide by any definition. But details can be tweaked. Let's try it. HouseBlaster (talk · he/him) 16:34, 23 February 2024 (UTC)
18. Let's give this a shot. Not 100% happy with the current criteria, but we can always work those out later, and the current ones are decent enough to start with. JavaHurricane 17:09, 23 February 2024 (UTC)
19. Support, why not? It's only a trial, after all. Queen of Hearts (talk • stalk • she/they) 18:23, 23 February 2024 (UTC)
20. It was a good idea in 2021, it should have been ruled as achieving consensus then, and it would still be a good idea now. --JBL (talk) 21:38, 23 February 2024 (UTC)
21. Support. I like this idea a lot. It actually addresses what I believe is the real reason that good potential candidates decline to be considered: the stress of having past mistakes that are not typical of who you are, being discussed in public and leading to pile-on opposes. But there would still be discussion before the candidate decides whether or not to enter the actual vote, so it's more nuanced than a straight vote. And I do believe many voters will examine the discussion before deciding, as happens with ArbCom elections. It's a trial, and candidates are still free to use the existing RfA system if they prefer, and there's room for working out the details. This is well worth a try. --Tryptofish (talk) 22:19, 23 February 2024 (UTC)
22. Support, per WP:NOBIGDEAL. BilledMammal (talk) 23:21, 23 February 2024 (UTC)
23. Support per Tryptofish. – Hilst [talk] 02:05, 24 February 2024 (UTC)
24. Support I like the election idea. – DreamRimmer (talk) 06:39, 24 February 2024 (UTC)
25. Support. I've had a classical request for adminship (RfA 2019) and an ArbCom election (ACE2023), and if I had the choice between RfA-style or ACE-style permissions application, I'd always choose the latter. I'd have chosen so before and my opinion didn't change after experiencing both. Improving the election experience and lowering the bar to applying for adminship would probably result in a higher percentage of all the qualified users actually deciding to apply for adminship. ~ ToBeFree (talk) 15:04, 24 February 2024 (UTC)
26. Support. Like this idea. BeanieFan11 (talk) 20:02, 24 February 2024 (UTC)
27. Support per my comments in 2021 and my comments at proposals 3 and 3(b). So long as discussion is held for a few days—allowing proper scrutiny of the candidate and the chance for constructive feedback—then I don't mind if we have a consensus-building !vote or a ballot vote. — Bilorv (talk) 23:37, 24 February 2024 (UTC)
28. Support – Let's see how it goes. Toadette ^{(Let's discuss together!)} 09:24, 25 February 2024 (UTC)
29. This isn't a ridiculous proposal, and in fact allows for an informed discussion. Those who are concerned that RfA is stressful by its length should be delighted to support this (I think that 3 days personally is a bit too short - I don't know how about others but I can easily imagine a 5-day workweek/schoolweek so stressful that you simply are too tired to spend half an hour to see what the candidate stands for and digest the arguments, so 5 days is best so that realistically there is a chance that all people ask their questions). The voting is stressless because it's secret. Worth seeing how it goes. If the threshold is too high, we can discuss lowering it or killing the initiative altogether. Szmenderowiecki (talk) 17:43, 25 February 2024 (UTC)
30. Support as a good idea. — ♠Ixtal ^{( T / C )} ⁂ Non nobis solum. ♠ 13:33, 26 February 2024 (UTC)
31. Support, although I'd prefer a 1-week discussion period. --Ahecht (TALK
    PAGE) 19:18, 26 February 2024 (UTC)
32. Support I think this is worth a shot. A discussion period (perhaps longer than 3 days since many editors have busy RL lives!) followed by a straight !vote. I support combining this with the minimum qualifications to !vote proposal below? RegentsPark (comment) 19:53, 26 February 2024 (UTC)
33. Support. Not sure about some of the details, but the idea is definitely worth a shot. Giraffer (talk) 20:02, 26 February 2024 (UTC)
34. Support anything that makes RfA less of a vicious hellscape. ♠PMC♠ (talk) 01:48, 27 February 2024 (UTC)
35. A secret ballot is exactly what RfA needs - it takes some of the pressure off the candidates (less pile-ons), lets people oppose without fear of being unfairly scrutinized, and shows what the community truly feels about the candidate. — Ingenuity (talk • contribs) 02:10, 27 February 2024 (UTC)
36. Support most importantly this separates discussion from voting, so only people with relevant comments feel the need to comment. Also very importantly, it's less scary to do RfA with a bunch (hopefully!) of people than being alone. We also have evidence from ArbCom elections that this process tends to be less toxic, even for controversial candidates. This probably will need tuning (probably lower threshold to 65%?) but we should try this. Galobtter (talk) 02:47, 27 February 2024 (UTC)

    Since the vote's results has no element of judging on arguments and concerns raised might not be read by supporters, I think 70% is low enough. I agree that we can always tune after, though. Aaron Liu (talk) 02:53, 27 February 2024 (UTC)

37. This. ~~ AirshipJungleman29 (talk) 02:50, 27 February 2024 (UTC)
38. Support. Ivan (talk) 08:42, 27 February 2024 (UTC)
39. Worth giving a go. No harm in trying. SilkTork (talk) 09:21, 27 February 2024 (UTC)
40. Support Let's give it a go, as others have said, there's no harm in trying this. Ritchie333 ^{(talk) (cont)} 12:29, 27 February 2024 (UTC)
41. Support — PerfectSoundWhatever (t; c) 14:00, 27 February 2024 (UTC)
42. Support of the proposals listed here, this seems like one of the most likely to encourage more potential admins to participate, without compromising the community's desire for vetting and consensus discussions. The amount of time given to comments, questions, and votes might need adjustment after the first election. Rocfan275 (talk) 14:15, 27 February 2024 (UTC)
43. Support Bruxton (talk) 15:38, 27 February 2024 (UTC)
44. Support * Pppery * _{it has begun...} 17:14, 27 February 2024 (UTC)
45. Support I feel as if this would greatly reduce the stress and toxicity of RFA. Nagol0929 (talk) 17:31, 27 February 2024 (UTC)
46. Conditional support - There should be a trial period, even if it's a full year (to have two elections). Otherwise this seems like one of the proposals worth trying. — Rhododendrites ^talk \\ 17:35, 27 February 2024 (UTC)
47. Strong Support - I really like the idea, it feels like a nice addition to the RfA, as said above, it lets editors put in their opinions without being called out or criticized for what they feel. I'd also support, as the comment above states, a trial period of 6 months - 1 year, personally leaning on 6 months, because in my mind what could happen is we say it goes for 6 months, we do a vote on who likes it and who doesn't, which would probably last about a week, and then if everything goes well, we keep it in. If it's broken or people don't really like the structure, we don't use it anymore. I'd say those would be my thoughts on this, but overall I love the idea, so I give strong support in full. -- ThatOneWolf (^Chat_Edits 17:59, 27 February 2024 (UTC)
48. Support this proposal as it has a chance of resulting in more admins which is what we need - no harm in giving it a try. – filelakeshoe (t / c) 🐱 18:02, 27 February 2024 (UTC)
49. Support It is the right way to vote. Lightburst (talk) 18:25, 27 February 2024 (UTC)
50. Support - because, why not? I love policy proposals that add a different track rather than adding more lipstick to the existing pig (see the civility proposal). But let's be honest with ourselves - this won't change anything. There will still be social stigma attached to those who fail. It will quickly run into the issue that CUOS elections had when they were done by a strict election - nobody will pass, there will be endless arguing over whether the support threshold should be moved, it will be changed to 65%, still nobody will pass, and five years down the road we'll all be back at RFA review 2029 complaining about how broken the system is but unable to agree on how to fix it.

    To fix the problem, look at the system. Adminship is a big deal. You need to stand for a massive public election in front of hundreds of people who scrutinize every time you sneezed. Because the process is so intense and with such significant social consequences for failure (both during RfA, as people pile on opposes, and after, as you are known as the failure who couldn't pass an RfA), most people won't stand for election at all, further elevating the social status of admins by making it a very exclusive role. This proposal does nothing to address the core problem here: if we want more admins, if we want more people to run, it needs to be less of a big deal. People aren't shivering from anxiety as they submit an application for rollback permissions.

    If - and that's a big if - the community wants to open up adminship, you need not look beyond what was done for CUOS. Take the community out of RfA. Create a parallel process where interested candidates can submit applications against a set of criteria for evaluation, privately so there wouldn't be social consequences for submitting a refused application. But alas, such a proposal would never get sufficient support, because despite not liking RfA nobody really wants to change it. RfA sits in the perfect middle, balanced between different considerations in a way that nobody really likes but nobody can agree to change. So we might as well try this - I'll go out and get another few tubes of lipstick, and see you all in 2029. -- Ajraddatz (talk) 18:43, 27 February 2024 (UTC)

51. Support but I would allow users to comment when they vote, and those comments should be available to crats if the candidate is around the 65-75% mark. But if we have too many candidates, it could become unwieldy... SportingFlyer T·C 19:17, 27 February 2024 (UTC)
52. Support – Hmm... If this proposal allows co-existence of (rather than replace) the existing RfA, then I'm all up for secret ballots. George Ho (talk) 20:00, 27 February 2024 (UTC)
53. Support. The most objective process I have seen on this poll. Proper discussion and then the vote. Aszx5000 (talk) 20:08, 27 February 2024 (UTC)
54. Support, this is long overdue, a very sensible alternative. Chiswick Chap (talk) 20:10, 27 February 2024 (UTC)
55. Support - I favor secret voting. The 2021 vote was improperly closed. Carrite (talk) 21:21, 27 February 2024 (UTC)
56. Support since I did last time and haven't had cause to change my opinion since then. XOR'easter (talk) 22:33, 27 February 2024 (UTC)
57. Support I'm not sure how much better this is than RfA, but don't see a reason not to try it. Banedon (talk) 03:32, 28 February 2024 (UTC)
58. Support - like I keep saying, RFA already functions as a straight vote. Allowing a structured period of questions for the candidate and community comment, followed by something like SecureVote, seems like a reasonable method to try. This makes RFA like Arbcom elections, which I don't think will be less stressful, but I like the idea. In the current process, late questions and comments can impact a discussion unfairly. Ivanvector (^Talk/_Edits) 15:44, 28 February 2024 (UTC)
59. Support trials per theleekycauldron Yoblyblob (Talk) :) 18:37, 28 February 2024 (UTC)
60. Sure. The Night Watch (talk) 01:49, 29 February 2024 (UTC)
61. IMO, this deserves a trial. I strenuously hope it will achieve full implementation and believe it will serve as a complementary process to RfA and an overall betterment to admin replenishment.--John Cline (talk) 09:51, 29 February 2024 (UTC)
62. Worth a shot. Stifle (talk) 11:14, 29 February 2024 (UTC)
63. We go round this cycle of looking how to improve RfA regularly, and while I've stepped away from the encyclopedia, I did have this proposal noted to me because it's a copy of something I proposed a few years ago. I strongly believed in the concept then, and I strongly believe in it now. We will never please all the people, all the time and once we are up and running, there are changes that we can make (voter suffrage, or support percentages etc) - but let's not let perfection stand in the way of good. This makes RfA less of a hell hole for individuals, while keeping scrutiny and discussion of candidates. It allows a complete alternative to RfA for those who simply believe the entire process isn't worth it.
    It has a real potential for real change, and we should try this. Worm^TT(talk) 11:55, 29 February 2024 (UTC)
64. Support - seems worth trying Eddie891 ^Talk _Work 19:22, 29 February 2024 (UTC)
65. Support looks good to try. Dreamy Jazz ^{talk to me | my contributions} 15:15, 1 March 2024 (UTC)
66. Intrigued. Would basically want what Xaosflux suggests below (currently oppose #4), but I'm weakly interested to see how it goes. ~ Amory (u • t • c) 13:20, 2 March 2024 (UTC)
67. Support Great idea. Leijurv (talk) 15:39, 2 March 2024 (UTC)
68. Support Supported this last time as a complementary process and my opinion has not changed. Hawkeye7 (discuss) 00:11, 3 March 2024 (UTC)
69. Support I'm happy to give this a go. If this proposal passes though I feel that some more discussion is needed to determine the suffage requirements. If the closer intends to do it as part of this discussion my preference would be that it reflects extended-confirmed requirements rather than ArbCom elections. Individual admins have signficant more power than a singe arbitrator given that arbitrators need to have a majority to do something and their terms are limited to 2 years. Callanecc (talk • contribs • logs) 03:06, 3 March 2024 (UTC)
70. Support. This makes a lot of sense to me. Real potential to de-dramatise the whole process by having a batch of people up at once and taking away the public support/oppose votes. Worth a go, in my opinion. There might need to be a further discussion of exactly who can vote in such an election, but I wouldn't want that to get in the way of making this happen. The Land (talk) 13:08, 3 March 2024 (UTC)
71. Support Should be simple to implement, and has the potential to remedy the administrator drain. — FenrisAureus ▲ (she/they) (talk) 03:46, 4 March 2024 (UTC)
72. I’d prefer this was run on a trial basis first, but has the potential to reduce the toxic element and gets rid of the chance of any unnecessary late process interference. - SchroCat (talk) 08:39, 4 March 2024 (UTC)
73. Support. Sure, let's at least try this. JoelleJay (talk) 01:51, 6 March 2024 (UTC)
74. Suport Would be good to trial -Kj cheetham (talk) 15:00, 6 March 2024 (UTC)
75. Support it only as a trial measure and in addition to the existing process. It could fail spectacularly but it's worth trying at least once. Gizza (talk) 03:38, 7 March 2024 (UTC)
76. Support even though I don't like it. At this point, pretty much anything is better than nothing. I could reasonably support automatically promoting everybody who's been here 2 years, has written a good article or two to demonstrate competence, and hasn't been sanctioned or blocked. Reaper Eternal (talk) 05:09, 7 March 2024 (UTC)
77. Support An excellent idea but needs refinement. No way can we properly handle 50 simultaneous RFA type discussions twice per year which is what this would cause. Probably should be set up to be done on a continuous basis. North8000 (talk) 19:14, 7 March 2024 (UTC)

    The securepoll software is the limiting factor here. It is not trivial to get the wmf to set it up. Luckily I do not think we will be getting 50 rfas per cycle. I would estimate more like 1 to 5. –Novem Linguae (talk) 21:30, 7 March 2024 (UTC)

78. Support I don't know if this would work, but I'd be willing to give it a trial. The Wordsmith^{Talk to me} 21:42, 7 March 2024 (UTC)
79. Support Very good idea, and will hopefully turn more editors into admins. JML1148 ^{(talk | contribs)} 22:08, 9 March 2024 (UTC)
80. Support as a trial. This should have passed last time. the wub "?!" 18:27, 11 March 2024 (UTC)
81. Support as a trial, as detailed above. Chaotıċ Enby (talk · contribs) 11:22, 14 March 2024 (UTC)
82. Support - Already has been passed once, as far as I am concerned. Secret voting will lessen drama and bad feelings. Carrite (talk) 13:13, 14 March 2024 (UTC)
83. Support unlike most of the proposals here this one could at least potentially fix the problem. Hut 8.5 17:58, 14 March 2024 (UTC)
84. Support. Secret ballots for the win. It will bring less drama, less petty bickering, and better voting decisions. As anonymity in ensured, voters would feel safer as some may fear retaliation from the admin candidate or their supporters. ✠ SunDawn ✠ (contact) 06:07, 15 March 2024 (UTC)
85. worth a try, at the very least sawyer * he/they * talk 02:54, 16 March 2024 (UTC)
86. Support This goes in the same direction as 3/3b - discussion first, voting second. Both variants look promising to me. Let's give her a try. --Elmidae (talk · contribs) 16:11, 16 March 2024 (UTC)
87. Support as it could encourage people to run, so worth a try. 0xDeadbeef→∞ (talk to me) 06:05, 17 March 2024 (UTC)

Oppose (proposal 13)

1. Strong Oppose - What we have now is a hybrid of CON and voting. But it still has discretionary closure. It still has discussion throughout. This proposal removes the last vestiges of CON, and turns it into a vote. Strong Oppose. - jc37 08:18, 23 February 2024 (UTC)
2. Oppose voting is appropriate for picking a set number of people such as for Arbcom. Especially when we need eight people and we are OK with several qualified but not quite so popular/esteemed candidates being rejected. But RFA is more like a driving test, we want everyone who meets the standard to pass, and everyone who doesn't meet the standard to fail - but to know why they failed as like me, they may pass on a second attempt a few months later after addressing some of the reasons why they failed the first time. With an election the unsuccessful candidates won't know why they were unsuccessful. There is also the issue of removing crat discretion, currently a candidate who had mostly moral supports could fail while a candidate where the opposes mostly marked themselves weak could pass. but if you move to a simple vote the reverse happens. ϢereSpielChequers 11:29, 23 February 2024 (UTC)

   You describe what RFA was like in 2007, it is currently not at all like a "driving test". Current RFA practice does not produce the 30+ admins we need for sustainability each year. It keeps out or completely disillusions failed candidates (MB left, Vami IV would never have run again). It does also not keep out people who should not be admins (Eostrix, Wifione). Maybe it should be a driving test, but driving tests usually test the candidate against the rules and have one examiner, not 250 examiners who all argue with each other about how to assess the candidate and what the Highway Code says and what the Highway Code should say. Voting keeps the community element but removes the heat. —Kusma (talk) 11:46, 23 February 2024 (UTC)

   I agree that RFA is not producing anywhere near enough new admins, I actually think we need more than thirty a year as a minimum. If admins stayed active for an average of ten years then fifty a year would maintain a cadre of 500. But my driving test analogy is not based on how well RFA works, it is based on how it needs to work. We have no limit on the number of mops, the more admins we have the closer we can get to the model of a self organising community with admins being editors who also do a bit of mopping. By contrast ARBCOM is a committee that has to have limited numbers in order to function. When you have unlimited numbers to appoint and you want all qualified candidates appointed you need a driving test type of system. When you have a limited number of posts and you want the best available group of people to serve, you want an election system. ϢereSpielChequers 12:07, 25 February 2024 (UTC)

   I think implicitly, this proposal does wish to remove the feedback. Receiving feedback from ~200 of your peers, many of whom you may have interacted with and respect, can be quite tough. In a workplace, (IME), one gets feedback from a select number of people, usually your manager. Getting feedback from everyone, in a process that permanently documents everything good/bad you've done at WP:Requests for adminship/Your Name is a bit daunting. (In the workplace, feedback given is pretty much forgotten about by everyone but perhaps the recipient.) In my view, the lack of feedback creates a potential feature not a bug. For those who want feedback, they can make a normal WP:RFA. For those who do not, they can go via the election method. This proposal leaves choice with the candidate. In your case, you could've continued to make a normal RFA if you wanted feedback. ProcrastinatingReader (talk) 12:27, 23 February 2024 (UTC)

3. Oppose I believe this would lead to a situation in which individual candidates are not properly vetted. LEPRICAVARK (talk) 13:09, 23 February 2024 (UTC)
4. Conditional Oppose as-written, but Conditional Weak Support in general. As to the specifics that I think are problems: 3-days is not long enough for the first phase, should be at least 1-week. Would like to see a 1 week discussion, perhaps with a 2-week overlapping voting period. As far as voter suffrage goes, ACE suffrage is a manual process that is very complicated, would want to limit suffrage to automated functions available in securepoll already (max-registration, not-sitewide-blocked, not-bot, min-edits). If the parameters were adjusted the conditionals above would be satisfied for me. — xaosflux ^Talk 15:08, 23 February 2024 (UTC)

   @Novem Linguae: how attached are you to the suffrage limits. Basically, if it can't be automated (e.g. "edits in last x days" or "edits by namespace" sort of stuff) cutoffs that SP can have it means someone needs to manually build the electoral rolls. Obvious things can be handled by scrutineers (e.g. no voters that start with "Renamed user" / "Vanished user" ) aren't cumbersome but programmatically enforcing something like that goes back to requiring a whitelist. — xaosflux ^Talk 16:26, 23 February 2024 (UTC)

   I'd like to see some kind of suffrage limit. I think this is our best defense against sockpuppets, and our best defense against having to checkuser everybody. But of course, the exact criteria are negotiable. I think this proposal currently proposes copying ace? Which of the ace criteria is labor intensive and requires creating a whitelist? That's the one you propose deleting, correct? –Novem Linguae (talk) 19:29, 23 February 2024 (UTC)

   @Novem Linguae limits are absolutely possible, however some can be used easily and some can not be. The automated things built in to secure poll include:

   • Has the voter been registered for at least x days?
   • Is the editor site blocked?
   • Does the editor have at least x total edits?
   • Is the editor in the bots group?.

   Medium-easy items that would not be onerous for scrutineers are:

   • Does the username start with "Renamed" or "Vanished"
   • Does the username end with "bot" and is not a false positive like User:The Brown Sabot (to catch unflagged bots).

   Most anything else involving a calculation is hard. Specifically from ACE the hard things are:

   • Have 150 mainspace edits by a specific cut off date
   • Have 10 live edits (in any namespace) within a specific window of dates.

   — xaosflux ^Talk 19:48, 23 February 2024 (UTC)

   Assuming a SecurePoll implementation, I think removing those last two bullets would be fine. Although as you probably know since I've stated it a few times, I'm really hoping this RFC will be less about technical details and more just finding a consensus to try some kind of admin elections. –Novem Linguae (talk) 20:48, 23 February 2024 (UTC)

   @Novem Linguae There is general support for occasional scheduled admin elections via SP. (FWIW - If it was an on-wiki non-secret-ballot vote, abuse filter could handle the first items as well.) With those tech details out of the way, I'm more support than oppose. I think we differ on the discussion/voting lengths - but that's really just something for everyone to come to an agreement on. — xaosflux ^Talk 21:14, 23 February 2024 (UTC)

   Xaosflux, do you know dewiki's criteria for automatically receiving the "editor" permission? They contain absurdly specific requirements like "There are at least 15 edits by the user that have a time difference of at least 3 days to each other" and somehow they automated this in a MediaWiki extension, without a bot or human having to do it. So I'd say everything is possible. ~ ToBeFree (talk) 12:53, 25 February 2024 (UTC)

   @ToBeFree yes, however that is dependent upon custom software (mw:Extension:FlaggedRevs) that is not installed here on the English Wikipedia and has been deprecated for a decade. It also doesn't have anything to do with Secure Poll. It is indeed not impossible to write such software, but unless there is a large group of software developers that will commit to building and maintaining such software it isn't realistically going to happen. — xaosflux ^Talk 13:13, 25 February 2024 (UTC)

   FlaggedRevs is installed on enwiki, but has most of its features turned off via a feature flag. This extension is a nightmare to configure (ive written some patches for it) and i do not recommend enabling more of its features on enwiki. –Novem Linguae (talk) 16:50, 25 February 2024 (UTC)

   And it would still do nothing for automating securepoll. (At the best it could possibly help build a do-nothing-group, so that creating a manual list from the do-nothing-group could be easier). But this goes back to main question of do we want to build a supervisor-of-elections group that will need to do this work? It is possible (zhwiki uses a manual list in their SP admin elections - I don't know how complicated their suffrage requirements are though. Also keep in mind that almost everything at enwiki is orders of magnitude more work than other projects due to our size.) — xaosflux ^Talk 18:14, 25 February 2024 (UTC)

   How much "discussion only" time would you consider enough before editors are allowed to vote? Soni (talk) 20:17, 23 February 2024 (UTC)

   @Soni I think a week for discussion is good because not everyone edits every day. Assuming this is secret ballot, I'd be fine with voting being open at the same time. This is also assuming the the discussion is also the Q&A period. Three days is pretty tight for Q&A, especially if a question comes in on day 2 for example. Other elections (ACE, Stewards, etc) are usually open for weeks at a time for comparison. — xaosflux ^Talk 22:14, 23 February 2024 (UTC)

   I'd also be fine with QA/Discuss being a week, then a week of voting. Or QA/Discuss being a week, with a 2 week voting period (starts at same time, runs a week). Keep in mind, SP is going to be a slow process, as we are a large project and scrutineering takes time. Expect it could take a couple of weeks after the election to get any results. — xaosflux ^Talk 23:05, 23 February 2024 (UTC)

   The original proposal is slightly too vague for any of us to say, but my interpretation of it was that the Q&A and discussion would continue to be open during the voting period. Aaron Liu (talk) 23:17, 23 February 2024 (UTC)

   Yeah I likewise prefer 'M days of "Discussion and Q&A only" and then 'N days of voting+discussions+Q&A'. Soni (talk) 04:05, 24 February 2024 (UTC)

   JBL has pointed out to me that, according to the link, this is not the case. I've changed my !vote to a weak support. Aaron Liu (talk) 21:39, 27 February 2024 (UTC)

5. Oppose I think the vetting of candidates is important. I don't think many editors would read the discussion before voting - and having multiple candidates on one ballot would make it even less likely that editors might be aware of concerns other editors have about a candidate. While I do believe the serving as an admin is no big deal, I trust the community to identify concerns about temperament, and the shorthand way of identifying if concerns exist is through the oppose and neutral sections. --Enos733 (talk) 18:23, 23 February 2024 (UTC)
6. Weak oppose RfA should not be 100% voting (even though it is quite a bit a vote) but I'm not super opposed to trying it out. ‍ Relativity 23:23, 24 February 2024 (UTC)
7. Weak oppose if this was implemented, I would not be too bothered, but I think the public system is better for telling editors what their strengths and weaknesses are so that, regardless of outcome, they can work to make improvements in their Wikipedia editing. I think a voting system would make this less likely that editors would comments and give their thoughts, as evidenced by the hundreds of people who vote in ArbCom elections who do not comment on any of the candidate pages. Z1720 (talk) 01:30, 25 February 2024 (UTC)

   Weak oppose as written. 70% would be too high. I do not want potential candidates to not get their mops, and if it had been shown to be too high no one would want to have elections. Also, given how elections had worked in Chinese Wikipedia I don't believe it would help with the other problem, that Wikipedia needs more admins. 0xDeadbeef→∞ (talk to me) 12:22, 25 February 2024 (UTC)

   What would be a reasonable percentage according to you? Soni (talk) 13:00, 25 February 2024 (UTC)

   Can you talk a bit more about how elections have worked on Chinese Wikipedia, and what lessons have been learned from that? –Novem Linguae (talk) 16:52, 25 February 2024 (UTC)

   Since the vote's results has no element of judging on arguments and concerns raised might not be read by supporters, I think 70% is low enough. Aaron Liu (talk) 17:06, 25 February 2024 (UTC)

   You know what, I'm going to strike this. There was a huge RfC for RfA reform in Chinese Wikipedia a few months ago [2], and there was a subsequent discussion [3] for how much the percentage cutoff should be lowered. Chinese Wikipedia's community has a lot of trust issues, and even then they had consensus for decreasing the whopping 80% requirement down to 75% after what they have seen from SecurePoll. Note that at the same time they found consensus for appointing temporary admins for six months with supports ranging from 65% - 75% range. I'm still worried that the anonymity would decrease the support rate and thus make election candidates harder than a public RfA, but I think I don't hold that concern for a trial anymore after thinking about it for some time. 0xDeadbeef→∞ (talk to me) 14:35, 26 February 2024 (UTC)

8. Either we have one or the other. Redundant processes on Wikipedia that have the same end result tend to get merged together eventually. Steel1943 (talk) 02:38, 27 February 2024 (UTC)

   Could you provide some examples of alternative pathways being merged? Aaron Liu (talk) 02:52, 27 February 2024 (UTC)

   Best example I can provide is WP:NFCR and WP:PUF into WP:FFD. I believe most failed proposals fail because at least one aspect of the proposal's functionality is already present somewhere else. Steel1943 (talk) 18:30, 27 February 2024 (UTC)

   Well, these still had the same paradigm in processes, unfortunately. The only difference was that NFCR didn't have a mandated closing time, so it was mostly an unnecessary "content fork". IMO, that doesn't hold true for this proposal. Aaron Liu (talk) 21:42, 27 February 2024 (UTC)

   Thanks for calling my argument a strawman, though I disagree with that assessment. Thanks to the redundancy, discussions were closed to "wrong venue" quite often prior to the merging of the forums. I can see a similar issue here. Steel1943 (talk) 22:30, 27 February 2024 (UTC)

   @Steel1943: If this proposal were planned to replace the current RFA in 6-12 months, would you support it then? Or do you disagree with this one beyond "2 parallel processes" Soni (talk) 19:29, 27 February 2024 (UTC)

   @Soni: "If this proposal were planned to replace the current RFA in 6-12 months, would you support it then?" Since that would be a replacement instead of redundancy, possibly. Steel1943 (talk) 19:43, 27 February 2024 (UTC)

9. Oppose vetting of candidates is important. This would require more upfront time investment to do adequate due diligence, and this is a non-starter for folks who are short on time thanks to IRL commitments (myself included). -Fastily 07:14, 27 February 2024 (UTC)

   To me it sounds like discussion is open for the entire period, including voting. Aaron Liu (talk) 12:27, 27 February 2024 (UTC)

   JBL has pointed out to me that, according to the link, this is not the case. I've changed my !vote to a weak support. Aaron Liu (talk) 21:39, 27 February 2024 (UTC)

10. Same as my opposition to another proposal. No hidden votes, ever. Acalamari 04:11, 28 February 2024 (UTC)
11. Oppose There are good reasons why we've never done this, nor should we. --Dweller (talk) Old fashioned is the new thing! 12:42, 29 February 2024 (UTC)

    And what would these reasons be? Aaron Liu (talk) 13:09, 29 February 2024 (UTC)

12. Conditional Oppose I like the simplicity of this, overall, I just feel a 70 percent threshold is a bit too low and would prefer it be set at the upper end of extant, non-discretionary close spectrum (i.e. 75 percent) Chetsford (talk) 02:58, 1 March 2024 (UTC)
13. Oppose as is, but open to conditional support I think the basic idea may have some merit, but I'm not comfortable with some of the nuts and bolts. Three days is insufficient for questions and discussions. Go to one full week for Q&D and 1 week for voting with a straight pass at 75% (NOT 70%) and fail at anything below that. Set it up as a one-year (12 month) trial. Once the 12 months is over, we hold a community wide discussion and referendum on whether to make it permanent. -Ad Orientem (talk) 04:34, 7 March 2024 (UTC)
14. Oppose. In ArbCom elections, a lot of people "vote" but never say anything. That is...less than ideal for an RfA. An open system requires (or at least strongly encourages) the person who is offering their opinion to say why, and if someone does not give any reason or gives a silly one, allows for their input to be given substantially less weight. A closed system would allow a lot of what would amount to "Oppose, I just don't like you", where at RfA such behavior would be discouraged. Seraphimblade ^{Talk to me} 20:33, 7 March 2024 (UTC)
15. Oppose. I prefer supports and opposes to be out in the open where their rationales can be used to reach an informed consensus. Also, I am concerned that too many candidates will apply at once, leading to reduced scrutiny. Tim Smith (talk) 23:30, 14 March 2024 (UTC)

General discussion (proposal 13)

What does "In addition to the existing RfA process" mean? Does the same person have to pass both the existing RfA process & the elections, or does it mean one can become an admin via either the existing RfA process or election? Banedon (talk) 05:37, 27 February 2024 (UTC)

The latter. Candidates can choose which process to use. –Novem Linguae (talk) 11:18, 27 February 2024 (UTC)

Proposal 14: Suffrage requirements

Currently All Wikipedians—including those without an account or not logged in ("anons")—are welcome to comment and ask questions in an RfA, but numerical (#) "votes" in the Support, Oppose, and Neutral sections may only be placed by editors while logged in to their accounts. In practice, editors with low edit count who cast "votes" are usually suspected to be trolls or socks, and the discussions around reverting or striking these votes just lead to more unnecessary heat. It would be easier to just set a minimum bar for participation. For example, we could just use the rules from the Arbcom elections (account is 2+ months old, has 150+ mainspace edits and has made ten edits in the last year).

Support (proposal 14)

1. As proposer. I would also be OK with the "lazy" option of using 30/500 protection on all RfAs as long as non-ECP and IP editors can use the talk page and have their comments (not their votes) copied to the main RfA page. — Preceding unsigned comment added by Kusma (talk • contribs)
2. Anyone can edit kind of makes sense; anyone can vote does not. I'd support regardless of the details of the criteria (within reason). Levivich (talk) 13:45, 23 February 2024 (UTC)
3. I, too, would support this regardless of the criteria, within reason. It's long been evident that experienced editors are more forgiving, and other things being equal more likely to make reasoned !votes, than inexperienced ones. Comparing admin !votes to non admins, for instance (I'm aware that's an extreme example); my supposedly contentious RFA had no current admins in opposition. Tamzin's, the poster-child for contentious RFAs, had admins split 100-17 (if my count is correct). SFR had admins split 69-19. The latter two wouldn't have gone to a crat-chat at all if admins had been the only ones !voting. I'm not suggesting we go that far by any means, but we need to recognize that RFA isn't really an exercise in democracy, and analogies between Wikipedia governance and RL government break down very quickly. RFA is intended to assess whether candidates are suitable for adminship and have the community's trust. It's not unreasonable to limit who can comment in such a discussion. Vanamonde93 (talk) 16:17, 23 February 2024 (UTC)
4. I would be inclined to oppose this as a solution in search of a problem, but given that proposal 13 currently appears likely to pass, this would be a useful safeguard against vote stacking. LEPRICAVARK (talk) 21:23, 23 February 2024 (UTC)

   Proposal 13 seems already inclined towards implementing its own suffrage requirements per the discussion under Xaosflux. Aaron Liu (talk) 23:13, 23 February 2024 (UTC)

   Perhaps, but that doesn't seem to be stated in the proposal itself. LEPRICAVARK (talk) 21:10, 25 February 2024 (UTC)

   It actually is; from the linked Wikipedia:Requests for adminship/2021 review/Proposals/Admin elections:

   Voter suffrage should initially match the Arbcom elections i.e. registered over 1 month before election, 150 edits by election, 10 edits in the year running up to election, not sitewide blocked during the election, not vanished, and not a bot - though the suffrage decisions could be changed in future.

   Aaron Liu (talk) 21:17, 25 February 2024 (UTC)

5. As an accurate description of policy as already practiced. —Compassionate727 ^(T·C) 23:02, 23 February 2024 (UTC)
6. At least semi-protect all RfAs. My own received such helpful questions from non-autoconfirmed users as "do you have a cock or a cunt or neither of them" and "If you do not withdraw your RFA within 24 hours, I am going to microwave my dog. Do you have it in your heart to add the death of an innocent animal to your name?" (And those are just the printable ones.) That sort of thing doesn't bother me, but the constructive-to-nonconstructive ratio here is extremely low, and making highly visible pages easy targets for vandalism (or, worse, subtle trolling of this variety) is just obviously not a good idea. Will this fix RfA? Of course not. But rejecting small fixes just because they don't solve the entirety of the problem is not a good strategy for making this process better. Extraordinary Writ (talk) 05:14, 24 February 2024 (UTC)

   To be clear, I support anything up to and including extended-confirmed. Extraordinary Writ (talk) 06:16, 16 March 2024 (UTC)

7. Support I would support autoconfirmed or ECP (realistically, most votes I've seen are already ECP). Sungodtemple (talk • contribs) 22:04, 24 February 2024 (UTC)
8. Support Anons can have good observations about a candidate too. ‍ Relativity 23:27, 24 February 2024 (UTC) Oops, read this wrong. Just goes to show... gotta do your research before you add your !vote. ‍ Relativity 23:29, 24 February 2024 (UTC)
9. Support at least autoconfirmation. My reasoning has less to do with potential disruption, and more to do with the fact that RfA is supposed to reflect whether or not the community trusts an editor with the admin tools. A brand new user has not been part of the community long enough to understand what adminship is or how to assess whether a candidate can be trusted with it. Sdkb ^talk 00:45, 25 February 2024 (UTC)
10. Support – Logically all new editor votes are often socks, but I would strongly support sufferage requirements because inexperienced users may not take the right decision whether to support, oppose or be neutral. I would recommend the sufferage to be at least a month of editing, having 150 mainspace edits, and 250/300 total edits, and not be partial blocked or santioned. Toadette ^{(Let's discuss together!)} 09:13, 25 February 2024 (UTC)
11. One of my memories from my early days on Wikipedia was when I first came across the RFA process, realised there was some unwritten rule as to the minimum criteria !voters needed to meet, couldn't work out what the unwritten rule was and whether I met it, so I left the RFA area for a while. I think we should set a minimum threshold such as extended confirmed, doing so would make us more open to newbies as they'd either know that their participation would be welcome, or know how far they were from meeting the criteria. Bonus points if we could do this programmatically so only extended confirmed editors could view let alone edit RFA pages, this would reduce the drama as the page would no longer be public for all to see. ϢereSpielChequers 11:47, 25 February 2024 (UTC)
12. Per the proposal, with semi-protection of RfAs as the minimum. ~ ToBeFree (talk) 12:23, 25 February 2024 (UTC)
13. Agree with the rationale, but we seem to disagree with the franchise threshold. I think that whatever allows you to access WP:LIBRARY should be the minimum. Why? It's ECP, but we make sure that people who broke the rules do not get to choose those who are about to enforce them (including against them) - it will also be a disincentive to do all sorts of weird stuff that's against the rules (the disenfranchisement will only last for the block's duration). Also, the requirements are such that you still have to be at least minimally active in WP's workings and that there's a large cooldown period so that we know they are long enough to know what we stand for for better or worse. The voting page should be therefore ECP-protected to prevent edits from non-ECP users, but the transcluded discussion and Q&A pages should not as a general matter be protected. Szmenderowiecki (talk) 17:32, 25 February 2024 (UTC)
14. Per WereSpielChequers. Sincerely, Novo Tape^{My Talk Page} 01:58, 26 February 2024 (UTC)
15. Weak support Despite all our repeated statements, RfA is not really a !vote, except within the discretionary range. Given that it is a sort of vote, some control, in principle, over who votes is not a bad idea. Weak support mainly because I'm not sure it will make a difference since the ones that end up failing typically fail because of issues brought up in oppose votes (ok, ok - !votes) and, generally, contentious RfAs do end up in the discretionary range anyway.--RegentsPark (comment) 19:27, 26 February 2024 (UTC)
16. Support. Although I would much prefer suffrage requirements that can be checked with extremely low effort, such as an edit count or extended confirmed, rather than something that requires complex calculations. has made ten edits in the last year is a complex calculation that cannot be checked at a glance. –Novem Linguae (talk) 01:25, 27 February 2024 (UTC)
17. Better than what we currently got, though I'd rather extended confirmed be the requirement. Steel1943 (talk) 02:09, 27 February 2024 (UTC)
18. Makes sense to me. popodameron ⁠talk 03:06, 27 February 2024 (UTC)
19. Realistically, I don't know how someone is supposed to evaluate someone for adminship without at least a few hundred edits under their belt. Also per WereSpielChequers. I'd support an automatic threshold of ECP; I think anything else is too much work. Galobtter (talk) 03:53, 27 February 2024 (UTC)
20. Support per WereSpielChequers. Butterdiplomat (talk) 04:43, 27 February 2024 (UTC)
21. Support per Sdkb. Make RfA EC protected and allow others to make comments on the talk page. I had to go back and check in order to find out (to my surprise) that the first RfA I'd ever participated in was Rosguill's, which was after three years and 3,000 edits. StonyBrook _babble 12:36, 27 February 2024 (UTC)
22. Support I will support any proposal that seems likely to have even the smallest impact on making RfA less unpleasant and/or will help good candidates be elected, and I will oppose or remain neutral on the ones that do not seem to be likely to make such an impact. This might actually help a little. --Dweller (talk) Old fashioned is the new thing! 15:36, 27 February 2024 (UTC)
23. Support per nom and most of the comments above. Gog the Mild (talk) 16:55, 27 February 2024 (UTC)
24. The number of experienced RfA regulars is large enough that the participation of new users has little practical effect anyway, so no potential for harm. * Pppery * _{it has begun...} 17:14, 27 February 2024 (UTC)
25. Support: I support a minimum threshold for voting and I think it has the potential to make RfA more bearable. Hey man im josh (talk) 17:24, 27 February 2024 (UTC)
26. Support - Service guarantees citizenship. Would you like to know more? — Rhododendrites ^talk \\ 17:55, 27 February 2024 (UTC)

    So admins are a fascist corps? :P --Goldsztajn (talk) 09:00, 12 March 2024 (UTC)

27. Support either the arbcom or ECP requirments. This makes it very likely that the voters know policy well, and also makes it more likely that they know the nominee themselves. GrayStorm^{(Talk|Contributions)} 23:56, 27 February 2024 (UTC)
28. Support. If it is done for Arbcom, makes even more sense for RfA. Why would a brand new editor with zero experience opine on a tenured Wikipedia editor who has given many years to the platform? Should be ECP? Aszx5000 (talk) 20:43, 28 February 2024 (UTC)
29. Support with the comment that it should match an existing class to make it easier for editors to understand eligibility and for ease of implementation unless there is a compelling reason to change it. If there continue to be a significant number of troll edits using the Arbcom elections requirements we should consider upping the requirement to extended confirmed. I was surprised the first time I got an alert of participate in a RfA as I thought myself too inexperienced at that point to have an informed opinion. 🌿MtBotany (talk) 21:52, 28 February 2024 (UTC)
30. Support This is something that may not really change anything, but probably won't hurt anything either. It certainly seems odd that a totally new user would be proficient enough at Wikipedia to judge whether someone should be an admin. ᴢxᴄᴠʙɴᴍ (ᴛ) 00:12, 29 February 2024 (UTC)
31. Support I'm not sure this would significantly help detoxify RfA (though I'm not certain I agree with the premise it's toxic in the first place), however, I'd support this as a more general gamesproofing measure. Chetsford (talk) 02:52, 1 March 2024 (UTC)
32. Support Dreamy Jazz ^{talk to me | my contributions} 15:17, 1 March 2024 (UTC)
33. Support: anyone with under 30/500 is unlikely to have a meaningful contribution to evaluating a candidate. And as others noted, while not a huge problem, such !votes can be disruptive, and the solution is trivially easy to implement. Owen× ☎ 00:17, 2 March 2024 (UTC)
34. Support Unlikely to change outcomes, but may take some of the heat out of the process. Hawkeye7 (discuss) 00:14, 3 March 2024 (UTC)
35. Support My preference is to use extended-confirmed as the requirement but I'm okay with duplicating the ArbCom election voting requirements. Callanecc (talk • contribs • logs) 03:09, 3 March 2024 (UTC)
36. Support Try to find a way to keep it simple. Not a huge direct impact, but it might make some other "just a vote" ideas more viable. North8000 (talk) 20:00, 7 March 2024 (UTC)
37. Support works for ArbCom. Extended confirmed is preferred, but auto-confirmed is fine as well. Doing something other than those two seems like it would be clunky though. Senior Captain Thrawn (talk) 13:02, 9 March 2024 (UTC)
38. Support per Owenx. JML1148 ^{(talk | contribs)} 01:18, 10 March 2024 (UTC)
39. Support --Goldsztajn (talk) 09:00, 12 March 2024 (UTC)
40. Support although requiring 30/500 permissions would be a preference, this is better than nothing. Joseph2302 (talk) 10:42, 12 March 2024 (UTC)
41. People who want to participate in community governance should be meaningfully active in the community. ETA: RfA is a vote, albeit a vote with comments attached. That we vote in public and have the option to explain why does not negate the fact that almost all RfAs come down to numbers. HJ Mitchell | Penny for your thoughts? 12:19, 14 March 2024 (UTC)
42. Support I don't see why not. Even if editors who aren't logged in are not the cause of the problem(s), it's still a sensible expectation that one should be accountable for their vote. Banedon (talk) 04:06, 15 March 2024 (UTC)

Oppose (proposal 14)

1. I have seen no indication that the issue at RfA is due to anons or low-activity users !voting. In fact, my impression is that extended-confirmed users are just as capable of causing disruption at RfA as any other user type. _{Duly signed,} ⛵ WaltClipper -(talk) 13:42, 23 February 2024 (UTC)
2. Don't think we should disenfranchise contributors from participating in discussions based on this. It's not a vote. If we did want to make this a vote, then I'd be open to revisiting but would prefer something simple (like must be autconfirmed). — xaosflux ^Talk 14:58, 23 February 2024 (UTC)

   If the actual-vote option passes, I think I'd be OK with starting with the QA/Discussion is limited to SPP on such listings, and enforced that way. — xaosflux ^Talk 23:56, 24 February 2024 (UTC)

   If this is going to pass, and the question is "what level" - I'd rather us start at semi-page protection. As with the other section the "Arbcom elections" bespoke suffrage requirements are not something that can be automated - so it would be "here's a banner with the rules, don't break it -- clerks will just remove your contribution". Going with something liek SPP or ECP is much more feasible. — xaosflux ^Talk 14:26, 26 February 2024 (UTC)

3. I don't think it's vitally important new users vote, but since they almost never do I fail to see a problem that needs solving. Mach61 (talk) 15:05, 23 February 2024 (UTC)

   I'm new to enwiki and even newer to RfA so take this with a grain of salt, but I don't think edits by new accounts/ips are anywhere near the main cause of disruption and stress at RfAs. Sincerely, Novo Tape^{My Talk Page} 16:20, 23 February 2024 (UTC) Moving to support Sincerely, Novo Tape^{My Talk Page} 01:52, 26 February 2024 (UTC)

4. I had to read the proposal a couple of times, to fully understand what parts are "currently" and what parts would be changes. The change would be that we would institute something like the last sentence, starting "For example... ". I have a hard time picturing a past RfA where the users who would have been disenfranchised by this proposal were the ones who made it problematic. This won't do anything to make RfA go more smoothly, and one of the reasons we have bureaucrats evaluate the discussion is so that they can discount comments from clueless users. --Tryptofish (talk) 22:28, 23 February 2024 (UTC)
5. Strong Oppose per Xaosflux and WaltCip. 🌺 Cremastra (talk) 20:17, 25 February 2024 (UTC)
6. Oppose Let's not make the mistake that it's new editors that are causing the issues of toxicity, increasing standards, and oppose reply pile-ons. Seriously doubt disenfranchising them will do anything but worsen issues. — ♠Ixtal ^{( T / C )} ⁂ Non nobis solum. ♠ 13:37, 26 February 2024 (UTC)
7. Oppose Barring someone from commenting (not just voting) is crossing a bridge too far. OhanaUnited^{Talk page} 04:11, 27 February 2024 (UTC)
8. Oppose Ixtal hit the nail on the head -Fastily 07:14, 27 February 2024 (UTC)
9. Oppose 10 edits in the last year requirement. Ivan (talk) 08:47, 27 February 2024 (UTC)
10. Oppose New and low-level users are already subject to scrutiny when they !vote and they are rarely the source of toxicity and grief. Disenfranchising a swathe of people who are not the cause of any problems is fundamentally wrong. - SchroCat (talk) 10:21, 27 February 2024 (UTC)
11. Oppose I do not think this is a problem that needs solving. SportingFlyer T·C 19:17, 27 February 2024 (UTC)
12. Oppose strongly. Admins are admins for all users, not just those who achieve an arbitrary level of activity, and discussions on their appointment should have no more entrance requirements than the reasonable restriction of requiring an account. Suspected socks can be reported just like anywhere else, and this isn't a good approach to low-effort votes. Ivanvector (^Talk/_Edits) 15:47, 28 February 2024 (UTC)
13. Oppose per Ivanvector. RfA is not a vote but a discussion and discussions should be open to all. Does anyone supporting this have any examples that this is indeed a widespread problem in dire need of fixing? Regards SoWhy 20:00, 28 February 2024 (UTC)
14. Per Ivanvector, SC, and Ixtal. AryKun (talk) 19:32, 29 February 2024 (UTC)
15. Oppose. While I understand the intent, either RFA is a vote, or it isn't. If it is a vote, then all registered editors, regardless of tenure, are allowed to vote. In reality, while we restrict voting to those who are "age of majority", within that rather large group we don't restrict voting to only those who are up to speed on politics and current affairs. That would be silly and also impossible to enforce. With a few narrow exceptions (i.e. certain severe criminal convictions in certain jurisdictions) anyone who is 16/18/21 is allowed to vote in any election. As long as we continue to have watchlist notices for RFAs, we either need to A). Stop assuming that every newish user who votes is a sock, or B). Disable the watchlist for new users entirely. On the contrary, if we say that RFA isn't a vote, then it should be treated like XFD, where the outcome is determined not by counting votes but by the strength of the arguments, and comments from newbies or other users who clearly have no idea what they are talking about are given significantly less weight. Under this system, all comments should be supported by some rationale, and there should be a limit as to how far "Support per nom" or "Oppose per X" can go before independent reasoning becomes necessary. We need to decide whether RFA is a vote, or a discussion based on consensus. This half-and-half thing where it's "kind of sorta but not really a vote" and "well it is a vote but only established users are given weight" does no good. Taking Out The Trash (talk) 00:16, 1 March 2024 (UTC)
16. While I do understand the goals of the proposal, !voting by inexperienced editors or trolls doesn't seem like it would affect the results all that much. Secondly, I think I have seen more people that are extended confirmed causing more problems than newer editors. Finally, it is not exactly impossible (though tedious) to have sockpuppets become extended confirmed. ✶Quxyz✶ 17:00, 2 March 2024 (UTC)
17. Oppose All of the drama comes from tenured editors anyway. _Dial^mayo 15:24, 14 March 2024 (UTC)
18. Oppose agree with the above that many of the borderline-troll opposes and comments actually come from experienced editors. Gizza (talk) 23:02, 14 March 2024 (UTC)
19. Oppose - Most of the dramas came from experienced editors instead of newer editors. Newer editors will most likely be baffled at what's going on instead of stirring the pot. Deal with sockpuppets in another way, but don't stop people from voting in. Newer editors that have a bad dealing with the admin candidate must also be allowed to speak up easily and prominently instead of being hidden away in talk pages (where they may not find it either). ✠ SunDawn ✠ (contact) 06:05, 15 March 2024 (UTC)
20. Oppose. Haven't seen evidence for people not meeting these requirements would be incapable of making well-reasoned votes, or that they cannot be accountable for their votes. I would argue that most disruption comes from editors that meet this requirement. 0xDeadbeef→∞ (talk to me) 06:19, 17 March 2024 (UTC)

General discussion (proposal 14)

Putting this out as a slight improvement in case the more radical proposals fail. —Kusma (talk) 12:28, 23 February 2024 (UTC)

Voters should be extended confirmed. There needs to be evidence that voters understand Wikipedia with enough experience to vote, and extended confirmed would meet that threshold. Steel1943 (talk) 02:06, 27 February 2024 (UTC)

• Only suppporting this for any vote-only (or secure-vote) process (like proposal 13), if any are implmented. Oppose this for our currrent process and anything else. - jc37 02:36, 27 February 2024 (UTC)

• Would people under the requirement be able to comment on the talk page? --Aaron Liu (talk) 12:30, 27 February 2024 (UTC)

• no potential for harm, Pppery by harm do you mean an effect on the results or on the voters themselves? — ♠Ixtal ^{( T / C )} ⁂ Non nobis solum. ♠ 12:49, 29 February 2024 (UTC)

  I mean no effect on the results. * Pppery * _{it has begun...} 14:47, 29 February 2024 (UTC)

  Thanks for the clarification. — ♠Ixtal ^{( T / C )} ⁂ Non nobis solum. ♠ 22:10, 29 February 2024 (UTC)

Proposal 15: Community-based process for appointing CheckUsers and Oversighters

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I think we should consider the idea of having the community appoint CUs and OSs in a similar process that RFAs are run by. I think in this way, the community has more of a say in who is most qualified for these positions. Interstellarity (talk) 01:22, 25 February 2024 (UTC)

For the discussion of this failed proposal, see Wikipedia:Requests for adminship/2024 review/Phase I/Closed proposals#Proposal 15: Community-based process for appointing CheckUsers and Oversighters

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 16: Allow the community to initiate recall RfAs

Administrators currently retain their permissions indefinitely, and the community itself has no means to revoke administrator permissions once they are given. The only way to remove an administrator is for the Arbitration Committee to open a case and rule against the administrator in light of egregious conduct. There is no means to remove permissions for administrators who have lost the trust of the community unless they have committed egregious or ban-worthy offenses.

If this proposal passes, the community will be able to revoke the permissions of an administrator pending a new RfA. A recall will occur if a consensus is found to do so at WP:AN, WP:ANI, or WP:XRV, similar to how community bans are currently handled. The administrator will then be required to pass a new RfA to retain administrator permissions.

Benefits of this proposal would be that administrators can be better held accountable for repeatedly acting against consensus, failing to abide by policy, or other serious infractions that do not rise to the level of ARBCOM. It would create a binding alternative to the currently optional recall process, which has been criticized for its inefficacy. The potential drawback is that it would limit an administrator's ability to take necessary but controversial actions that may prompt a kneejerk recall: there are ways this could be mitigated, such as requiring only a simple majority at RfA to be reconfirmed. Thebiguglyalien (talk) 03:48, 27 February 2024 (UTC)

Update: I've struck WP:XRV as a forum for recall per the comments below. Thebiguglyalien (talk) 17:32, 27 February 2024 (UTC) WP:ANI has also been struck. Thebiguglyalien (talk) 07:30, 28 February 2024 (UTC)

Support (Proposal 16)

1. General support for the idea. It would need some kind of gatekeeping to filter out serious recalls from frivolous ones. If there were RFA suffrage requirements, those should also be recall suffrage requirements. Levivich (talk) 05:28, 27 February 2024 (UTC)
2. I don't see why not, but one should set the threshold for initiating recall RfAs fairly high. Banedon (talk) 05:39, 27 February 2024 (UTC)
3. Agree with nom, plus having an easier way to remove adminship might reduce the tension at RFAs, which I believe to be the result of the perceived "high stakes" of granting adminship. The main issue is where to set the bar for initiating the recall RfA. Setting the bar too low has obvious issues per the arguments above, but setting it too high defeats the purpose of having this easier process for desysop; editors might simply bring the case to arbcom if they believe it's too hard to gain consensus to even start the reconfirmation. Liu1126 (talk) 11:27, 27 February 2024 (UTC)

   There's also the question of how the bar should be set. Nominator suffrage requirements (like only allowing EC editors to start reconfirmations) are the easiest to implement, but this disadvantages newer editors. Requiring prior discussions and consensus of wrongdoing may be better, but would be tricky to set the bar; having one admin action overturned at WP:XRV probably isn't cause for a desysop, but requiring multiple such discussions makes the situation ripe for arbitration anyway (unless arbcom decides that reconfirmation is also included in the "dispute resolution methods" that need to be exhausted first). Liu1126 (talk) 11:45, 27 February 2024 (UTC)

4. Support: Currently, the threshold to desysop is a lot higher than to indeff a rank-and-file editor. Sweet6970 (talk) 12:03, 27 February 2024 (UTC)
5. While Arbcom seems to have made it easier to hear cases of admin misconduct in recent years (eg: User:Athaenara), I'm still supportive of the general principle that it should be easier to demote admins without having to drag things through Arbcom. Ritchie333 ^{(talk) (cont)} 12:35, 27 February 2024 (UTC)
6. Support in principle. It would have to be well advertised, as RfAs are now, to avoid undue influence in either direction by a small group of friends or foes. We should require a substantial quorum to start the process. However, that might be difficult to collect: while the vast majority of admins deserve praise for carrying out a wonderful job, the few who don't can be intimidating. Certes (talk) 13:03, 27 February 2024 (UTC)
7. Perennial proposal, still good. If we already trust the community to elect, we should trust them to remove. Other WMF projects do this Mach61 (talk) 13:06, 27 February 2024 (UTC)

   I actually think the community would be more conservative than ArbCom currently is Mach61 (talk) 13:09, 27 February 2024 (UTC)

8. It works for removing all other permissions (e.g. rollback, autopatrolled), so why wouldn't it work for adminship? As for frivolous requests, I would point to the (lack of) frivolous requests to remove those other permissions. I would also expect admins to have thicker skins than rollbackers, so I don't see why the former needs more "protection" from frivolous requests than the latter. HouseBlaster (talk · he/him) 13:41, 27 February 2024 (UTC)
9. Needed — PerfectSoundWhatever (t; c) 14:02, 27 February 2024 (UTC)
10. Idea support, oppose as written. This proposal is premature. This is something that needs a lot of workshopping and would do best as a standalone proposal. — xaosflux ^Talk 14:24, 27 February 2024 (UTC)

    Spitballing: Have a "Requests for recall" page, if ten editors (feel free to impose sufferage requirements) ask for recall within one week a vote is started. Mach61 (talk) 14:51, 27 February 2024 (UTC)

    Please god no. Every admin with a backbone has at least 10 detractors. In a wiki this large, you will piss off some people, more if you're doing admin things. Any community recall process needs to be a fairly high threshold so we don't give admins an strong incentive against our high importance areas.

    Otherwise my take is identical to @Xaosflux:. The heart is in the right place, but I'd like more details fleshed out. What'd be confirmation RFA percentages? Would we have recalls triggered by all of these forums? Etc. Soni (talk) 15:14, 27 February 2024 (UTC)

11. Putting my formal weak support support down. Full comment just above Soni (talk) 15:50, 27 February 2024 (UTC)
12. Needs revision with further RfCs, but I support the general concept. Sincerely, Novo Tape^{My Talk Page} 16:14, 27 February 2024 (UTC)
13. Conditional on some workshopping. The idea is solid, but it needs some protection against witch-hunts and hot-headed behavior. A minimum time-frame is a good idea, per Kusma below; I agree that ANI is a terrible venue for this, and a dedicated board is probably better; and we'd need a similar pass/discretionary zone/no pass system, or frame the consensus-determination around "has this user violated ADMINACCT/ADMINCOND", so that it doesn't become a gameable voting exercise. Vanamonde93 (talk) 17:00, 27 February 2024 (UTC)

    I'd say we use AN. Currently it's only clearly used for closure reviews and news z Aaron Liu (talk) 17:10, 27 February 2024 (UTC)

14. Unfortunately this is not likely to go anywhere, because like most RfA reforms people support it in the abstract but not when a concrete proposal comes up, but sure, let's give this another go. * Pppery * _{it has begun...} 17:14, 27 February 2024 (UTC)
15. I'll give moral support to the idea of fleshing this out with details that are lacking now. I'm having flashbacks to WP:CDARFC, from the wiki-Cretaceous period. What I think has changed over the years is that ArbCom has gotten good at dealing with those admins who should be removed, something that ArbCom years ago was not good at. So what I have to be persuaded of is: how would this be different from a request to ArbCom? I suppose the answer is that ArbCom wouldn't be needed in the process if the community could do it on our own, but please follow where I'm going with this. I think it would be a net negative to have admins subject to removal without a thoughtful examination of the evidence. So one solution to that would be to have this process lead to a recommendation to ArbCom to actually make the final decision. But that's just a kludgy way to do WP:RFAR. Otherwise, there has to be a way to prevent unfair passions from running away with removal of a good admin who made a tough call, and also there has to be a way to prevent a popular but flawed admin from being overly defended by their friends. --Tryptofish (talk) 20:18, 27 February 2024 (UTC)
16. Good idea. Kneejerk/revenge recalls could be mitigated by a rule that a recall may not be begun for a year (say) after a failed recall. CohenTheBohemian (talk) 10:31, 28 February 2024 (UTC)

    I would be in favour of such a rule. Soni (talk) 15:41, 28 February 2024 (UTC)

17. My belief is that this is already possible based on a straight-forward reading of WP:CONSENSUS and WP:ADMIN; might as well formalize it. BilledMammal (talk) 12:44, 28 February 2024 (UTC)
18. Ab so lutely. Gives the community the power to desysop without going up to ArbCom. Queen of Hearts talk
    she/they
    stalk 13:21, 28 February 2024 (UTC)
19. Community recall is many, many years overdue. LEPRICAVARK (talk) 15:51, 28 February 2024 (UTC)

    Support in principle moving to neutral. Admins serve with the support of the community, but we have no process by which the community can withdraw its support. That is a glaring omission. I would like to see a more fulsome proposal with defined requirements before I support outright; this comment should be interpreted as support for initiating that discussion, not support for whatever anyone comes up with. Ivanvector (^Talk/_Edits) 15:54, 28 February 2024 (UTC)

20. Support in principle I think details need be worked out. --Enos733 (talk) 17:14, 28 February 2024 (UTC)
21. At the moment the process is usually a discussion at AN/ANI, which results in an ARBCOM case that in turns results in admin rights being removed. In reality the ARBCOM cases are always going to end up removing rights. If the community no longer has faith in an admin then ARBCOM is highly unlikely to back the admin against the community.
    But I'm deliberately avoiding the 'S' would in my comment. This is a nice sentiment, but it will need a well thought out and robust process. Otherwise it will just become a playground of sockpuppets reporting their most disliked admin over and over. That will result in editors not wanting to become admins not because of the toxicity of RFAs, but the endless toxicity of the recall processes. -- LCU ActivelyDisinterested «@» °∆t° 20:10, 28 February 2024 (UTC)
22. Support in principle, but needs more details explicitly laid out. In addition to other concerns laid out (requirements to initiate a recall, minimum time frame, etc.) I'd like to emphasize that a recall would need to be listed in the same places as an RfA (e.g., at WP:CENT). RunningTiger123 (talk) 01:33, 29 February 2024 (UTC)
23. I think a two-stage system might work, where 10-15 editors need to express support for desysopping for a RfDA to be initiated, and then the whole community can !vote in the second the stage. The first stage should purposely have no discussion; just an initial statement for what incident or behavior has precipitated the request, and then supports (no opposes and no rationale needed) from those who think a RfDA is justified by the circumstances. I think this is a reasonable standard that lets the community decide and still avoids the issue of single disgruntled editors trying to take their ire out on admins. AryKun (talk) 19:30, 29 February 2024 (UTC)
24. Many details would need to be worked out in order to make this work and not malfunction. But I think in vague terms it's a good idea. This could even help "lower the stakes" for RFA's. North8000 (talk) 19:55, 29 February 2024 (UTC)
25. Support the idea, but this needs to be workshopped longer before passing. There should be a subpage of RFA for this purpose and the same notices that go out when an RFA is open should also go out when a recall is open. I also support suffrage requirements - calls for a recall should be limited to uninvolved users past a certain edit count. 9yz (talk) 22:47, 29 February 2024 (UTC)
26. I support this in theory, but agree that it needs further improvements and work-shopping before I could actually support this being put into practice. Dreamy Jazz ^{talk to me | my contributions} 15:26, 1 March 2024 (UTC)
27. Perpetual support for some sort of recall ~ Amory (u • t • c) 13:05, 2 March 2024 (UTC)
28. Support This has been something people have been asking for for a long time. Hawkeye7 (discuss) 00:17, 3 March 2024 (UTC)
29. Support. We don't see AN using its site-ban power or its topic-ban power or its PERM-revocation power to inflict unnecessary punishment for minor infractions and petty grudges. Why would a desysop (a far less serious remedy than a site-ban) be any different? +sysop is not inherently special, and if we can build a culture that's willing to remove adminship at AN, we'll soon have a culture that's willing to grant it there too. Extraordinary Writ (talk) 01:37, 3 March 2024 (UTC)
30. Support absolutely, although this seems out of scope for the current goal of making RFAs less ugly. Grandpallama (talk) 19:43, 3 March 2024 (UTC)
31. Yup - Been kicking this horse for years. It's never going to actually pass, because there's gonna be 1,000 people who will confidently tell us that it will light the entire project on fire. It wont. It's been working just fine at places like Commons for a long time. You can screw around on the edges of RfA and change out the drapes and furniture, but unless you fix demopping in a way that doesn't require a Supreme Court case that lasts three months and sees three or four people quit out of anger, depression or spite, you're not going to fix the mop-giving process. GMG^talk 17:03, 6 March 2024 (UTC)
32. Support But not overly important regarding RFA problems. Would need a lot of work to get it right. North8000 (talk) 20:05, 7 March 2024 (UTC)
33. Support as the following: If there is consensus at ANB for removal of administrator tools, then the tools are procedurally removed. The removal can be appealed only to ArbCom for three months after the removal, after which it requires a new RfA. Of course, if the administrator resigns, then it counts as resigning under a cloud. This essentially has the same behavior as suspended ArbCom cases, without all the drama of ArbCom unless if requested. Awesome Aasim 20:43, 7 March 2024 (UTC)

    Why would we need an appeal at ArbCom and an RfA? Wouldn't just the latter be enough? Aaron Liu (talk) 21:27, 7 March 2024 (UTC)

34. Support in principle, but the details need to be fleshed out. Cullen328 (talk) 01:50, 8 March 2024 (UTC)
35. I feel that effectively, the community already has a process that can this since last May, though actually using that specific process to implement only a desysop as the intended sanction is probably needlessly complicated and a little bit like using a sledgehammer to open a door (by smashing it and then replacing it with a new, unlocked door). I am, of course, referring to WP:BANDESYSOP, which means that should the community act to place an indefinite siteban and then later remove that siteban, the overall effect is a desysop. Still, probably worth workshopping an equivalent process for just desysoping when doing it by siteban+removal seems like a lot of unnecessary process for process's sake if a desysop was the only intended outcome. Probably also not urgent though, honestly I'd expect whoever closes such a discussion to just do the desysop and dispense with the unwanted ban since closers aren't robots doomed to follow the letter of policy exactly as written. Alpha3031 (t • c) 08:40, 9 March 2024 (UTC)
36. Support Ivan (talk) 19:46, 11 March 2024 (UTC)
37. Support --Goldsztajn (talk) 08:48, 12 March 2024 (UTC)
38. Support in principle. I like the idea but the details need a lot of work (and I prefer 16c). HJ Mitchell | Penny for your thoughts? 11:49, 14 March 2024 (UTC)
39. Moral support. I have worries about how this might have a chilling effect on administrative activity in controversial areas, but I do think something along these lines is needed. —Compassionate727 ^(T·C) 12:19, 14 March 2024 (UTC)
40. Support: blocking/banning is significantly more serious than de-adminning and the status quo is that community consensus, for instance found at AN or ANI, can lead to blocks and bans. This process also works for removal of rights such as autopatrolled. I disagree with others that there are further details to work out. Bureaucracy is to be avoided when it comes to dealing with intractable incivility and misconduct as problems and solutions can take many different forms: the flexibility of the existing concept of consensus would work well for cases where admin tools need to be removed. Where past recall seems to have failed is in mandating numbers of accounts that meet certain criteria and timeframes and so on, so this proposal is better than 16(c). — Bilorv (talk) 23:01, 15 March 2024 (UTC)
41. On principle, strongly support the idea. Like many others above, I think this needs a lot of ironing-out with further discussion. sawyer * he/they * talk 02:50, 16 March 2024 (UTC)
42. Support on principle. – Hilst [talk] 23:42, 16 March 2024 (UTC)

Oppose (Proposal 16)

1. Oppose "trial by ANI" as recall process. Recent Arbcoms have desysopped for relatively small infractions and have mentioned community trust, so I do not see evidence that bypassing Arbcom is needed or helpful. —Kusma (talk) 11:54, 27 February 2024 (UTC)

   I would prefer something like dewiki's decentralised recall requests pages de:WP:AWW, where a recall election has to be started by the admin when 25 new votes for recall have accumulated in one month, or 50 have accumulated in one year. Just say no to anything involving the dramaboards. —Kusma (talk) 15:43, 27 February 2024 (UTC)

   Also opposed if it is AN instead of ANI. Make a fast track Arbcom procedure for "community wishes desysop" instead. —Kusma (talk) 14:33, 28 February 2024 (UTC)

2. Oppose - the reason this keeps failing is that it would tend to scare any admin from handling any highly controversial issues. This would include making the problems with the unlockables worse (remember the Frame case?). Animal lover |666| 17:47, 27 February 2024 (UTC)
3. I've supported some recall proposals in the past, but one which requires a simple consensus on a noticeboard with no requirements for quorum, etc. isn't sufficiently well fleshed out for me to support. — Rhododendrites ^talk \\ 17:58, 27 February 2024 (UTC)
4. Oppose per Animal lover 666. Gamaliel (talk) 04:25, 28 February 2024 (UTC)
5. Oppose. Making admins essentially RFA again does not seem to solve the problem of making RFA less toxic and more appealing to candidates. And Arbcom seems to be taking its role of moderating admins quite seriously, with several desysops recently, for a variety of infractions both large and small. –Novem Linguae (talk) 05:13, 28 February 2024 (UTC)
6. Oppose. I don't think this improves RfA at all and it will in fact decrease the number of people willing to go through the RfA process. The ArbCom has proven itself capable of handling cases that arise. Daniel Quinlan (talk) 18:04, 28 February 2024 (UTC)

   I've been thinking about this some more. My other concern is that this proposal may discourage admins from handling controversial issues and dealing with abuse from long-term users. Daniel Quinlan (talk) 17:51, 29 February 2024 (UTC)

7. Oppose per Kusma, Animal lover 666 and Novem Linguae. Also, I have not seen any evidence that this is indeed a problem that needs fixing, i.e. that ArbCom is unable to handle those few cases where such sanctions are necessary. This proposal has no discernible upside but the downsides are palpable. Regards SoWhy 19:55, 28 February 2024 (UTC)
8. Oppose I think this sort of thing should be left to experts, I can see a witch hunt type situation starting because an admin did something somebody didn't like. ᴢxᴄᴠʙɴᴍ (ᴛ) 00:17, 29 February 2024 (UTC)
9. Oppose; like Animal lover 666, I am concerned that this would discourage admins from doing anything likely to draw significant ire. Such a process also seems a magnet for drama and bad blood, which would negate the advantages it possesses over our current system. ― novov (t c) 04:48, 29 February 2024 (UTC)
10. Oppose. Not a proper venue for this proposal. See WP:RFDA. Stifle (talk) 11:11, 29 February 2024 (UTC)

    Also would oppose generally, by the way, as the current methods for dealing with problematic admins are satisfactory and recall creates a chilling effect by allowing threats of frivolous or vexatious recall petitions. Stifle (talk) 10:24, 1 March 2024 (UTC)

11. Oppose I'm concerned with the lack of a safety protocol to prevent mobbing Admins involved in contentious areas into recall. Chetsford (talk) 05:51, 1 March 2024 (UTC)
12. Oppose - we don't have enough administrators now, so any proposal likely to make adminship less attractive to prospective candidates would be a step backward in my view - and the prospect of admins being mobbed or harassed for dealing with difficult or controversial matters is very real IMO. I have also seen no credible evidence that the current system of desysopping via Arbcom is insufficient. We should be looking to make adminship more attractive to potential candidates, not less so. Gatoclass (talk) 15:23, 2 March 2024 (UTC)
13. Oppose trial by AN which tends to be not well-suited to examining intrackable or complicated issues such as longer-term concerns about admin actions. I also agree with the comments above that I don't believe this will make RFA less toxic. Callanecc (talk • contribs • logs) 03:20, 3 March 2024 (UTC)
14. Oppose I don't believe this would lead to useful desysoppings - I believe it would simply lead to enormous amounts of drama and wasted time. The ArbCom system we have in place is clunky but basically functional and much more structured. —Ganesha811 (talk) 06:09, 3 March 2024 (UTC)
15. Pretty much per Animal lover 666 and Callanecc. Trial by AN is not the way to go for community-based desysop processes - that's just an invitation for more drama. JavaHurricane 20:23, 3 March 2024 (UTC)
16. I'm not unalterably opposed to some form of community desysop besides arbitration, but I am to ones that aren't resilient to off-wiki collusion. This doesn't even try. Besides, the problem with RFA isn't that it's promoting unfit admins; it's that it's so toxic that fit candidates don't want to go through it. The prospect of having to go through it again every time you offend someone with a sufficiently large drawer of socks is going to have the exact opposite of the effect we want. —Cryptic 21:19, 4 March 2024 (UTC)
17. Oppose as written, though I support the general idea of having a community desysop process. As has been mentioned by others, "Trial by ANI" is a terrible idea and reconfirmation RfA has too many drawbacks. Any community desysop process would need to be very well structured to prevent abuse. I have an idea I was tinkering with at User:The Wordsmith/Requests for comment/Administrator conduct roughly based on the old WP:RFC/U but it needs more work before it would be ready to propose. The Wordsmith^{Talk to me} 20:25, 7 March 2024 (UTC)
18. Oppose per Animal lover 666. Without some formal process, I worry all we'll get is an avalanche of frivolous desysop proposals. JML1148 ^{(talk | contribs)} 01:20, 10 March 2024 (UTC)
19. We have a community based desysopping system, it is called Arbcom. We also have some community agreed criteria for minimum admin activity and hundreds of admins have been desysopped under those rules. If someone wants Arbcom to be harsher on admins, or to desysop for a reason that it currently wouldn't, then ask a question at the next Arbcom election, start an RFC to set a new rule for admin behaviour or stand for arbcom yourself. But please, be specific as to the sort of admin behaviour that you want to end. ϢereSpielChequers 11:56, 10 March 2024 (UTC)
20. Discussions at AN often have relatively little participation. I do not want administrators being demoted by the consensus of <10 editors, which I think would be common. —Compassionate727 ^(T·C) 23:21, 17 March 2024 (UTC)
21. Oppose. I have a specific concern that some outside group will at some point try to "take over" Wikipedia through sheer force of numbers, merely by getting enough accounts to vote out whoever stands in their way. Admins will always be the first line standing in the way of such a group. BD2412 T 03:23, 18 March 2024 (UTC)

Neutral (Proposal 16)

1. Big-picture I think that making it easier to remove administrators will make RfA a lower-stakes process, which should decrease toxicity there, and so long-term increase the number of people willing to consider running for RfA; but I have to think that the first-order effect ("make it easier to remove administrators") will be larger in magnitude than the third-order effect ("more people willing to run for RfA") and so that this would exacerbate the problem of too few admins. So I would not support this in isolation, only in combination with changes whose first-order effect would be to increase the number of administrators. --JBL (talk) 18:51, 27 February 2024 (UTC)
2. Moved from support. I support the general idea that the community should be able to recall administrators, but this proposal is too vague and open to abuse. More discussion is needed, and not in this threaded format. Ivanvector (^Talk/_Edits) 18:25, 1 March 2024 (UTC)
3. I support the idea of allowing the community to revoke admin permissions pending a new RfA. But I would prefer a structured way of doing that, not just WP:AN. Tim Smith (talk) 22:55, 15 March 2024 (UTC)

Discussion (Proposal 16)

Is incompatible with the agreed scope of WP:XRV. — Preceding unsigned comment added by SmokeyJoe (talk • contribs) 04:34, 27 February 2024 (UTC)

+1 I am not going to nitpick and oppose the idea behind the proposal, but XRV is supposed to operate like DRV. HouseBlaster (talk · he/him) 13:50, 27 February 2024 (UTC)

I don't agree with the part about XRV either. XRV is about the administrative action, and the only thing that is up for discussion there should be the action itself and the performing admin's reason for it. When I open an XRV thread it says nothing about what I think about the performing admin's suitability for adminship. 0xDeadbeef→∞ (talk to me) 14:11, 27 February 2024 (UTC)

Thebiguglyalien, any chance I could get you to strike ANI too? It's just going to draw additional opposes of the ANI-is-a-cesspool variety, and ANI threads tend to attract less attention since there are so many of them (leading to a weaker consensus than you'd get at AN). Extraordinary Writ (talk) 07:07, 28 February 2024 (UTC)

Done. Thebiguglyalien (talk) 07:30, 28 February 2024 (UTC)

I've begun drafting two proposals for a more specific recall process at User:Novo Tape/sandbox (I strongly prefer the first; the second is just to get an idea of what to focus a proposal on). Anyone is free to edit them and/or provide feedback. Sincerely, Novo Tape^{My Talk Page} 18:05, 28 February 2024 (UTC)

I suggest reviewing some of the previous proposals listed at Wikipedia:Requests for de-adminship § Proposed processes, for context. isaacl (talk) 18:23, 28 February 2024 (UTC)

Proposal 16b: Require a reconfirmation RfA after X years

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

As described in the previous proposal, administrators are only subject to ARBCOM once they are given administrator permissions. There is no means to remove permissions for administrators who have lost the trust of the community unless they have committed egregious or ban-worthy offenses.

If this proposal passes, administrators will be required to pass a new RfA after a certain number of years to confirm that they still have the trust of the community and need for the tools. The number of years will be decided by the community, either in this proposal (if there is strong consensus for a specific number) or in a follow up discussion. Administrators who do not initiate a new RfA will have their administrator permissions expire in good standing with the option to reapply at a later time. This will replace the current inactivity rules for administrators. Current administrators will not be immediately subject to reconfirmation if they have served longer than X years. If several administrators must be reconfirmed in a short period, reconfirmations may be staggered at bureaucrat discretion to allow sufficient time for review.

Supporters of this proposal may condition their support on a minimum or maximum number of years they would be willing to support. As with the previous proposal, the benefit would be stronger accountability for administrators who have lost the trust of the community. It would also simplify the current inactivity rules. The potential drawback is that it would make administrators less likely to take necessary but controversial actions, though it would allow time to pass before an RfA due to its scheduled nature, preventing kneejerk reactions. This drawback could be further mitigated through means such as requiring only a simple majority to reconfirm. Thebiguglyalien (talk) 03:48, 27 February 2024 (UTC)

For the discussion of this failed proposal, see Wikipedia:Requests for adminship/2024 review/Phase I/Closed proposals#Proposal 16b: Require a reconfirmation RfA after X years

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 16c: Community recall process based on dewiki

This is a way to initiate recalls for admins without requiring WP:ARBCOM. Seeing the calls for a formalised process in Proposal 16, I'm presenting one based on dewiki's Admin recall process.

1. WP:Admin Reconfirmation will be created, where any subpages can be created for individual admins. Editors may sign on those subpages to vote for a reconfirmation.
2. The reconfirmation is initiated if 25 editors with Extended Confirmed rights vote for it within the last 1 month. Or if 50 editors with Extended Confirmed rights vote for it within the last 1 year.
3. Once a reconfirmation is started, the admin in question must run for a "Reconfirmation RFA" (RRFA) within the next 30 days. Otherwise a bureaucrat can remove their admin rights.
4. A RRFA will be identical to any RFA, but with lower thresholds. Instead of 75% "generally passing", it'll be 66%. And the discretionary range for Bureaucrats will be 55% to 66% instead of 65% to 75%. Any admins who fail a RRFA will have their admin rights revoked.
5. Any admins may voluntarily stand for RRFAs at any time if they like. This will be otherwise considered identical to a community initiated Reconfirmation.
6. Admins who have successfully run for an RFA, RFB, RRFA, or Arbcom elections in the last 1 year are not eligible for a community initiated Reconfirmation. Any votes for reconfirmation in the 1 year after an admin succeeds any of these will be struck.

If there's any one part of this proposal you'd prefer editing, please state so in the discussions below. I'm happy for the exact details to be tweaked by a future RFC or proposal closers by community consensus, as long as there's support for the overall recall process outlined.

Soni (talk) 14:28, 29 February 2024 (UTC)

Edits : Used RRFA as a short form for clarity, add line about rights removal (if no RRFA happens), rephrased RRFA thresholds to match intent (same as RFA, but lower thresholds) Soni (talk) 19:12, 29 February 2024 (UTC)

Support (Proposal 16c)

1. As proposer Soni (talk) 14:28, 29 February 2024 (UTC)
2. I quite like this; I don't believe there is anything radically new here, but it does address many of the common concerns with recall. There's a dedicated venue, away from the cesspit; there's limited suffrage, to prevent gaming; there's a time limit, so opposition to an active admin can't just accumulate; there's a discretionary zone, so people who are upset because they were at the receiving end of justified admin actions can have their !votes discounted if needed; and the discretionary zone is lower that at RFA, recognizing the fact that an active admin will have more opposition than a fresh admin candidate. I might suggest some tweaks: 50 editors in a year isn't that much, when you consider our larger editor body, and a 11% discretionary zone is an odd artefact. But these are quibbles. I don't see this as incompatible with the previous recall proposal, but the specifics are far preferable here. Vanamonde93 (talk) 17:21, 29 February 2024 (UTC)
3. Reasonably well fleshed out. I would strongly prefer we use a recall system where recalls can be initiated based on pure numbers rather than notmal consensus, as otherwise we run into the problem described at c:User:Alexis Jazz. Whether the recall itself is a straight vote is less important. Mach61 (talk) 18:03, 29 February 2024 (UTC)
4. While I'm still not sure we really need a community desysop procedure, something of this type is better than any of the other suggestions I have seen. Numbers may need tweaking based on enwiki's larger user base. —Kusma (talk) 19:43, 29 February 2024 (UTC)

   I'm still not sure we really need a community desysop procedure The reason I have always been supportive of this idea is because of the community role in sysop in the first place. RFA is essentially a vote of confidence by the community in a particular editor to hold the mop. Once an admin, though, desysop is only really possible through misuse of the tools they've been granted; there is no way to address the notion that the community has lost faith in that admin's judgment. Misconduct should not be the only way in which an admin can be desysopped. The current admin-for-life approach is problematic. Grandpallama (talk) 19:39, 3 March 2024 (UTC)

5. I do like the idea of this/ Dreamy Jazz ^{talk to me | my contributions} 15:24, 1 March 2024 (UTC)
6. This looks like a satisfactory system. LEPRICAVARK (talk) 17:16, 1 March 2024 (UTC)
7. Support. Others have pointed out the issue with consesnus, however this is certainly better than nothing and I doubt we're going to see many frivolous reconfirmation RfAs triggered. If we do, we can always scrap it in a later RfC. Sincerely, Novo Tape^{My Talk Page} 17:43, 1 March 2024 (UTC)
8. Equal choice with 16a. HouseBlaster (talk · he/him) 03:47, 2 March 2024 (UTC)
9. Support Seems reasonable. Hawkeye7 (discuss) 00:19, 3 March 2024 (UTC)
10. Support (if 16a fails) basically per Vanamonde. This recall proposal has the added benefit that, thanks to de-wiki's experience, we more-or-less know it works. The increase in accountability to the community is a great benefit, and the various checks are enough to make most of the potential cons quite unlikely. Extraordinary Writ (talk) 01:50, 3 March 2024 (UTC)
11. This seems like a good starting point for a process. Before implementing it, further discussion on the specifics would be needed. Callanecc (talk • contribs • logs) 03:28, 3 March 2024 (UTC)
12. Support , a recall process for admins has been long overdue. Ratnahastin (talk) 06:50, 3 March 2024 (UTC)
13. Support as something long overdue. Of course, the problem has never really been community support, so much as inability to form consensus on how this should actually work. Grandpallama (talk) 19:39, 3 March 2024 (UTC)
14. Support I lean support but would like to see something more - since the default should be to keep the administrator, a recall RfA should start with "here is why we, the people who voted to start the RRfA, think the administrator should no longer be trusted", and the administrator should be able to defend themselves. Banedon (talk) 07:10, 4 March 2024 (UTC)

    I believe any RRFA that fails because of "lack of admin trust" will have enough discussion in the Q&A and comments section of RRFA alone, if not elsewhere. Discussion and cross-questioning can happen at their own place, I'm just not convinced "all" RRFAs need to default to an Arbcom style "Accusations then Defence" style. Soni (talk) 13:40, 4 March 2024 (UTC)

15. Support Neat! Leijurv (talk) 00:54, 6 March 2024 (UTC)
16. Per Vanamonde and Novo Tape. Queen of Hearts talk
    she/they
    stalk 19:55, 7 March 2024 (UTC)
17. Support Would probably need some refining. North8000 (talk) 20:10, 7 March 2024 (UTC)
18. If it works on dewiki it should work on enwiki. BilledMammal (talk) 11:57, 10 March 2024 (UTC)
19. Support Ivan (talk) 19:44, 11 March 2024 (UTC)
20. The bar of 50 in a year seems low to me for initiating such a high-drama process and the supporters should be able to point to something the admin has done that has caused them to lose faith in the admin. But in principle I strongly support some sort of community-based process for deciding whether an admin retains the trust of the community. HJ Mitchell | Penny for your thoughts? 11:44, 14 March 2024 (UTC)
21. We've got to do this or something like it. I'm finding myself struggling to support any candidates at RFA when a "yes" puts a person I don't know in a position of power over me that I can't take back. Arbcom is woefully insufficient to answer that concern because you can't even access Arbcom unless they've done something egregious and then refused to apologise; any fool could keep their bit in the face of such a process. Only a working community desysop process suffices. This needs workshopping and development but it's important that it passes.—S Marshall T/C 12:16, 14 March 2024 (UTC)
22. Support. I have long been in favor of a community-based recall process, and I like the idea of basing it on one which is already in use at another wiki (in this case, dewiki). As to the specifics, in point 4, I would prefer the threshold for RRFAs to be the same as for RFAs, i.e. 75%. I also don't think anyone should be immune from recall, let alone for a year, so I would strike point 6. Tim Smith (talk) 00:17, 16 March 2024 (UTC)
23. —Compassionate727 ^(T·C) 05:34, 17 March 2024 (UTC)

Oppose (Proposal 16c)

1. Oppose. I believe dewiki generally uses their procedure to desysop largely inactive administrators, not to deal with ADMINCOND issues for the most part. Either way, I believe initiating a desysopping should be based on consensus, not on an admin having a bunch of (for lack of a better word) enemies. Sincerely, Novo Tape^{My Talk Page} 17:03, 29 February 2024 (UTC) Moving to support. Sincerely, Novo Tape^{My Talk Page} 17:43, 1 March 2024 (UTC)

1. Oppose: I don't think the community should be able to remove admin rights unless there's an explicit consensus to desysop. Admin recall is a really good start, but the status quo of a recall discussion should favor the admin in question – no consensus defaults to retain tools. theleekycauldron (talk • she/her) 20:05, 29 February 2024 (UTC)

   @Theleekycauldron, A no-consensus to desysop result would allow the admin to keep tools under this proposal Mach61 (talk) 22:15, 29 February 2024 (UTC)

   ... no? if enough people sign a desysop petition, you have to run and pass an RRfA or you're desysopped. theleekycauldron (talk • she/her) 23:26, 29 February 2024 (UTC)

   @Theleekycauldron I meant no consensus during the RRfA Mach61 (talk) 01:28, 1 March 2024 (UTC)

   How are we supposed to judge consensus if e never have a discussion over it? AryKun (talk) 06:52, 1 March 2024 (UTC)

   We should have discussion, AryKun, but the status quo should be retention. Admins should be desysopped when a discussion at AN results in clear consensus to do so for cause – not when a discussion at AN results in "no consensus to retain". theleekycauldron (talk • she/her) 20:23, 1 March 2024 (UTC)

   @Theleekycauldron this proposal mentions nothing about AN, I think you're confusing it with 16d below Mach61 01:55, 2 March 2024 (UTC)

2. Oppose for the same reasons I provided in 16. Chetsford (talk) 05:53, 1 March 2024 (UTC)
3. Oppose, current process works just fine. Stifle (talk) 10:22, 1 March 2024 (UTC)
4. The numbers in #2 aren't suitable for enwiki, which is a significantly larger community than dewiki. The combination of #5 and #6 will encourage admins to time reconfirmations when they haven't screwed up recently, to get immunity for a year. And, as in Prop 16, this is going to make the current overwhelming problem with RFA worse, not better. —Cryptic 21:19, 4 March 2024 (UTC)
5. Oppose. First, this doesn't solve any issues we have today with RfA. Second, the thresholds are much too low for English Wikipedia. The likely result of this proposal is that external drama boards, not Wikipedia community consensus, will be involved in driving votes over the required thresholds more often than not. Daniel Quinlan (talk) 09:06, 6 March 2024 (UTC)
6. Oppose This does nothing to solve the ongoing issues with RfA. Additionally, this has been a perennial proposal and all the reasons not to adopt it from previous proposals in 2009, 2010, 2015 and 2019 are still valid. Any admin that works in contentious areas will naturally accumulate enough people that don't like being made to follow the rules. WP:AOR used to be very much in vogue, and every time a recall RfA happened it was invariably a mess. The Wordsmith^{Talk to me} 20:48, 7 March 2024 (UTC)
7. Oppose per TLC, Daniel Quinlan and The Wordsmith. Would consider a reformulated proposal that skews toward admin retention (no auto-desysoping, higher petition roll call). StonyBrook _babble 05:23, 8 March 2024 (UTC)
8. It pains me to oppose this, since I do think we should have a recall process. I'm opposing based solely on #2. We should not subject admins to having a reconfirmation vote hanging over their head for a full year. — Rhododendrites ^talk \\ 15:04, 14 March 2024 (UTC)
9. Per Cryptic's second sentence. * Pppery * _{it has begun...} 23:09, 14 March 2024 (UTC)

Neutral (Proposal 16c)

1. Although I gave a moral support to Proposal 16, I'm starting to feel like the multiplicity of sub-proposals is getting away from the intended focus on improving the RfA process. Although I understand the logic behind saying that easier recall of unsatisfactory admins might make the granting of adminship less fraught in the first place, I also think there's a significant risk of overloading this process by taking the proposals in too many directions, resulting in nothing getting done. Using the de.wiki model as a starting point may well be a good approach, but anything like this needs a lot more working out of details before being ready for prime time. --Tryptofish (talk) 21:30, 29 February 2024 (UTC)

   Hear hear. The community has expressed desire for and discussed administrator recall for many, many years, but any effort to develop such a process seems to start with throwing down competing proposals that we expect are fully developed even though there has been absolutely no prior discussion, and then we shout at each other over procedural nitpicks for a while before everyone gets frustrated and goes and does something else. The format of this page is good for periodic reviews of established processes and proposing quick solutions for minor issues that can be implemented fairly quickly. It's not good for developing an entirely new policy and process from scratch. It's time to have a proper, separate, dedicated discussion about recall, and probably quite a lot of it, before any proposal should be voted on. Ivanvector (^Talk/_Edits) 18:17, 1 March 2024 (UTC)

   @Ivanvector I think the entire reason this RfA review has started is because people are very mad about the lack of substantive changes, and the last thing anyone wants to hear is that more time is necessary for workshopping. Mach61 01:51, 2 March 2024 (UTC)

   Well then we're going in circles. These proposals keep failing because not enough time is spent on their development, and nobody sees (or accepts) that the solution to that problem is not to continue proposing more not-sufficiently-developed proposals, but to take the time to workshop and develop one that addresses most editors' concerns. Observe that we're up to six on this page now, and the only ones remotely close to passing are the vague "we should do this" one, and this one that reads "we should copy the process a different wiki spent the time to develop". The rest aren't bad proposals, but they need to bake longer. Ivanvector (^Talk/_Edits) 21:36, 5 March 2024 (UTC)

2. Neutral. Moved from oppose.
   Oppose on the numbers suggested. Firstly, the initiation process threshold of 25 EC editors is too high. This necessitates organizing the mob before going official. Secondly, the reconfirmation threshold of 66% is too hard. Instead, the question should be whether there is a consensus to desysop. On numbers, that would imply 33% is enough to survive, however, numbers should be less important than the test by a bureaucrat of whether there is a consensus to desysop. Of course, a consensus to desysop will be much harder to achieve than to have originally disrupted a consensus to promote at the original RfA. --SmokeyJoe (talk) 05:02, 3 March 2024 (UTC)

   @SmokeyJoe I disagree that getting 25 EC editors in a month is a particularly high threshold. Consider, if you will, how many ArbCom cases wrt admin conduct get well over 25 preliminary statements in less than a week. And while I would personally prefer a lower threshold, it doesn't seem very helpful to refuse the community the ability to desysop at all because of that (especially given the lack of any alternate proposal, though even then, it makes strategic sense to support one flawed proposal so that the closers don't dismiss it for lack of quorum) Mach61 05:54, 3 March 2024 (UTC)

   Have you ever tried to corral 25 people, to sign on for a serious matter? It won't happen short of something already damaging the community so seriously that it constitutes an emergency, for which there are existing procedures. I support in principle, but oppose this as a formulation doomed to fail and make the principle look bad.

   On the other side, I would make it much harder to desysop. Easier to start the process, harder to desysop.

   I suggest seven (7) is more like a lot of people prepared to go on the record as wanting an admin desysoped, for something short of an emergency. These seven will initiate a process that will attract a huge number of people. At that point, I think is right to expect a consensus to desysop, not a failure of a consensus to promote. If such a process is to be a positive to the project, it must allow for the experience to be a learning experience, with a presumption that the accused will learn.

   With the high (25) burden to initiate, and the low threshold to desysop, this process will encourage a secret staging preparation, to hit hard and fast, and I oppose it. SmokeyJoe (talk) 07:18, 3 March 2024 (UTC)

   This would co-exist with the existing way ArbCom can unilaterally decide to desysop someone. It has worked on dewiki, and unless someone knows that similar negative effects have happened on dewiki I don't think one can presuppose that that would happen. Aaron Liu (talk) 17:01, 3 March 2024 (UTC)

3. "If it works on dewiki". Does it? On the Italian Wikipedia at least, being one of the first dozen or so users to request recall of a possibly abusive admins is like begging for an indefinite block as retaliation from the admin corp. Only the not-so-abusive administrators will ever be deflagged this way (or people will need to secretly organise off-wiki and come to the recall with the required majority pre-arranged, as SmokeyJoe says). This could work only with a secret tally. There's a mention of quartely SecurePoll runs above at #How to implement anonymous voting. There could be a quarterly poll where people could vote for the request of a recall procedure for individual sysops; above a sufficient threshold, a new RfA would be opened for them (below the threshold, the result of the vote would not be published). If an annual confirmation is desired, sysops could be randomly distributed in 4 groups so that 1/4 of the sysops are put up for vote every quarter, or it could be 1/12 if we want to be less dramatic and only give such a chance every 3 years. Nemo 13:42, 10 March 2024 (UTC)

Discussion (Proposal 16c)

• @Soni: how committed are you to making this a literal vote (using hard % cutoffs that are directly counted) - vs using something like "the ordinary RFA success standards"? — xaosflux ^Talk 14:36, 29 February 2024 (UTC)

  I am not committed to that at all. I was trying to phrase it as "usual RFA success standards" but lower thresholds, rather than convert this to a full voting process. I believe any reconfirmation process will need different thresholds from RFA, given we want to encourage admins to keep working at contentious areas.

  I'm happy to reword to make that clearer. Soni (talk) 14:43, 29 February 2024 (UTC)

• The process referred to in step 2 should be a consensus discussion/traditional straw poll, not a race to some arbitrary number of supports. An editor requesting a reconfirmation should need to convince the community that it is warranted, not just find 24 friends. Anyone who's paid any attention to AFD or any real-world controversial topic knows how easy it is to attract armies of meatpuppets to support any course of action. Ivanvector (^Talk/_Edits) 14:42, 29 February 2024 (UTC)

  For better or for worse, this proposal is committed to an unambiguous threshold process, as opposed to a full run through the "drama boards", so to speak. Either you'd get something that goes through the high voltage bickering at AN/ANI/similar, or you skip them but risk your concerns above. I'd be happy to support Proposal 16D based on community discussion, but think this has merit on its own. Soni (talk) 15:03, 29 February 2024 (UTC)

• I also would prefer if the time periods for discussion were shorter. A year is far too long: presumably any editor can propose a reconfirmation any time for any reason, and an admin so named then gets a Sword of Damocles over their head for the next year? No. Reconfirmations should be in response to particular admin conduct issues, and we ought to deal with incidents much quicker than this. We require 72 hours for sanction discussions, and even that was contentious for being too long. Ivanvector (^Talk/_Edits) 14:45, 29 February 2024 (UTC)

  Having a month to cool down can have people retract their vote. Aaron Liu (talk) 15:19, 29 February 2024 (UTC)

  Yeah, a week to get 20 or two months to get 50 seems fairer Mach61 (talk) 18:10, 29 February 2024 (UTC)

• dewiki's voter eligibility criteria, including for admin recall, contain an activity requirement. A more accurate translation of dewiki's recall criteria is at User:ToBeFree/recall. ~ ToBeFree (talk) 21:33, 29 February 2024 (UTC)

• The discussion about thresholds has been interesting, because there's a lot of people having disjoint preferences for what RRFAs could do. This proposal will not be a "one solution fits all" and will not straight up replace Arbcom-removals. The proposal was based off "25 EC editors in 1 month"/"50 EC editors in 1 year", and I continue to believe that's a good place to start RRFAs off. Happy to reconsider if another threshold is favoured by strong consensus. Soni (talk) 13:32, 4 March 2024 (UTC)

  @Cryptic, StonyBrook, and Daniel Quinlan: since all of you mentioned thresholds being different, do you have suggestions on what you'd consider fair? I was reading through File:Active_editors_on_German_Wikipedia_over_time.png and File:Active_editors_on_English_Wikipedia_over_time.png to figure out rough editor counts at every activity threshold, and it looked like enwiki seemed to be roughly 5x the editor count of dewiki for all metrics (I mostly cared about 100 edits/month as a high but still "reasonable" check for editor counts). Looking at newer stats for similarish thresholds gave me the same rough ratio.

  This does tell me nothing about how centralised/decentralised the two communities are though. Regular RFAs in enwiki get anywhere starting from 200 editors responding to it as a whole, after CENT/Watchlist etc, so a threshold closer to it may turn out fangless. I wonder though if your concerns are primarily about the RRFA's "cutoffs" like @Theleekycauldron:'s are. If so, a number closer to current but lower cutoff may be a good solution for everyone? Soni (talk) 05:45, 8 March 2024 (UTC)

  Thanks for considering the differences between de and en. I think the initial bar to getting a petition going should be set high enough to avoid a pile-on by anyone disgruntled by a recent controversial action, such as the closing of a contentious RfC or XfD. I'm not really sure what the number should be, but 50 EC editors in a month or 100 in a year sounds to me to be about right. A watchlist notice could then be sent out for an RRfA. Of course, if § Proposal 14: Suffrage requirements passes, there would be fewer editors who could participate in the !vote, but still I wouldn't want to see a desysoping become too easy a process. StonyBrook _babble 06:30, 8 March 2024 (UTC)

  @Rhododendrites Same question as above, is the year constraint the only part of it that you disagree with? I'm trying to figure out which direction the numbers should change to improve the proposal, and it doesn't seem like people have a strong preference yet Soni (talk) 20:03, 14 March 2024 (UTC)

  I looked at the stats page for RFA in dewiki and it seems that the centralisation is actually comparable. If I'm reading correctly, every successful dewiki RFA/RRFA since 2020 had at least ~150 editors !voting on it. On enwiki this number is >130 or so. I don't know which other metrics (median?) might be good to see, but it does seem like centralisation wise, enwiki should not be much larger than dewiki in terms of RFA engagement. My guess is now closer to 1x-2x instead of 5x Soni (talk) 05:05, 17 March 2024 (UTC)

• The process on Commons works fine, and it's also a large project. It's a simple process that anyone can easily understand. GMG^talk 14:44, 14 March 2024 (UTC)

Proposal 16d: Community recall process initiated by consensus

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Any extended confirmed user may begin a recall discussion at WP:AN. They must inform the administrator being discussed and must explicitly state that the discussion is to initiate a Reconfirmation RfA (WP:RRfA). Following a minimum period of seven days and a minimum !voter turnout of at least 20 users, any uninvolved bureaucrat or arbitrator may close the discussion. Any user may comment in the discussion, but only !votes by extended confirmed users will be considered by the closer. Should the minimum turnout not be reached, the discussion should be closed. An admin may have no more than one AN thread for recall opened in a three month timeframe.

Should consensus be found in favor of desysopping them, the user in question must be notified via their talk page by the closer. The user will have one month to initiate a RRfA. Like a typical RfA, an RRfA would be listed at the WP:RfA page, appear on watchlists, and be listed at WP:CENT. They may have one or more nominators or opt to self-nom, just as in a typical RfA. During this time, they may continue to use any tools included in the administrator user group.

Should they elect not to hold an RRfA, their administrator permissions will be removed. If, at a later date, they wish to regain their administrative tools, they must run through an RfA with the typical thresholds (75% automatic and 65% 'crat chat at the time of this writing). Should they choose to participate in an RRfA, it will run with lower confirmation thresholds than a normal RfA (65% for an automatic pass and 55% for a 'crat chat). Should the RRfA fail, a bureaucrat will desysop them.

An admin may not go through an RRfA until at least one year after the conclusion of their previous RRfA or RfA. Sincerely, Novo Tape^{My Talk Page} 17:17, 29 February 2024 (UTC)

For the discussion of this failed proposal, see Wikipedia:Requests for adminship/2024 review/Phase I/Closed proposals#Proposal 16d: Community recall process initiated by consensus

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 16e: Allow the community to initiate recall RfBs

Bureaucrats currently retain their permissions indefinitely, and the community itself has no means to revoke bureaucrat permissions once they are given. The only way to remove a bureaucrat is for the Arbitration Committee to open a case and rule against the bureaucrat in light of egregious conduct. There is no means to remove permissions for bureaucrats who have lost the trust of the community unless they have committed egregious or ban-worthy offenses.

If this proposal passes, the community will be able to revoke the permissions of a bureaucrat pending a new RfB. A recall will occur if a consensus is found to do so at WP:AN, similar to how community bans are currently handled. The bureaucrat will then be required to pass a new RfA to retain bureaucrat permissions.

A recall RfB may be bundled with a recall RfA’s, but are not required to be.

Benefits of this proposal would be that bureaucrats can be better held accountable for repeatedly acting against consensus, failing to abide by policy, or other serious infractions that do not rise to the level of ARBCOM. It would create a binding alternative to the currently optional recall process, which has been criticized for its inefficacy. The potential drawback is that it would limit a bureaucrat’s ability to take necessary but controversial actions that may prompt a kneejerk recall: there are ways this could be mitigated, such as requiring only a simple majority at RfB to be reconfirmed. 16:37, 3 March 2024 (UTC)

Support (Proposal 16e)

1. Support, conditional on 16 passing - it makes no sense for us to be able to recall admins but not bureaucrat, and I believe we need to explicitly state that we are permitted to do so lest failing to do so cause controversy in the future. BilledMammal (talk) 16:37, 3 March 2024 (UTC)
2. Seems consistent with having recall for admins, which is also something I support. LEPRICAVARK (talk) 23:00, 4 March 2024 (UTC)
3. Would need a lot of work to get it right. North8000 (talk) 20:12, 7 March 2024 (UTC)
4. We can recall admins, we should be able to recall 'crats as well, as 'crat abuse is likely to happen as is admin abuse. — Preceding unsigned comment added by Rusty4321 (talk • contribs) 01:01, 13 March 2024 (UTC)
5. Per my comment at Proposal 16. The bureaucrat right should be no different to adminship, autopatrolled, rollback etc. I don't anticipate much need for community removal of crats but the option should be there. — Bilorv (talk) 23:04, 15 March 2024 (UTC)

Oppose (Proposal 16e)

1. Oppose. I don't think we necessarily need to have parallel recall processes for crats as for admins, and (aside from one atypical case at ArbCom now) we really don't have problems with crats, and certainly not that ArbCom has been shown to be unable to handle. --Tryptofish (talk) 21:54, 3 March 2024 (UTC)
2. We should probably figure out a way to have more crats instead of potentially removing existing ones. – Hilst [talk] 23:09, 3 March 2024 (UTC)
3. I am more worried about the low number of current bureaucrats than the occasional bad actor, which doesn't seem to have been a problem in recent history other than the one current case request at ArbCom. QuicoleJR (talk) 23:24, 3 March 2024 (UTC)
4. Oppose This seems to be a solution in search of a problem. The Wordsmith^{Talk to me} 20:50, 7 March 2024 (UTC)
5. Solution in search of a problem. Stifle (talk) 09:07, 8 March 2024 (UTC)
6. Oppose reads to me as a solution in search of a problem. Dreamy Jazz ^{talk to me | my contributions} 23:34, 8 March 2024 (UTC)
7. Oppose as completely unnecessary. JML1148 ^{(talk | contribs)} 01:22, 10 March 2024 (UTC)
8. Oppose I don't think "trial at WP:AN" is a good way to handle this. Either 16f, or a more formalized recall process (akin to RfB) would be my preferred route. — xaosflux ^Talk 13:31, 14 March 2024 (UTC)

Neutral (Proposal 16e)

1. I support the idea of allowing the community to revoke crat permissions pending a new RfB. But I would prefer a structured way of doing that, not just WP:AN. Tim Smith (talk) 23:07, 15 March 2024 (UTC)

Discussion (16e)

@Tryptofish and QuicoleJR: I don't have any particular feelings about this proposal, but Wikipedia:Arbitration/Requests/Case/Andrevan wasn't that long ago. --JBL (talk) 00:26, 4 March 2024 (UTC)

IDK, I think 5 or 6 years is a pretty long time. QuicoleJR (talk) 00:52, 4 March 2024 (UTC)

That's correct, and I had forgotten it, but my overall rationale remains the same. --Tryptofish (talk) 23:56, 4 March 2024 (UTC)

• Unless I'm mistaken there has been one instance of a bureaucrat being removed for cause (other than inactivity) in Wikipedia's entire history, and that was 15 years ago. The records on that aren't great, though, and I can't see from that data if there have been any resignations under a cloud, and maybe the current case request will make it two, but that case is also demonstrating why Arbcom is the proper venue for this sort of thing. I wouldn't oppose development of a community bureaucrat recall process, but it's just not a problem that urgently needs solving. Ivanvector (^Talk/_Edits) 22:02, 5 March 2024 (UTC)

Proposal 16f: Require a reconfirmation RfB after X years

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Partly the same motivation in 16e above, and in some of the other proposals to narrow or eliminate the discretion zone and cratchats - bureaucrats retain their permissions indefinitely, with no means for the community to remove them unless there's misconduct severe enough for arbcom to become involved; and the current cadre of bureaucrats are nearly all ancients, with only one of the 18 having registered after 2010, and a few who have almost no interaction with the community besides participating in one or two cratchats a year.

Unlike 16b, there's few enough bureaucrats that we can schedule re-rfbs without overwhelming the process - a two-year term, for example, would average one new reconfirmation starting every 40 days. And unlike 16e, regularly-scheduled reconfirmations don't have the stigma recalls do, and severely limit the potential for retaliatory recalls following controversial-but-necessary actions.

This still has all the benefits of 16e, albeit slower, in that bureaucrats who act outside policy or against consensus can eventually be removed. It will also allow us to get new blood in the bureaucrat corps without risking making cratchats less of a pure consensus process and more of a vote (and there have already been a few that looked like the latter: discussion, then a poll, then closed according to the majority rather than trying to convince the holdouts). —Cryptic 20:12, 5 March 2024 (UTC)

For the discussion of this failed proposal, see Wikipedia:Requests for adminship/2024 review/Phase I/Closed proposals#Proposal 16f: Require a reconfirmation RfB after X years

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 17: Have named Admins/crats to monitor infractions

For Arbcom cases there are named crats clerks who oversee some aspects of the process – keeping word counts within reason, applying some discipline where necessary, etc. In a contrary position is RfA, where there is/are no named individual(s) to take responsibility for personal attacks, borderline disruption, etc. This means that when there is (for example) an uncivil oppose, there is a pile on of further comments and RFA turns into another disruptive sink.

Having a small panel of three or four named admins and crats per RfA (with a notice at the top of the RfA, similar to the notice at Arbcom) to deal with problematic behaviour would stop some of the disruption.

Support (Proposal 17)

1. As proposer - SchroCat (talk) 17:56, 27 February 2024 (UTC)
2. Seems reasonable: having someone in charge would avoid the frequent removal/restoration/moving to talk-page/restoring/etc. battles. Precise implementation details can be worked out later. --JBL (talk) 18:56, 27 February 2024 (UTC)
3. I think this might merit having the details fleshed out (noting, as below, that it's clerks, not crats, who do this for ArbCom). I could certainly see having a panel of admins who are named for this role, and that might be a good thing. Nominators should be excluded, and the panel members would not be able to support/oppose, to maintain impartiality. I'm ambivalent about having crats do it, because this probably should be a role kept separate from closing/chatting the RfA. --Tryptofish (talk) 20:25, 27 February 2024 (UTC)
4. Support. Right now, editors are free to violate almost any behavioral policy or guideline as long as it's at RFA. I'm in favor of any attempt to address this problem. City of Silver 02:21, 28 February 2024 (UTC)
5. Cratship selects for different skills than required for this. And it'd be good to have different people closing the rfa vs clerking it, simply because that seems to be one point of reluctance from crafts to clerk. Galobtter (talk) 13:58, 28 February 2024 (UTC)
6. Support. I believe this would help improve civility, enable easier enforcement guidelines and policies, help avoid diffusion of responsibility issues, and it would also be easy to trial. Daniel Quinlan (talk) 18:18, 28 February 2024 (UTC)
7. Support: in a general sense, I think we could do much more to assert/reinforce the values we claim the community to hold, particularly those of civility and collegiality. This would be a good step in that direction. UndercoverClassicist ^T·C 19:16, 28 February 2024 (UTC)
8. Makes sense. * Pppery * _{it has begun...} 01:34, 29 February 2024 (UTC)
9. Support - Assigning editors will force some moderating to happen, which I think is necessary. — ♠Ixtal ^{( T / C )} ⁂ Non nobis solum. ♠ 12:43, 29 February 2024 (UTC)
10. Per above. Aaron Liu (talk) 03:02, 2 March 2024 (UTC)
11. —Compassionate727 ^(T·C) 15:24, 2 March 2024 (UTC)
12. I'm not confident that this'll work, but it's at least worth a try (after figuring out the details, of course): psychologically I think this would make people less hesitant to do the clerking that WP:RFA2015 authorized. I don't want this to turn into "only these three people are allowed to clerk", though. Extraordinary Writ (talk) 08:50, 3 March 2024 (UTC)
13. Tentatively supportive of this idea, but the details of how it's implemented would be pretty key. There are some admins who would be eager, or have already expressed eagerness, to take on this sort of role, but whose judgment regarding what does/doesn't constitute a personal attack or incivility is not in sync with community norms. Also, per Tryptofish, nominators should be recused, and this is not an appropriate role for 'crats, who should not be involved in activity both during the nomination and in a potential evaluative discussion afterward. Grandpallama (talk) 19:28, 3 March 2024 (UTC)
14. Does RfA suffer from the bystander effect where lots of administrators all wait for some other administrator to take action? If so then this seems reasonable. Banedon (talk) 07:11, 4 March 2024 (UTC)
15. Worth a try. — Rhododendrites ^talk \\ 14:57, 14 March 2024 (UTC)
16. Worth a try. I think Arbcom is very effective at dealing with disruption, in what in theory should be a more contentious space than RfA. My guess is that this would lead to more discrete removal of PAs. I agree that vote-striking should not really be in the remit here (unless it's clear socks and all); this typically leads to more drama and I have full confidence crats disregard silly votes anyway. Practically, how would the process work? Should we have a group of volunteers on a page, and that nominators ask in advance who wants to help out with the process? —Femke 🐦 (talk) 19:05, 14 March 2024 (UTC)
17. Support, but only if the RfA "clerks" are selected at random from a list of volunteers created before the RfA. If the clerks are allowed to volunteer after the RfA starts, I could imagine several issues even if they aren't allowed to !vote; if the number of clerks is capped, there could be accusations of bias that the volunteers filled the spots just to push their views as a super-!vote (whether or not that's true), and if the number is not capped, it's no different than the current system. RunningTiger123 (talk) 18:31, 15 March 2024 (UTC)
18. Support: if this fizzles out in practice then it's no great loss to have tried, but it could work. Enormous harm to living people has been done from incivility at RfA over the last five years, as well as a serious chilling effect on more candidates standing. Crats and admins have failed to do their job of preventing and mitigating the effect of incivility and personal attacks, sometimes because they believe it is out-of-process or someone else's job. This would be one way to make somebody feel like it is their job. — Bilorv (talk) 23:10, 15 March 2024 (UTC)
19. anything that might make RfA more civil is worth trying; completely agree with Bilorv here. support with some caveats per RunningTiger123 sawyer * he/they * talk 03:13, 16 March 2024 (UTC)
20. Support. Bystander effect occurs, and happen especially when there are personal attacks or disruption coming from experienced users. 0xDeadbeef→∞ (talk to me) 06:24, 17 March 2024 (UTC)
21. Support Similarly to my reasons for proposal 2, it's a good idea to try and reduce incivility at RfA. Seems reasonable too. Rusty4321 ^{talk contribs} 15:34, 17 March 2024 (UTC)

Oppose (Proposal 17)

1. Inclined to oppose; see 01:51, 28 February 2024 (UTC) in the discussion below. ~ ToBeFree (talk) 01:57, 28 February 2024 (UTC)

1. Oppose, I think the community should reinforce that 'crats should monitor RfAs, and not ask admin to step up and do so. Z1720 (talk) 02:07, 28 February 2024 (UTC)

   I tend to agree, but there is pushback from individual crats on doing so and I think a wider pool of crats and admins spreads the workload a little more fairly. - SchroCat (talk) 09:07, 1 March 2024 (UTC)

2. We already have such oversight and all the proposal does is introduce an unclear way of limiting the pool of people who can do this. Better to remove the need by having a secret ballot so that there's no badgering. Andrew🐉(talk) 12:18, 28 February 2024 (UTC)

   We currently have pile-ons from multiple people, including admins, for where there are problematic opposes. Having a small dedicated group to oversee such problematic input stops a dubious oppose becoming a toxic pile-on. We also reduce the dramah by having only a small number of people who are the ones able to move threaded comments (although not votes) onto the talk page. - SchroCat (talk) 12:22, 28 February 2024 (UTC)

   Limiting the number of people who can intervene will tend to reduce the amount of intervention rather than increasing it. The drama might then increase rather than decrease. Andrew🐉(talk) 08:39, 1 March 2024 (UTC)

   I'm struggling to see any logic in that statement, but a trial run would show whether this is the case or not. - SchroCat (talk) 09:07, 1 March 2024 (UTC)

   SchroCat, my reading of Andrew's comment is that currently there are 18 Crats responsible for monitoring RfA, and the proposal suggests that only 3 or 4 named individuals should be responsible, so theoretically reducing the amount of people available to potentially monitor the RfA. However, the reality is that only a few Crats are willing and able to monitor an RfA in the manner the community would like, so the current system is not working. I do understand Andrew's objection; I feel that what we actually need is more Crats. New, active Crats who are tuned to the needs of todays' Wikipedia. I feel that if we had more active Crats then there would be more active and engaged monitoring of RfAs. Perhaps what we need is a proposal for more admins to volunteer to be Crats. If those named admins who would be willing to step forward to be an RfA monitor would instead step forward to be a Crat, then we wouldn't need this proposal. SilkTork (talk) 13:38, 1 March 2024 (UTC)

   Named admins can be way more than 4 in number, plus 'crats would still be able to moderate. Aaron Liu (talk) 13:55, 1 March 2024 (UTC)

   (edit conflict) Hi SilkTork. Maybe I should clarify: the 'three or four' refers to each individual RfA, rather than only 3 or 4 overseeing them every RfA (such a small number would possibly lose interest or drop off the list fairly quickly, so rotating the duties between 20 or 30 would spread the workload. I have in mind something similar to the Arbcom model: a panel of, say, 20 volunteers (a mix of Admins and 'crats), from which three or four can step up when a new RfA is being set up. I certainly agree we need more 'crats and that the existing ones should be more active there (see my response to Z1720 a couple of lines above), but the reality is that at the moment we don't have enough that are willing to do this work and would rather be active elsewhere. (I'm not sure we need a proposal for more admins to be crats, just a robust recruitment drive through the admin newsletter, or posting onto each admin's talk page(s)); I know the median appointment date for the current holders is c. 2010, and the role has changed a lot since many took on the mantle, but that's really not something that most of us on the site can alter! Cheers - SchroCat (talk) 14:01, 1 March 2024 (UTC)

3. Oppose As unnecessary and bureaucratic. I have on occasion commented that a particular thread needed to be moved to the talk page and it always has been, shortly, by a viewing admin. All a concerned party needs to do is ask! Leaky caldron (talk) 21:46, 5 March 2024 (UTC)
4. Oppose Lightburst (talk) 03:58, 6 March 2024 (UTC)
5. OpposePer the above 4 opposes.North8000 (talk) 20:16, 7 March 2024 (UTC)

Discussion (Proposal 17)

Some questions about the proposal implementation: When is the list of admins for a given RfA determined? For instance, will it be established before the RfA is launched, so it will be in place from the onset? Will there be a pool of volunteers and a rotation established? Is any admin eligible to volunteer for a given RfA? isaacl (talk) 18:05, 27 February 2024 (UTC)

A panel of interested admins/crats could be held to be called on, although any admin/crat would be eligible to volunteer at the time the RfA is either planned or once it starts. To remain neutral, they would not be the nominators and would not be able to !vote in that particular RfA. - SchroCat (talk) 18:14, 27 February 2024 (UTC)

Thanks for the responses. If the list isn't required to be present at the onset, what happens if no one volunteers? Does the RfA proceed? isaacl (talk) 18:36, 27 February 2024 (UTC)

The RfA should probably still proceed - we have admin who try to get involved from time to time, so even once it's underway, others will join in. - SchroCat (talk) 19:04, 27 February 2024 (UTC)

I suspect since any admin can still take any actions as they feel necessary without formally volunteering, there isn't much incentive to put one's name on a list. isaacl (talk) 05:29, 28 February 2024 (UTC)

Given some admins don't want to get involved in this area (using their powers in more technical areas) and some clerks crats have openly said they have no interest in doing much in the area, a list provides an initial point of contact for people to ask if they are willing and would be available for a forthcoming RfA. - SchroCat (talk) 14:05, 28 February 2024 (UTC)

Sure. Nonetheless, having a list won't provide incentive for admins or bureaucrats to get involved if they currently aren't interested (not sure what you mean by "some clerks"). isaacl (talk) 16:53, 28 February 2024 (UTC)

? There's no incentive for admins or crats to anything if they don't want to - but that's always the case for them and every other volunteer on the site. It is a step forward from having no named individuals to whom people can turn. - SchroCat (talk) 17:10, 28 February 2024 (UTC)

Having a list is a step forward only if there is a plan for how to get admins to put their names on the list. With the base assumption that admins are currently reluctant to get involved, I think the list may just remain blank. isaacl (talk) 17:16, 28 February 2024 (UTC)

I doubt it will remain blank. I have seen Admins and Crats say before that they would be prepared to step up on a named basis, but I can't find the thread now. Anyway, the only way to find out is to run it as a trial and see who signs up for it. - SchroCat (talk) 17:24, 28 February 2024 (UTC)

I don't see any harm in having a list (even if it remains blank), but we've had this discussion multiple times about getting more bureaucrats and admins involved, and there are still concerns about insufficient interest. If part of the reason is a desire to avoid becoming a lightning rod for complaints, then I don't think admins with this in mind will want to become a point of contact. I don't think it's a reasonable workload for Primefac if they're the only one putting their name onto a list over and over again. isaacl (talk) 17:41, 28 February 2024 (UTC)

I'd support an ElectCom (which is for the ArbCom elections) style system where every six months or an year the 5 people with the highest support are elected (with some backups) to be the rfa moderators. They would have the mandate to moderate RfA and only the extra authority of if there's a dispute over whether a comment/discussion should or should not be removed or moved they make the final say.

If we move towards elections every 6 months this would work well with that. Galobtter (talk) 19:02, 28 February 2024 (UTC)

Just a note regarding the arbitration process: bureaucrats aren't involved. There are clerks that handle administrative tasks like checking word counts and monitoring comments (though they will typically defer to the committee for decisions that aren't clearcut). isaacl (talk) 18:39, 27 February 2024 (UTC)

I'm not strictly against this; it may be a good idea. However, I'd oppose votes being struck for their explanation – remove the explanation if necessary, keep the support/oppose/neutral vote. Bureaucrats can then still ignore the vote (I think they shouldn't either). Also, neither the applicant nor their nominator(s) should be allowed to influence who gets to moderate the RfA, and the moderators should ideally also not be able to spontaneously become moderators in response to seeing a specific user's RfA. In the name of civility, this proposal – if implemented without the needed care and restrictions – will allow a few opinionated people to have a more noticeable influence on the RfA result than simple unmoderated votes would have had. ~ ToBeFree (talk) 01:51, 28 February 2024 (UTC)

No-one is suggesting (with this proposal) striking any !votes. That isn’t mentioned at all in the proposal. And I've already made it clear that those participating should be neutral - that is fairly obvious. - SchroCat (talk) 06:48, 28 February 2024 (UTC)

Taking "responsibility for personal attacks" was recently interpreted as including vote striking. The proposal is currently open about whether this is included and about which measures enforce the desired neutrality. ~ ToBeFree (talk) 21:50, 28 February 2024 (UTC)

Striking votes has zero to do with this proposal. You don’t like votes being struck? Then open a new proposal about it, but at the moment your oppose is not based on anything in this particular proposal and when the consensus is determined, the false rationale will be taken into account. - SchroCat (talk) 22:07, 28 February 2024 (UTC)

The proposal specifically mentions "an uncivil oppose" and "a pile on of further comments". Which of these two are meant to be affected by the proposal, and which clerk/moderator response would be appropriate? ~ ToBeFree (talk) 22:09, 29 February 2024 (UTC)

That is for others to work out. I don’t get paid enough to spoon feed all the answers. If you want to codify the allowable or banned Admin actions in future RfAs, I really do suggest you open a proposal to deal with it. Personally I am OK if duplicate votes and socks are struck, but I’m uncomfortable with others, but as I’m not an Admin, it’s not my call. - SchroCat (talk) 22:23, 29 February 2024 (UTC)

I believe the actual concern being addressed by the proposal is that administrators who could take action currently don't do so out of hesitation. So appointing named moderators is meant to make them less hesitant to perform actions. My concern is that this will lead to excessive actions that wouldn't have happened due to the hesitation before. Perhaps a voting edit will be reverted by a moderator who wouldn't have done so if they hadn't been a moderator; perhaps a comment will be removed or whatever else. All I said is that I'd oppose vote-striking as the result of this change. If it's not going to happen, that's good! It's a weak oppose based on a fear that may be entirely unjustified. We'll see if it happens or not. ~ ToBeFree (talk) 23:35, 29 February 2024 (UTC)

It happened already without named administrators. If you don’t want it to happen again, open a new proposal. - SchroCat (talk) 03:58, 1 March 2024 (UTC)

Proposal 18: Normalize the RfB consensus requirements

Reduce the successful RfB threshold from 85% to 75%

Put quite simply, there's no other area of the project that requires 85% of participants to support something for it to happen. We only have 18(!) 'crats, and we need more of them if we want robust civility clerking (for example, if we want there to be 'crats on-call for each RfA). It should be the same as RfA; I'd also support lowering it to 75% with no discretionary range.

To be clear: the standards for bureaucrats are already higher than they are for admins. This isn't making RfB as easy as RfA, the requirements are still more stringent, and RfB !voters uphold that. But if 75% of participants agree (a full 3:1 ratio) that a candidate does meet those higher standards, that is nearly always a consensus, and we should treat it like one. theleekycauldron (talk • she/her) 21:23, 27 February 2024 (UTC)

Support (proposal 18)

1. Support: this is a no-brainer as far as process. This isn't about the skills required to become a 'crat, those stay the same. We need more 'crats, and we need 'crats to be more in touch with the community. This is the simplest way to move towards that. theleekycauldron (talk • she/her) 21:23, 27 February 2024 (UTC)
2. Support. Never !voted in an RfB but 85 seems awful high per TheLeelyCauldron. Sincerely, Novo Tape^{My Talk Page} 22:32, 27 February 2024 (UTC)
3. Support. I'm intrigued by something User:Xaosflux said: "The lack of more 'crats isn't related to excessive nominees failing to pass RFB". This is true but this proposal is asking a different question: are potential nominees for bureaucratship not standing because of the high likelihood of failure? Editors should be promoted to bureaucratship a whole lot more often than the one who's gotten it the last (just about) four years. I'd like to know if the 85% standard is why this part of the project comes up so short. City of Silver 01:57, 28 February 2024 (UTC)
4. Support Per City of Silver and leeky. I fully expect the RFB process voters to continue to apply the high standards we'll like from crats anyway. I think a 75% consensus is strong enough as it is, and this proposal will be a change in the positive direction. Soni (talk) 15:40, 28 February 2024 (UTC)
5. Personally, I have long favored the es-wiki approach where admins and crats are basically the same (which also seems to work fine) but absent such a radical change, it makes sense to adjust the requirements a little. I don't think clerking is necessarily the reason for this but more crats also means more redundancy and more diverse opinions which is usually beneficial. Plus, with all due respect to our current crats, only 2 of those 18 have been editors for less than 15(!) years and only 1 for less than 10 years. It is not that unlikely that many of them will not be around as editors for that much longer. Regards SoWhy 18:53, 28 February 2024 (UTC)
6. Support - I believe we can trust that RfB voters will have a higher standard while voting than when they do so at RfA and fully agree on needing more 'crats. The lack of meaningful moderation at recent RfAs is a clear indicator of that. — ♠Ixtal ^{( T / C )} ⁂ Non nobis solum. ♠ 12:42, 29 February 2024 (UTC)
7. Support - Quoting from WP:BN " In general, the threshold for consensus is somewhere around 85%.". m:Stewards/Elections_2024 - Even Stewards do not require 85%. I'd also support a compromise of 80%. - jc37 03:40, 1 March 2024 (UTC)
8. Support There are so many nit-picky negative voters that getting to 85% is very difficult. I have seen some very qualified potential 'crats get voted down. --rogerd (talk) 02:21, 3 March 2024 (UTC)
9. Support We do not need the threshold to be higher than stewards, that is absurd. Furthermore, maybe if it was possible to succeed we would have some more people running. We have not had an RfB, successful or unsuccessful, since 2022. That is over a year since the last time somebody ran for bureaucrat. QuicoleJR (talk) 13:55, 4 March 2024 (UTC)
10. Support Lower standard could allow for more crats per rogerd and QuicoleJR. Rusty4321 ^{talk contribs} 01:03, 13 March 2024 (UTC)
11. Support (identical standards to RfA): the percentage figure and discretionary zone at RfA is designed to measure consensus. There is no need for some "superconsensus" for somebody to become a bureaucrat, just a consensus. Much more important decisions about the encyclopedia are made by consensus. RfB participants will decide on the standards that make it harder to pass than RfA (if the prevailing view is that higher standards are desirable). — Bilorv (talk) 23:18, 15 March 2024 (UTC)

Oppose (proposal 18)

1. I fail to see the necessity of this. Mach61 (talk) 21:38, 27 February 2024 (UTC)

   RfB has the same problems as RfA, except worse, and having 'crats is essential to having RfA work properly. theleekycauldron (talk • she/her) 21:39, 27 February 2024 (UTC)

2. The lack of more 'crats isn't related to excessive nominees failing to pass RFB. As far the 'need more clerks' - other proposals are already looking in to clerking options that wouldn't require being a crat at all. — xaosflux ^Talk 22:41, 27 February 2024 (UTC)
3. I agree with Xaosflux. We shouldn't be changing the criteria for crats simply because there are proposals that might, if passed, give them additional roles. --Tryptofish (talk) 00:12, 28 February 2024 (UTC)
4. Oppose - bureaucrat is a very high trust position since they push advanced buttons and there also aren't that many to scrutinize each other's work, so requiring high confidence to promote is not unreasonable. I would even support it being higher than 85%. Ivanvector (^Talk/_Edits) 16:03, 28 February 2024 (UTC)
5. I have never been convinced we need more crats, and thus see no need to make the process easier. * Pppery * _{it has begun...} 01:34, 29 February 2024 (UTC)
6. No, we need actual consensus, and reach it regularly in such matters. -- Alanscottwalker (talk) 17:11, 29 February 2024 (UTC)
7. I am not entirely convinced we need a lot more 'crats. I also haven't seen indication that the higher threshold is a problem in RfB's that happen. Eddie891 ^Talk _Work 18:31, 29 February 2024 (UTC)
8. There's a current case of a legacy bureaucrat who made three attempts to become one and whose standing is now in question. That discussion has been closed three times already which demonstrates the difficulty of getting action taken against such privilege. We therefore need to maintain high standards, rather than lowering them. Andrew🐉(talk) 08:31, 1 March 2024 (UTC)

   ... and it doesn't bother you that that person represents a full 6% of the entire 'crat corps? Unless you think that >50 admins are currently engaged in similar rulebreaking (I count two), RfB is currently worse than the "lower standards" RfA at electing trustworthy functionaries. The fact that half of our 'crats were elected before 2010, thus giving a lot of chances for legacy bureaucrats who are out of touch with community norms, is a direct consequence of the same well-intentioned "high standards". theleekycauldron (talk • she/her) 08:46, 1 March 2024 (UTC)

   I see that the case is now at Arbcom. The idea that this is extraordinary and atypical seems quite naïve. The way that other functionaries have circled the wagons to protect one of their own seems all too typical. This bothers me but so it goes. See the Iron law of oligarchy, "Bureaucracy happens. If bureaucracy happens, power rises. Power corrupts." Andrew🐉(talk) 21:44, 1 March 2024 (UTC)

   Proverbs 26:11 Hawkeye7 (discuss) 00:32, 3 March 2024 (UTC)

9. Orthogonal to the issue. ~ Amory (u • t • c) 13:08, 2 March 2024 (UTC)
10. Per Ivanvector. The general line of thinking that because we don't have enough people in a role, we should lower standards so that more people can attain that role, is flawed. I am reminded of some states' teacher shortages, which they are inexplicably addressing by eliminating certain licensing requirements (i.e., "too many current applicants can't pass the licensing exam, so we should remove the licensing exams"). Grandpallama (talk) 17:20, 3 March 2024 (UTC)
11. Oppose Not directly related to the topic of the review - RfA. This review doesn't need to consider tenuous / potential links & consequences for RfB at this stage. Postulate that this passes. Nothing else passes. So we will have modified RfB based on....nothing at all. Leaky caldron (talk) 16:29, 5 March 2024 (UTC)
12. Oppose Lightburst (talk) 03:56, 6 March 2024 (UTC)
13. Oppose A highly trusted position that doesn't need a lot of people. The rationale of the proposal seems to be that more are needed so that we can give them additional jobs. North8000 (talk) 20:19, 7 March 2024 (UTC)
14. Oppose I don't see a need for more 'crats. BilledMammal (talk) 01:06, 13 March 2024 (UTC)
15. I'm in agreement with the concerns raised above, particularly why we would want to lower the bar for a position which does not require significant membership and should rightly be deemed to have a more stringent "pass" criteria than rfa. It feels like a solution searching for a problem. Bungle ^{(talk • contribs)} 18:15, 14 March 2024 (UTC)
16. Oppose. Doesn't seem necessary. Also, there are degrees of consensus, appropriate to different positions and situations. We don't need to have the same threshold everywhere. Tim Smith (talk) 00:26, 15 March 2024 (UTC)

Discussion (proposal 18)

Nominally, this proposal isn't within the scope of requests for administrative privileges. Personally I don't feel there has been enough discussion of problems with the requests for bureaucrat privileges process to make a case that this proposal belongs with RfA proposals. I think looking at solutions for RfA-related problems is a sufficiently broad area so personally I'd rather deal with RfBs in a dedicated RfC. isaacl (talk) 01:11, 28 February 2024 (UTC)

It seems like how this is trying to relate is:

1. We don't have enough clerking at RFA's
2. Only 'crats can clerk at RFA's
3. It is too hard to become a 'crat
4. Therefore, if we make it easier to become a crat, more crats will be made, and those crats will clerk the RFA's

However, iv doesn't necessarily follow from the assumptions. I think that adjusting ii is much easier. — xaosflux ^Talk 14:53, 28 February 2024 (UTC)

I feel that step (iii) hasn't had enough discussion to establish that the underlying reasons are similar to those underlying problems with RfA. I would prefer a discussion dedicated to step (iii) in order to give it an appropriate amount of focus. isaacl (talk) 17:06, 28 February 2024 (UTC)

I may be wrong on this, but I suspect that one way to recruit more crats would be to fix RFA so that more people become admins - more admins would lead to more RFBs. ϢereSpielChequers 21:49, 9 March 2024 (UTC)

Proposal 19: Discussion-only RfAs

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I am proposing to change RfA by removing ongoing voting during the week-long RfA process. During the RfA, users can either ask up to two questions of the candidate, or provide a statement in support or in opposition of the candidate's RfA, similar to a user statement at ArbCom. Threaded discussion could also take place. At the end of one week, the RfA is closed as a discussion, and then a user vote would take place through a secret ballot process. (A possible addition may be that the admin closing the discussion may judge that the RfA has no chance of succeeding before voting starts.) This takes the two proposals above and places the focus completely on the vetting process, which users can then read before casting their vote.

Basically, there are three types of RfAs: clear supports, clear fails, and edge cases. We struggle the most as a community with the edge cases. My belief is completely separating the voting from the discussion process will actually be less stressful for the candidate, who can use the week focus on simply answering questions about their work and their interest in the admin toolset instead of having to worry about whether consensus is breaking for or against them.

Addendum: per the discussion below, the intent here is to create a process which generates a discussion that users can use to cast a vote on a timeline of the candidate's choosing, similar to something you might receive from a political party or candidate before an election in a democratic political system.

For the discussion of this failed proposal, see Wikipedia:Requests for adminship/2024 review/Phase I/Closed proposals#Proposal 19: Discussion-only RfAs

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 20: Make RFA an internal non public process

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

One of the criticisms of RFA is that the whole process is public, anyone can see it. This deters some from running, especially if they edit under their own name.

If RFAs were only visible to accounts that were extended confirmed, then it becomes an internal process, only visible within the Wikipedia community. They don't publish recordings of job interviews and driving tests on the internet, why publish RFAs?

I appreciate this would require some IT work, but the WMF can afford to employ some programmers and I believe they want to make RFA less stressful. Once an account becomes extended confirmed they would be able to see RFA pages and take part.

I appreciate that this has similarities to the proposal to limit voting to extended confirmed accounts as a side effect, but some of the opposition to that was from people who saw no benefit.

The watchlist notice would also need changing so that it only promoted RFA to extended confirmed editors.

For the discussion of this failed proposal, see Wikipedia:Requests for adminship/2024 review/Phase I/Closed proposals#Proposal 20: Make RFA an internal non public process

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 21: Reduce threshold of consensus at RfA

One commonly cited trope at RfA is that "an oppose is worth as much as three supports". This may be a reason that individual opposes get so much badgering, from the basic underlying premise that their vote is effectively worth more than yours.

Currently, an RfA requires 75% support (ie: support / support + oppose) to be usually considered successful, and 65% support to be under consideration by bureaucrats.

This proposal would reduce the thresholds to 66% and 50% respectively.

In other words, a candidate simply has to get more people supporting than opposing to be considered appropriate for adminship, and can be generally considered suitable at two-thirds majority support.

This could be considered the "Holy Grail" clause from a line in Monty Python and the Holy Grail ... "but all the decisions of that officer have to be ratified at a special bi-weekly meeting by a simple majority, in the case of purely internal affairs, or by a two-thirds majority, in the case of ...." Or, if you prefer, "strange women lying in ponds distributing swords is no basis for determining adminship".

The most recent RfA this might have made a difference is Wikipedia:Requests for adminship/Tails Wx, which might have persuaded them to continue the RfA instead of withdrawing. (Note, I opposed at that RfA). Ritchie333 ^{(talk) (cont)} 11:54, 28 February 2024 (UTC)

Support (proposal 21)

1. As proposer. I have pondered this for several years but never quite got round to codifying it into an RfC, so here we are. Ritchie333 ^{(talk) (cont)} 11:54, 28 February 2024 (UTC)
2. Support, per WP:NOBIGDEAL. In addition, proposal 16 looks set to pass, and as such I see it necessary to lower the requirements for an editor to become an admin in the first place. BilledMammal (talk) 12:41, 28 February 2024 (UTC)

   If you mean "If 16 passes, admins will have to reconfirm RFA", that could be a separate RFC than this one. ("What should be thresholds for reconfirmation RFCs"). Maybe you meant 16 implies "All RFAs could have a threshold reduction" Soni (talk) 15:36, 28 February 2024 (UTC)

3. Support lowering the "automatic" threshold to 2/3. Not happy about a wide discretionary range (66% to 2/3 would be wide enough for me). —Kusma (talk) 13:24, 28 February 2024 (UTC)

   Isn't 66% two thirds? Aaron Liu (talk) 13:44, 28 February 2024 (UTC)

   No, 66% is 33/50. Two thirds is 1/150 more than 66%. —Kusma (talk) 14:27, 28 February 2024 (UTC)

4. Having read through the RFAs that would fall in the new discretionary range, I agree. I am not extremely comfortable with a 50% discretionary range, and would be okay having further discussion on it (Maybe 55? Maybe 60?). I think a lower auto-pass could be good (I'd be happy with 2/3rds or 70%), in part because I expect the community to apply its usual standards and thresholds anyway. Soni (talk) 15:36, 28 February 2024 (UTC)
5. The problems are toxicity at RFAs and declining admin numbers, the solution is to regard adminship as NOBIGDEAL. -- LCU ActivelyDisinterested «@» °∆t° 19:58, 28 February 2024 (UTC)
6. I voted neutral above on two proposals that would make it easier to remove administrators; I would support this as a package deal with one or both of them. --JBL (talk) 22:01, 28 February 2024 (UTC)
7. Support. This is safe enough to try. If a given admin does a bad job, remove the rights. ―Justin (koavf)❤T☮C☺M☯ 22:28, 3 March 2024 (UTC)
8. Support. Carrite (talk) 13:07, 14 March 2024 (UTC)
9. We want more admins and reduce stress for candidates. This helps. 0xDeadbeef→∞ (talk to me) 06:29, 17 March 2024 (UTC)

Oppose (proposal 21)

1. 66% doesn't seem very trusted by the community. Aaron Liu (talk) 12:39, 28 February 2024 (UTC)
2. Reduce it again??? The current levels make sense per above. Steel1943 (talk) 13:22, 28 February 2024 (UTC)
3. Oppose: If only there is only 50% support, then there is 50% opposition, which demonstrates that the prospective admin does not have the trust of the community. Sweet6970 (talk) 13:53, 28 February 2024 (UTC)
4. 50% is way to low, admin candidates should not be so controversial that they have such low support. — xaosflux ^Talk 14:12, 28 February 2024 (UTC)
5. The threshold is not the problem. LEPRICAVARK (talk) 15:58, 28 February 2024 (UTC)
6. I support some loosening, but 50% is too low for me, sorry. WP governance is not RL government, and admins are not elected representatives. 50%+1 support is not a good model. Vanamonde93 (talk) 16:08, 28 February 2024 (UTC)

   dropping the thresholds to 60-70% is something I would support. Vanamonde93 (talk) 16:10, 28 February 2024 (UTC)

7. It's already too low. Those users who were promoted despite being below the then-current threshold have, without exception so far as I can remember, not turned out well. And the example RFA is particularly poorly-chosen, since the candidate afterwards admitted to lying in the answer of one of the questions. —Cryptic 16:11, 28 February 2024 (UTC)
8. This proposal doesn't reflect available statistics (mine, for example). Over quite a long time, RFAs with support below 70% have nearly always failed, regardless of crat chats and regardless of having changed the discretionary range in 2015. Arbitrarily lowering the pass percentage to two-thirds would not reflect the evident consensus. Also, lowering the discretionary range from 70% to 65% had basically no effect on promotions, thus I don't see why lowering it even further would have an effect now. Ivanvector (^Talk/_Edits) 16:11, 28 February 2024 (UTC)
9. Oppose. I don't think this idea is supported by the data. The current thresholds are reasonable and are working. Daniel Quinlan (talk) 18:32, 28 February 2024 (UTC)
10. Oppose seems like it would make controversial candidates stay in RfA for longer and have more time to get bombarded by the community. Not a way to reduce RfA hostility. — PerfectSoundWhatever (t; c) 18:34, 28 February 2024 (UTC)
11. Oppose While I like the idea of a 2/1 majority, this already exists under the current system, where 65% is technically still a pass. I don't think that a simple majority will work to get us good admins. For a simpler solution, perhaps what needs to happen is for the community to encourage the 'crats to be slightly more forgiving throughout the entirety of the discretionary zone. StonyBrook _babble 19:09, 28 February 2024 (UTC)
12. Oppose per Sweet6970 and Xaosflux. Sdkb ^talk 20:06, 28 February 2024 (UTC)
13. Oppose as written, because I feel that's too big a change in the percentages. I might actually support lowering 75% to 70% and 65% to 60%. Given that this page is so full of concerns that RfA has become too fraught, it's actually pretty reasonable to consider lowering the bar, but I don't want us to lower it too far too fast. --Tryptofish (talk) 21:09, 28 February 2024 (UTC)
14. Oppose while I could support moving to majorities on some aspects of Wikipedia governance, I do think that new admins need the support of a supermajority rather than just a majority. ϢereSpielChequers 22:51, 28 February 2024 (UTC)
15. Oppose Given recent RfAs it doesn't seem that hard to gain a large threshold of the vote if you are shown to be competent, you have to have really mucked something up to get a proportion of support votes that low. It has the possibility of approving people who are just unqualified. ᴢxᴄᴠʙɴᴍ (ᴛ) 00:22, 29 February 2024 (UTC)
16. * Pppery * _{it has begun...} 01:34, 29 February 2024 (UTC)
17. Oppose: "Consensus" is ideally unanimity, or since that may not be achievable in practice, close to it (and miracle of miracles, practical unanimity happens regularly at RfA); so no, this proposal is not consensus (certainly not in a mater of trust) and would likely warp so-called "consensus" in other areas of the project. Should we want to move to strict voting, let's do it straight out, not warp the idea of "consensus" into what is decidedly not a consensus. (Also the only time Bureaucrats dipped a smidge below 65 -- which they should not have done -- turned out very bad for the candidate and the project). Alanscottwalker (talk) 11:44, 29 February 2024 (UTC)
18. Oppose this is not the problem. SportingFlyer T·C 20:21, 29 February 2024 (UTC)
19. Oppose I feel like many Admins are already passing the threshold at levels that make the results of an election in the DPRK seem like a shellacking. I think I passed with 99-percent or something. Chetsford (talk) 02:50, 1 March 2024 (UTC)
20. Oppose: Per above. ARandomName123 (talk)^{Ping me!} 14:16, 1 March 2024 (UTC)
21. Oppose; mops are supposed to have broad community trust. Queen of Hearts talk
    she/they
    stalk 19:58, 1 March 2024 (UTC)
22. Oppose I wouldn't feel comfortable with an admin who is only supported by 66% of the community and has access to sensitive information (deleted pages, revdel) and can block users. ‍ Relativity 05:51, 4 March 2024 (UTC)
23. Oppose Broad community trust isn’t found in narrow margins. - SchroCat (talk) 06:54, 4 March 2024 (UTC)
24. Oppose per ᴢxᴄᴠʙɴᴍ - indications are that if that many people oppose, there is generally something substantial, at which point it makes sense to examine the RfA carefully. — Preceding unsigned comment added by Banedon (talk • contribs) 02:25, 4 March 2024 (UTC)
25. Oppose because a 65% raw is something like a 11/20 standardised score, and I don't think we want that? The interesting part about en.wiki RfAs is that despite the difficulty, competent people tend to do very well with near-perfect standardised scores (compared to steward elections at least). Leaderboard (talk) 17:27, 5 March 2024 (UTC)
26. Oppose I'd support a slight reduction, but 50% is far too low. -Kj cheetham (talk) 15:11, 6 March 2024 (UTC)
27. Solution in search of a problem, in my view. JavaHurricane 18:55, 7 March 2024 (UTC)
28. Oppose A slight reduction would be good so that one "sour grapes" tangent can't kill an RFA (or worrying about one scaring people off) But this is too big of a change. North8000 (talk) 20:30, 7 March 2024 (UTC)
29. Oppose this as too low, but I would support a smaller reduction to 60 and 70%. The Wordsmith^{Talk to me} 21:12, 7 March 2024 (UTC)
30. Oppose I agree with what Tryptofish said on this. Cullen328 (talk) 02:03, 8 March 2024 (UTC)
31. Oppose Any admin that sits in the 50-60 range will carry questions of legitimacy with a far too large minority. Regards, --Goldsztajn (talk) 08:39, 12 March 2024 (UTC)
32. Oppose 66 and 50 are far too low numbers for strong trust and support. Rusty4321 ^{talk contribs} 01:05, 13 March 2024 (UTC)
33. Per what I wrote below, but add to that discomfort with the idea of such low support numbers in general. — Rhododendrites ^talk \\ 14:55, 14 March 2024 (UTC)
34. Oppose - suggest a WP:SNOW close. This ain't gonna pass. Gizza (talk) 23:05, 14 March 2024 (UTC)
35. Oppose per Relativity. Rather than reducing the threshold, I would even favor raising it to 70-75%, as it was before 2016. Tim Smith (talk) 00:57, 15 March 2024 (UTC)

Discussion (proposal 21)

It would be interesting to see more examples of RfAs that would have gone another way, although this is quite difficult due to the small number of RfAs these days. I don't think there are too many that would have changed

• Wikipedia:Requests for adminship/MB (68%) - would have closed as successful. I suspect this would have gone the same way as Wikipedia:Requests for adminship/Moneytrees, in that they would have been advised to take things carefully and consider the opposition carefully. They wouldn't have quit Wikipedia as a result of the RfA.
• Wikipedia:Requests for adminship/Ifnord (withdrawn on 67%) - probably would have gone to a crat chat and closed unsuccessfully anyway
• Wikipedia:Requests for adminship/theleekycauldron (withdrawn on 66%) - would have gone to a crat chat and potentially passed. Since TLC is now an admin, all this meant is they would have become an admin sooner
• Wikipedia:Requests for adminship/Shushugah (withdrawn on 56%) - at best, would have gone to a crat chat, and probably wouldn't have succeeded anyway
• Wikipedia:Requests for adminship/Vami IV - Out of respect, I don't think we should discuss this
• Wikipedia:Requests for adminship/CASSIOPEIA (withdrawn on 69%) - might have gone to a crat chat, not sure what the result would have been
• Wikipedia:Requests for adminship/RexxS (64%) - Pretty much exactly what did happen then would have happened anyway.

There are very few RfAs that have ever ended between 50 - 65%, simply because the candidate withdraws and bails out by that point, possibly also quitting the project at the same time.

As an aside, somebody I can't stand managed to get elected US President on 46% of the vote, so 50% is far less controversial than you might think. Ritchie333 ^{(talk) (cont)} 14:25, 28 February 2024 (UTC)

John Quincy Adams did end up with ~38%, went to 'crat chat, and won! — xaosflux ^Talk 14:39, 28 February 2024 (UTC)

• Wikipedia:Requests for adminship/Jbhunley is another that comes to mind, where a productive editor essentially quit after a difficult RFA. IMHO it clearly had stronger consensus than several others that did pass even with our current thresholds, but that's neither here nor there. Vanamonde93 (talk) 16:09, 28 February 2024 (UTC)

  There's no evidence that Jbhunley quit as a result of the RfA. They had a history of month-long periods of relatively low activity before, and their most recent activity spurt ended with a major unrelated controversy. * Pppery * _{it has begun...} 20:01, 29 February 2024 (UTC)

  I don't know that a jury or a scientific peer review would buy it, but when a user stops editing within days of their RFA, and subsequently returns to make only <500 of their total of 23k edits, I find it personally convincing. Vanamonde93 (talk) 22:16, 29 February 2024 (UTC)

• I don't think elections are comparable to requests at the moment. Aaron Liu (talk) 16:27, 28 February 2024 (UTC)
• We would consider withdrawn RfAs for adminship...? Isn't the whole point of withdrawing that they no longer want to be considered? — PerfectSoundWhatever (t; c) 16:32, 28 February 2024 (UTC)

  He means that they probably wouldn't withdraw in the first place. Aaron Liu (talk) 17:47, 28 February 2024 (UTC)

  Gotcha. — PerfectSoundWhatever (t; c) 17:56, 28 February 2024 (UTC)

• Your last comment highlights the problem with the proposal, warping the idea of consensus is not the way to go: should we want an election, than lets move all in, to a vote. Also, in reality those who stay in like that, are more likely to be the subject of pro-longed discomfiting, such that in itself, it brings their judgment into question. -- Alanscottwalker (talk) 12:10, 29 February 2024 (UTC)

Proposal 21b: Slightly reduce threshold of consensus at RfA

Lower the discretionary range from 65–75% to 60–70%.

Support (proposal 21b)

1. I think 50% is too low, but two-thirds is a healthy margin that should probably be in the upper half of the discretionary range. HouseBlaster (talk · he/him) 16:54, 1 March 2024 (UTC)
2. Support for the reasons I gave in my support for 12c and my oppose for 21. --Tryptofish (talk) 22:45, 1 March 2024 (UTC)
3. Support A small change. Reduce the possibility of one negative tangent derailing an RFA, and fear of such by potential candidates. North8000 (talk) 20:32, 7 March 2024 (UTC)
4. We want more admins and reduce stress for candidates. This helps. 0xDeadbeef→∞ (talk to me) 06:30, 17 March 2024 (UTC)

Oppose (proposal 21b)

1. Per my reasons given at #Proposal 12c: Lower the high end of the bureaucrats' discretionary zone from 75% to 70%, which is pretty much half of this proposal. Aaron Liu (talk) 03:07, 2 March 2024 (UTC)
2. Oppose. It may be worth revisiting the discretionary zone in a year or two depending on the result of this RfC (since proposals like #3 may lower the average amount of support), but under the present system I think 65–75% is as low as we should go. I have yet to see an candidate fail post-WP:RFA2015 who I thought had the trust and confidence of the community, and that's what really matters. Extraordinary Writ (talk) 04:55, 3 March 2024 (UTC)
3. Oppose per Extraordinary Writ. ‍ Relativity 06:02, 4 March 2024 (UTC)
4. Oppose Lightburst (talk) 03:53, 6 March 2024 (UTC)
5. Oppose because it is a slippery slope that will not lead to any improvement. StonyBrook _babble 02:05, 8 March 2024 (UTC)
6. Oppose Anything close to 2/3 is already veering well away from consensus. We don;t necessarily need overwhelming consensus, but it is far better that admins begin their work with as a high a level of legitimacy as possible, reducing the threshold cuts back on that overall legitimacy. Regards, --Goldsztajn (talk) 08:35, 12 March 2024 (UTC)
7. Oppose for the same reasons, I put forth above in 21. -- Alanscottwalker (talk) 21:41, 12 March 2024 (UTC)
8. Oppose this is not the problem we are trying to solve. SportingFlyer T·C 22:52, 12 March 2024 (UTC)
9. Repeatedly lowering the bar for support in reaction to increased expectations seems like it could just raise expectations (or make people err on the side of opposing when on the fence). — Rhododendrites ^talk \\ 14:53, 14 March 2024 (UTC)
10. Oppose per Goldsztajn. Rather than lowering the range, I would even favor raising it to 70-75%, as it was before 2016. Tim Smith (talk) 00:47, 15 March 2024 (UTC)
11. Oppose per SF; not the problem. Queen of Hearts ^she/_they^talk/_stalk 04:42, 16 March 2024 (UTC)
12. Oppose I think the current values are sufficient. — xaosflux ^Talk 20:00, 16 March 2024 (UTC)

Proposal 22: Change the name from RFA to "Nominations For Adminship"

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

The people that we really need are the capable "I'm willing to serve" people rather than the "I want this" folks. RFA has an "I want this" atmosphere / basis, a basis and environment that the "willing to serve" folks are often unwilling to go into. Also, it puts the crowd and conversations at RFA into a "you are asking for this, you'll need to fight/grovel/beg for it" mode. Changing the name to "Nominations For Adminship" would shift the psychological ground in all of these areas.North8000 (talk) 15:29, 29 February 2024 (UTC)

Names and words in titles are very powerful and influential in Wikipedia, including for the common shortcuts. For example the widely used word "Onus" (WP:Onus) does not exist in policy, Wikipedia:Tag teaming exists only as a redirect to an essay And so the word "request" in RFA. North8000 (talk) 14:27, 7 March 2024 (UTC)

For the discussion of this failed proposal, see Wikipedia:Requests for adminship/2024 review/Phase I/Closed proposals#Proposal 22: Change the name from RFA to "Nominations For Adminship"

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 23: All Admins are probationary for first six months

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

I'm resurfacing an idea I advanced in 2021 [4]. Namely, all Admins are on probation for the first six months of their tenure. During this period, the Admin will be subject to a compulsory binding recall process using a to-be-determined formula if such a recall process is initiated. If the administrator is not recalled within 180 days, the probation is lifted and the current status quo with respect to recall processes (voluntary) resumes.
This would significantly lower the stakes of RfA and make RfA less of a life-or-death struggle. Chetsford (talk) 03:08, 1 March 2024 (UTC); edited 16:48, 1 March 2024 (UTC)

A point of clarification: There seems to be some confusion that I'm suggesting all new Admins must go through RfA a second time after six months. This is not the case. All this is, at the end of the day, is Proposal #16 with the restriction that community-initiated recall is only binding on an Admin in the first 180 days after they are sysoped (the "probationary period"). After 180 days, Admins can voluntarily expose themselves to recall or not at their discretion (identical to the status quo), but it ceases being compulsory. Chetsford (talk) 16:44, 1 March 2024 (UTC)

For the discussion of this failed proposal, see Wikipedia:Requests for adminship/2024 review/Phase I/Closed proposals#Proposal 23: All Admins are probationary for first six months

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 24: Provide better mentoring for becoming an admin and the RfA process

I am proposing to expand the mentoring options available for users considering putting their hat in for the mop.

My general idea is to provide an additional process for mentorship besides the optional candidate poll by creating a separate, distinct process which would feature the following:

• structure the RfA poll to make the user provide more information on why they are interested
• time when the feedback will happen, perhaps annually or bi-annually, and promote it to allow as much feedback as possible
• start promotion the week before as a call for people potentially interested in being admins to express their interest publicly
• use a support/oppose/unsure system instead of a 0-10 poll
• moderate it to keep things as civil as possible. Unlike an RfA, this would be a chance for someone who would oppose to have an honest discussion directly with the candidate. I think you would probably have to disallow directly responding to other users in a threaded manner.

I've noted above I believe the problem we're trying to solve here are the edge cases, the candidates who either don't fail so spectacularly or aren't complete shoo-ins, because the community can get very difficult about deciding what conduct is and is not disqualifying when vetting a candidate.

Right now my two biggest reasons for not wanting to be an admin are that I don't want to do anything which might increase my time spent on here and that I don't want to go through an RfA. Right now, the only real way of getting public feedback is through the optional poll, which is often poorly attended, and feedback not necessarily helpful.

Changing the way we do admin intake to make it more conversational and collegial before an RfA is even started should help candidates understand what they are "up against" when being formally vetted.

Support (Proposal #24)

1. Support as proposer. SportingFlyer T·C 23:22, 1 March 2024 (UTC)
2. Support as a general concept. The details will need more work, but guidance is clearly a good thing. --Tryptofish (talk) 22:03, 2 March 2024 (UTC)
3. Support as a general concept. The details will need more work. North8000 (talk) 20:35, 7 March 2024 (UTC)
4. Support, why not? – Hilst [talk] 13:07, 10 March 2024 (UTC)
5. Support as a general concept. The details will need more work. I'm the third person who said this verbatim, proving it's all a conspiracy. Queen of Hearts ^she/_they^talk/_stalk 04:45, 16 March 2024 (UTC)
6. Support as a concept per Queen of Hearts. Specifically, I would propose that the 0-10 poll system be retained. For this specific application, I think it makes the most sense. JML1148 ^{(talk | contribs)} 05:44, 16 March 2024 (UTC)
7. Support in principle. I think WP:ORCP has a way of helping your confidence and reducing stress. Like many other things, it is considered bad because you are telling people that you want to become an admin publicly. What's wrong with wanting to be an admin for a cool project that is of Wikipedia? 0xDeadbeef→∞ (talk to me) 06:34, 17 March 2024 (UTC)

Oppose (Proposal #24)

1. I have nothing against "better mentoring" in the abstract, but this particular proposal seems to just be for a supercharged version of WP:ORCP, and I don't see how that would help. There's a good reason experienced nominators encourage candidates to avoid ORCP: it has a way of digging up problems (real or perceived), putting them effectively on the candidate's permanent record, and worsening the prospects of an eventual RfA. The proposed system would just exacerbate this problem by making the poll an even bigger deal. As always, the best advice for a potential candidate who wants to understand what they are "up against" is to go to Wikipedia:Request an RfA nomination, find an editor you respect, and send them an email asking for an honest evaluation of your chances. Extraordinary Writ (talk) 07:49, 13 March 2024 (UTC)

Discussion (Proposal #24)

I suggest just making this a new proposal from scratch, leaving aside the current optional RfA candidate poll. It serves a very specific, lightweight purpose. Perhaps it would no longer be necessary with a new proposal in place, but I think it's better not to couple the adoption of one to the end of the other. (Note numerical scores are no longer a focus in the current process of the optional poll.) isaacl (talk) 23:30, 1 March 2024 (UTC)

Regarding currently available methods for reliable feedback: anyone can ask someone they trust for feedback. Receiving it in private can also allow it to be more frank, but also due to the personal, one-on-one nature, it might also be given in a more sympathetic manner (though that will depend on the individual). isaacl (talk) 23:34, 1 March 2024 (UTC)

Well, yes - that's how a lot of nominations occur, I would think. But that creates the challenge that you may not get the feedback you need, which could potentially lead to stress. To your first point, given this is directly related to RfA reform, I don't see any problem with leaving it here as it would serves a purpose as sort of a "pre-RfA." SportingFlyer T·C 23:38, 1 March 2024 (UTC)

I'm not suggesting to move the proposal. I'm saying don't call it a reform of the optional RfA candidate poll. Let the proposal stand on its own, and as a separate matter, interested editors can discuss the poll. isaacl (talk) 23:43, 1 March 2024 (UTC)

Good call, I've made some small edits. SportingFlyer T·C 23:45, 1 March 2024 (UTC)

It sounds like you are suggesting to have a review discussion that is similar to the current RfA process, but without threaded discussion and with moderators keeping the discussion focused on constructive dialogue. ("Mentoring" is generally a focused relationship with a small number of mentors, not an open crowd.) But then the editor and community would have to go through the similar RfA process to actually request administrative privileges. I'm not sure how much incentive potential reviewers would have to participate in the review, since it doubles the amount of discussions to follow. Plus, I think there's a risk that, similar to the admin nominators WikiProject, a lot of editors would not want to discourage good editors by pointing out their shortcomings. Perhaps an open call for privately submitted feedback would work better at casting a wide net for feedback. isaacl (talk) 23:54, 1 March 2024 (UTC)

Perhaps I've made it sound too formal? There's two goals here: provide a venue for users to publicly disclose possible interest in being admins, provide the opportunity for structured feedback, and to set it at a specific time or times each year in order to increase the number of users who participate in giving feedback. I'd love to know what my odds were before going to RfA if I ever decide to go for it. Also, I'm not sure I would privately oppose someone. Perhaps I might anonymously. SportingFlyer T·C 00:16, 2 March 2024 (UTC)

The moment you wrote "structured feedback", "moderate", and "specific time or times", you introduced the need for volunteers to co-ordinate and manage the process, which necessarily adds formality. There are existing ways to disclose interest. When you say you'd like to know your odds, do you mean you want to have a trial run? I feel your proposal boils down to this. Other aspects seem more like an individual choice; I'll follow up on your talk page. isaacl (talk) 01:09, 2 March 2024 (UTC)

Proposal 25: Require nominees to be extended confirmed

I'm proposing to make extended confirmed a formal requirement for admin candidates. Currently, the RfA page is already extended protected, so non-EC editors need to ask for somebody else to transclude their nomination (per a 2017 discussion). By streamlining this, we can slightly reduce the wall of text at WP:RfA. Furthermore, with admin elections (proposal 13) on course of gaining consensus, we may succeed in lowering the bar for nominees. This also raises the risk of a new editor wanting to apply with no chance of passing. Preventing them from asking to be nominated will avoid some discouragement. —Femke 🐦 (talk) 08:46, 2 March 2024 (UTC)

Support (Proposal #25)

1. As proposer. —Femke 🐦 (talk) 08:46, 2 March 2024 (UTC)
2. Support. Sure. Should save experienced editor time and make it easier to close WP:TOOSOON nominations. –Novem Linguae (talk) 08:52, 2 March 2024 (UTC)
3. Support. Reasonable incremental improvement. MER-C 11:14, 2 March 2024 (UTC)
4. Support, with reducing the wall of text being a large benefit. In an extraordinary case, the extraordinary nonEC candidate will know how to ask for assistance. —SmokeyJoe (talk) 11:19, 2 March 2024 (UTC)
5. Support per Novem Linguae. It's practically impossible for non-EC candidates to pass RfA under current admin expectations (or even past expectations), so this wouldn't change anything except for making the standards clearer. Liu1126 (talk) 11:50, 2 March 2024 (UTC)
6. Support regardless of whether the other proposal passes or not. The current system is already a difficult one for non-EC editors from passing anyway. – robertsky (talk) 12:59, 2 March 2024 (UTC)
7. Sure. Aaron Liu (talk) 13:14, 2 March 2024 (UTC)
8. —Compassionate727 ^(T·C) 15:25, 2 March 2024 (UTC)
9. Sure, the current "it's protected but actually anyone can still be an admin" is a weird compromise not reflective of reality. Galobtter (talk) 15:38, 2 March 2024 (UTC)
10. Seems good to me. GrayStorm^{(Talk|Contributions)} 15:47, 2 March 2024 (UTC)
11. Sure. Vanamonde93 (talk) 17:07, 2 March 2024 (UTC)
12. As explained in the proposal. ~ ToBeFree (talk) 17:31, 2 March 2024 (UTC)
13. Support considering this is likely a de facto requirement for users who want to pass RfA. Dreamy Jazz ^{talk to me | my contributions} 17:38, 2 March 2024 (UTC)
14. Support, as codifying the reality of RfA. Giraffer (talk) 18:56, 2 March 2024 (UTC)
15. Support already the de facto norm. — PerfectSoundWhatever (t; c) 19:15, 2 March 2024 (UTC)
16. Support Cuts down on the amount of rules text needed without actually meaningfully changing the status quo. QuicoleJR (talk) 20:32, 2 March 2024 (UTC)
17. Support. My initial reaction was to wonder why this would be needed, but the given rationale actually makes good sense to me. --Tryptofish (talk) 22:07, 2 March 2024 (UTC)
18. Support per Liu1126. ❤HistoryTheorist❤ 02:32, 3 March 2024 (UTC)
19. Support Seems like a logical step to what is effectively already expected of candidates (ie WP:TOOSOON). Callanecc (talk • contribs • logs) 02:54, 3 March 2024 (UTC)
20. Support Just makes sense to be clear about what is already a universally-held expectation among Wikipedians. —Ganesha811 (talk) 06:04, 3 March 2024 (UTC)
21. Support don't see any issue with this. Ratnahastin (talk) 06:52, 3 March 2024 (UTC)
22. Support; why not? Toadette ^{(Let's discuss together!)} 08:32, 3 March 2024 (UTC)
23. Support It will only affect a couple of noms a year at most, but it will save people time in having to deal with those at least. - SchroCat (talk) 09:24, 3 March 2024 (UTC)
24. Support, if you cannot !vote then you should not be able to !run.--☾Loriendrew☽ ☏(ring-ring) 15:21, 3 March 2024 (UTC)

    To clarify, you can vote if you're not extended confirmed now. Only the main RfA page is extended protected. Individual RfA pages are not. With admin elections we'll likely define some stronger criteria for voting to avoid gaming however. —Femke 🐦 (talk) 16:24, 3 March 2024 (UTC)

25. Support - it's already effectively an unwritten rule as it is, so it might as well be a formal one. --Sable232 (talk) 15:30, 3 March 2024 (UTC)
26. Support with the understanding that any candidate that is found eligible under this minimal (to my mind) requirement also has extensive (a lot more than EC) experience on some other wiki. StonyBrook _babble 17:11, 3 March 2024 (UTC)

    Why should inactivity on other wikis preclude adminship on enwiki? Aaron Liu (talk) 17:14, 3 March 2024 (UTC)

    To clarify: While I am happy to support this proposal, I would prefer that a candidate have at least one year and 5,000 edits to be considered for adminship (10x more than EC). Under this scenario, the additional requirement could be satisfied via activity in another wiki, even though EC had only been attained here. While I am still on the fence regarding Proposal 13, having this as the yardstick would make it a whole lot easier for me to support admin elections. I just don't see how anything less could provide the background that would be necessary for the proper implementation of the tools. I checked a few random examples from noms within the last ten years or so and couldn't find anyone who passed with anything lower, although I concede there might be. StonyBrook _babble 20:06, 3 March 2024 (UTC)

27. Support - it's extremely unlikely that a non ECP user could possibly succeed at an RFA. Animal lover |666| 18:43, 3 March 2024 (UTC)
28. Support WP:SNOW nominations like ones from new editors just waste everyones time so its better if we just prevent them from happening in the first place and save every one a lot of trouble. — FenrisAureus ▲ (she/they) (talk) 03:22, 4 March 2024 (UTC)
29. Support. EC exists because it demonstrates someone who has made a serious commitment to Wikipedia. I don't think any user would reasonably expect to get the mop on the 301st edit, but I was surprised to learn that this restriction is not formally in place already. Daniel Case (talk) 03:42, 4 March 2024 (UTC)
30. Yes. As far as I'm aware, we only had one non-EC user granted admin rights, they only wanted to edit I want to say one page or one filter, and they had tons of experience from another wiki already. (Anyone have the link to that rfa?) Unless we have another situation like that again, there's no reason why someone who's not EC would be qualified for adminship. ‍ Relativity 05:41, 4 March 2024 (UTC)

    This one? Perfect4th (talk) 05:45, 4 March 2024 (UTC)

    @Perfect4th: Yes, thanks ‍ Relativity 05:47, 4 March 2024 (UTC)

    In that case, they only wanted to edit the spam blacklists. But my point still stands. ‍ Relativity 05:48, 4 March 2024 (UTC)

31. Support This should help reduce the SNOW closes. Nobody (talk) 10:35, 4 March 2024 (UTC)
32. Support Won't cause any harm. Ritchie333 ^{(talk) (cont)} 15:06, 4 March 2024 (UTC)
33. Support This will be the first time I have ever been in favor of making RfA more restrictive, but this seems like a reasonable restriction, because I can't think of any users who don't have EC who's RfA would succeed. --rogerd (talk) 19:40, 4 March 2024 (UTC)
34. Support seems obvious. LEPRICAVARK (talk) 22:53, 4 March 2024 (UTC)
35. Support. Sure. I remember being in opposition of the original EC protection of RfA, but it hasn't caused any harm and this is the clear continuation of that. Anarchyte (talk) 09:31, 5 March 2024 (UTC)
36. Support for all reasons previously stated by others. Chetsford (talk) 19:08, 5 March 2024 (UTC)
37. Support per WP:NOTNOW,WP:SNOW. Also won't cause harm. Reasonable restriction. Rusty4321 ^{talk contribs} 21:32, 5 March 2024 (UTC)
38. Support Straightforward. Leijurv (talk) 00:52, 6 March 2024 (UTC)
39. Support It's already a de facto requirement if you want to pass, so let's make it official. Exceptional cases can apply for XC first at WP:PERM. —pythoncoder (talk | contribs) 03:40, 6 March 2024 (UTC)
40. Support sensible move, even if it's not the largest problem with RFA process. Joseph2302 (talk) 14:49, 6 March 2024 (UTC)
41. Support I don't think it'll make much difference, but a very slight improvement is better than nothing. -Kj cheetham (talk) 14:56, 6 March 2024 (UTC)
42. Support Saves a lot of community effort and the embarrassment of a failed RfA from an overzealous new editor. DarmaniLink (talk) 15:51, 6 March 2024 (UTC)
43. Support, de facto required already and I'm always in favour of simplifying instructions. the wub "?!" 18:28, 11 March 2024 (UTC)
44. Shorter instructions is better. I'm sympathetic to the idea that "anyone can run to be an admin" is in line with the fabled "wiki way" but practically speaking, it's a fiction. — Rhododendrites ^talk \\ 14:49, 14 March 2024 (UTC)
45. Nobody who is not extended confirmed will ever pass RfA. * Pppery * _{it has begun...} 23:11, 14 March 2024 (UTC)
46. the opposes aren't terribly convincing to me; i think the proposal would increase clarity & making the instructions shorter is good. sawyer * he/they * talk 02:43, 16 March 2024 (UTC)
47. Support. AFAICT, the only non-ECs to succeed were the ones before EC existed. In the rare circumstances, we can always grant them EC. Queen of Hearts ^she/_they^talk/_stalk 04:47, 16 March 2024 (UTC)
48. Support. This seems like exceedingly common sense. BD2412 T 02:56, 18 March 2024 (UTC)

Oppose (Proposal #25)

1. Oppose more ECR gatekeeping. EC is meant for abuse mitigation, and this is not that. There used to be advice (maybe there still is) that accounts with fewer than about 3,000 edits will have a rough go of RFA, and we very quickly close nominations that are clearly not ready anyway and at a much lower threshold than EC, so either way this change is functionally meaningless. It will just lead to more EC gaming, and have zero benefit. Ivanvector (^Talk/_Edits) 13:58, 4 March 2024 (UTC)
2. Oppose, WP:SNOW nominations of people below EC don't seem to be a major issue, and taking the risk above (more WP:GAMING) isn't worth it just to use this as a preventative measure. NotAGenious (talk) 18:26, 4 March 2024 (UTC)

   In my opinion, SNOW of people below EC is likely to deter eventual administrators. However, there is one subset of new users who are much less likely to be next year's administrators, and that is the users who will GAME the system - and these will almost certainly lose. Animal lover |666| 17:25, 12 March 2024 (UTC)

3. Oppose, preventing non-ec noms is not a problem that needs solving. Lets not try to use a needle to kill a tiger. Sohom (talk) 01:52, 5 March 2024 (UTC)
4. Oppose under the "Lustiger seth" clause. Once in a great while there is a candidate worth appointing with great global experience, and we can trust participants to separate those from the normal NOTNOW no-hope filings without this formal rule. Courcelles (talk) 16:35, 5 March 2024 (UTC)

   and for such situations we can just have them request ECR at RfP Aaron Liu (talk) 17:37, 5 March 2024 (UTC)

5. Oppose because, realistically, XC is way too low a bar, and it would just set up an expectation for new editors that "once I reach 500 edits and 30 days I can become an administrator!" This would likely lead to an increase in disastrous RfAs and editors feeling discouraged and leaving the project. WP:RFA study doesn't show anyone passing RfA with less than 5000 edits and 1 year of tenure, and I don't recall any successful RfAs in the last 5 years with less than 10,000 edits, so why should we pretend that 500/30 is enough? --Ahecht (TALK
   PAGE) 15:48, 6 March 2024 (UTC)

   It's not pretending that it's enough, it's establishing it as a minimum barrier. Aaron Liu (talk) 17:24, 6 March 2024 (UTC)

   We can also write something along the lines of "ECP is not nearly enough for users to have any real chance to succeed; it's merely the absolute minimum to be allowed to try." Animal lover |666| 17:32, 12 March 2024 (UTC)

6. Oppose As a practical matter, this already exists and the rare situations affected are easily handled. Formalizing it would give the mis-impression that XC is somewhat the experience threshold. North8000 (talk) 20:40, 7 March 2024 (UTC)
7. Per Ivanvector, Ahecht. Just increases confusion. Nemo 13:24, 10 March 2024 (UTC)
8. Oppose since this doesn't solve anything meaningful. Extended-confirmed protection is just intended for anti-abuse measures, and WP:RFA is already under ECP anyway. Reaper Eternal (talk) 20:55, 18 March 2024 (UTC)

Neutral (Proposal #25)

1. I mean, it does just make sense – the community zeitgeist is not coming back down to 500 any time soon. (There were extraordinary circumstances where non-ECR editors get adminship, but they usually involve circumventing RfA anyway.) However, all of the SNOW RfAs I can find as of recent are ECRed users self-nomming – since RfA is already ECPROTed, the only thing this would prevent is users who are not ECRed getting nominated by users who are, and I don't see any examples of that (because by the time you know how to and want to nominate someone else for adminship, you know not to do that for people who aren't ECR). theleekycauldron (talk • she/her) 20:31, 4 March 2024 (UTC)

Discussion (Proposal #25)

Regarding the current extended-confirmed protection without making it a formal criterion for candidacy: as I recall, when it was discussed, one reason was to allow for editors with extensive track records on other WMF wikis to remain eligible. isaacl (talk) 17:19, 2 March 2024 (UTC)

Ah, that's an interesting point – If a need for this actually arises, I think we'd just manually grant extended confirmation. This is where the proposal differs from one that makes "30/500" a requirement. ~ ToBeFree (talk) 17:59, 2 March 2024 (UTC)

I think we can say, with zero exceptions, that any user who is hasn't reached 30/500 and has no basis to convince an administrator to grant him ECP early, won't pass an RFA. Users with extensive track records on other WMF projects would probably have little difficulty in convincing an administrator. Animal lover |666| 18:46, 3 March 2024 (UTC)

Can things snow closed as accepted? If so, I think this should be closed in that manner. This has more unanimous support than some snow closed proposals had unanimous opposition (minus the nom's vote). GrayStorm^{(Talk|Contributions)} 02:42, 3 March 2024 (UTC)

You're looking for WP:AVALANCHE (which is under SNOW)Wikipedia:Snowball clause § Avalanche. Though one should probably implement that on the RfA page. Aaron Liu (talk) 03:02, 3 March 2024 (UTC)

As I discussed at that page's talk page, let's not introduce a new jargon term, particularly not one that no one uses. isaacl (talk) 03:05, 3 March 2024 (UTC)

In my view, we should not be ending discussion early on proposals before at least a few days of discussion, as I discussed on the 2024 review talk page. There isn't much down side to letting productive, active discussion continue, and to avoid people later arguing about discussion being closed too early, would rather just let the conversation come to a natural end. isaacl (talk) 03:03, 3 March 2024 (UTC)

Seconded, we're not in a hurry and giving it a few more days won't hurt anyone. —Ganesha811 (talk) 06:05, 3 March 2024 (UTC)

Okay, but this is rearranging deck chairs on the Titanic ~ Amory (u • t • c) 18:40, 3 March 2024 (UTC)

Proposal 26: Have the admin corps select its own members

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

• Executive summary. Just what the title says. Everything else is arguments and details, but the key point is in the first two paragraphs.

Close to 100% of functional large organizations have promotions given by a boss, often with discussion/approval of other bosses and/or the bosses boss etc. (I would suppose). Close to 0% percent have promotions have promotions given by public discussion vetting by all the employees (with no veto power by the boss(es)).

Most of these organizations by far exist to make profit. Making profit is very much enhanced if your internal organization, and the procedures for maintaining it, work well. If the latter method worked well, it would tend to increase profits. Therefore you would see it used in a non-negligible number of functional large organizations, which number would tend to increase over time. That is how it tends to work with large organizations in our system, period.

"Doing what basically every other large successful organization in the free world does" is certainly something to look at closely, n'est-ce pas? Sure we're different -- nonprofit, with article content crowd sourced to volunteers, which works very well, altho crowd-sourced management doesn't seem to -- but I'm sure Goodwill Industries or the Red Cross and so on use a basically similar paradigm. We are an encyclopedia publishing house. We are not the Hog Farm or the Oneida Community. The public lemon-squeezing adoration/flagellation system has got to go. It is horrible, cruel sometimes, and not working that well. When you deselect for sensitive people, you are going to get insensitive people. We have enough of these already in the admin corps and its not getting better.

Howevvvver...we don't have bosses. Well, not exactly, but the admin corps does a number of boss like things -- firing people, and a number of others. They're kinda-sorta the bosses. And (important!) They are supposed to be the best of our best -- vetted as being the most experienced, honest, intelligent, thoughtful, and so on. Who better to decide who they want to promote into their ranks.

Also important -- politics is everywhere (including here of course) and politics is the art of the possible. The admin corps might go for this, big time. There are a number or proposals that are just not going to fly. The admin corps is made of humans, and I don't think are ever going to allow admin recall even if they themselves are grandfathered in, and some of these other also, and at the margins they have ways to pretty much make this stick. And significant enthusiasm on the part of the admin corps would be a huge boost for this proposal. Some people do tend to follow those they consider to be our best and brightest, and some people tend to follow leaders.

The admin corps would go for it I believe because would give the admin corps more power. Who doesn't like that. Also more work, sure, but the work could be mostly given to a small group of admins (there would be plenty volunteers), with whatever oversight from the corpse general that they like. The could all vet on their Discord server or mailing list or whatever they use; all this'd be up to them.

Optional: the admin corps could also be empowered to remove members. Let's not consider that right now, we've got enough to ponder with just what I've laid out here. Herostratus (talk) 21:03, 3 March 2024 (UTC)

For the discussion of this failed proposal, see Wikipedia:Requests for adminship/2024 review/Phase I/Closed proposals#Proposal 26: Have the admin corps select its own members

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 27: Introduce training/periodic retraining for admins

As the title says, we need better training for admins. Especially around accurate deletion tagging as we've had a few candidates fail because their deletion tagging looked heavy handed to many !voters.

Fifteen years ago I did User:Filll/AGF Challenge 2 Directions I think that's not been maintained for quite a few years, though some of it still looks good to me..

My hope is that some candidates would do the training before RFA and either hold off till they'd got better scores or do better at RFA. It may even give some the confidence to run. More importantly, the admins who get desysopped are often people who've been around for years and drifted away from community norms. If we had proper training modules and periodic retraining then one hopes that drift would become rarer and community confidence in admins would rise.

Why does this relate to RFA, well it is at least as relevant as all the recall options.

Support (Proposal #27)

1. As nom ϢereSpielChequers 22:00, 3 March 2024 (UTC)
2. Support, pending some details getting worked out. I can see arguments for doing it before RfA, or just after a successful RfA, and I'm not sure which is better. As for periodic refresher courses, this has the potential to do good, particularly as a way to avoid desysopping after a mistake, but it also might need to be optional for admins who are doing well and don't feel that they need it. But sharing best practices is inherently a good thing. --Tryptofish (talk) 22:16, 3 March 2024 (UTC)
3. Support - yes, some form of "admin school" and/or new admin onboarding is needed. The way we do it now is we give all of the tools immediately to the successful candidate, and except for a few processes that have instructions there's basically no documentation, so new admins are expected to learn by trial and error. Some admins might offer to mentor a new admin, and there are the noticeboards for asking questions, but this should be formally standardized at least for the most common things like page protection, deletion, blocks, and so on. New admins should all get the same sort of basic "Admin 101", and maybe pass some sort of basic exam. Just like the recall/reconfirmation proposals this needs a lot more working out, but I support the idea. Periodic retraining I'm not as sure about - we have had a handful of issues with long-inactive admins returning and not being up to date with the evolution of community expectations, but I think this would be better solved by merging this education process with the inactivity procedures (i.e. an inactive admin is expected to re-test before getting the tools back) rather than periodically re-testing all admins. Ivanvector (^Talk/_Edits) 14:30, 4 March 2024 (UTC)
4. Support We need better admin intake before an RfA is even launched. I'm not sure retraining would necessarily be helpful, but anything to help create a pathway would be great. SportingFlyer T·C 18:18, 5 March 2024 (UTC)
5. Support This can only help with keeping people effective as admins. ᴢxᴄᴠʙɴᴍ (ᴛ) 21:26, 5 March 2024 (UTC)
6. Support Wikipedia is different to what is was 15 years ago, when large numbers of admins started. Making it easier for people, particularly those who are inactive for a while and then return, to re-adjust/keep up seems like a good idea. Joseph2302 (talk) 17:02, 6 March 2024 (UTC)
7. Support Some form of CPD process for Admins? Sure. I'm sure there are some that get deeply involved in a narrow area, but don't 'get' a different area and sometimes make a mistake. This could be beneficial, although a formal training regime can be time-consuming to set up and keep up to date. - SchroCat (talk) 20:28, 7 March 2024 (UTC)
8. Support in principle, very good idea. Concur with SchroCat, some type of CPD-lite ... CLE/CC for the non-antipodeans ... professional development for the non-lawyers! Does not need to be heavy, a series of modules, refreshers - even simple strategies/best practices on dealing with drama etc. Regards, --Goldsztajn (talk) 01:00, 11 March 2024 (UTC)
9. Support the idea, even if the details will need fleshing out a bit. The m:WikiLearn platform might be suitable for this. the wub "?!" 19:56, 11 March 2024 (UTC)
10. Support as a 100% optional set of reading pages etc. However, these pages must be maintained on a regular basis - outdated pages may actually be worse than not having them at all. Animal lover |666| 17:42, 12 March 2024 (UTC)
11. My first thought was "we already have extremely high standards for new admins -- why would we expect them to know everything and then go through training", but I'm supporting for the possibility of a different scenario: training that is sufficiently well-known and well-respected that we can, for example, stop quizzing RfA candidates about usernames and CSD tagging because we know they'll go through a thorough onboarding process. — Rhododendrites ^talk \\ 14:45, 14 March 2024 (UTC)
12. Support; unsure about the logistics of it all but I support the concept. Queen of Hearts ^she/_they^talk/_stalk 04:49, 16 March 2024 (UTC)
13. Support in principle, though I do fear that it won't have sustained participation. 0xDeadbeef→∞ (talk to me) 06:38, 17 March 2024 (UTC)

Oppose (Proposal #27)

1. Oppose. This doesn't solve any problem we're experiencing with RfA and there are many different areas where administrators perform administrative actions. Deletion is only one area and many admins are more focused on other areas. If someone wants to improve administrator documentation, create tutorials or other training materials, etc. they are free to do so. Daniel Quinlan (talk) 07:09, 4 March 2024 (UTC)
2. We can't properly formalize a training requirement in a volunteer community where the training itself has to be provided by volunteers. Also, I'm afraid the linked "AGF challenge" would be a pretty unwelcoming experience to at least some suitable candidates when expected to be answered by them before/during an RfA. Each question feels like it's full of traps; I wouldn't have wanted to go through this in addition to the RfA. For example, the best answer to "Is it pseudoscience or science?" generally seems to be "This is not my task to decide as an administrator". Or, more directly: "Irrelevant question". ~ ToBeFree (talk) 22:50, 4 March 2024 (UTC)

   (Oh, look: People had similar concerns in 2008. [5], [6]). ~ ToBeFree (talk) 23:04, 4 March 2024 (UTC)

3. If this will in any way be some sort of requirement, building/testing/getting feedback/improving this program should be done first (as it could be useful even if not a requirement this doesn't need any approval to start). A big missing concern is that if this does become any sort of requirement, who is going to judge that it is met? (e.g. is that a question for RFA participants to determine -- or is is a qualification that first must be met?) — xaosflux ^Talk 20:02, 5 March 2024 (UTC)
4. Oppose Impossible to do well for such a diverse role and so any attempt would likely be a mess. North8000 (talk) 20:42, 7 March 2024 (UTC)

   But a good idea in principle. North8000 (talk) 17:57, 12 March 2024 (UTC)

5. Oppose a formalised training program is likely to fall apart because it will be run by volunteer admins and the amount of time needed to keep it going will make this a problem. Dreamy Jazz ^{talk to me | my contributions} 23:44, 8 March 2024 (UTC)
6. Can't see this working in a volunteer context. Stifle (talk) 12:04, 14 March 2024 (UTC)

Discussion (Proposal #27)

Training has been discussed in the past, such as during the 2021 RfA review. As I said then, no one has proceeded further to-date though, which is understandable given the amount of effort required and the uncertain return on investment. Nonetheless, if anyone wants to start working on it, that would be great—just do it! It's something an interested group of editors can implement on their own initiative. isaacl (talk) 23:07, 3 March 2024 (UTC)

• So maybe every newly elected admin would be assigned an interested, experienced admin, who would tutor them for maybe a month or so? ‍ Relativity 05:44, 4 March 2024 (UTC)

  New admins tend not to be our problem, the few new admins we get these days are usually up to speed and ready to use the tools in the areas they are interested in. Long established admins who have drifted away from community norms are more the issue. So for example, we could have training modules re specific tools, existing admins who were thinking of moving into a new area, or candidates for an RFA, or former admins coming back from a long break would all benefit from training modules. If we have consensus to build something then the WMF might be persuaded to support this Charles Matthews might be able to tell us of some of the possibilities. ϢereSpielChequers 20:10, 4 March 2024 (UTC)

  WSP is picking up on a recent meetup conversation. An approach that would make sense to me is (a) agree some specific training need or needs, and (a) agree in outline why "just reading the Help: and Wikipedia: pages" doesn't suffice. For admin work here, building up some case studies might be appropriate. Charles Matthews (talk) 05:52, 5 March 2024 (UTC)

  Thanks Charles, I suppose one reason why just reading those pages might not suffice for some is that passing some sort of test establishes that we are more likely to have understood the instructions in the way the author(s) of the test intended. ϢereSpielChequers 15:44, 5 March 2024 (UTC)

  Sure; that's all stuff interested editors can proceed with now. Any volunteers would be greatly appreciated! isaacl (talk) 18:10, 5 March 2024 (UTC)

• Is there a more specific plan for what retraining would look like? Would it just be reading through training documents, or would it require admins to answer questions to a set of problems? And if it's the latter, who would determine if the answers are "right" to pass? RunningTiger123 (talk) 18:13, 15 March 2024 (UTC)

Proposal 28: limiting multi-part questions

Clarify that multi-part questions count as multiple questions. For example, What would you do for the following usernames would count as one question per username.

Support (Proposal #28)

1. As proposer. We supposedly limit editors to two questions, but then permit multi-part behemoths which are essentially the same thing. I realize that the candidate can choose not to answer these questions, but that misses the point of what this would do. To illustrate the point, I draw an analogy to freedom of contract. That doctrine argues that individuals have the right to enter into any contract they choose, and thus regulations like minimum wage laws are unconstitutional. The point of this proposal is to save candidates from appearing as if they are avoiding questions. HouseBlaster (talk · he/him) 19:04, 5 March 2024 (UTC)
2. Strong support. Absolutely, yes, as these questions are becoming increasingly annoying and unproductive. I note the comment below, that we already have language about "multi-part questions disguised as one question", but I think this gets gamed by editors who claim that they are not "disguising" anything. We should make it explicit. --Tryptofish (talk) 22:20, 5 March 2024 (UTC)
3. I'd say this is already implemented, but we could remove "disguised as one question, with the intention of evading the limit" from the existing RfA template to make this more clear. ~ ToBeFree (talk) 22:53, 5 March 2024 (UTC)
4. Listing four obviously egregious usernames unnecessarily wastes the candidate's time and increases the pressure on them. We should presume they can read the PAGs. This wont' fix RFA, but it will help. For non-username questions, one still shouldn't be able to take up too much time. Sincerely, Novo Tape^{My Talk Page} 23:33, 5 March 2024 (UTC)
5. Yes, these are multiple questions. And I agree with Tryptofish and ToBeFree that the current language "disguised as one question, with the intention of evading the limit" harmfully hinges on bad intention. If the standard that clerks have to apply requires them to find an editor guilty of bad intent in order to take action, then clerking will remain the big deal that it shouldn't be. Adumbrativus (talk) 04:33, 8 March 2024 (UTC)
6. Tentatively, as it's not indicated what the limits are. I will support any proposal that seems likely to have even the smallest impact on making RfA less unpleasant and/or will help good candidates be elected, and I will oppose or remain neutral on the ones that do not seem to be likely to make such an impact. I'm persuaded by that this measure may help, if set at an appropriate level. Many questions does make RfA harder work for candidates, as they know that they'll be opposed by some for not answering questions, and also for answering them badly! --Dweller (talk) Old fashioned is the new thing! 09:42, 8 March 2024 (UTC)
7. I'm biased on this one as I'm not a fan of the "pop quiz" style of RfA questions. The ones that come to mind tend to be irrelevant to the areas of interest to the candidate or otherwise areas that are easy to learn. — Rhododendrites ^talk \\ 14:38, 14 March 2024 (UTC)
8. I personally think these quiz-type questions are quite superficial. Admins in action are allowed to ignore cases they don't know how to handle. A good alternative is to ask the candidate about a real situation and what they would do differently. 0xDeadbeef→∞ (talk to me) 06:44, 17 March 2024 (UTC)

Oppose (Proposal #28)

1. Oppose, because I think this is framed badly. We don't want candidates to be swamped with questions. We do want !voters to be able to ask a reasonable questions that assess a candidate in the area they want to work. I think the username question with four or five examples is a perfectly valid question for someone who expresses an interest in UAA. The questions we want to prevent are ones like this, which is definitely two questions masquerading as one. This, on the other hand, is a good question. I do recognize that the UAA questions can feel silly sometimes, but you can't legislate against silliness; we need to encourage candidates for whom that's an irrelevant question to just say they're not planning on working at UAA. Vanamonde93 (talk) 00:13, 6 March 2024 (UTC)
2. Oppose. This issue, in my view, is downstream from the issue (discussed at length elsewhere) or bureaucrats not clerking more actively. Per Vanamonde93, I don't think multi-part questions are the biggest obstacle RfA faces, but to the extent they are, it's a matter of 'crats enforcing existing rules, not creating new ones. Sdkb ^talk 16:51, 6 March 2024 (UTC)
3. Per Cryptic. Aaron Liu (talk) 17:27, 6 March 2024 (UTC)
4. Per above 3 posts. North8000 (talk) 20:45, 7 March 2024 (UTC)
5. Oppose - some times these multi-part questions are an attempt at GAMing the system, bit other times they actually are a single question. If a candidate wants to start with handling bad usernames (possibly along with other issues), a good understanding of how the candidate interprets the policy is important. For this purpose, a list of potentially problematic user names is the best way to get an understanding. A single question with a dozen or so names (and accepting "I'll leave this for more experienced admins" for one or two of them) is actually a very important question to be asked once. Animal lover |666| 10:23, 8 March 2024 (UTC)
6. Oppose I think this is too broad. While a user giving 5-10 usernames could probably be seen trying to game the limit a few should be reasonably seen as one question if all the user asks is "what would you do with these usernames". Dreamy Jazz ^{talk to me | my contributions} 23:47, 8 March 2024 (UTC)
7. Oppose too much creep. "What would you do about if you came across edits such as (1),(2)" shouldn't be "two questions". — xaosflux ^Talk 13:19, 11 March 2024 (UTC)
8. While a bit more subjective, I think it should instead be aimed at preventing generally unwieldy lists. A list of five shouldn't count as five questions, especially with the fact that these questions seem easier and less original to answer. However, a list of eight is probably not productive. Also, I might be open to prohibiting these questions unless there is a reasonable doubt that the candidate might not understand the username policy, possibly in the form of different diffs. ✶Quxyz✶ 11:24, 14 March 2024 (UTC)

   In the form of "different"? Aaron Liu (talk) 11:34, 14 March 2024 (UTC)

   Sorry, I typed it out on my phone. I meant diffs. ✶Quxyz✶ 18:23, 14 March 2024 (UTC)

9. Oppose per Vanamonde. Only allowing 2 examples is far too little. Queen of Hearts ^she/_they^talk/_stalk 04:52, 16 March 2024 (UTC)
10. Per Vanamonde. —Compassionate727 ^(T·C) 02:38, 17 March 2024 (UTC)
11. Oppose Not persuaded that further restrictions are needed or would be useful. Nothing that more astute RfA clerking / management cannot contain. Some multi-part Qs reveal a lot and and are necessary. Leaky caldron (talk) 10:38, 17 March 2024 (UTC)

Discussion (Proposal #28)

• We already do. From the standard Q&A intro:

  You may ask optional questions below. There is a limit of two questions per editor. Multi-part questions disguised as one question, with the intention of evading the limit, are disallowed. Follow-up questions relevant to questions you have already asked are allowed.

  Italics mine, bolding and font size in original. —Cryptic 19:46, 5 March 2024 (UTC)

  Is there consensus clarifying that those username questions are multi-part and not just one question? They're still being asked without anyone complaining. (most recently in Tails WX's RfA I believe) Sincerely, Novo Tape^{My Talk Page} 23:39, 5 March 2024 (UTC)

  I read it that way too, but the response to my comment at Wikipedia:Requests for adminship/Hey man im josh#General comments suggests we're in the minority. Extraordinary Writ (talk) 04:47, 7 March 2024 (UTC)

Proposal 29: Provide a few paragraphs of respondent-guidance / advice on the RFA page.

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Provide a few paragraphs of respondent-guidance / advice on the RFA page. It would include things like the qualities needed for admin and advise evaluating and commenting on those. It would advise avoiding some of the common problems that have been occurring. Including problems inherent to a crowd responding/discussing North8000 (talk) 21:59, 5 March 2024 (UTC)

For the discussion of this failed proposal, see Wikipedia:Requests for adminship/2024 review/Phase I/Closed proposals#Proposal 29: Provide a few paragraphs of respondent-guidance / advice on the RFA page.

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 30: Emphasize that just granting the tools does not mean that they will be blocking experienced editors tomorrow

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Emphasize that just granting the tools does not mean that they will be blocking experienced editors tomorrow. In reality, most newer admins start in safer areas and evolve into the rougher high impact areas like blocking experienced editors at WP:ANI and similar high tension high impact blocking areas. But WP:RFA sort of assumes that they will be doing this tomorrow and sets a very grueling standard accordingly. The WP:Administrators page gives some very weak guidance to this effect. The proposal is to strengthen the guidance there along these lines as well as developing this as more of a public expectation. So newer admins (and RFA) can start where it really is "No big deal" and then grow into the areas where it really is a Big Deal. North8000 (talk) 22:10, 5 March 2024 (UTC)

So this is not to solve a current a problem with admins. It's is to: 1. Reinforce the current practice. 2. get RFA respondents to lower the bar accordingly. North8000 (talk) 03:06, 6 March 2024 (UTC)

I'm afraid I did a bad job of explaining this because it has been misunderstood. To put it another way, RFA is a high bar because respondents view it as if every candidate is going to be doing the heaviest duty stuff immediately. In reality (with rare exceptions) newer admins work in the areas where they are comfortable with their ability in, and evolve into the heavier duty areas. The main proposal is to make this current reality clearer so that respondents at RFA will go a bit easier on candidates. Sincerely, North8000 (talk) 14:07, 7 March 2024 (UTC)

For the discussion of this failed proposal, see Wikipedia:Requests for adminship/2024 review/Phase I/Closed proposals#Proposal 30: Emphasize that just granting the tools does not mean that they will be blocking experienced editors tomorrow

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 31: Eliminate the support, oppose, and neutral sections and instead: publish the entire !voting sequence and threaded discussion in one section, as participants arrive

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

The RfA model of segregating and tallying !voter commentary is demonstrably conducive to group think and piling on whereas the AfD model, for example, is much more discussion oriented and demanding of respondents to individually reach and own the opinions they publish. While it will be more difficult to assess consensus, I believe it will result in far less toxicity, overall.--John Cline (talk) 10:17, 6 March 2024 (UTC)

For the discussion of this failed proposal, see Wikipedia:Requests for adminship/2024 review/Phase I/Closed proposals#Proposal 31: Eliminate the support, oppose, and neutral sections and instead: publish the entire !voting sequence and threaded discussion in one section, as participants arrive

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal 32: Add OoA: Offer of Adminship

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

RfA remains a seperate process. Additionally, any editor who reaches a set of milestones (account age, edit count, block-free period, et cetera, numbers and details TBD) receives a friendly message on their talk page, offering adminship. If they accept they get the mop. If they mess up, the ordinary 4-level warning system applies. 4th warning, admin assesses situation, mop kept or removed. No admin action logged for a year, mop removed. This offer is once-off. — Preceding unsigned comment added by Pgallert (talk • contribs) 19:24, 7 March 2024 (UTC)

For the discussion of this failed proposal, see Wikipedia:Requests for adminship/2024 review/Phase I/Closed proposals#Proposal 32: Add OoA: Offer of Adminship

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.