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

For the discussion of this successful proposal, see Wikipedia:Requests for adminship/2024 review/Phase I/Closed proposals#Proposal 2: Add a reminder of civility norms at RfA

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)

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) reply

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) reply

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) reply

For details of this successful proposal, see Wikipedia:Requests for adminship/2024 review/Phase I/Closed proposals#Proposal 3b: Make the first two days discussion-only (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) reply

For the discussion of this failed proposal, see Wikipedia:Requests for adminship/2024 review/Phase I/Closed proposals#Proposal 4: Prohibit threaded discussion (trial)

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)

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. ^[a]

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)

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) reply

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

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) reply

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) reply
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) reply

   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) reply

4. 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) reply
5. 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) reply
6. 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) reply
7. Seems reasonable. * Pppery * _{it has begun...} 23:07, 14 March 2024 (UTC) reply
8. 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) reply

   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) reply

9. — Compassionate727 ^{( T· C)} 23:07, 17 March 2024 (UTC) reply

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) reply
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) reply
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) reply
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) reply
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) reply
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) reply

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

   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) reply

7. Fails the foundation requirement that viewdelete access only be given following a community process. Stifle ( talk) 11:47, 12 March 2024 (UTC) reply
8. Oppose there needs to be a review process before admin are promoted. Z1720 ( talk) 14:31, 13 March 2024 (UTC) reply
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. Java Hurricane 17:47, 13 March 2024 (UTC) reply
10. Oppose Any form of adminship should be subject to approval by the community. Sweet6970 ( talk) 13:00, 14 March 2024 (UTC) reply
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) reply
12. Oppose - Luck should not replace "community support".-- ☾Loriendrew☽ ☏(ring-ring) 23:21, 14 March 2024 (UTC) reply
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) reply
14. Oppose per my notes in 6d. — xaosflux ^Talk 20:21, 16 March 2024 (UTC) reply
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) reply
16. Oppose per my reasons stated in 6d. Gizza ( talk) 01:33, 21 March 2024 (UTC) reply

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) reply

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) reply

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) reply

@ 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) reply

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) reply

? 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) reply

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) reply

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) reply

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) reply
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) reply
3. Same as 6c, I support the general idea. Banedon ( talk) 04:01, 15 March 2024 (UTC) reply

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) reply

   @ 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) reply

   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) reply

   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) reply

   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) reply

   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) reply

   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) reply

   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) reply

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

   (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) reply

2. The issue is not the criteria. See opposition and discussion for #6. — Cryptic 01:30, 7 March 2024 (UTC) reply
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) reply
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) reply
5. Oppose per my comment on 6c. JML1148 ^{( talk | contribs)} 01:09, 10 March 2024 (UTC) reply
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) reply
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) reply
8. Oppose Any form of adminship should be subject to approval by the community. Sweet6970 ( talk) 13:01, 14 March 2024 (UTC) reply
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) reply
10. Oppose - Luck should not replace "community support".-- ☾Loriendrew☽ ☏(ring-ring) 23:22, 14 March 2024 (UTC) reply
11. Oppose The community should be able to specifically evaluate candidates prior to promotions. — xaosflux ^Talk 20:20, 16 March 2024 (UTC) reply
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) reply
13. Oppose admins need to earn the trust of the community, which they won't achieve if selected by sortition. Gizza ( talk) 01:31, 21 March 2024 (UTC) reply

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) reply

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) reply
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) reply
3. Support — PerfectSoundWhatever ( t; c) 13:55, 27 February 2024 (UTC) reply
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) reply
5. Support Don't really think this will change much, but a good idea nonetheless. JML1148 ^{( talk | contribs)} 01:10, 10 March 2024 (UTC) reply
6. Support Sounds like a good idea, structuring it, as discussions are often bulleted. Rusty4321  ^{talk  contribs} 05:04, 22 March 2024 (UTC) reply

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) reply
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) reply
3. Not seeing how this would improve RfA. Extraordinary Writ ( talk) 03:51, 29 February 2024 (UTC) reply

Neutral (proposal 7)

1. Doesn't seem like this changes anything substantial. Banedon ( talk) 05:30, 27 February 2024 (UTC) reply
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) reply

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) reply
• 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) reply

  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) reply

  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) reply

  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) reply

  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) reply

• I have no idea what this is asking to change. * Pppery * _{it has begun...} 17:27, 20 February 2024 (UTC) reply
• 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) reply

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

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) reply

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

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) reply

*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) reply

Support (proposal 9b)

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

   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) reply

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) reply
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) reply
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) reply
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) reply
7. * Pppery * _{it has begun...} 23:08, 14 March 2024 (UTC) reply
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) reply
9. Makes sense. Could also be redundant given we can already action upon those claims per ASPERSIONS. 0x Deadbeef→∞ ( talk to me) 06:12, 17 March 2024 (UTC) reply
10. Support on a trial basis, similar to earlier proposals :) theleekycauldron ( talk • she/her) 18:47, 19 March 2024 (UTC) reply
11. with the change that only specific policy violations require diffs sawyer * he/they * talk 21:40, 21 March 2024 (UTC) reply
12. Support: I think this is reasonable and I can't see why not. Rusty4321  ^{talk  contribs} 05:06, 22 March 2024 (UTC) reply
13. Support. Something of a no brainer, but I understand this is the same way as Vanamonde. Gog the Mild ( talk) 22:46, 30 March 2024 (UTC) reply
14. Support Proper evidence (with URL links) needs to be presented at RfA if the candidate or any other editor has violated any Wikipedia policies. TheGeneralUser ( talk) 13:41, 12 April 2024 (UTC) reply
15. Support This should (hopefully) discourage users from casting aspersions in the first place. Fanfanboy ( talk) 17:56, 24 April 2024 (UTC) reply

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) reply

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) reply

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) reply

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

@ 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) reply

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) reply
2. Oppose as unnecessary process creep. Crats can already discount !votes which allege misconduct but lack evidence. Enforcing this creates opportunities for drama/busy-work and imo that's time better spent elsewhere. - Fastily 08:09, 13 April 2024 (UTC) reply
3. Oppose this makes it harder to register concerns. Anyone can scare up a mess of diffs about an editor. If we decide to vote in private this proposal is not needed. Lightburst ( talk) 23:15, 18 April 2024 (UTC) reply

   It will only make it harder to register concerns about policy violations. Any other type of concern you can register. Aaron Liu ( talk) 00:14, 19 April 2024 (UTC) reply

Neutral (proposal 9b)

• While I can agree that in theory that this is a good idea, the reality is that people will get round the necessity of "X did [a bad thing] at [diff]" by saying "I wasn't comfortable with X's actions in [thread name]". I suspect it'll scare off some valid opposers from commenting (as per SportingFlyer), which is my main concern. - SchroCat ( talk) 12:41, 16 April 2024 (UTC) reply

  The proposal imo should be changed to require diffs. I also imagine there is something else that could be used to prove claims but I cannot think of any right now. This would remove people doing as you said. Nagol0929 ( talk) 13:52, 19 April 2024 (UTC) reply

  I'm not sure what you mean. This proposal would require diffs for specific violations. Aaron Liu ( talk) 14:39, 19 April 2024 (UTC) reply

  It says provide evidence for their allegations* in the form of a link (preferably in the form of a diff). So it doesn't require diffs in particular, so thats what i mean. Nagol0929 ( talk) 14:48, 19 April 2024 (UTC) reply

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) reply

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) reply

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) reply

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) reply

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) reply

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

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) reply

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) reply

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

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

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

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) reply

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

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) reply

For the discussion of this failed proposal, see Wikipedia:Requests for adminship/2024 review/Phase I/Closed proposals#Proposal 12c: Lower the high end of the bureaucrats' discretionary zone from 75% to 70%

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.

For the discussion of this successful proposal, see Wikipedia:Requests for adminship/2024 review/Phase I/Closed proposals#Proposal 13: Admin elections.

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) reply
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) reply
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) reply

   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) reply

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

   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) reply

5. As an accurate description of policy as already practiced. — Compassionate727 ^{( T· C)} 23:02, 23 February 2024 (UTC) reply
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) reply

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

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) reply
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) reply
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) reply
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) reply
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. Ϣere SpielChequers 11:47, 25 February 2024 (UTC) reply
12. Per the proposal, with semi-protection of RfAs as the minimum. ~ ToBeFree ( talk) 12:23, 25 February 2024 (UTC) reply
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) reply
14. Per WereSpielChequers. Sincerely, Novo Tape ^{My Talk Page} 01:58, 26 February 2024 (UTC) reply
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) reply
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) reply
17. Better than what we currently got, though I'd rather extended confirmed be the requirement. Steel1943 ( talk) 02:09, 27 February 2024 (UTC) reply
18. Makes sense to me. popodameron ⁠ talk 03:06, 27 February 2024 (UTC) reply
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) reply
20. Support per WereSpielChequers. Butterdiplomat ( talk) 04:43, 27 February 2024 (UTC) reply
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) reply
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) reply
23. Support per nom and most of the comments above. Gog the Mild ( talk) 16:55, 27 February 2024 (UTC) reply
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) reply
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) reply
26. Support - Service guarantees citizenship. Would you like to know more? — Rhododendrites ^talk \\ 17:55, 27 February 2024 (UTC) reply

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

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) reply
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) reply
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) reply
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) reply
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) reply
32. Support Dreamy Jazz ^{talk to me | my contributions} 15:17, 1 March 2024 (UTC) reply
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) reply
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) reply
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) reply
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) reply
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) reply
38. Support per Owenx. JML1148 ^{( talk | contribs)} 01:18, 10 March 2024 (UTC) reply
39. Support -- Goldsztajn ( talk) 09:00, 12 March 2024 (UTC) reply
40. Support although requiring 30/500 permissions would be a preference, this is better than nothing. Joseph 2302 ( talk) 10:42, 12 March 2024 (UTC) reply
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) reply
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) reply
43. i'd support either autoconfirmed or the ArbCom requirements; i think EC might be a bit too strict - like lepricavark, i think this could provide some safeguards should proposal 13 pass. sawyer * he/they * talk 21:27, 21 March 2024 (UTC) reply

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) reply
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) reply

   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) reply

   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) reply

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) reply

   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) reply

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) reply
5. Strong Oppose per Xaosflux and WaltCip. 🌺 Cremastra ( talk) 20:17, 25 February 2024 (UTC) reply
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) reply
7. Oppose Barring someone from commenting (not just voting) is crossing a bridge too far. OhanaUnited ^{Talk page} 04:11, 27 February 2024 (UTC) reply
8. Oppose Ixtal hit the nail on the head - Fastily 07:14, 27 February 2024 (UTC) reply
9. Oppose 10 edits in the last year requirement. Ivan ( talk) 08:47, 27 February 2024 (UTC) reply
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) reply
11. Oppose I do not think this is a problem that needs solving. SportingFlyer T· C 19:17, 27 February 2024 (UTC) reply
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) reply
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 So Why 20:00, 28 February 2024 (UTC) reply
14. Per Ivanvector, SC, and Ixtal. AryKun ( talk) 19:32, 29 February 2024 (UTC) reply
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) reply
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. ✶Qux yz ✶ 17:00, 2 March 2024 (UTC) reply
17. Oppose All of the drama comes from tenured editors anyway. _Dial ^mayo 15:24, 14 March 2024 (UTC) reply
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) reply
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) reply
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. 0x Deadbeef→∞ ( talk to me) 06:19, 17 March 2024 (UTC) reply

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) reply

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) reply

• 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) reply

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

• 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) reply

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

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

• I am supportive of some restrictions to reduce the workload of checking for socks, but I am afraid that this might raise the bar for candidates to pass. The most onerous requirements for adminship come from experienced editors with extensive "laundry lists" that candidates can never meet, which I personally disagree with. Maybe someone has a statistical analysis on this, but currently I can't be sure that this won't harm RfA numbers. Toadspike ( talk) 16:14, 23 March 2024 (UTC) reply

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) reply

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

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) reply

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) reply

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) reply
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) reply
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) reply

   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) reply

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) reply
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) reply
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) reply
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) reply

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

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. House Blaster ( talk · he/him) 13:41, 27 February 2024 (UTC) reply
9. Needed — PerfectSoundWhatever ( t; c) 14:02, 27 February 2024 (UTC) reply
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) reply

    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) reply

    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) reply

11. Putting my formal weak support support down. Full comment just above Soni ( talk) 15:50, 27 February 2024 (UTC) reply
12. Needs revision with further RfCs, but I support the general concept. Sincerely, Novo Tape ^{My Talk Page} 16:14, 27 February 2024 (UTC) reply
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) reply

    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) reply

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) reply
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) reply
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) reply

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

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) reply
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) reply
19. Community recall is many, many years overdue. LEPRICAVARK ( talk) 15:51, 28 February 2024 (UTC) reply

    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) reply

20. Support in principle I think details need be worked out. -- Enos733 ( talk) 17:14, 28 February 2024 (UTC) reply
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) reply
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) reply
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) reply
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) reply
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) reply
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) reply
27. Perpetual support for some sort of recall ~ Amory ( u • t • c) 13:05, 2 March 2024 (UTC) reply
28. Support This has been something people have been asking for for a long time. Hawkeye7 (discuss) 00:17, 3 March 2024 (UTC) reply
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) reply
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) reply
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) reply
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) reply
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) reply

    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) reply

34. Support in principle, but the details need to be fleshed out. Cullen328 ( talk) 01:50, 8 March 2024 (UTC) reply
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) reply
36. Support Ivan ( talk) 19:46, 11 March 2024 (UTC) reply
37. Support -- Goldsztajn ( talk) 08:48, 12 March 2024 (UTC) reply
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) reply
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) reply
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) reply
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) reply
42. Support on principle. – Hilst [talk] 23:42, 16 March 2024 (UTC) reply
43. Conditional support A formal recall process is long overdue. The optional status quo is silly. Seeing the opposition below, there must be a higher threshold to start a recall than one person disagreeing with the admin, and a lower threshold for passing the re-RfA than the usual ~70%. For the former, perhaps requiring a specific number of users in favor of the recall (5? 10?), requiring an admin to support the recall, or requiring consensus at AN would work. For the latter, the 50% suggested elsewhere should be good. re-RfAs would likely be stacked against the admin, so a lower bar is only fair. Toadspike ( talk) 16:35, 23 March 2024 (UTC) reply

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) reply

   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) reply

   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) reply

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) reply
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) reply
4. Oppose per Animal lover 666. Gamaliel ( talk) 04:25, 28 February 2024 (UTC) reply
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) reply
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) reply

   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) reply

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 So Why 19:55, 28 February 2024 (UTC) reply
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) reply
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) reply
10. Oppose. Not a proper venue for this proposal. See WP:RFDA. Stifle ( talk) 11:11, 29 February 2024 (UTC) reply

    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) reply

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) reply
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) reply
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) reply
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) reply
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. Java Hurricane 20:23, 3 March 2024 (UTC) reply
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) reply
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) reply
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) reply
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. Ϣere SpielChequers 11:56, 10 March 2024 (UTC) reply
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) reply
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) reply
22. Oppose as written. Agreed that we could use a recall process, but trial by AN just ain't it. - Fastily 20:17, 24 March 2024 (UTC) reply

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) reply
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) reply
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) reply

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) reply

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

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. 0x Deadbeef→∞ ( talk to me) 14:11, 27 February 2024 (UTC) reply

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) reply

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

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) reply

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) reply

• Keep it simple. Use the Commons model. There needs to be a community discussion, normally at AN, which is closed with a consensus that the mop should stand for a reconfirmation. They can resign under a cloud, they can open a reconfirmation RfA, or one will be opened for them by a crat. The reconfirmation runs just like a normal RfA but just needs a simple majority to keep the mop. GMG ^talk 11:48, 19 March 2024 (UTC) reply

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) reply

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

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) reply

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) reply

Support (Proposal 16c)

1. As proposer Soni ( talk) 14:28, 29 February 2024 (UTC) reply
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) reply
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) reply
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) reply

   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) reply

5. I do like the idea of this/ Dreamy Jazz ^{talk to me | my contributions} 15:24, 1 March 2024 (UTC) reply
6. This looks like a satisfactory system. LEPRICAVARK ( talk) 17:16, 1 March 2024 (UTC) reply
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) reply
8. Equal choice with 16a. House Blaster ( talk · he/him) 03:47, 2 March 2024 (UTC) reply
9. Support Seems reasonable. Hawkeye7 (discuss) 00:19, 3 March 2024 (UTC) reply
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) reply
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) reply
12. Support , a recall process for admins has been long overdue. Ratnahastin ( talk) 06:50, 3 March 2024 (UTC) reply
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) reply
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) reply

    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) reply

15. Support Neat! Leijurv ( talk) 00:54, 6 March 2024 (UTC) reply
16. Per Vanamonde and Novo Tape. Queen of Hearts talk
    she/they
    stalk 19:55, 7 March 2024 (UTC) reply
17. Support Would probably need some refining. North8000 ( talk) 20:10, 7 March 2024 (UTC) reply
18. If it works on dewiki it should work on enwiki. BilledMammal ( talk) 11:57, 10 March 2024 (UTC) reply
19. Support Ivan ( talk) 19:44, 11 March 2024 (UTC) reply
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) reply
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) reply
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) reply
23. — Compassionate727 ^{( T· C)} 05:34, 17 March 2024 (UTC) reply
24. Strong Support This addresses all of my concerns with Proposal 16. Toadspike ( talk) 16:41, 23 March 2024 (UTC) reply
25. Support - Tweak the numbers as needed, but this makes good sense. My only question is whether there should also be a restriction on how many of these reconfirmations a given editor can sign on to in a given timeframe. I can see there being a pool of folks with an ACAB attitude towards admins (AAAB?) who pile into every recall attempt, and that's not productive. Retswerb ( talk) 03:26, 24 March 2024 (UTC) reply

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) reply

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) reply

   @ 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) reply

   ... 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) reply

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

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

   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) reply

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

2. Oppose for the same reasons I provided in 16. Chetsford ( talk) 05:53, 1 March 2024 (UTC) reply
3. Oppose, current process works just fine. Stifle ( talk) 10:22, 1 March 2024 (UTC) reply

   Also, having a recall open for an entire year is ridiculous. Stifle ( talk) 09:00, 21 March 2024 (UTC) reply

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) reply
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) reply
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) reply
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) reply
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) reply
9. Per Cryptic's second sentence. * Pppery * _{it has begun...} 23:09, 14 March 2024 (UTC) reply

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) reply

   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) reply

   @ 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) reply

   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) reply

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) reply

   @ 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) reply

   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) reply

   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) reply

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) reply

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) reply

  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) reply

• 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) reply

  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) reply

• 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) reply

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

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

• 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) reply

• 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) reply

  @ 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) reply

  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) reply

  @ 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) reply

  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) reply

• 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) reply

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) reply

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

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)

For the discussion of this failed proposal, see Wikipedia:Requests for adminship/2024 review/Phase I/Closed proposals#Proposal 16e: Allow the community to initiate recall RfBs

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) reply

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

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.

For the discussion of this successful proposal, see Wikipedia:Requests for adminship/2024 review/Phase I/Closed proposals#Proposal 17: Have named Admins/crats to monitor infractions.

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) reply

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) reply
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) reply
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) reply
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) reply
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 So Why 18:53, 28 February 2024 (UTC) reply
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) reply
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) reply
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) reply
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) reply
10. Support Lower standard could allow for more crats per rogerd and QuicoleJR. Rusty4321  ^{talk  contribs} 01:03, 13 March 2024 (UTC) reply
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) reply
12. Support but perhaps only to 80% rather than 75%. I have no issue with RfB having a higher threshold than RfA. Not convinced this change will have impact on RfA in practice. - Kj cheetham ( talk) 22:30, 24 March 2024 (UTC) reply

Oppose (proposal 18)

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

   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) reply

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) reply
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) reply
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) reply
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) reply
6. No, we need actual consensus, and reach it regularly in such matters. -- Alanscottwalker ( talk) 17:11, 29 February 2024 (UTC) reply
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) reply
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) reply

   ... 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) reply

   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) reply

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

9. Orthogonal to the issue. ~ Amory ( u • t • c) 13:08, 2 March 2024 (UTC) reply
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) reply
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) reply
12. Oppose Lightburst ( talk) 03:56, 6 March 2024 (UTC) reply
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) reply
14. Oppose I don't see a need for more 'crats. BilledMammal ( talk) 01:06, 13 March 2024 (UTC) reply
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) reply
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) reply
17. Oppose per above. Solution in search of a problem - Fastily 20:17, 24 March 2024 (UTC) reply

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) reply

It seems like how this is trying to relate is:

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) reply

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) reply

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. Ϣere SpielChequers 21:49, 9 March 2024 (UTC) reply

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

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

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) reply

For the discussion of this failed proposal, please see Wikipedia:Requests for adminship/2024 review/Phase I/Closed proposals#Proposal 21: Reduce threshold of consensus at RfA

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

For the discussion of this failed proposal, see Wikipedia:Requests_for_adminship/2024_review/Phase_I/Closed_proposals#Proposal_21b:_Slightly_reduce_threshold_of_consensus_at_RfA

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) reply

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) reply

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"

I'm resurfacing an idea I advanced in 2021 [1]. 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) reply

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) reply

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

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) reply
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) reply
3. Support as a general concept. The details will need more work. North8000 ( talk) 20:35, 7 March 2024 (UTC) reply
4. Support, why not? – Hilst [talk] 13:07, 10 March 2024 (UTC) reply
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) reply
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) reply
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? 0x Deadbeef→∞ ( talk to me) 06:34, 17 March 2024 (UTC) reply
8. Support I'm late to the party, but I definitely co-sign this proposal (even though I agree that details might need more work)! As for a comment I left on this article, I feel like, in comparison to experienced users, new faces are more exposed to be "lonely" and overwhelmed by the multitude of services available on the site; so, I think this could be a good way to offer people better guidance and "keep them grounded", so to speak. Oltrepier ( talk) 10:49, 1 April 2024 (UTC) reply
9. Full Support - This is a good idea that can definitely help a candidate identify their strengths and weaknesses, boost their confidence, and prepare them in a better way for their RfA. It will surely need brainstorming with a more detailed and fully prepared proposal in Phase 2, and by taking ideas from Wikipedia:Admin coaching and Wikipedia:Requests for adminship/Optional RfA candidate poll, an even better successor process page can be created that will benefit all future RfA and RfB candidates. TheGeneralUser ( talk) 16:59, 12 April 2024 (UTC) reply
10. Support per comments above, but fearing that adopting the Support/oppose/unsure will make ORCP feel more of a vote rather than a rating. Toadette ^{( Let's talk together!)} 12:05, 14 April 2024 (UTC) reply

    Note the proposal in its current form is for a separate process, leaving the optional RfA candidate poll process intact. isaacl ( talk) 18:08, 14 April 2024 (UTC) reply

11. Weak support. Mentoring doesn't always work, but when it does, the effects are nearly always positive. The devil will be in the detail, but I think this is at heart a good idea, although I'd want to see more detail into what this process actually is, and how it would work in practice. - SchroCat ( talk) 12:32, 16 April 2024 (UTC) reply

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) reply

Neutral (Proposal #24)

1. There doesn't seem to be anything to !vote on here. Folks can already get mentoring with or without a "formal" process. - Fastily 20:17, 24 March 2024 (UTC) reply
2. This seems out-of-scope for RfA review, and it isn't clear to me why we need to obtain a consensus instead of somebody just starting a page for it. But I have no objection to this, other than that it seems likely to me to just combine the worst features of RfA and ORCP as currently written. — Compassionate727 ^{( T· C)} 23:00, 19 April 2024 (UTC) reply

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) reply

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) reply

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) reply

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) reply

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

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) reply

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) reply

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) reply

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) reply

For the discussion of this successful proposal, see Wikipedia:Requests for adminship/2024 review/Phase I/Closed proposals#Proposal 25: Require nominees to be extended confirmed

• 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) reply

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

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 Ϣere SpielChequers 22:00, 3 March 2024 (UTC) reply
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) reply
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) reply
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) reply
5. Support This can only help with keeping people effective as admins. ᴢxᴄᴠʙɴᴍ ( ᴛ) 21:26, 5 March 2024 (UTC) reply
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. Joseph 2302 ( talk) 17:02, 6 March 2024 (UTC) reply
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) reply
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) reply
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) reply
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) reply
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) reply
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) reply
13. Support in principle, though I do fear that it won't have sustained participation. 0x Deadbeef→∞ ( talk to me) 06:38, 17 March 2024 (UTC) reply
14. Conditional Support - Additional training criteria and procedures like Wikipedia:Admin coaching (which is currently inactive) can be created for extra training of administrators, and more details on them can be created in Phase 2, but participation in them must be completely voluntary since this is a volunteer project. TheGeneralUser ( talk) 15:50, 12 April 2024 (UTC) reply

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) reply
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) reply

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

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) reply
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) reply

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

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) reply
6. Can't see this working in a volunteer context. Stifle ( talk) 12:04, 14 March 2024 (UTC) reply
7. I'm not convinced this would actually be beneficial or work in practice - perhaps a set of "admin advice" essays written by the community would be a bit easier & provide some of the same value sawyer * he/they * talk 21:22, 21 March 2024 (UTC) reply
8. It isn't clear what this is proposing: is it some sort of mandatory training process, or is it just improved guidance? If it's the former I think it'll be ineffective and an unnecessary burden, and if it's the latter it doesn't require a proposal at all; anyone can create guidance pages (as indeed some have at WP:ADMINGUIDE) or improve them. Extraordinary Writ ( talk) 07:13, 22 March 2024 (UTC) reply
9. Oppose - moral support, but don't see it working in practice. - Kj cheetham ( talk) 17:54, 24 March 2024 (UTC) reply
10. Oppose This literally fixes nothing and would probably create more problems than it solves. - Fastily 20:17, 24 March 2024 (UTC) reply
11. Oppose This site is conspicuously contradictory with competing policies, guidelines and essays. Administrators often interpret them according to their own understanding. The best we can do is elect administrators who we trust to use good judgement. Lightburst ( talk) 23:22, 18 April 2024 (UTC) reply
12. I can't see this becoming anything but a source of frustration on a volunteer project like this. — Compassionate727 ^{( T· C)} 22:55, 19 April 2024 (UTC) reply

Neutral (Proposal #27)

1. I can't support or oppose, but the pros is to have veteran admins train new ones as new admins might not yet understand all the admin instriction. The con is the potential issue that would come up from either semi active admins who might not keep up with current policies and such would make students conduct bad/unjustified blocks/deletion etc., or admins who would just teach recklessly to their student, including the possibility for making incivil comments to students. Toadette ^{( Let's talk together!)} 11:59, 14 April 2024 (UTC) reply

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) reply

• 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) reply

  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. Ϣere SpielChequers 20:10, 4 March 2024 (UTC) reply

  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) reply

  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. Ϣere SpielChequers 15:44, 5 March 2024 (UTC) reply

  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) reply

• 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) reply