Wikipedia:Requests for adminship/2021 review/Proposals

What changes should be made to Requests for Adminship (RfA) to solve the issues identified by the community? 15:48, 31 October 2021 (UTC)

Introduction and format

The last comprehensive examination of our Requests for Adminship (RfA) system occurred in 2015. Nearly 6 years later there has been lots of discussion about what has worked, and what has not, from that reform process. There has also been further discussion on a regular basis at Requests for adminship and elsewhere about other issues with RfA and of changes that may ameliorate those issues. In 2021, we are on pace for a record low year of RfAs. Our current pace puts us on track for having roughly 2/3 as many RfAs as 2018, the year which previously had the fewest total RfAs.

A 30 day discussion identified 8 issues which have community consensus. We will now be considering solutions that address these identified issues.

To attempt to ensure the most editors possible can supply feedback for ideas, for 7 days prior to the start of Phase 2 and during the first 7 days of the 30 day discussion period editors may propose changes. New ideas suggested after that time or which don't need a formal consensus to be implemented (e.g. a new WikiProject) will be moved to the talk page. No votes will be allowed before the start of the 30 day discussion. To help editors navigate proposals, proposed changes will be grouped according to the main issue they are addressing.

Instructions for voters

• Editors may support, oppose, or simply discuss the changes proposed in the appropriate sections.
• Consider returning after 11/7 after which no new proposals will be added
• To best represent consensus, participants are encouraged to comment on as many potential statements as they are able
• Participants are encouraged to stay focused on the proposed changes. Related discussion, discussion about the process, or general discussion about RfA should happen on the talk page.

Instructions for proposing new ideas

The following format will be used when presenting ideas:

==(Issue Number and letter) A few word summary description of the solution being proposed==
A (neutral) description of up to 75 words for the solution being proposed. Up to 225 more words in details may be included in a collapsed box (using something like {{ctop}} & {{cbot}} ). For larger changes where more information is needed editors are encouraged to link to a subpage with wording and further details. There is no need to sign the proposal.

Example

This example is based on a proposal from the 2015 RfA. ==1A Advertise RfAs with a watchlist notice== Another option is to post a notice announcing current RfAs on [[MediaWiki:Watchlist-details]], which will display the notice on all watchlists. ===Support 1A Advertise RfAs with a watchlist notice=== # ===Oppose 1A Advertise RfAs with a watchlist notice=== # ===Discussion 1A Advertise RfAs with a watchlist notice===

The goal is that no further RfCs/phases will be needed to implement any idea which gains consensus from this discussion. Some details may, of course, be worked out during the 30 day discussion (i.e. during the 2015 review multiple proposals for the exact percentage that the discretionary range would start at were discussed/considered). Proposals which are not substantially ready for implementation, are proposed after the first 7 days of the 30 day discussion period (November 7), or which don't need formal consensus, will be moved to the talk page. For proposals which address more than one area, the proposal should be placed under the main issue it addresses.

Instructions for closers

The uninvolved closer(s) shall have the discretion to determine which solutions attained consensus. They are encouraged to consider the degree of consensus reached for the issue being addressed during phase 1 and the amount of participation relative to the size of the proposed change when determining consensus for any potential solutions.

Issues identified

Following Phase 1 the following issues had a clear consensus of support from editors:

1. Corrosive RfA atmosphere: The atmosphere at RfA is deeply unpleasant. This makes it so fewer candidates wish to run and also means that some members of our community don't comment/vote.
2. Level of scrutiny: Many editors believe it would be unpleasant to have so much attention focused on them. This includes being indirectly a part of watchlists and editors going through your edit history with the chance that some event, possibly a relatively trivial event, becomes the focus of editor discussion for up to a week.
3. Standards needed to pass keep rising: It used to be far easier to pass RfA however the standards necessary to pass have continued to rise such that only "perfect" candidates will pass now.
4. Too few candidates: There are too few candidates. This not only limits the number of new admin we get but also makes it harder to identify other RfA issues because we have such a small sample size.
5. "No need for the tools" is a poor reason as we can find work for new admins

The following issues had a rough consensus of support from editors:

6. Lifetime tenure (high stakes atmosphere): Because RfA carries with it lifetime tenure, granting any given editor sysop feels incredibly important. This creates a risk averse and high stakes atmosphere.
7. Admin permissions and unbundling: There is a large gap between the permissions an editor can obtain and the admin toolset. This brings increased scrutiny for RFA candidates, as editors evaluate their feasibility in lots of areas.
8. RfA should not be the only road to adminship: Right now, RfA is the only way we can get new admins, but it doesn't have to be.

Editors should also consider the following which had consensus against them when proposing solutions:

• There is no issue
• Not enough like a discussion
• Too much discussion
• Administrator is undesirable position
• RfA reflects a declining editor base
• Who participates
• Splitting the admin role
• Too few trusted and experienced nominators

Issue 1: Corrosive RfA atmosphere

The atmosphere at RfA is deeply unpleasant. This makes it so fewer candidates wish to run and also means that some members of our community don't comment/vote.

1A Formal moderation of RfA

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

---

This idea was brought up in the brainstorming phase [1], and I believe it merits further consideration here.

Extended content

The gist of the idea is that formal moderators would police RfAs, with the power to remove uncivil comments, bad questions, and in general fight the corrosive atmosphere present. I would suggest that moderators who are active on an RfA be required to abstain from voting on said RfA. Addition, 17:43, 31 October 2021 (UTC) Moderators would either be appointed from a group of admins who have opted in to moderating RfA discussions, or elected from the community at large in an election process.

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

1B Zero tolerance for incivility or personal attacks

Within an RfA, anything that can be liberally construed as incivility or personal attacks should be immediately removed. This would not require any changes to the civility or personal attacks policies, but would be a new guideline for RfAs directing that participants apply a strict standard of civility in order to avoid a corrosive atmosphere. Criticism would, of course, still be permitted, but it would need to be presented dispassionately and objectively.

Support 1B Zero tolerance for incivility or personal attacks

1. As proposer. Nosferattus (talk) 17:25, 31 October 2021 (UTC)
2. Strong support. WP:CIVIL and WP:NPA are incdeed already policies but RFA is the one place on Wikipedia where these policies are traditionally ignored and allowed to stand with umpuity and unclerked. The toxic nature of RfA is identified by consensus as the reason why candidates are reluctant to come forward and it's what all these discussions are about. Kudpung กุดผึ้ง (talk) 19:12, 31 October 2021 (UTC)
3. I support the idea that we could be a tad more strict here. Just like with any other talk or project space page, any user should be able to apply their own judgement when removing comments they deem to be uncivil during an RfA (which can then be challenged somewhere else, such as that user's talk page or the RfA talk page). This might alleviate the issue somewhat, though not entirely. Isabelle ^🔔 03:05, 1 November 2021 (UTC)
4. If someone has concerns about a user's suitability for the role, they better ought to be able to express it in a manner which is not unbecoming: else they're directly taking away credibility from their concerns by showing how unsuitable they are. Ritchie333 "this might give a trigger-happy admin carte blanche to block someone": as far as I see, there is nothing in this proposal that suggests that. This is just a clearer message the NPA and CIVIL will be enforced; and seems like the first step would be removing the offending comment and warning the user (i.e. the regular method of dealing with such things), not giving carte blanche to some rogue admin. RandomCanadian (talk / contribs) 14:46, 2 November 2021 (UTC)

Oppose 1B Zero tolerance for incivility or personal attacks

1. Unhelpful rules creep. Personal attacks are already not permitted, this rule will just lead to accusations that mildly critical comments are inappropriate. User:力 (power~enwiki, π, ν) 17:37, 31 October 2021 (UTC)
2. WP:CIVIL and WP:NPA are already policies and honestly I think some people are already too quick to performatively leap on oppose !voters at RfA. It's important that RfA is open to good-faith criticism and important that potential admins are able to receive it, even if it's not phrased perfectly. – Joe (talk) 17:50, 31 October 2021 (UTC)
3. Per all. Unnecessary and won't necessarily help.  – John M Wolfson (talk • contribs) 18:35, 31 October 2021 (UTC)
4. Not opposed in principle, but without establishing "who" and "how" (in this case, who will be authorized to do the removals, and how they will determine when they are needed), this is basically a blank check. This proposal as written would even permit supporters of the candidate to decide that something is a "personal attack" and remove it, and that would clearly not be a wise idea. Seraphimblade ^{Talk to me} 23:24, 31 October 2021 (UTC)
5. Oppose as written. I would support the idea of enforcing existing policy in a stricter fashion though. HighInBC ^{Need help? Just ask.} 23:29, 31 October 2021 (UTC)
6. The point of RfA is partially to evaluate a candidate's personality and "comment on content, not on the contributor" is inapplicable when the main purpose of RfA is so that people can comment on the contributor to judge if they're acceptable for adminship. NPA states that using someone's political affiliations to discredit them is not allowed. If someone with extreme political opinions was to request adminship, would this mean we couldn't comment on that given we're now strictly enforcing NPA? Chess (talk) (please use {{reply to|Chess}} on reply) 03:31, 1 November 2021 (UTC)
7. Per above, plus an admin has to be able to remain calm if someone abuses them (I mean routine abuse with a few bad words, not actual harassment). If a candidate cannot cope with the stress of someone being unpleasant at their RFA, they would not be a suitable admin. Johnuniq (talk) 08:30, 1 November 2021 (UTC)
8. I can't believe I find myself here. However, this proposal is dangerous. If it was as easy as saying "zero tolerance of CIVIL breaches", then we'd have done this years ago - the problem is that civility is subjective, based on the situation. Given that we're in a place where feedback is meant to be given, it is impossible to find the right line to enforce - and if we're saying "zero tolerance", that's just inviting trouble. It sounds like a lovely idea, but this is not the solution. Worm^TT(talk) 08:34, 1 November 2021 (UTC)
9. While I often see concerns about discourtesy handwaved with "just suck it up" or "it's their right to do so", I can't support this one without some qualifiers: I'd like to specify exactly who would be allowed to enforce this. There is also the issue how to draw the distinction between fair critique (Oppose: The candidate often files incorrect speedy deletion requests") from ill-supported insinuatory claims and vanilla personal attacks. Jo-Jo Eumerus (talk) 11:15, 1 November 2021 (UTC)
10. Per Worm. Civility isn't a universal thing, culture comes into play, and this is just asking for more drama, not less. Dennis Brown - 2¢ 11:28, 1 November 2021 (UTC)
11. Per above, already several good arguments against. But also, it makes it too easy to dismiss a !vote/comment based on the editor making it, as opposed to the actual comment. - wolf 16:54, 1 November 2021 (UTC)
12. Personal attacks are already prohibited. Worm and Dennis have it right here. Carrite (talk) 17:02, 1 November 2021 (UTC)
13. Unnecessary given Wikipedia's longstanding, sitewide guidelines on the subject. Ganesha811 (talk) 19:11, 1 November 2021 (UTC)
14. Just make the existing agreed process for RfA management work. No need for creep. Leaky caldron (talk) 21:32, 1 November 2021 (UTC)
15. Personal attacks are already prohibited. Friction against opposition occurs anyway. This year in my RfA, User:Chess was the first opposer. Chess was not satisfied with my answer to their question. Chess opposed shortly after and raised legitimate issues of competence and judgement, based on my answers to other questions as Chess read them. Not about my judgement in the distant past but my judgement now. Totally in bounds. Opposing alone was a courageous thing to do, with 75 already supporting. Chess was not rude, insulting or incivil. They put forward their position and took a bit of heck for it, earning my respect. I'm not judging those heck-giver editors in that process, but opposing is necessarily adversarial and so some friction is inevitable. Zero tolerance doesn't seem practical so long as we have an adversarial process. BusterD (talk) 22:11, 1 November 2021 (UTC)
16. Naming no names, but this might give a trigger-happy admin carte blanche to block someone for simply expressing a blunt opinion in an oppose, which doesn't actually attack anyone as such. Ritchie333 ^{(talk) (cont)} 22:15, 1 November 2021 (UTC)
17. Disagree that one of our five pillars is routinely ignored at RfA and that we need a new, special policy for zero tolerance. Better enforcement? Maybe. Better clerking? Sure. But this is unnecessary and probably not beneficial. ~ Amory (u • t • c) 15:25, 2 November 2021 (UTC)
18. It is both necessary and desirable to draw attention to competence and character aspects which are incompatible with adminship, or behaviour which suggests that these problems may exist, but the way that one brings these points to attention should be civil, polite, and as far as reasonably possible respectful of our colleagues who offer their services for what can be thankless tasks. It is not always possible to do what must be done without someone taking offence, even where none is intended. Zero tolerance is not practicable unless there is clear and unambiguous understanding of what is and is not acceptable, and it is quite obvious that there is no clear and unambiguous universal expectation of behaviour across the varied cultures from which we come. · · · Peter Southwood ^(talk): 18:46, 3 November 2021 (UTC)
19. Unnecessary creep, no need here for any sort of "zero tolerance". — csc^-1 21:39, 3 November 2021 (UTC)
20. Zero tolerance is never helpful. 🐔 Chicdat  ^{Bawk to me!} 11:11, 5 November 2021 (UTC)

Discussion 1B Zero tolerance for incivility or personal attacks

@力 and Joe Roe: So are you saying that RfAs are in fact civil and not corrosive? That would seem to go against the consensus established in the previous discussions. Nosferattus (talk) 18:06, 31 October 2021 (UTC)

I am saying that adding this rule will not make discussions more civil. User:力 (power~enwiki, π, ν) 18:08, 31 October 2021 (UTC)

To expand on that: without making clear *who* will do the enforcement (bureaucrats if you can get them to agree to it, some new group otherwise), *what* is an inappropriate comment (something like "bad CSD tagging" must not be considered a personal attack), and *where* the inevitable disagreements over whether comments should be removed should be litigated (somewhere far away from the RFA, hopefully) this will certainly just make things worse. If you try to explain all that, we just have the (still being drafted) 1A proposal. User:力 (power~enwiki, π, ν) 23:57, 31 October 2021 (UTC)

• @Nosferattus: who do you think should remove the comments? How could the commenter "appeal" to get the comment reinstated, if the comment was necessary (albeit unpleasant) as part of scrutinising a candidate, and not incivility upon closer inspection? If a comment is removed, is it removed without comment or any evidence that it was ever left, or with a {{Redacted}} message or some other notice, and if a vote consists entirely of a personal attack then is the vote left behind? — Bilorv (talk) 18:44, 31 October 2021 (UTC)
  • Anyone could remove the toxic comment. To appeal, the poster would ask to have the comment reinstated. This isn't a new process. The only thing that's new is that the existing policies would be strictly enforced at RfA rather than laxly enforced (as they are now). Nosferattus (talk) 23:28, 31 October 2021 (UTC)
    • The problem is that trying to legislate a culture change will not work, particularly when the old culture is the one voting on the legislature and decides that no, actually, they'd prefer to keep the personal attacks and incivility around, thanks for asking. — Bilorv (talk) 12:18, 1 November 2021 (UTC)
• RfA is a discussion about a person's trustworthiness and competence. My default support vote text is "Trusted, competent". Any opposition from me is practically a personal attack about trustworthiness and competence, but I'd expect not to be sanctioned for not writing my usual text. "Talk about content, not the contributor" works on article talk pages, but not at RfA. ~ ToBeFree (talk) 18:54, 31 October 2021 (UTC)

  @ToBeFree: I think the intent of this is not to prohibit commenting on such issues, but to enforce it being done in a constructive and polite fashion. You can very well say that you don't think X is skilled enough without saying "X is an incompetent [...]"; and you can certainly also explain why you think so (hence giving constructive criticism and not pile-on incivility). RandomCanadian (talk / contribs) 14:54, 2 November 2021 (UTC)

• These policies already apply, so I'm not sure it's worth opposing. However I don't believe this proposal as written will achieve its goal for the reasons others have given. I do support moderation by bureaucrats per the 2015 RfC. — Wug·a·po·des​ 20:18, 31 October 2021 (UTC)
  • Agreed, on all points. —Cryptic 03:34, 1 November 2021 (UTC)
• RFA is kinda sorta an exemption in that it is manifestly a discussion of a specific users fitness for a particular role, but personal attacks are already not allowed anywhere on the project. Beeblebrox (talk) 21:51, 1 November 2021 (UTC)

  I disagree an exemption is necessary to discuss a user's suitability for a role. This can be done in a constructive manner and centred on the user's behaviour, not the underlying motivations. isaacl (talk) 22:21, 1 November 2021 (UTC)

  @RandomCanadian: I said that I disagree that an exemption is necessary. isaacl (talk) 14:49, 2 November 2021 (UTC)

  Noted, fixed. RandomCanadian (talk / contribs) 14:51, 2 November 2021 (UTC)

1C Semiprotect all RFAs/voter requirements

All RFAs are semiprotected so that anonymous editors and non-autoconfirmed accounts cannot edit them. Only !votes made from registered accounts that were autoconfirmed when the RFA starts will be counted.

Support (Semiprotect all RFAs/voter requirements)

1. The signal:noise ratio of anons and new accounts to RFA is very low. Plus, this impedes the drive-by doxxing trolls. Many other large wikis have voting requirements that are more extensive - German, French Wikipedias, Wikidata come to mind. The second sentence is meant to close the {{editprotected}} loophole as well as addressing the odd cases where autoconfirmed is given as part of the confirmed flag or a global rights package. --Rschen7754 07:15, 1 November 2021 (UTC)
2. Support unless somebody can furnish diffs of IPs or new accounts making significant contributions that swings consensus. Ritchie333 ^{(talk) (cont)} 14:08, 1 November 2021 (UTC)
3. Support, and better still, Extended Confirmed. Kudpung กุดผึ้ง (talk) 11:59, 7 November 2021 (UTC)

Oppose (Semiprotect all RFAs/voter requirements)

1. I don't think that at RfA or RfB IPs or newby accounts have a substantial negative impact, myself - they aren't really the main reason for the poor reputation of these processes. Also, the tendency of people to want to apply semi/extended confirmed protection everywhere that's not article space bothers me, as there is usually little evidence of a substantial benefit. Jo-Jo Eumerus (talk) 11:19, 1 November 2021 (UTC)
2. More of a solution looking for a problem. Policy allows for IPs to opine, just not be counted in the !vote. SP would break this tradition without really solving any major problem. Dennis Brown - 2¢ 11:32, 1 November 2021 (UTC)
3. Not currently an issue, nor is there a reason to exclude the possibility of long-term IP editors contributing in cases where they may have novel input (e.g. raising the issue of a candidate having an attitude of biting IP editors). — Bilorv (talk) 12:32, 1 November 2021 (UTC)
4. Per all. Not necessary, especially as IPs already can't !vote, and won't necessarily help. – John M Wolfson (talk • contribs) 12:49, 1 November 2021 (UTC)
5. We don't protect pages unless we need to and I have yet to see disruption at RfA that can be handled with reverts and the odd block. – Joe (talk) 14:28, 1 November 2021 (UTC)

   You're forgetting the occasional revdel or suppression, which (in the case of doxxing) happens after the privacy violation. --Rschen7754 18:07, 1 November 2021 (UTC)

6. Fully agreed with Dennis Brown - this is a solution looking for a problem. Ganesha811 (talk) 19:12, 1 November 2021 (UTC)
7. New editors participating is best handled on a case by case basis. HighInBC ^{Need help? Just ask.} 01:06, 2 November 2021 (UTC)
8. Per above. IP editors already cannot !vote in RfA's, but I see no reason to prevent them from commentating. -FASTILY 05:44, 2 November 2021 (UTC)
9. Not an issue, and non-accounts can provide (and have provided) valuable contributions. Prohibiting !voting is sufficient. ~ Amory (u • t • c) 15:26, 2 November 2021 (UTC)
10. Preemptive protection is unnecessary, and would be counterproductive by preventing any meaningful input from IPs. — csc^-1 21:42, 3 November 2021 (UTC)
11. Protection is overkill, and I think there's an argument that this proposal is out of process altogether given that phase 1 section L rejected the proposition that "the kind of editors who participate in RfA are ill-suited for the task". I could support raising the suffrage requirements (sans protection), but this isn't the way to do it. Extraordinary Writ (talk) 23:16, 6 November 2021 (UTC)

Discussion (Semiprotect all RFAs/voter requirements)

Out of curiosity - what problem are we fixing with this? How many RfA's are being hijacked by non-autoconfirmed accounts or IPs? Worm^TT(talk) 08:35, 1 November 2021 (UTC)

• As above, it might be hard work, but some statistics on the number of edits by IPs/non-autoconfirmed-users would be useful. Is there a reason anyone under extended confirmed (500 edits/30 days) should vote at an RFA? Their opinions would be welcome on the talk page in case they can point to a problem, but such votes are problematic given the possibility of attempts to rig RFAs. Johnuniq (talk) 08:38, 1 November 2021 (UTC)
• I think this (redacted, admins only) is a good example of the problem. Ritchie333 ^{(talk) (cont)} 14:53, 1 November 2021 (UTC)
• Harassment from trolls and LTAs - which can dissuade people from running. --Rschen7754 18:02, 1 November 2021 (UTC)
• Harassment from trolls and LTAs goes with the mop, not just with RFA, depending to some extent on where one deploys the mop. I do not see how this could be entirely preventable, even in theory, while remaining the encyclopedia that anyone can edit. · · · Peter Southwood ^(talk): 19:00, 3 November 2021 (UTC)
• The heading for this section references two things: semiprotecting all RfAs and imposing !voter requirements. Although these things seem similar, they aren't quite the same. I for one would likely support some sort of !voter requirement but oppose enforcing it via semiprotection, and I imagine others would feel the same way. (Regardless, though, this is not a serious problem, and phase 1 quite firmly rejected the idea that "the kind of editors who participate in RfA are ill-suited for the task.") Extraordinary Writ (talk) 21:46, 3 November 2021 (UTC)
• Again, there is some reluctance to provide stats. It was done easily enough here, why can't it be done for this series of reform discussions? Or is anecdotal evidence the new norm? Kudpung กุดผึ้ง (talk) 12:04, 7 November 2021 (UTC)

Issue 2: Level of scrutiny

Many editors believe it would be unpleasant to have so much attention focused on them. This includes being indirectly a part of watchlists and editors going through your edit history with the chance that some event, possibly a relatively trivial event, becomes the focus of editor discussion for up to a week.

2A Introduce an optional "generic question" at least 48 hours into an RfA

Have, in addition to the 3 standard questions, a question of the form:

n. Is there a question you wished was asked during the RfA? If so, answer it.

After at least 48 hours after the start of the RfA.

Support 2A Introduce an optional "generic question" at least 48 hours into an RfA

1. As proposer.  – John M Wolfson (talk • contribs) 16:12, 31 October 2021 (UTC)
2. I think this would be a positive change that allows candidates to highlight things voters may have missed. Seems low risk, high reward to me. Trainsandotherthings (talk) 16:15, 31 October 2021 (UTC)
3. Seems positive without negative Nosebagbear (talk) 16:20, 31 October 2021 (UTC)
4. I found, and also probably other candidates felt similar, that a candidate may not be able to provide comment on a issue if someone hasn't already asked the question. By providing this optional self-asked question, the candidate doesn't have to wait to provide their thoughts on a situation which may have been misunderstood or needs further context. This wouldn't allow candidates to badger opposers with rebuttals, but would allow candidates to provide a clarification or give an answer for something which has been raised by commenters / opposers. For example, a hypothetical candidate has a number of oppose votes due to a block log entry where they were blocked for a reason later found to be incorrect. This candidate, or others, may feel a need to "respond" to these oppose voters. The candidate could provide their viewpoints in this answer instead of directly responding to specific voters or comments, and so means their response isn't directed and is for all who intend to comment at the RfA. Dreamy Jazz ^{talk to me | my contributions} 16:30, 31 October 2021 (UTC)
5. Per Nosebagbear. The only question for me is whether this will make candidates comfortable addressing opposition or whether they will continue to feel pressure not to respond to anything negative. If that happens, we could adjust the wording to more explicitly offer the chance to respond to concerns raised. {{u|Sdkb}} ^talk 17:19, 31 October 2021 (UTC)
6. Support. RfA has an extremely restrictive etiquette for candidates, who will get pile-on opposed as soon as they address any opposes, even if they have a new and non-combative insight that may change participants' opinions. I see this proposal as much more of a social change than a rule change, though it is dressed up as a new procedure. It is a regular complaint from candidates who have run that they did not get sufficient chance to address comments that were raised. They instead have to watch a game of telephone where someone opposes based on an incomplete understanding of a situation, and a supporter responds to that oppose with their perspective on the candidate's perspective, and the discussion continues on until it bears no resemblance to the situation referenced. — Bilorv (talk) 19:14, 31 October 2021 (UTC)
7. I can certainly imagine cases where a candidate has something they wish they could address, but is (not without cause) afraid of being seen as "badgering" if they do so (and I certainly also understand why we don't want the candidate arguing over all the opposes; that will just turn into a mess.) This is a good, nonconfrontational way for candidates to put forth clarifications or additional information that might be helpful to RfA participants. In any case, I certainly can't see any real downside—if the candidate does something inappropriate with this, participants are of course free to factor that into their decision as well. There's certainly potential upside here, and little to no potential downside, so I'd like to see this one tried. Seraphimblade ^{Talk to me} 23:28, 31 October 2021 (UTC)
8. Support as meaningless. Anyone can ask a question, there is nothing at all preventing a candidate from asking themselves a question right now so I don't see what this changes.
   Note: I considered this exact same wording but with "Oppose as meaningless" which would have resulting in the exact same result. Pass or fail the candidate has the same abilities in this regard. HighInBC ^{Need help? Just ask.} 23:47, 31 October 2021 (UTC)
9. Support, but why wait 24H? Anyway, support +1Paradise Chronicle (talk) 04:52, 1 November 2021 (UTC)
10. Support Lomrjyo (publican) ^(taxes) 15:26, 1 November 2021 (UTC)

Oppose 2A Introduce an optional "generic question" at least 48 hours into an RfA

1. Unnecessary instruction creep and I don't see how it solves the purported problem. If there are questions the candidate feels should be answered they are free to answer them in their opening statement, or on their RfA's talk page at any time. I don't follow the idea that if there is already too much scrutiny the candidate should further increase that scrutiny by asking themselves a question that they then must answer. This also implies a restricted time window, outside of which the candidate's ability to participate in their own RfA is limited, and I don't think limiting a candidate's rights to participation is helpful. – wbm1058 (talk) 16:27, 31 October 2021 (UTC)
2. Candidates can already make any statement they want at any time. Hut 8.5 17:50, 31 October 2021 (UTC)
3. Meh, weak oppose - mostly per Hut 8.5. This seems too formal, but be fine with updating the directions to remind candidates that they can amend their statements as needed. — xaosflux ^Talk 19:12, 31 October 2021 (UTC)
4. Unnecessary. Would not add anything of a net benefit to process. Kudpung กุดผึ้ง (talk) 19:16, 31 October 2021 (UTC)
5. In general, administrators must be able to find a way to convey their points without seeming unduly defensive or non-responsive. There are already avenues with the current requests for adminship format that candidates can take advantage of, thus demonstrating their communication skills. isaacl (talk) 21:41, 31 October 2021 (UTC)
6. Per Hut 8.5. Unnecessary process creep with no obvious benefits -FASTILY 04:22, 1 November 2021 (UTC)
7. No demonstrable need. Anarchyte (talk) 06:14, 1 November 2021 (UTC)
8. This isn't a game show. If it really is necessary for a particular candidate, the candidate can do it themselves. --Rschen7754 06:44, 1 November 2021 (UTC)
9. Too WP:CREEPy. Also a WP:SLOP. 🐔 Chicdat  ^{Bawk to me!} 10:59, 1 November 2021 (UTC)
10. WP:CREEP without tangible benefits. Dennis Brown - 2¢ 11:33, 1 November 2021 (UTC)
11. Not a bad question, but I really don't see the point in making it mandatory, especially with the weird time-lag that will make it yet another formality someone has to remember to do (or write a bot for). If the nine people who have supported so far just agree to ask it themselves at the next nine RfAs, we'll be covered for a couple of years. – Joe (talk) 12:27, 1 November 2021 (UTC)
12. Optional questions are not really optional until about 24 hours before an RfA closes. The usual procedure is 1. Silly question asked 2. Question criticised as silly. 3. Criticism rebuked as unacceptable 4. Rinse and repeat 5. Question finally answered. Optional: 6. Questioner blocked not long after the RfA closes due to sockuppetry, NOTHERE or both. Ritchie333 ^{(talk) (cont)} 14:12, 1 November 2021 (UTC)
13. Don't see a need to add additional rules/instructions without a clear tangible need. - wolf 16:59, 1 November 2021 (UTC)
14. Doesn't solve any real problems. Beeblebrox (talk) 21:20, 1 November 2021 (UTC)
15. The question is fine, but there's no real need for it to be codified in policy. — csc^-1 21:44, 3 November 2021 (UTC)

Discussion 2A Introduce an optional "generic question" at least 48 hours into an RfA

• The general idea is fine, and implementing it in this way would also be okay. Theoretically, the candidate can already ask up to two questions to themselves. It does occasionally happen: I did that at my RfA (Q4 was mine). I had also deliberately kept the second question in hand to respond to possible concerns. It can't hurt to formally allow or standardize this. ~ ToBeFree (talk) 16:41, 31 October 2021 (UTC)
• I'm neutral on this propossal. As said above, formalizing this seems like a fine idea, but I don't see how this is supposed to adress the issue at hand. Isabelle ^🔔 17:00, 31 October 2021 (UTC)
• Re: "Candidate may feel a need to "respond" to oppose voters" – See how I handled this at Wikipedia talk:Requests for adminship/Wbm1058#Responding to the content creators. Forcing me to wait 48 hours to respond, or making me ask myself an artificial question to respond to the real concerns raised by others... it's just not helpful. wbm1058 (talk) 17:07, 31 October 2021 (UTC)
• Re: "Wouldn't allow candidates to badger opposers with rebuttals" – oh, yes, we want to allow candidates to badger their opposition, though we'd prefer that they didn't, because their badgering could be evidence supporting an "oppose" vote. wbm1058 (talk) 17:07, 31 October 2021 (UTC)
• Maybe a better idea would be to allow all candidates to post a nomination statement, even if they're nominated by someone else? – filelakeshoe (t / c) 🐱 17:31, 31 October 2021 (UTC)

If I recall correctly, someone did that once and ironically put their foot in it and consequently lost their bid for the mop. Kudpung กุดผึ้ง (talk) 19:18, 31 October 2021 (UTC)

• Not a fan but I don't see any harm so I won't explicitly oppose. That said, I don't see how this is any better than just letting the candidate respond inline or just reminding them that they can ask themselves questions. — Wug·a·po·des​ 20:22, 31 October 2021 (UTC)
  • Letting candidates directly respond to opposes breaks purdah and invites badgering. Also, a candidate asking themselves a question seems rather odd in my view, although this is just a formalized version of it. – John M Wolfson (talk • contribs) 20:26, 31 October 2021 (UTC)
    • But candidates do respond to opposes, and if the concern is that they are looked down for it (something I haven't really seen in recent years) why not just change our guidance to reflect that community expectation? Why formalize a new process that duplicates something candidates can already do? If candidates asking themselves questions is odd, asking them to ask themselves a question is just as odd. — Wug·a·po·des​ 22:12, 31 October 2021 (UTC)
• I'm also neutral. Not sure this is better than "candidates or their nominators can also ask questions", which is apparently already allowed by policy and thus wouldn't even need an RFC. User:力 (power~enwiki, π, ν) 23:20, 31 October 2021 (UTC)

2C Cohorts of candidates

Withdrawn and moved to talk

2D Quarterly elections

Admin elections are held every three months, replacing the current asynchronous nominations of RFA.

Candidates must sign up by a certain date, and all the RFAs for that quarter will start and end at the same times. The nominations themselves run just as current RFAs do (7 days, public voting and discussion, etc.)

Support (Quarterly elections)

1. This is an attempt to address some of the objections brought up in 2C and 8B in a different proposal. At four times a year, hopefully all prospective candidates can make one of those times. There is no indeterminate waiting period as was proposed with the cohorts. And the opposes to 8B based on the SecurePoll go away. --Rschen7754 06:38, 1 November 2021 (UTC)

   I will also note that we already make candidates wait up to a year to apply for CU/OS (appointments are held only once a year), so this is not entirely unprecedented. --Rschen7754 18:24, 1 November 2021 (UTC)

2. The September 2020 RfA flight was a forerunner to this and it went very well. I imagine that regular admin elections would eliminate the "singling out" problem that makes so many RfAs get stressful. 🐔 Chicdat  ^{Bawk to me!} 10:58, 1 November 2021 (UTC)
3. Support. This just formalises an existing informal process where candidates tend to run in groups, whether co-ordinating this behind the scenes or deciding to pull the trigger when they see someone else is running. There is no need for RfAs to be done ad hoc at random intervals anymore, when we have so few RfAs. This would be better for voters too, as they would know when they need to schedule in some time to research candidates. (Rather than, say, a sockpuppet running for adminship with no warning and ArbCom having to privately decide if they are a sock within the week...) It is surprising to me that opposers think that anybody runs for RfA with less than three months of preparation and planning. — Bilorv (talk) 12:13, 1 November 2021 (UTC)
4. Might be worth trying. Of course, informal versions of this are easily possible within the current structures. —Kusma (talk) 15:05, 3 November 2021 (UTC)

Oppose (Quarterly elections)

1. Another proposal that seems like a solution looking for a problem. I fail to see how this will bring more quality candidates or solve problems with the system itself. If anything, it will discourage a few quality candidates. It isn't like we have SOOOO many RFAs that we need to corral them. Thinking this will make observers "nicer" and less likely to single anyone out? This doesn't change how observers react, just when. Dennis Brown - 2¢ 11:36, 1 November 2021 (UTC)

   This overlooks the historical record that, as of late, a large number of candidates do prefer delaying their RfAs in order to run alongside other candidates, and even sometimes manage to co-ordinate this themselves behind the scenes while not making it public that any of them are planning to run. Do you think the five candidates running within a week of each other in January 2020 or September 2020 was a coincidence? Have you asked them why they chose to do so? — Bilorv (talk) 12:13, 1 November 2021 (UTC)

   Leaving things as they are will not remove their ability to do so. As to why, I can think of several reasons, but I didn't ask those particular candidates, which represent a very small number of candidates anyway. Dennis Brown - 2¢ 23:47, 1 November 2021 (UTC)

   The problem I have with that is how does one know or find out about a bunch of people planning to run? It's really just who you know and word of mouth through Discord or IRC or email. We need some way to level the playing field - maybe it's not this, but then we need to come up with something. --Rschen7754 04:17, 2 November 2021 (UTC)

   Potential candidates can let a point of contact know, who could co-ordinate amongst the editors. isaacl (talk) 04:23, 2 November 2021 (UTC)

   And who is that point of contact? --Rschen7754 04:26, 2 November 2021 (UTC)

   Last time, Barkeep49 volunteered. We can create an appropriate page for it and solicit volunteers. Also see Wikipedia talk:Requests for adminship/2021 review/Brainstorming § Status check, where I discussed the idea of having a volunteer week where those involved in any Wikipedia initiative could solicit volunteers. (I suspect uptake will be embarrassingly low, but I'd be willing to try to slowly build it up over time if there's any interest at all.) isaacl (talk) 04:47, 2 November 2021 (UTC)

   In terms of how I found candidates it was through posts to WT:RFA and AN that candidates and their noms found me. I announced it well in advance and would mention it when appropriate in other places too. There were another 5 or so editors who explored a run at various levels of seriousness beyond the five who did, including John Wolfson who I would go on to nominate a few weeks after. I have been skeptical of doing another of these owing to the loss of two editors who I am not sure would have left the project absent the initiative and zero who passed who I think wouldn’t have run without it. However, based on the feedback given in this process, not to mention the data I found, if no reform passes that would rendered such an effort moot, including this one, I will commit to doing this a second time. Best, Barkeep49 (talk) 08:30, 2 November 2021 (UTC)

2. I agree with Dennis Brown here. I also think candidates could end up being unable to participate in RfA just because they got unlucky. This really doesn't seem ideal to me, at all. Invalid^OS_talk 12:05, 1 November 2021 (UTC)
3. The good part of #8B Admin elections is the election format, not the schedule. That's just a practical constraint on holding SecurePoll elections. If the only benefit is running at the same time as someone else, we can, and do, do that under the current system just as well. – Joe (talk) 12:25, 1 November 2021 (UTC)
4. Agree with Dennis Brown. I wouldn't want a candidate to run because it's the right time window for others, if it's not suitable for them. Ritchie333 ^{(talk) (cont)} 14:13, 1 November 2021 (UTC)
5. This seems like a solution without a problem. - wolf 17:01, 1 November 2021 (UTC)
6. Nope, candidates shouldn't have to wait months to apply for access as the only path to adminship, and if this was simply an option instead of a replacement it can already happen now so no change is needed. — xaosflux ^Talk 18:15, 1 November 2021 (UTC)
7. This seems like an extra rule that does not solve any problem. HighInBC ^{Need help? Just ask.} 01:07, 2 November 2021 (UTC)
8. Definitely not. We don't need more rules that increase complexity without actually solving any of our existing problems. -FASTILY 05:42, 2 November 2021 (UTC)
9. I can see a lot of downsides to this for candidates (who can't schedule their rfa at their convenience but have to do it at set times) and for voters (who have more work to review multiple candidates at once), and I do not think last September's flight went well at all, we lost editors, and I think it's because the flight format may have encouraged some to run who should not have run. Generally speaking, I'm not sure that lowering the barriers to entry is a good idea if we don't also lower the barriers to a successful exit. In other words, don't do things to encourage people to run if we're not going to lower the bar for passing. Levivich 15:40, 3 November 2021 (UTC)

   @Levivich: Which editors did we lose? As far as I can tell, all those editors are chugging along perfectly fine. 🐔 Chicdat  ^{Bawk to me!} 11:47, 7 November 2021 (UTC)

10. Candidates should be able to schedule their RfA at their own convenience. — csc^-1 21:47, 3 November 2021 (UTC)
11. Per Joe: this takes the bad part of 8b and leaves out the good. Extraordinary Writ (talk) 23:12, 6 November 2021 (UTC)

Discussion (Quarterly elections)

This proposal can be implemented now in parallel with ad hoc requests for adminship without requiring community consensus approval, which I feel would cover its main benefits. Thus at least for initial implementation, I do not feel it is necessary to eliminate ad hoc requests. isaacl (talk) 14:48, 1 November 2021 (UTC)

2E Use year numbers instead of iteration numbers in RfA page titles

Having to expect a "2" in the title of the next RfA may discourage first attempts, as it may seem to indicate "having failed before" in the most prominent way possible. It may also discourage trying again afterwards. Use year numbers instead, for every RfA.

Status quo:

• Wikipedia:Requests for adminship/Example
• Wikipedia:Requests for adminship/Example 2
• Wikipedia:Requests for adminship/Example 3
• Wikipedia:Requests for adminship/Example 4

Proposal:

• Wikipedia:Requests for adminship/Example 2009
• Wikipedia:Requests for adminship/Example 2014
• Wikipedia:Requests for adminship/Example 2014 2
• Wikipedia:Requests for adminship/Example 2021

Support 2E Use year numbers instead of iteration numbers in RfA page titles

1. As proposer. This was one of my concerns before starting my first RfA, so perhaps I've found a convenient, simple improvement in the spirit of 5A's simplicity. It's not a huge change, but it may make a tiny positive difference.
   Edit: Sorry for the ambiguity. I had "every future RfA" in mind. I'm fine with moving the old ones as well, leaving redirects behind, if there's an additional consensus for that among the supporters. ~ ToBeFree (talk) 20:05, 6 November 2021 (UTC)
2. These seems a simple, stigma reducing, solution. —¿philoserf? (talk) 20:29, 6 November 2021 (UTC)
3. This is an interesting idea; it might help to some extent. – John M Wolfson (talk • contribs) 20:37, 6 November 2021 (UTC)
4. I think the "2" is pretty much a mark of shame. The one issue with this is that it is valid to want to look at previous RfAs, but that can be done in the little right pop-out box. Also handles the issue of people renaming and doing multiple RfAs. Also, would existing RfA be moved or no? Naleksuh (talk) 22:37, 6 November 2021 (UTC)
5. Simple and worth trying; I would support moving previous RFAs for consistency reasons. — Wug·a·po·des​ 22:38, 6 November 2021 (UTC)
6. At the very least, it would make page titles more informative. XOR'easter (talk) 22:40, 6 November 2021 (UTC)
7. I don't see any downsides to this, and it would indeed be more informative than the current system. Trainsandotherthings (talk) 22:41, 6 November 2021 (UTC)
8. Sure. My preference would be using parentheses similar to how we disambiguate for articles. --Rschen7754 23:04, 6 November 2021 (UTC)
9. Weakly. This could possibly have an incrementally positive effect, and it certainly wouldn't make things worse. It's clearly not a panacea, but that's not a reason to oppose. I do think that moving all of the old RfAs would likely be more trouble than it's worth. Extraordinary Writ (talk) 23:10, 6 November 2021 (UTC)
10. Definitely in the "tinkering around the edges" category, but that doesn't mean it's not a good idea. – Joe (talk) 10:46, 7 November 2021 (UTC)
11. No major problems with this proposal. It also provides more information in the page title as it gives the year of a RfA. Dreamy Jazz ^{talk to me | my contributions} 13:01, 7 November 2021 (UTC)

Oppose 2E Use year numbers instead of iteration numbers in RfA page titles

1. Stigma against failing an RFA doesn't come from a scarlet number in the page URL, it comes from the community. And the current proposal doesn't solve enough of the edge cases to overcome the inertia against change. User:力 (powera, π, ν) 23:59, 6 November 2021 (UTC)
2. Moving previous RFAs for consistency reasons is a good reason to oppose. Sounds like a lot of work, for dubious benefit, distracting whoever does this from working on something more useful. Is the point to try to hide the fact that a second-attempt is a second attempt, and hope the community forgets the first try? You could rename the first attempt to "2", then "3" on the third try, numbering down from oldest to newest, so that the current attempt never has a number. wbm1058 (talk) 00:32, 7 November 2021 (UTC)
3. Nugatory value. If you're on a +1 RfA the earlier RfAs are disclosed in plain sight. If you're contemplating a 1st RfA but are concerned that a failure will result in any subsequent attempt being numbered... well, seriously!? In reality, to be blunt, this is a pretty poor attempt to disguise that a candidate has previously attempted an RfA and failed. There's not much stigma in that - many Admins have come through that root. Leaky caldron (talk) 08:29, 7 November 2021 (UTC)
4. This is the most WP:SLOPpy proposal I have ever seen. I am astonished that anyone could ever support it. 🐔 Chicdat  ^{Bawk to me!} 11:28, 7 November 2021 (UTC)
5. Weak oppose - Don't think this is going to fix anything, especially since a list of all of your prior RfA's is in a big box right at the top of subsequent RfA's (and in Special:PrefixIndex/Wikipedia:Requests for adminship/Example). That being said, so long as all the prior discussions are still prominent I don't really care what they are called - not sure if it will break some reports but we don't need to build around report writers. — xaosflux ^Talk 13:22, 7 November 2021 (UTC)

Discuss 2E Use year numbers instead of iteration numbers in RfA page titles

@Wugapodes: My reasoning for wanting to use slashes is because they are RfAs for the same user, and also makes it clear the name of the account and makes conflicts impossible. It's less important with years than with numbers, but still relatively important. It looks like you passed your first RfA, but lets say you had a second one at Wikipedia:Requests for adminship/Wugapodes 2. This could be an RfA for an account called User:Wugapodes 2. I don't think that specifically has happened before ever (an existing username with a single-digit number, both of whom have RfAed before), but there are RfAs for account names ending in numbers, and it is confusing. The new system (partially) addresses this, because instead it will be Wikipedia:Requests for adminship/Wugapodes 2021 and an account called User:Wugapodes 2021 would RfA at Wikipedia:Requests for adminship/Wugapodes 2021 2021- but I think slashes "bundle" them and look better than spaces which are unorganized and prone to conflicts. Plus, if no slashes, why not Wikipedia:Requests for adminship Wugapodes or just Wikipedia:Wugapodes' request for adminship?

I hope this sums up my thoughts. If you disagree please let me know. Naleksuh (talk) 22:59, 6 November 2021 (UTC)

Why not Wikipedia:Requests for adminship/2021/Example as the page name format? User:力 (powera, π, ν) 23:57, 6 November 2021 (UTC)

Interesting idea. This has the advantages of allowing the current "Page 2" system to continue (but only if they're in the same year), and also allows people to browse RfAs by year filed. It would also make it really easy to update. Naleksuh (talk) 00:26, 7 November 2021 (UTC)

When making changes to 15-year-old infrastructure we should avoid introducing new complexity to the system, and new hierarchical structures (subpages) are complex. Some examples of where things could easily go wrong:

• Any RFA-related templates which rely on {{SUBPAGENAME}} will need to be changed, probably to uses of {{#titleparts:{{FULLPAGENAME}}|...}}. This discussion itself caused problems because of how it uses subpages. I modified the group edit notice for subpages of WP:RFA in order to accommodate it. Using spaces we wouldn't need to change that template at all, but using subpages we would need to add additional parser functions to handle the logic of these new levels and pages.
• There are off-wiki tools that we use and how they operate is more complex than our templates. Most tools were written on the assumption that a nomination will be a subpage of RFA and voiding that assumption risks bugs we may not anticipate. The risk of introducing a new hierarchical structure is high, but increasing the number at the end from 1 digit to 4 digits is comparatively trivial.
• Using subpages implicates pages that don't exist or that wouldn't be useful if they did exist. The .../Username/YEAR format implicates .../Username, but it probably won't exist. Even if it did exist, what use would it serve for most editors compared to the additional need to watch a page for vandalism? It would be especially useless for editors with only one RfA but would still require maintenance.
• A subpage-based solution is an anti-pattern leading to an explosion in useless subpages. Someone posts their first RfA in January 2022, it goes at WP:RFA/Username/2022, and it fails. 11 months later they try again, where does it go? Would we use a subpage like WP:RFA/Username/2022/2 or would we use a space? If we use a space, why not just use a space for the whole thing? If we use a subpage, what do we do about the first one? Move it or leave a non-sense hierarchical structure? What if it goes to a crat chat? We quickly have the possibility of going 5-levels deep on subpages, each level of which we will need to maintain.
• Introducing complexity into a legacy system in order to avoid problems that we have never encountered is not a good idea. If someone who isn't me created User:Wugapodes 2, they would get a WP:UNAMEPOL block for a username too similar to an existing editor. I looked through 5000 most active-editors by edit count and counted maybe 6 in that list who fit the pattern of "alphanumeric string and 4 digit number separated by a space". Most were years prior to the creation of wikipedia, some weren't even years just 4 random numbers.

What you want are categories. If the only reason to use subpages is for grouping related pages together, we should use categories instead. Not only would they do it better, they do not have all the associated risks of extensively modifying 15-year-old infrastructure. The worst case scenarios are highly unlikely, and even if they did occur the worst case is that some people might have to read the RFA more closely. Adding new levels of subpages just seems needlessly complex and not worth the additional trouble. — Wug·a·po·des​ 01:52, 7 November 2021 (UTC)

I'm not aware of anyone expressing concerns about the naming convention for additional requests for administrative privileges. It might be reasonable to change the naming format to avoid ambiguity with user names, but personally I don't feel this proposal addresses any issues with the level of scrutiny faced by candidates. A candidate running for the Nth time will face the same amount of scrutiny, regardless of the name of the request page. isaacl (talk) 01:20, 7 November 2021 (UTC)

Issue 3: Standards needed to pass keep rising

It used to be far easier to pass RfA however the standards necessary to pass have continued to rise such that only "perfect" candidates will pass now.

3A Add clear criteria for users to start an RfA

With such pronounced rising criteria, clear standards for starting an RfA should be added, so editors do not have differing views about what is needed to pass adminship.

Extended content

A set of stringent criteria for RfA should be passed, for instance, at least: 5,000 edits 1 year of experience One non-stub article creation or one case of significant article improvement Twenty edits in preferred admin area No active restrictions No non-accidental blocks in the last year If these standards are all passed, the regular seven days of !voting will occur. If they are not, the editor cannot proceed with RfA until the standards are met.

Support (3A Add clear criteria for users to start an RfA)

1. At first glance, it is not clear what this proposal does—is it increasing standards (the opposite of what we should do to address Issue 3), because it now requires RfA candidates to pass some additional hurdles? But, I think it is very cleverly encouraging a decrease in standards: by pre-agreeing criteria like "18 months of experience", this discourages "oppose: only been here for 2 years". As currently done, everyone has their own mutually exclusive and conflicting minimum criteria that continue rising randomly and with no scrutiny. (If you don't like my description of things, re-read Issue 3, which we have just overwhelmingly agreed on as a community.)
   By simple virtue of the candidate having met the minimum conditions the community generally expect, it seems to me that supporting could be made a much simpler business ("support: meets the generally agreed minimum criteria with no exceptional disqualifying factors"), while opposition would be mostly reduced to the specific reasons every RfA needs some ad hoc discussion of the candidate—assessing their temperament, any behavioural red flags etc. A minority of people may have stricter requirements on, e.g., content creation than the community as a whole, but we already have heterodox voters at RfA and I think this proposal would lessen their influence. — Bilorv (talk) 12:29, 1 November 2021 (UTC)
2. Establishing a clear baseline for eligibility would be, I believe, a good thing. It should help reduce disputes over some of the !votes that 'oppose' because of that voter's particular criteria, which often just amounts to floating goal posts. - wolf 17:12, 1 November 2021 (UTC)
3. I agree with the general idea of having fixed criteria to judge candidates against. This would help reduce standards inflation and give closers clear justification for discarding inappropriate rationales. RfA is actually quite unusual on Wikipedia in that it doesn't involve any written standards at all, most other processes do, e.g. FAC, XfD, RM discussions, even discussions about user conduct. Hut 8.5 20:16, 2 November 2021 (UTC)
4. I support this or something similar (the specific criteria are less important to me, eg whether it's 5k edits or 10k, 1yr or 18mo, etc.). Having generally-agreed-upon minimum criteria would help both candidates and voters by providing some benchmarks. Everyone having radically different criteria is a bug not a feature IMO, and while setting the minimum for a start won't do anything about making rfa easier to pass or a better environment, it might encourage some editors to run (who would be clued in that they are eligible), and discourage some of the opposes that are far outside consensus (eg, "only been here 2 years", "less than 25k edits", or whatever). Levivich 20:24, 2 November 2021 (UTC)

Oppose (3A Add clear criteria for users to start an RfA)

Oppose. This seems like it'd encourage gaming the system, which is definitely something we don't need in RfA. Invalid^OS_talk 12:08, 1 November 2021 (UTC)

@InvalidOS: I can only assume you have misread the proposal. A candidate still has to pass a normal RfA under this proposal. They just additionally have to meet some minimum criteria to start an RfA. — Bilorv (talk) 12:29, 1 November 2021 (UTC)

@Bilorv: I didn't. Though, thinking about it a bit more, if someone did try to game the system to start an RfA, there'd probably be a WP:SNOW close so people wouldn't have to waste their time. Invalid^OS_talk 12:48, 1 November 2021 (UTC)

@InvalidOS: currently, we already experience WP:NOTNOWs as extended confirmed is the only (implicit) requirement to run. How would increasing the standards to start an RfA and leaving the standards to pass unchanged involve "gaming" in any sense, shape or form? It is not "gaming" to meet the minimum criteria exactly and then decide to run. That's just a perfectly reasonable course of action. If you can pass RfA, you haven't "gamed" anything, and SNOW closes could only decrease under this proposal. — Bilorv (talk) 12:56, 1 November 2021 (UTC)

@Bilorv: Fair point, though I was just saying that in the case someone did decide to try to game the system in some way, there'd likely be a SNOW close. Also struck out my original post. Invalid^OS_talk 13:05, 1 November 2021 (UTC)

1. Strong oppose per the rest of discussion. I feel like this would have the effect of eliminating individual criteria, which would inappropriately make RfA seem like GAN or FAC. – John M Wolfson (talk • contribs) 13:37, 1 November 2021 (UTC)
2. If this became policy, Wikipedia:Requests for adminship/Cyberpower678 2 would have failed. Ritchie333 ^{(talk) (cont)} 14:13, 1 November 2021 (UTC)
3. This simply won't work, people will still have their own standards. Beeblebrox (talk) 21:22, 1 November 2021 (UTC)
4. This isn't improving anything or increasing the number of quality admin. We have a long standing tradition of letting anyone run, and a long standing tradition of handling it just fine. I don't think we've ever "elected" a newb with 100 edits by accident, so this really doesn't solve anything. It will cause drama, however, as everyone has different ideas on what the criteria should be. This is good. We leave it wide open, and let them apply their own criteria by voting in the RFA. We know that system works. Dennis Brown - 2¢ 23:52, 1 November 2021 (UTC)
5. We need to increase the number of admins, not create new barriers. We have never agreed on admin criteria, that is why RfAs are often full of different opinions. HighInBC ^{Need help? Just ask.} 01:08, 2 November 2021 (UTC)
6. If we could agree on a set of criteria to pass RfA, then we wouldn't need RfA! Differing criteria and opinions, and the fact that they do not and cannot fully capture the entirety of a person's contributions and behavior, are why this can't work. As xaos says below, this looks like "criteria to start" not "pass," which isn't needed. ~ Amory (u • t • c) 15:30, 2 November 2021 (UTC)
7. This is too prescriptive - there are countless edge cases where a candidate could well exceed some of these criteria while still missing one. This is the sort of thing that is most useful in a descriptive nature to warn candidates about what they may likely expect. — xaosflux ^Talk 11:01, 3 November 2021 (UTC)
8. [DISCLAIMER: I'm the nominator] We need more admins, not fewer. 🐔 Chicdat  ^{Bawk to me!} 11:07, 3 November 2021 (UTC)
9. What we don't need is prescriptive criteria. — csc^-1 21:53, 3 November 2021 (UTC)
10. I don't see how this is a positive for RfA. Worm^TT(talk) 11:24, 5 November 2021 (UTC)
11. In the extended content the proposer suggests "we already have heterodox voters at RfA and I think this proposal would lessen their influence". My challenge to them is why? Anyone can edit WP, so why should unorthodox editors have less (opportunity to) influence in RfA than orthodox editors? Leaky caldron (talk) 12:31, 5 November 2021 (UTC)
12. I don't think setting this many hard rules is a benefit to RfA. This may reduce the number of WP:SNOW closes, but I think it does not model what the community wants from a candidate well enough to be seen as a imposed prerequisites. Dreamy Jazz ^{talk to me | my contributions} 13:05, 7 November 2021 (UTC)

Discussion (3A Add clear criteria for users to start an RfA)

• As a minimum, I'd be fine with this to an extent. However, I doubt "rising standards" are a problem in the first place (see my comment on the talk page) and voted against issue 3 in phase 1, and I think it's asinine to treat RfA as FAC. So, if individual criteria are to be done away with entirely I'd have to strongly oppose this. – John M Wolfson (talk • contribs) 12:45, 1 November 2021 (UTC)
  • The proposal is for these as a minimum, not a replacement: If these standards are all passed, the regular seven days of !voting will occur. — Bilorv (talk) 12:56, 1 November 2021 (UTC)
    • I would still oppose these things being too specific. The only three major criteria I would like receive any official sanction is "Tenure", "Some content work", and "Some technical/backstage work", all as defined and interpreted by users. If that's not so different from the status quo, then so be it. – John M Wolfson (talk • contribs) 13:03, 1 November 2021 (UTC)
• I feel like the article creation criterion might need revision. I feel like there are other ways of demonstrating policy knowledge that might not necessarily be creation-related. The AfD requirement is also a bit odd. To me, that makes it seem like every admin is somehow supposed to work in AfD, with everything else on the side. Invalid^OS_talk 13:11, 1 November 2021 (UTC)
  • Admins need to have done some content, on if nothing else a moral level; we are an encyclopedia, after all, not some anime-discussing image board or tech forum. Also, AfD works well because it is a ubiquitous process that involves an admin action (deletion) and that non-admins can partake in quite easily, has some objective stats in the form of match rate (albeit rather gameable, but still), and is one of the best ways to demonstrate policy knowledge. – John M Wolfson (talk • contribs) 13:28, 1 November 2021 (UTC)
• This doesn't seem like a list of requirements to "pass RfA" but a list of minimum requirements to "start an RfA". — xaosflux ^Talk 18:16, 1 November 2021 (UTC)
  • Indeed. If we could agree on criteria, then RfA would be a breeze! ~ Amory (u • t • c) 15:27, 2 November 2021 (UTC)
  • @Xaosflux: I don't know who wrote the proposal (whoever they are, they don't seem to be supporting it), but in the interest of clarity—and that proposals here are meant to be adjusted in the first week and not "owned" by any individual—I've changed the title and part of the text from "pass RfA" to "start an RfA", as I agree that the title is misleading. Anyone has my permission to change it back if they think my action is out of line. — Bilorv (talk) 15:42, 2 November 2021 (UTC)
    • @Bilorv: It was me who wrote the proposal. I oppose it myself. 🐔 Chicdat  ^{Bawk to me!} 10:04, 3 November 2021 (UTC)

      Chicdat, it's perfectly fine to change one's opinion after making a proposal. I'd just like to note that it should not be done by someone already opposed to their own idea, as people opposed to their own proposal are unlikely to present it convincingly and may ruin an otherwise good proposal with weak arguments. ~ ToBeFree (talk) 20:09, 6 November 2021 (UTC)

Issue 4: Too few candidates

There are too few candidates. This not only limits the number of new admin we get but also makes it harder to identify other RfA issues because we have such a small sample size.

4A Opt-out sortition to nominate candidates

A random set of 5 users who meet a select base criteria would, using an opt-out system and sortition, be nominated for adminship every 4 months.

Full details

The process is as follows: The criteria will be: 10,000 edits (userspace/sandbox doesn't count); 20 months of active editing; no blocks in last 5 years (accidental blocks to be manually excluded); no active restrictions; at least (A) one GA/FA/FL (B) or 5 created (non-stub) articles; has participation at 35 or more different AFDs; and has not run for RfA before. Instead of nominators, an "advocate" would be assigned to each RFA to write an opening statement and shepard the process along. The sortition list of eligible candidates would have a month preceding the drawing where it is held for review by functionaries. If someone was added when compared to the previous list, they would have to be manually verified to ensure the eligibility criteria is met. Following the drawing, candidates would have one week before the RFA goes live to do a final opt-out. However, following that, a candidate can still withdraw the RFA early after consulting with the assigned advocate. Candidates would be under no obligation (and therefore should not be expected to) actively take part in their RFA. They are free to ignore it entirely or hang out and answer questions. This is to ensure the process complies with WP:VOLUNTARY. If an RFA is successful under this process, the candidate will be informed of the results and will have to post to WP:BN to ask for the tools and understanding that they will now be subject to WP:ADMINACCT and WP:SECUREADMIN. If they don't do that before the next drawing, then they will have to run again.

Support 4A Opt-out sortition to nominate candidates

1. Sounds good to me, I think many problems are surmountable.  – John M Wolfson (talk • contribs) 16:12, 31 October 2021 (UTC)
2. Curious to see whether this will work. Worth a try. The problem of not having enough candidates is urgent enough to try more radical measures. Femke (talk) 16:54, 31 October 2021 (UTC)
3. I support this idea in concept, though I'd potentially want to change the numbers of candidates and timeframe. Not entirely sure how. Trainsandotherthings (talk) 17:19, 31 October 2021 (UTC)

   I'm sure RfCs could change numbers/exact criteria if any prove to be a problem, but establishing a mandate for the sortition in some form is the most important priority. — Bilorv (talk) 19:07, 31 October 2021 (UTC)

4. Worth trying. —valereee (talk) 17:20, 31 October 2021 (UTC)
5. Strong support for an excellent proposal. Without some institutionalised/formalised process to encourage nomination, no method can improve on the existing system of a few highly-respected admins reaching out to individuals offering to nominate them, which has—due in no part to these admins—been an astounding failure in the last few years. We have had 10 RfAs in this calendar year, which have produced 6 currently-active admins ("active" generously construed), and we need at least 100 successful RfAs per year if we expect to maintain over 1,000 admins and expect every single new admin to contribute for the next 10 years and no admin to be desysopped.
   A sortition is a good way of eliminating human bias that arises from such things as a few elite admins being responsible for a supermajority of RfA nominations, to address 力 below, and could plausibly see a new diversity of admins promoted that would encourage existing editors who had never considered running ("I don't see why I'd want to be admin" / "I don't work in any of the 'admin areas'") to do so.
   The sortition also has very well thought out criteria, timings and associated processes, but I would be supporting it nonetheless if it didn't, as it is far more important to get some sort of process like this off the ground, and it can be refined as the community sees fit once we've had a couple of runs of it and understanding which criteria/bureaucracy can be improved upon. — Bilorv (talk) 19:07, 31 October 2021 (UTC)
6. Qualified support on the condition that this be a one year trial, after which a subsequent RfC is required for it to continue. I think this is worth a try, but I'm uncomfortable with authorizing it and just hoping it works. I would like the community to have a chance to evaluate whether it worked and what changes could be made to improve it. — Wug·a·po·des​ 20:26, 31 October 2021 (UTC)
7. Support As the proposer. Regarding HighInBC oppose comment, I would submit for consideration this MFD and {{User wikipedia/Administrator someday}}. As most people there agreed, most folks think that using the userbox which actively states you want to be an admin will most likely result in you not becoming one for longer (something literally written in WP:RFAADVICE). –MJL ‐Talk‐^☖ 01:11, 1 November 2021 (UTC)
8. The best leaders are the people who don't really want it. Dragging more people to RfA is a good system. Chess (talk) (please use {{reply to|Chess}} on reply) 03:35, 1 November 2021 (UTC)
9. Support. But I am curious to know what the needs are to be qualified for being considered a Sysop candidate.Paradise Chronicle (talk) 05:04, 1 November 2021 (UTC)

   @Paradise Chronicle: have you read the "Full details" that propose the initial set of criteria? — Bilorv (talk) 12:58, 1 November 2021 (UTC)

   Now I have. Thanks. Seems fair. Paradise Chronicle (talk) 15:09, 1 November 2021 (UTC)

10. Support trying something new. To me, I see a culture that states that potential admins should not want to be admins; if volitional adminship is deemed so negative, what alternative is there than conscription? I would advocate, if this was considered, that the nominee have to accept before the process officially began. From the oppose section, I see a consensus that a full AfD without the nominee's knowledge would be a poor course to take. Ifnord (talk) 01:18, 2 November 2021 (UTC)
11. I don't see the harm in trying it, if it's opt-out, then it's not "drafting" or making anyone an admin without their consent. Maybe it'll be hard/impossible to implement, but I just don't see what harm could come from trying it (it certainly won't drive anyone off the website). Levivich 16:02, 2 November 2021 (UTC)
12. I'd suggest nominating everyone who holds more than a handful of advanced permissions (not sure whether they should be allowed to opt out). —Kusma (talk) 15:03, 3 November 2021 (UTC)
13. This is a really good idea. --JBL (talk) 18:42, 6 November 2021 (UTC)

Oppose 4A Opt-out sortition to nominate candidates

1. I disagree with nominating candidates who have not indicating their willingness to serve prior to the nomination. I also feel the process is better served by having a dialogue with the candidate. I'd prefer a revived admin nominators wikiproject to use whatever criteria they want to find potential candidates, and then work with them on following the standard request process. isaacl (talk) 21:48, 31 October 2021 (UTC)
2. The Jargon file story about Sussman and Minsky comes to mind. Randomness may cultivate a mystique for the process, but I see no reason it will find more or better admins. The community has struggled for decades to find reasonable criteria to determine adminabiles; if these criteria manage to find wide acceptance why not just write a bot to suggest a nomination to anyone who reaches the threshold? User:力 (power~enwiki, π, ν) 22:39, 31 October 2021 (UTC)
3. The given criteria does not demonstrate suitability for being an admin. The most crucial criteria is that they want to be an admin. I don't believe the solution is closing our eyes and throwing darts at a list of names. As 力 suggests you could write a bot right now with no change in policy that suggests RfA to such people, go for it. HighInBC ^{Need help? Just ask.} 22:46, 31 October 2021 (UTC)
4. Per 力 and HighInBC. I don't think it makes sense to nominate editors unless they have actually expressed an interest in being an admin. Having a bot inform editors that they might be good candidates seems like a better idea. Nosferattus (talk) 23:32, 31 October 2021 (UTC)
5. RfA should be opt-in, not opt-out. No one should come back from a vacation in Hawaii to find out that they were involuntarily nominated for adminship, let alone read an RfA that sank like a rock and laid out all the reasons they weren't suitable for it, if they never wanted to serve in that capacity anyway. Adminship is a volunteer position, and so an RfA should only be initiated once the candidate has actually volunteered. Seraphimblade ^{Talk to me} 01:43, 1 November 2021 (UTC)
6. Per Seraphimblade. Doesn't actually solve an existing problem, and I can't imagine this would be a good experience for anybody who gets sent on a surprise trip to RfA. -FASTILY 04:25, 1 November 2021 (UTC)
7. Unimplementable as proposed. Not even one of the seven separate criteria can be automated, and each individually has far too many matches for the group as a whole to be done manually. —Cryptic 04:28, 1 November 2021 (UTC)
8. This pressures people to run for RFA and puts them in uncomfortable positions they don't want to be in. --Rschen7754 07:20, 1 November 2021 (UTC)
9. Strongest possible oppose: RfA should be opt-in, not opt-out. Sure, find some automated way to get a list of all users that match these (or some other) criteria, but then talk to them to see if they would be interested in running for adminship. --rchard2scout (talk) 09:20, 1 November 2021 (UTC)
10. I strenuously oppose any route to adminship that explicitly allows a candidate to ignore any questions by the community. There is, rightly, an expectation that candidates are responsive to its concerns. If people want to maintain VOLUNTARY, they should mandate that a candidate accepts the nomination instead of this baffling process where you're given a week to object. Sdrqaz (talk) 10:49, 1 November 2021 (UTC)
11. Random? No, no, no. What if the user doesn't want to be an admin? 🐔 Chicdat  ^{Bawk to me!} 10:54, 1 November 2021 (UTC)
12. Wow, just no. Many people who would quality prefer to stay out of the spotlight, and this could end up running people off the site. No. Not everyone wants to be an admin, or even noticed. Dennis Brown - 2¢ 11:39, 1 November 2021 (UTC)
13. I think it would be a good idea to write a bot that would identify editors that meet your criteria and post a message on their talk page encouraging them to run. Or put them on a list or something. But nominate people without their explicit consent? Absolutely not. Can you imagine how you would feel if you took a break from Wikipedia for a few months, only to come back and find that in your absence, you'd been scrutinised by hundreds of fellow editors for a position you didn't even ask for? – Joe (talk) 14:46, 1 November 2021 (UTC)
14. Don't see a point in nominating people who have not expressed any interest in being an admin. Will add more in talk section. - wolf 17:15, 1 November 2021 (UTC)
15. As soon as a process is used to identify, select and contact editors minding their own business seeking to thrust them into the unexpected spotlight of RfA, that is applying pressure well in breach of WP:VOLUNTARY Leaky caldron (talk) 17:38, 1 November 2021 (UTC)
16. Basically drafting admins? No thanks. Beeblebrox (talk) 21:23, 1 November 2021 (UTC)
17. Users have the right not to be admins, as absurd as this comment would be in any other context. Trainsandotherthings (talk) 04:20, 2 November 2021 (UTC)
18. We're having this discussion because RfA has become sufficiently unpleasant that few people want to go through it. Putting people through it at random, without them even having volunteered, would be practically a hazing ritual. Hut 8.5 20:08, 2 November 2021 (UTC)
19. I can't imagine that very many people would be pleased by a surprise nomination. LEPRICAVARK (talk) 06:33, 3 November 2021 (UTC)
20. Opposing on the basis that it sets up a murky expectation that the candidates should ignore discussion or other interaction with the community - I'd expect opposition to rise along the "Won't answer my question that I'm concerned with", while leaving it vague to the closing 'crat if this is something that is expected to be discounted. — xaosflux ^Talk 10:57, 3 November 2021 (UTC)
21. As per above, being willing to volunteer to do admin work is an essential characteristic of an admin, and this could discourage candidates from running without being randomly selected. — csc^-1 21:54, 3 November 2021 (UTC)

Discussion 4A Opt-out sortition to nominate candidates

• An interesting idea which I need to think about some more. Dreamy Jazz ^{talk to me | my contributions} 16:23, 31 October 2021 (UTC)
• Regarding criterion 2, how specifically is "20 months of active editing" defined? Regarding criterion 3, would there be a provision for excluding e.g. accidental blocks that were immediately undone? {{u|Sdkb}} ^talk 17:23, 31 October 2021 (UTC)

  @Sdkb: I've updated the criteria to specify accidental blocks should be manually excluded from blocking a user from being entered in the drawing. –MJL ‐Talk‐^☖ 18:11, 31 October 2021 (UTC)

• What mechanism is going to be used to ensure "randomness"? — xaosflux ^Talk 17:28, 31 October 2021 (UTC)

  Well, it would have to be a Random.org-type of pseudo-random number generator that would pick from the given list. –MJL ‐Talk‐^☖ 18:19, 31 October 2021 (UTC)

• Why is "random" selection of candidates better than a cabal selecting 5 candidates they think have the best chance of success? User:力 (power~enwiki, π, ν) 17:47, 31 October 2021 (UTC)

  Well, for starters, we wouldn't have to argue about who gets to be in the cabal. Either way.. Sortition offers several benefits which is why it is used for jury selection in the United States. –MJL ‐Talk‐^☖ 18:27, 31 October 2021 (UTC)

  We could use sortition to choose the cabal members. User:力 (power~enwiki, π, ν) 18:31, 31 October 2021 (UTC)

  Assuming this isn't a joke, the difference here is that the community still has final say over matters just to ensure the process doesn't lead to an outcome that the community finds negative. Either way, folks approaching users who are perceived to have the best chance of success is basically the system we have now. –MJL ‐Talk‐^☖ 22:27, 31 October 2021 (UTC)

• Who do you expect to come up with the list? —Cryptic 19:59, 31 October 2021 (UTC)

  It would most likely be a group of functionaries with some level of technical knowledge operating similarly to the ACE election coordinators. –MJL ‐Talk‐^☖ 22:23, 31 October 2021 (UTC)

• Why not just have a page called: "Users interested in being an admin", with a brief explanation of what an admin does, where anyone can sign up? Probably get a phone-book worth of new people, but for experienced users who seek to nominate people, if they come across a user they believe has a good head on their shoulders, they can easily check to see if they're on the list. If so, and they meet the criteria, then fire off a nom. If they don't yet meet the criteria, then watch them, maybe even guide them until they do, then nominate. That way we only have people who want to be admins running, instead of ferreting the few who do from a bunch that don't. (jmho) - wolf 17:23, 1 November 2021 (UTC)

  We already have one, actually. – Joe (talk) 19:15, 1 November 2021 (UTC)

  For the record, Davey2010 is on that list because 7 years ago he had {{User wikipedia/Administrator someday}} on his user page. Caker18 is on that list despite being CU blocked 2 years ago.
  I don't think having user publically list themselves in a centralized place is good idea. There is a reason why most potential noms get discussed offwiki. Secondarily, it's just inviting users to have a revolving WP:ORCP/pre-RFA at their talk page. The longer between a user publicly announcing their intention to become an admin; the less likely it is for them to pass. –MJL ‐Talk‐^☖ 20:20, 1 November 2021 (UTC)

How times change!, For me personally the off-putting thing about adminship at that time was the crap the admins had to put up with ... that and my short fuse at that time. Just couldn't be doing with people coming to me 247 complaining over my every move, Anyway unfortunately these days I have 0 interest in being an admin - quite happy trundling along as an editor.

I think the page was kept for historical purposes but if someone really wants me to remove the userbox I'll begrudgingly oblige, Thanks, –Davey2010^Talk 20:44, 1 November 2021 (UTC)

@Davey2010: You could just set |nocat= to yes, and the bot should remove you from the list in a few weeks. –MJL ‐Talk‐^☖ 21:22, 1 November 2021 (UTC)

(Well how about that? Didn't even know the page was there.)
That page just seems to be a list of people automatically added because they have the "admin someday" userbox on their page. I wonder how many of those people are actually aware of that? Many of those userpages appear to be copied from others userpages, with any and all userboxes included. But intead of debating the usefulness of that page, I'll go back to my original idea, that being a page where users manually sign themselves up with at least some idea what an admin is, what it takes to become one, and the active intent of achieving that some day. Such a page would ideally have some information regarding that at the top, along with links to all the relevant polices & guidelines and any useful essays. As for MJL's comment, I don't see where the concerns comes from; Davey2010 has never run for admin has no interest in being one (again, one of those userbox addees). Caker18 is one of about a dozen currently blocked users on that list, so what? On the list I'm suggesting, perhaps(?) there could be criteria for removal. You'll have to clarify: "There is a reason why most potential noms get discussed offwiki." for me. How would it "invitw users to have a revolving WP:ORCP/pre-RFA at their talk page"...? Is that happening with any of the listees now? (And again, there could be criteria for that if needed.) And your last comment: "The longer between a user publicly announcing their intention to become an admin; the less likely it is for them to pass.". I'm not sure what you base that on, but regardless of time, people pass or fail on the merits of their record and their RfA responses, no? But also, this isn't about newbie editors unwittingly adding themselves to a list with a userbox on the very first day they create an account. The idea here is that editors, with some idea of what becoming an admin entails and want to be one some day, can add their to a list. Experienced editors (especially those who seeks to nominate people) can look at the list and nominate those who they think are ready. Moreso, anyone who sees a name on the list that, though not currently RfA-ready but has potential, may want to give some helpful advice, or even guide them along until they are ready. That's all I was suggesting. - wolf 01:37, 5 November 2021 (UTC)

@wolf: In my experience, RFA is about scrutiny. In general, people who seek forms of power (whether it be the social capital or the technical abilities that +sysop offers, it is hard to deny that the status of admin is a form of power) are scrutinized heavily. If you are someone who works in the more controversial areas of this project, announcing publicly your intention to run for RFA soon will give people who perceive you as an enemy more time to prepare tank it.
Potential noms get discussed offwiki to ensure the public window of time between when the RFA starts and ends is as small as possible. The less amount of time people publicly discuss a candidate; the less scrutiny that candidate will receive (and thus the chances that something terrible in their contributions will be found).
To answer your question directly, I think people pass or fail on whether the opposers can form a compellingly negative narrative about the candidate before the RFA closes. A candidate's true nature and the totality of their actual contributions matter little if someone can demonstrate a sustained issue the candidate has. In the end, all that matters during RFA, as in most socio-political processes, is the perception of how things are. –MJL ‐Talk‐^☖ 03:34, 5 November 2021 (UTC)

@MJL: I agree that potential RfA candidates are scrutinized, even heavily... as they should be. Yes, you can have people opposing for legit reasons, and some opposing out of spite. But a legit oppose, even if spiteful, is still legit. And I believe that otherwise empty opposes, made for whatever reason, can be identified as such as struck during the process, or given zero weight afterward. Are you trying to say the RfA process is flawed or even broken? I agree with you again - 100%. This is why I'm suggesting some ways to hopefully improve it. This was just one suggestion. I actually have another that's still just forming, but that might address your concerns. I'll let this suggestion I posted stand as, perhaps it will gain some more interest... or not. Meanwhile, I'm gonna take few day to mull this other idea that's just popped into my head. Thank you for the replies, I enjoyed discussing this with you. Cheers - wolf 04:15, 5 November 2021 (UTC)

4B Establish an optional admin school with approved curriculum

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

---

Create an academy where qualified applicants may apply for grouped training over an approved curriculum. Mastery-based learning model. Graduates who pass RFA become next generation of instructors.

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

4C Add an optional sponsorship program for admin trainees and apprentices

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

---

Formalize/establish a program in which qualified volunteers may approach willing administrators as potential sponsors for admin coaching/training. Trainees would be responsible to their mentors and be willing to accept conditions set by the sponsor for activity and judgement. Successful trainees become their sponsor's apprentices, perhaps on a path toward RFA.

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

4D Sortition variant

Exactly like 4A, except (1) 10 people are randomly chosen instead of 5, and (2) each candidate must affirmatively accept the nomination.

Support 4D Sortition variant

1. Sure. – John M Wolfson (talk • contribs) 14:03, 7 November 2021 (UTC)

Issue 5: "No need for the tools" is a poor reason as we can find work for new admins

5A Revise standard Question 1

To provide candidates more flexibility to discuss their goals and motivations change standard question 1 to Why are you interested in becoming an administrator?

Support 5A Revise standard Question 1

1. Sounds good to me.  – John M Wolfson (talk • contribs) 16:13, 31 October 2021 (UTC)
2. This is a better way to ask the question. Admin candidates should not feel pressured to only work in certain areas, as experience shows the areas admins work in can and do change. This wording makes the question more about the candidate, which is how it should be. Trainsandotherthings (talk) 16:18, 31 October 2021 (UTC)
3. I agree that this is a better question. Dreamy Jazz ^{talk to me | my contributions} 16:21, 31 October 2021 (UTC)
4. Seems like an improvement over the current wording. Isabelle ^🔔 17:16, 31 October 2021 (UTC)
5. Sure, but don't want to set some precedent that future improvement of this area would need a multi-stage, multi-month RfC. — xaosflux ^Talk 17:24, 31 October 2021 (UTC)

   In theory none of the changes need a multi-stage RfC to pass. In reality large changes often take that process to form consensus. I certainly agree that this, and other similar tweaks, can happen successfully outside a process like this. It just so happened to come through in this process. Best, Barkeep49 (talk) 18:11, 31 October 2021 (UTC)

6. I'd remove Q1 altogether, but I'm fine with revising it to this. —valereee (talk) 17:29, 31 October 2021 (UTC)
7. Yes, that would work. – filelakeshoe (t / c) 🐱 17:33, 31 October 2021 (UTC)
8. Good idea. – Joe (talk) 17:52, 31 October 2021 (UTC)
9. Sensible. MER-C 18:16, 31 October 2021 (UTC)
10. I support this non-controversial minor change. User:力 (power~enwiki, π, ν) 18:32, 31 October 2021 (UTC)
11. A fantastic proposal from (I think) Barkeep49, which I have been waiting a week to properly praise. It directly addresses the statement that received widespread support in the first phase with a simple but effective wording change that still gives candidates the same (if not better) opportunity to communicate relevant thoughts they want RfA participants to know, but without the same implicit assumption of a requirement that the community no longer thinks is necessary for candidates. — Bilorv (talk) 18:35, 31 October 2021 (UTC)

    It is Wugapodes who wrote it as the idea emerged from the brainstorming process. I did propose it here so there would be an example proposal when the page went live. Best, Barkeep49 (talk) 18:48, 31 October 2021 (UTC)

12. I doubt that this will cure RfA's problems in any real sense, but it is indeed incrementally better than the current wording. Extraordinary Writ (talk) 19:08, 31 October 2021 (UTC)
13. Good idea. Certainly beats insisting on, or even inviting an additional self-nomination statement. Kudpung กุดผึ้ง (talk) 19:34, 31 October 2021 (UTC)
14. CaptainEek ^{Edits Ho Cap'n!}⚓ 20:10, 31 October 2021 (UTC)
15. — Wug·a·po·des​ 20:28, 31 October 2021 (UTC)
16. Makes sense. DanCherek (talk) 20:59, 31 October 2021 (UTC)
17. The difference to the current "What administrative work do you intend to take part in?" doesn't seem to be as large and meaningful as some of the support appears to imply, but it's fine. ~ ToBeFree (talk) 22:42, 31 October 2021 (UTC)
18. A positive and sensible change. The fact is no user needs to be an admin, it is simply a way for them to contribute to the project in a different way. This question has always been loaded and I agree with the proposed change. HighInBC ^{Need help? Just ask.} 22:48, 31 October 2021 (UTC)
19. Levivich 00:42, 1 November 2021 (UTC)
20. Certainly an improvement in the current wording. Seraphimblade ^{Talk to me} 01:45, 1 November 2021 (UTC)
21. Okay. --Rschen7754 03:51, 1 November 2021 (UTC)
22. An elegant edit. I see it lowering the entry-point to the candidate's willingness without lowering the criteria for the candidate's responsibility. I don't see a downside. As of this datestamp, no opposes. BusterD (talk) 05:13, 1 November 2021 (UTC)
23. Anarchyte (talk) 06:17, 1 November 2021 (UTC)
24.  ― Qwerfjkltalk 07:12, 1 November 2021 (UTC)
25. Support. MichaelMaggs (talk) 07:46, 1 November 2021 (UTC)
26. I sincerely hope that this isn't the only thing that comes out for RFA2021, but yes. Worm^TT(talk) 08:40, 1 November 2021 (UTC)
27. Any user running for adminship with enough experience, civility, and ability, by default, does have a need for the tools. 🐔 Chicdat  ^{Bawk to me!} 10:52, 1 November 2021 (UTC)
28. Sounds good to me — Preceding unsigned comment added by Ritchie333 (talk • contribs) 14:16, November 1, 2021 (UTC) (diff).
29. Sure - wolf 17:30, 1 November 2021 (UTC)
30. Sounds great. However I must add that what bothers me more is not oppose !votes saying "no need for the tools" when the candidate isn't already doing admin-y things, but rather when the candidate is doing lots of admin-y things but they don't have significant mainspace edits or enough AfD !votes, etc., and people use that as a reason to oppose. Anyway changing the wording of Q1 as proposed I think can help this side of the issue as well, as it sort of broadens the scope of adminship. — MusikAnimal ^talk 18:02, 1 November 2021 (UTC)
31. Support. Need for the tools is secondary to not being likely to misuse them. · · · Peter Southwood ^(talk): 18:24, 1 November 2021 (UTC)
32. Sure, seems a worthwhile focusing. ~ Amory (u • t • c) 15:33, 2 November 2021 (UTC)
33. LEPRICAVARK (talk) 06:33, 3 November 2021 (UTC)
34. Spencer^T•C 20:07, 3 November 2021 (UTC)
35. Looks good. — csc^-1 21:55, 3 November 2021 (UTC)
36. Support: I think the proposed open question should prompt better answers. —¿philoserf? (talk) 00:34, 5 November 2021 (UTC)
37. I can't imagine this will have a large positive effect, but I also can't imagine it would hurt. --JBL (talk) 18:46, 6 November 2021 (UTC)

Issue 6: Lifetime tenure (high stakes atmosphere)

Rough consensus Because RfA carries with it lifetime tenure, granting any given editor sysop feels incredibly important. This creates a risk-averse and high-stakes atmosphere.

6A Binding recall criteria

Before starting their RfA, a candidate may contact the bureaucrats, asking them to enforce bespoke recall criteria. If the bureaucrats agree that the conditions are objective and enforceable then the candidate can start the RfA with the recall criteria. Example criteria: "adminship will be removed 10 years after my RfA is closed" or "any administrator may start a petition: if signed by 20 extended confirmed editors within 7 days then I will be desysopped".

Full details

The process is as follows: Bureaucrats will decide on a way for them to be contacted privately e.g. by a centralised email. A candidate who wants to be open to recall may contact them in advance of their RfA, laying out their recall criteria. The bureaucrats decide among themselves whether the criteria are objective and enforceable. If they privately approve the criteria, the candidate can start an RfA with these criteria as public, unchangeable and binding if the RfA passes. When recall criteria are met, any user can notify the bureaucrats at Wikipedia:Bureaucrats' noticeboard with evidence that the criteria are met; any bureaucrat can verify this and remove admin rights. If a user has adminship removed by recall, they may only regain adminship through the standard process for non-admins.

Support 6A Binding recall criteria

1. Sounds good to me. Per the talk page, the effect of this is merely to prevent 'crats from refusing to abide by community consensus w/r/t desysopping criteria.  – John M Wolfson (talk • contribs) 16:14, 31 October 2021 (UTC)
2. I'd support this, but I'd rather see a set of standardized binding recall criteria. —valereee (talk) 17:36, 31 October 2021 (UTC)
3. Support as proposer. If someone wants to propose standardised recall criteria then feel free to do so separately, but I think the right path forward is a mandate for binding recall criteria, which would be groundbreaking. The fundamental issue we have that needs a formal RfC is that no recall criteria are enforced by crats, so candidates who want to set them can only pledge to follow them, and voters who want to support them are forced to either trust the candidate to act sensibly in a situation where they are unfit for adminship, or oppose because the criteria are not enforceable. This is the minimum viable proposal, with a lightweight stage of crat input to determine that crats can/will support the recall process in each case, and specific types of criteria approved/disapproved by the community ad hoc at each RfA (as opposing over someone for not being more easily recallable would be completely valid). — Bilorv (talk) 18:11, 31 October 2021 (UTC)
4. (Moved from Oppose): One main problem with having many different recall criteria is the lack of standardization. In wikis with a standardized recall procedure for all administrators, recalls regularly happen because upset editors know which path to universally take to vote for a recall, and because every editor knows about the effectivity of that process, and because it is always properly enforced. The proposal does not provide the necessary standardization. It does not even enforce having recall criteria at all. But that's okay for now. At least it is an improvement per Bilorv's points. ~ ToBeFree (talk) 17:16, 31 October 2021 (UTC)
5. Per Bilorv and TBF, this would be an incremental improvement, and there seems little downside of trying it. Levivich 00:41, 1 November 2021 (UTC)
6. Per Bilorv. And per Valereee I'd also like to see a set of standardized binding recall criteria.Paradise Chronicle (talk) 05:21, 1 November 2021 (UTC)
7. Proposed process is bad, especially the bespoke nature, but I've always been in favor of recall. We've never gotten buy-in for a universal recall system here, but by the same token we've literally never tried it. I don't think this idea is good, but IMO a system of universal, binding recall would be a massive good. ~ Amory (u • t • c) 14:14, 3 November 2021 (UTC)
8. Incremental improvements are better than no improvements, and provide good proof-of-concept before making drastic changes. --JBL (talk) 18:52, 6 November 2021 (UTC)

Oppose 6A Binding recall criteria

Moved to support. ~ ToBeFree (talk) 22:44, 31 October 2021 (UTC)

1. This will only reduce the number of admins we have. Enforcing policy is not always a popular decision and it should not come down to criteria set out when the admin is at their lowest level of experience. There is a list as long as my arm of admins who have been desysopped with our existing process, it is a myth that admin is a lifetime tenure.
   Our desysop criteria is a careful analysis of behavior and how our policies and community norms relate to it and it is called ARBCOM. You are an admin until you do something that gets your mop taken away, or stop using it for a year. The 'crats have already made it clear they do not want to be in charge of determining if arbitrary criteria has been met. Binding recall criteria will create a whole new barrier to becoming an admin and we will have even less.
   This is also unfair to new admins because of the huge amount of old timers who get to be an admin without these criteria. HighInBC ^{Need help? Just ask.} 22:53, 31 October 2021 (UTC)

   @HighInBC: The 'crats have already made it clear they do not want to be in charge of determining if arbitrary criteria has been met – in this proposal, crats are contacted in advance of the RfA to agree that they are willing to enforce the criteria, which must be objective and enforceable (the opposite of arbitrary). If they do not want to determine if the criteria are met then they will reject them. The intention is that criteria are so obviously objective that any uninvolved bureaucrat should be able to determine uncontroversially whether they are met (it is no more difficult than determining to desysop for inactivity). — Bilorv (talk) 23:09, 31 October 2021 (UTC)

   Have any 'crats indicated that they would want to take this task on? Because as I have said they have indicated in the past that they are not willing to make judging binding recall part of their responsibilities. HighInBC ^{Need help? Just ask.} 23:19, 31 October 2021 (UTC)

   If this passes with substantial consensus and existing bureaucrats aren't willing to enforce it, it should be straightforward to promote new bureaucrats running on a platform that they are willing. —Cryptic 03:20, 1 November 2021 (UTC)

2. The bureaucrats have already made very clear that they are unwilling to take on the role of judging or enforcing recalls. Unless they have changed their position with respect to that, we would be telling participants that the criteria are binding when in fact no one will enforce them. Seraphimblade ^{Talk to me} 01:47, 1 November 2021 (UTC)
3. I was skeptical about fully bespoke criteria, and with at least one bureaucrat on the record against it I'm going to oppose. I might support a similar proposal with a small set of permissible recall criteria that would get pre-approval from the community (and bureaucrats). User:力 (power~enwiki, π, ν) 02:19, 1 November 2021 (UTC)
4. Candidates already have the option to choose to be open to recall, I don't see what codifying this accomplishes. And with others stating above that the bureaucrats are unwilling to be the recall police force, this is impossible to enforce anyhow. Trainsandotherthings (talk) 02:21, 1 November 2021 (UTC)

   @Trainsandotherthings: candidates do not have the option to be open to binding recall, and indeed there have been instances in the past of people who simply refuse to abide by their recall criteria when the conditions are met (example given below). The point is to make recall binding, and this is the minimum viable codification to do this. If the crats are "unwilling" to enforce the criteria then they will simply reject them when a candidate requests them to. — Bilorv (talk) 11:39, 1 November 2021 (UTC)

5. This could result in de facto bullying: "Oppose unless you agree to XYZ". --Rschen7754 02:41, 1 November 2021 (UTC)
6. Not the right way to go about removing adminship. Forcing arbitrary processes onto people that haven't even got the tools yet will just make the process more hostile. We need to discuss reconfirmation RfAs and non-ArbCom sysop removal instead. Anarchyte (talk) 06:19, 1 November 2021 (UTC)
7. We need more admins, not fewer! 🐔 Chicdat  ^{Bawk to me!} 10:50, 1 November 2021 (UTC)
8. Unenforceable in a fair way. People have different criteria, and to enforce it, Crats would have to interpret individual "rules" which may or may not always be clear. If I were a Crat, I would refuse to participate in a recall petition because of this. Dennis Brown - 2¢ 11:25, 1 November 2021 (UTC)

   @Dennis Brown: I don't understand this comment. The proposal involves consulting the crats in advance, who must agree that the criteria are objective and enforceable (hence, not "may not always be clear"). How would a situation arise that the crats are asked to judge something unclear? — Bilorv (talk) 11:42, 1 November 2021 (UTC)

   They may not be the same crats. · · · Peter Southwood ^(talk): 18:33, 1 November 2021 (UTC)

9. Seems rather pointless. It's optional, so why would any admin do this? And if they do, they can set whatever "bespoke" criteria they want that bureaucrats might not even follow through with. (more on talk below) - wolf 17:45, 1 November 2021 (UTC)

   @Thewolfchild: It's optional, so why would any admin do this? – many admins already do and have done since at least 2006. I'm not sure I understand they can set whatever "bespoke" criteria they want that bureaucrats might not even follow through with – in the given proposal, how could a situation arise where the bureaucrats would not follow through on enforcement? — Bilorv (talk) 18:02, 1 November 2021 (UTC)

   I think it should mandatory, for all admins, not optional. And there should be a standardized recall criteria, not a bespoke list. It was mentioned above that some crats might not follow through with any recalls, hence the reason I mentioned it. If that is indeed the case, then it would need to be addressed beforehand, to remove any choice in the matter. - wolf 18:38, 1 November 2021 (UTC)

10. I agree with Rschen7754. At my own RfA I felt pressured into being open to recall (Q4). I never wrote my criteria, as the whole concept of optional recall seems off to me. !Voters should support candidates because they trust them, not because of some criteria the 'crats may or may not actually enforce, or the candidate may or may not abide by. I think there should be standard recall criteria for everyone or none at all. — MusikAnimal ^talk 18:21, 1 November 2021 (UTC)
11. The people who keep trying to give this unused process some teeth need to drop the stick, like, yesterday. Let it go. Recall isn't a thing. Maybe it had potential when it was new, but it hasn't been used in a very long time and does not have broad community support. Continuing to try and make it into something useful is a waste of time, what we need is an entirely new process, not a rehash of this failed one. Beeblebrox (talk) 20:08, 1 November 2021 (UTC)

    I'd argue it's never really been tried. It's never been accepted at a community level, and it won't here, but I don't think it's fair to say it's a failed process when it's never been used project-wide. Failed to gain consensus, sure. ~ Amory (u • t • c) 14:26, 3 November 2021 (UTC)

12. Community de-adminship should operate on consistent standards, not bespoke criteria which could depend not on the merits of the admin but on how hard they were pressured into signing up for recall at their RfA. -- King of ♥ ♦ ♣ ♠ 20:17, 1 November 2021 (UTC)
13. Per King of Hearts, plus I doubt (based on the comments at WP:BN) that the crats would be willing to execute this proposal in any way true to its intent. Extraordinary Writ (talk) 03:52, 2 November 2021 (UTC)
14. I got rid of my recall criteria because it is a useless process --Guerillero ^{Parlez Moi} 10:26, 2 November 2021 (UTC)
15. per Anarchyte. Isabelle ^🔔 16:15, 2 November 2021 (UTC)
16. I think a recall process would be fine, but not this one. Specifically, all of the mandatory secret prescreening and approval by bureaucrats parts here are a no go for me, not just as a 'crat - but because these shouldn't require any secret proceedings. I'd prefer a standard community-wide recall criteria. — xaosflux ^Talk 10:52, 3 November 2021 (UTC)
17. I don't believe we should be encouraging the creation of bespoke recall criteria, any community recall process should be universal. — csc^-1 22:05, 3 November 2021 (UTC)
18. Recall is inherently a mess. ArbCom is very effective at removing admin access when necessary, and sometimes when not. Jehochman ^Talk 08:11, 5 November 2021 (UTC)

Discussion 6A Binding recall criteria

• Recall criteria are something which I proudly have, and will stick to. I'm unsure if making them unchangeable makes this a good idea as with change that will always come the recall criteria may need to be updated. For example, a user right mentioned in the recall criteria may cease to exist. Without having a way for the criteria to be changed, they could over time become un-useable. As such I'm not voting support unless there is a way to change the criteria. Such a way should include community discussion to make the change. If there was a way to change them, I would be supporting this. Dreamy Jazz ^{talk to me | my contributions} 16:51, 31 October 2021 (UTC)
  • @Dreamy Jazz: make a suggestion of the most lightweight process through which they could be changed (a discussion at AN? a new process at RFA?). Proposals can be altered within the first seven days and if no supporters object to the changes then we could introduce a measure to change the criteria, other than the method that would be available by default: run a reconfirmatory RfA with new recall criteria. — Bilorv (talk) 18:11, 31 October 2021 (UTC)
• I strongly support the concept of admin recall. That being said, I haven't opted-in to recall because I find the whole process weird and complicated and confusing. There should be a standardized, mandatory, community-based admin recall process. WP:DESYSOP2021 failed, but it's worth putting the effort into figuring out why it failed and coming up with a better proposal. -- RoySmith (talk) 17:47, 31 October 2021 (UTC)

  PS, orthogonal to this discussion, I was just granted that most coveted of collectable hats, admin on testwiki. And what I discovered is that my mop is temporary ("Expires 17:35, 31 October 2022"). I didn't even know admin rights could be granted with a time limit in the currently software, and I'll bet most people didn't know that either, so mentioning it here as a PSA. -- RoySmith (talk) 17:56, 31 October 2021 (UTC)

  If you look at the archives for meta:SRP, you can see that on most small projects (the ones that don't have local 'crats), temporary adminship happens regularly. Some projects are apparently small enough to not even require a permanent administrator. --rchard2scout (talk) 09:31, 1 November 2021 (UTC)

  A bit off-topic, but on those projects temporary adminship is generally given if 0-8 people have supported the request. This is basically a mandatory confirmation to protect that smaller project in case the admin turns out to be bad - and stewards also have more leeway to revoke adminship immediately if someting goes wrong. --Rschen7754 04:21, 2 November 2021 (UTC)

  Ditto. I'm totally open to recall, have it as a category on my user, but I have zero idea what to put down as criteria. Levivich and EEng both tell me it's time to hand in the mop? —valereee (talk) 20:42, 31 October 2021 (UTC)

• An unnecessary layer of buraucracy. Kudpung กุดผึ้ง (talk) 19:39, 31 October 2021 (UTC)

  @Kudpung: I'm confused about what this means you think about recall in general. Do you think the whole thing is a waste of time? That recall is fine as is, where an admin decides whether or not to stand by their own criteria after the conditions are met? Or that a standardised process could have less bureaucracy than this specific proposal? — Bilorv (talk) 19:43, 31 October 2021 (UTC)

  Bilorv, I haven't stated what this means I think about recall in general. I would have thought however, that an admin who subscribes voluntarily to their own recall criteria would abide by them. Kudpung กุดผึ้ง (talk) 20:03, 31 October 2021 (UTC)

  Sadly, there is historical precedent of admins not abiding by objective recall criteria once they are met. Here's a statement by an admin deciding to simply ignore the outcome of a successful recall discussion about them in 2008, and they remain an admin today. (If you think 2008 is too long ago, take a look at Wikipedia:Administrators open to recall/Past requests: very few recall attempts have been started since 2010, because the community understand that recall is useless with no power of a crat to enforce it.) — Bilorv (talk) 20:32, 31 October 2021 (UTC)

• I've gone ahead and started a thread at WP:BN asking for an opinion on whether bureaucrats would be willing to enforce this. User:力 (power~enwiki, π, ν) 01:52, 1 November 2021 (UTC)

Crat comments on their role

There was a request for 'crat comment on the WP:Bureaucrats noticeboard - If we're going to chat about it, why not here? Worm^TT(talk) 09:18, 1 November 2021 (UTC)

• Bureaucrats will decide on a way for them to be contacted privately e.g. by a centralised email. & A candidate who wants to be open to recall may contact them in advance of their RfA, laying out their recall criteria.

  We closed down the bureaucrat mailing list a while back, and it was never used for creating consensus (towards the end it was only for renames, and few crats did them from there). Crat's don't work as a committee, it's an individual thing, so I'm reluctant to start it back up. Worm^TT(talk) 09:18, 1 November 2021 (UTC)

• The bureaucrats decide among themselves whether the criteria are objective and enforceable. & If they privately approve the criteria, the candidate can start an RfA with these criteria as public, unchangeable and binding if the RfA passes.

  So the crat's decide if the criteria is good enough? Not as written. The crat's role is to weigh consensus - we'd need something measurable that the crats can see if it works against. Worm^TT(talk) 09:18, 1 November 2021 (UTC)

• When recall criteria are met, any user can notify the bureaucrats at Wikipedia:Bureaucrats' noticeboard with evidence that the criteria are met; any bureaucrat can verify this and remove admin rights.

  I have no issue with this part. Worm^TT(talk) 09:18, 1 November 2021 (UTC)

• If a user has adminship removed by recall, they may only regain adminship through the standard process for non-admins.

  Nor this part, which is not really crat based. Worm^TT(talk) 09:18, 1 November 2021 (UTC)

@Worm That Turned: I don't understand why "objective and enforceable" are not "measurable" and, themselves, two objective criteria? The role would not be to say "these recall criteria do not meet community standards"—that's part of what participants would vote on at RfA—just to say "if the community agreed on this then it's logistically possible to implement". This is no different to if we gave specific recall criteria to choose from and the crats were consulted to say "yes, we would be willing to do this", except that it would be done on a case-by-case basis. As for the reason the system needs to be private, this is because candidates would object to it being public, as it gives the game away that they are about to run for RfA (and you'll have noticed as surely as I have that very few people are comfortable publicly declaring in advance when they are about to run for RfA). — Bilorv (talk) 11:36, 1 November 2021 (UTC)

• I've left a comment at Wikipedia:Bureaucrats' noticeboard#Bureaucrats and 2021 RFA review. I have that page watchlisted, so will respond there to any queries. SilkTork (talk) 11:49, 1 November 2021 (UTC)

Bilorv - The same reason that recall has always been a problem. "Objective and measurable" can include "if one of these specific 5 editors says I should quit", "If 10,000 editors with over 150 edits say I should step down", "If the party of the first part explains that the party of the second part that the incident in question is a violation of technical point 4 of my personal recall criteria", and any other stupid criteria. You could say that the community can shout it down at RfA - but that's not the problem, the question will be posed of the 'crats "Why did you let that through?". And the answer will be "because it's objective and measurable" - and I foresee disagreement. Worm^TT(talk) 12:31, 1 November 2021 (UTC)

• Why not just have mandatory RfAs every five years, for every admin, current and upcoming, no exceptions. This allows the community to determine their continued suitability. No different than the elected positions in many democracies, except there's no term limits. (jmho) - wolf 17:45, 1 November 2021 (UTC)

  @Thewolfchild: because (a) that's nothing to do with recall and (b) the community literally rejected mandatory RfAs every ten years as too harsh by a two-to-one margin earlier this year. — Bilorv (talk) 17:56, 1 November 2021 (UTC)

I did state "jmho", but that aside, it should be noted that WTT did describe it as a "perennial proposal". And while it was voted down, there was still a significant number of supporters, many of whom had good reasoning attached to their !votes. And while there was an even larger number of people that opposed, I believe that in of itself is evidence that the process could work. But, again... jmho. - wolf 18:26, 1 November 2021 (UTC)

6B Desysop at AN(I)

A discussion at either Wikipedia:Administrators' noticeboard (AN) or Wikipedia:Administrators' noticeboard/Incidents (ANI), closed by three uninvolved admins, may achieve consensus to remove admin rights from a user. (The bureaucrats will enforce this after being notified of the closing statement at Wikipedia:Bureaucrats' noticeboard. The user may then only regain adminship through the standard process for non-admins.)

Support 6B Desysop at AN(I)

1. Sounds good to me. I think "bad-faith desysops" are far more a moral panic than an actual issue, and admins are nowhere near combat veterans.  – John M Wolfson (talk • contribs) 16:14, 31 October 2021 (UTC)
2. I'd support this, given details can be worked out. —valereee (talk) 17:35, 31 October 2021 (UTC)
3. Support as proposer. If admins can be elected by the community then the community must also be able to decide to remove admin permissions. It is insane that the community do not have this right. The proposal is relevant to the theme of this RfA review because much opposition and toxicity in RfA comes from a group of users who believe that admins are unaccountable and unable to be desysopped except in the most extreme cases, and therefore hold candidates to excessive standards (they need to prove that, even in 15 years, they will not be acting in a way that the community will oppose).
   The proposal is an extension of the existing processes we use in some cases to remove PERM-given rights and instate topic bans, interaction bans, or temporary or indefinite blocks. It, however, asks for substantially more scrutiny to prevent abuse: three administrators closing the discussion, which is now a common closure method for large-scale contentious RfCs that have much larger mandates than removing adminship from one user who can regain it with a successful RfA at any time.
   To support this proposal, you do not need to believe AN(I) is a good judge of community consensus. You only need to believe that if it achieves a mandate to remove adminship then an admin should be re-scrutinised by the community—as they are welcome to immediately stand for RfA again and will be reinstated if the community actually do support them (and this is the default appeal process). — Bilorv (talk) 18:30, 31 October 2021 (UTC)
4. Weak support as noted in the discussion, I would strongly prefer these discussions to not be on WP:AN/WP:ANI, but a follow-up ANI reform RFC can hopefully fix that. The main question is "should the community be able to vote to de-sysop for any reason, or indeed no reason at all"? (to a certain extent, there is no distinction between voting to require a recall election, and voting for a de-sysop that can be over-ridden by a new consensus at RFA). A similar proposal failed earlier this year, and I doubt this one will do any better. But my personal vote is yes, the community should be able to do so. User:力 (power~enwiki, π, ν) 23:03, 31 October 2021 (UTC)
5. Per Bilorv. If ANI can handle tbans and sitebans, then it can handle desysops, too. I never understood why desysop should be essentially exempt from the consensus process. We can use consensus discussions to make major decisions like end IP editing or banishing an editor or deleting a page, but not for -sysop? I just don't believe it. Levivich 00:40, 1 November 2021 (UTC)
6. Don't think this really changes RfA, but support in principle because AN can siteban any editor, and it can strip any permissions other than +sysop, so I don't see why it can't -sysop. If AN is broken, why should only admins be exempt from its brokenness? Fix AN. If AN isn't broken, then there's no reason it can't handle -sysop. ProcrastinatingReader (talk) 14:15, 1 November 2021 (UTC)
7. Support in principle; although I think we need to clarify exactly what "consensus" means, in general I trust the community to come to the right decision. Ritchie333 ^{(talk) (cont)} 14:18, 1 November 2021 (UTC)
8. Support on principle; there is a need for a community desysop mechanism. There's some good reasons noted below by opposers why there could be some problems with this, but I still think it would be a good start, it could be improved as needed, and something here is better than nothing. - wolf 17:53, 1 November 2021 (UTC)
9. If longtime editors can be blocked at the Great Dismal Swamp, than so can admins be de-sysopped. It may be a cesspit, but that's a reason why ANI should be reformed, not why de-sysopping should be exempt from community consensus. — csc^-1 22:08, 3 November 2021 (UTC)

   However, taking note of the lack of full community involvement at ANI, such a discussion should have to be listed on WP:CENT and run for 7 days just like an RfA. — csc^-1 22:16, 3 November 2021 (UTC)

Oppose 6B Desysop at AN(I)

1. Too little detail on some fairly relevant aspects, but also doesn't handle that it's not that there would be many problematic cases, but any problematic cases that an ArbCom wouldn't have suffered from is too many. Nosebagbear (talk) 16:25, 31 October 2021 (UTC)
2. I don't see any reasons why arbcom cannot handle this. It is not often that admins are desysopped for cause. I'm also concerned that this proposal leaves no method of appeal and could lead to frequent spurious attempts to desysop admins. Trainsandotherthings (talk) 17:00, 31 October 2021 (UTC)
3. Per the above, and per my previous opposition at the RfC about this a while ago. I see no evidence that ArbCom or the 'crats can't handle this on their own. RandomCanadian (talk / contribs) 17:04, 31 October 2021 (UTC)

   What do you mean by the crats handling desysops "on their own", RandomCanadian? They currently do not act to desysop involuntarily except when ArbCom requires them to, or purely procedurally in inactivity cases. (Or IAR, I suppose.) — Bilorv (talk) 18:30, 31 October 2021 (UTC)

   Here I was clearly grouping the two together, in the sense that 'crats and ArbCom can handle this on their (collective) own. There's no indication they are unable to do so, nor any need to add a process ripe for abuse on top of it. RandomCanadian (talk / contribs) 22:48, 31 October 2021 (UTC)

4. Plenty of far better thought out community desysop proposals, with better safeguards against abuse, have failed. ANI generally does a terrible job of handling behavioural issues involving experienced editors, and it's also prone to lynch mobs. Hut 8.5 17:40, 31 October 2021 (UTC)
5. AN(I) is a horribly ineffective at handling all but the most straightforward conduct issues. Decisions there are completely at the mercy of the (very non-representative and, despite the name, primarily non-admin) crowd of people that watchlist those pages; are susceptible to groupthink, witch-hunts and popularity contents; have a tendency to rush to conclusions, fizzle out, or spin off topic entirely; I could go on... but I assume these problems are obvious to most people who have experienced the place. I fully agree that the best way to make it easier to sysop people is to make it easier to desysop them if we make a bad call, but this isn't the way. It's unfair to subject a decision made by typically 100+ editors at an RfA to reversal by an arbitrarily sized, self-selected mob at AN(I). Admin conduct cases at ArbCom may have their faults but it at least attempts to provide due process and space for people to properly defend themselves. – Joe (talk) 18:11, 31 October 2021 (UTC)
6. ANI often doesn't have the "full" community around. As such, especially in cases of low participation, the decision there may not reflect what the full community wants. Although having a three-admin panel closing the discussion does alleviate some of the concerns, without further details to prevent short length discussions and involved admin closure, I don't think I'd support this. Furthermore, for an admin to be desysoped at ANI like this I can see them being unwilling to go through another RfA to see if the "full" community supports them. I do though support the idea of having a community led way to desysop someone, but finding an appropriate way to achieve this is difficult. Dreamy Jazz ^{talk to me | my contributions} 18:47, 31 October 2021 (UTC)
7. ANI is probably the one place that's more dysfunctional than RfA, and so I cannot support giving it desysop powers without (at a minimum) some serious procedural safeguards along the lines of this suggestion. Subjecting admins to removal via a single discussion by whichever capricious group happens to be congregating at ANI that week strikes me as a very bad idea that would, if anything, make candidates less likely to run at RfA. Extraordinary Writ (talk) 19:16, 31 October 2021 (UTC)
8. Strong oppose. Concurring with Extraordinary Writ ANI was scientifically assessed a couple of years ago and established as being largely disfunctional. It would allow everyone in the public gallery to be judge, jury, and executioner. This would first require a strict reform of ANI. That doesn't mean that Arbcom is any better - it sometimes appears to simply read a perceived 'consensus' of all those who come to comment, involved or not. Kudpung กุดผึ้ง (talk) 19:55, 31 October 2021 (UTC)
9. ANI is a circus and in no way setup to handle this sort of thing. Everyone with an ax to grind with an admin will show up out of the woodwork to try to come up with a convincing reason to take the mop away from the admin who blocked them from edit warring 6 months ago. HighInBC ^{Need help? Just ask.} 22:56, 31 October 2021 (UTC)
10. Good God, no. In a case where an involuntary removal of tools is requested, it will be one of two situations. Firstly, the admin may be committing egregious, "bright line" violations (and the account may even potentially be compromised, given that this is presumably very out of character for them). When this happens, ArbCom already can and does perform a rapid desysop pending a full case. In these scenarios, the AN(I) process would take too long; the damage must be contained immediately. Conversely, the complaint may be a longstanding pattern of less egregious but still concerning lapses. In that case, the AN(I) process will be too short and scattershot to do a complete evaluation of the allegations, the evidence behind them, and the context surrounding them. I really can't see a scenario where such a process would be the appropriate one to handle a desysop, and I can see a thousand ways it could go wrong. Seraphimblade ^{Talk to me} 01:55, 1 November 2021 (UTC)
11. And of course, the logical progression will be a non-admin closing such discussions. Besides what has been mentioned above. --Rschen7754 02:42, 1 November 2021 (UTC)

    Why would this be the logical progression, Rschen7754? There would need to be a later RfC to determine that even an admin could close the discussion, rather than three mandated at present. — Bilorv (talk) 11:45, 1 November 2021 (UTC)

    This is what has historically happened over the past, with the vast expansion of NAC. --Rschen7754 18:04, 1 November 2021 (UTC)

12. I mention in #Oppose 6A Binding recall criteria that we need a process outside of ArbCom to remove adminship, and while ANI looks like the most obvious avenue, I wouldn't trust it in its current state. It's completely disorganised and full of people with vengeances and drama seekers with a spare fifteen minutes. Similarly, many of the discussions over there are closed by non-admins which is a completely different environment to requiring a bureaucrat to close an RfA. I think we should explore using RfA for both assigning adminship and removing it. Of course, some may argue that RfA is better than ANI, but at least we have some semblance of process at the former. Anarchyte (talk) 06:28, 1 November 2021 (UTC)
13. ANI is a crazy place that is not the way to solve the problem. Why, we need more admins, not fewer! 🐔 Chicdat  ^{Bawk to me!} 10:49, 1 November 2021 (UTC)
14. I worked on this, including several proposals, over the last decade. ANI/AN is a horrible place for this. Dennis Brown - 2¢ 11:42, 1 November 2021 (UTC)
15. AN/ANI alone should not be used as a venue for desysopping. I support a Commons-style de-adminship process: get rough consensus first at AN/ANI, and then open a formal de-RfA. After a week, the de-RfA will be successful if a simple majority votes for removal. -- King of ♥ ♦ ♣ ♠ 19:04, 1 November 2021 (UTC)
16. I cannot support a process where as few as three admins could desysop anyone after a discussion on a forum that many Wikipedians avoid on principle. While I am open to the idea of a community de-sysop procedure, this proposal would not appreciably improve the RfA process or adminship in general. Ganesha811 (talk) 19:16, 1 November 2021 (UTC)
17. ANI is a cesspit --Guerillero ^{Parlez Moi} 10:26, 2 November 2021 (UTC)
18. Per Guerillero: ANI is bad and this just makes a rough process worse. ~ Amory (u • t • c) 15:54, 2 November 2021 (UTC)
19. To overcome our shortage of admins and to make things surrounding adminship suck less, let's allow one of our most sucky boards to remove even more of them? Sounds wonderful. Not. —Kusma (talk) 15:01, 3 November 2021 (UTC)
20. Every problem editor eventually get summoned to ANI. The selection of users watching that page is strongly biased towards troublemakers. I wouldn't be an admin if I hadn't been summoned to ANI in 2005. Jehochman ^Talk 08:14, 5 November 2021 (UTC)
21. Has nothing to do with RFA reform, no idea why anyone would think this would make candidates more likely to run for RFA. AN/I is the home of some of the most disruptive and anti-admin users on the project. Thanks, no. Risker (talk) 23:21, 6 November 2021 (UTC)

Discussion 6B Desysop at AN(I)

• Leaning oppose, but need some more time to think. Dreamy Jazz ^{talk to me | my contributions} 18:21, 31 October 2021 (UTC)
  • Voted oppose for now. Dreamy Jazz ^{talk to me | my contributions} 18:44, 31 October 2021 (UTC)
• Regarding, "Why can't arbcom handle this?", I think the answer is that arbcom is the ultimate in heavyweight processes. Slow and ponderous and high-stakes, not to mention opaque. More importantly, it's not community-based. If our goal is to make giving somebody a mop less of a big deal, it's important that we have a way for the community to say, "We gave you a mop, but now we realize that we made a mistake and are taking it back". Arbcom de-sysoppings are about breaking rules. Community de-sysoppings are about losing faith. As noted above, we need some way to keep it from turning into a witch hunt, but we also need something more lightweight than arbcom. -- RoySmith (talk) 18:22, 31 October 2021 (UTC)
  • More importantly, it's not community-based. I've never understood this perspective. Arbitrators are experienced members of the community, elected by the community for the express purpose of handling desysops (amongst other things) in accordance with a community policy. And given that c. 2000 people vote in its elections, ArbCom is arguably far more representative of the broader community than the self-selected dozen or so that show up at a given AN/I. I'm all for decentralised decision-making but it isn't always practical and proposals to de-fang ArbCom and shift things to AN/I don't diffuse authority, they just shift it to a less representative and less accountable clique. – Joe (talk) 19:29, 1 November 2021 (UTC)
• @Valereee and Nosebagbear: which details are absent from the proposal? — Bilorv (talk) 18:30, 31 October 2021 (UTC)

  @Bilorv, off the top of my head...time discussion is open, announcements posted, ability of the admin in question to veto certain closers they feel might be biased? I'm not trying to complicate this, just to think of things that might make some admins wary of signing on. —valereee (talk) 18:42, 31 October 2021 (UTC)

  @Valereee: why are none of these things that need to be spelled out as rules for the existing discussions that determine removal of PERM-given rights or implementations of topic bans, interaction bans, or temporary or indefinite blocks? It seems to me that there is nothing new here to discuss in the case of admins, except discussions that would already need to take place for existing procedures. If an admin doesn't like that they could be desysopped in just a 72-hour discussion, why have they not been protesting against non-admins with over 50,000 edits being indefinitely blocked/banned after such discussions? As for the "veto certain closers", that's already a standard part of Wikipedia:Consensus. — Bilorv (talk) 18:51, 31 October 2021 (UTC)

  @Bilorv, I'm not trying to make the world fair. I'm trying to bulletproof the proposal, which I support. Politics being the art of the possible. —valereee (talk) 19:29, 31 October 2021 (UTC)

  @Valereee: the more conditions you add to a proposal, the more objections you gather over individuals opposing just one or two specific conditions that are immaterial to the broader mandate you are trying to achieve. That is why the proposal is as simple as possible. I don't see that further specification of the types you have named would help the proposal gain more support, but that doesn't mean I wasn't asking you the above questions earnestly and with interest in considering in your answer. — Bilorv (talk) 19:44, 31 October 2021 (UTC)

  @Bilorv, yes, and that's why I stated my support the way I did: "Given details can be worked out." I'm not asking for those details to be specified in the proposal. I'm just acknowledging that there might be concerns that needed to be worked out. —valereee (talk) 19:47, 31 October 2021 (UTC)

• I'm undecided, and I have an implementation question that I am also undecided about: should these discussions be on structured sub-pages? On the one hand, it might decrease visibility; on the other, additional discussion structure (and not overwhelming the often-long ANI page) may aid in clarity of discussion. User:力 (power~enwiki, π, ν) 19:05, 31 October 2021 (UTC)

  Again, 力, I would ask: why only for these discussions, and not for discussions about indefinitely blocking experienced editors? AN(I) seems currently able to regulate its own discussion structure sufficiently to obtain consensus for much, much more wide-reaching and significant actions than removing admin status from an individual. — Bilorv (talk) 19:16, 31 October 2021 (UTC)

  I don't think some of those other ANI discussions function well either. Why should we extend a broken process? The whole "ARS" thing currently at ANI should probably be structured and on a subpage as well. User:力 (power~enwiki, π, ν) 19:18, 31 October 2021 (UTC)

  @力: would you prefer the proposal to forego any mention of specific pages at all, and simply say that desysopping could occur after any discussion where three admins agree consensus was obtained to do so? AN(I) and "a new subpage [of ???]" could then be listed as example pages where such a discussion could occur. (Of course, you'd expect no admins would make such a close if a discussion had low participation or mostly canvassed participants.) — Bilorv (talk) 19:44, 31 October 2021 (UTC)

  @Bilorv: I would personally prefer that, but I am not sure it would make the proposal more likely to pass. User:力 (power~enwiki, π, ν) 19:46, 31 October 2021 (UTC)

• I would also prefer a different location for the discussion but won't withhold my support on the basis of using AN(I) alone. To offer a suggestion, perhaps open the discussion on a subpage of the RfA they succeeded in becoming an admin. Two points which do stifle my desire to support this proposal: 1. Please stipulate the minimum timeframe in which the discussion will remain open. And 2. Please stipulate how you will advertise the discussion. Here I'd like to suggest, amongst other things possible, that each person !voting at the RfA which they succeeded in becoming an admin, receive a talk page notification. I look forward to supporting this proposal if my concerns are allayed. Nevertheless, I will not oppose.--John Cline (talk) 11:37, 1 November 2021 (UTC)
• I think we need some use cases. The one that comes to mind is when Neelix was found to have created a huge number of inappropriate redirects that needed to be deleted (indeed, a separate CSD criteria was created for them!) and we had to create an Arbcom case before he finally decided to relinquish the tools. The other use case was when Fred Bauder was IAR desysopped for self-unblocking and wheel warring; an Arbcom case was created as a formality, but there's no reason the consensus couldn't have been decided at ANI instead. Both of these (AFAIK) found an overwhelming consensus to desysop which was highly unlikely to be found controversial (and indeed wasn't). While I filed a number of ANI threads about RHaworth, I don't think there would have been consensus at ANI for a desysop; similarly I doubt RexxS would have got his tools stripped at ANI. Ritchie333 ^{(talk) (cont)} 14:23, 1 November 2021 (UTC)
  • Agreed, Ritchie333, that these are two good example cases where the proposed process would have improved things, and two cases where the process wouldn't have changed anything (since people are worried about it being too easy to trigger). — Bilorv (talk) 15:31, 2 November 2021 (UTC)

6C Administrative action review

Create a new process, Wikipedia:Permissions review (PRV) Wikipedia:Administrative action review (XRV), that will determine whether an editor's specific use of an advanced permission, including the admin tools, is consistent with policy. XRV will use a structured discussion format, open to all editors and closed by an uninvolved administrator, to reach a consensus on whether an action or set of actions is endorsed or not endorsed. Acting on this consensus, if necessary, is deferred to existing processes.

Details

The goal of XRV is to provide a focused and constructive venue in which admins and other advanced permissions users can be held accountable to the community. Any action, or set or related actions, requiring an advanced permission and not already covered by an existing process (e.g. WP:DRV for deletions), may be referred to XRV. A structured discussion format, closed by an uninvolved administrator, will be used to reach a consensus on whether the action should be endorsed or not endorsed. Participation in XRV is open to all editors. The purpose of XRV is solely to reach a consensus on whether the use of the permission was appropriate, not to remove permissions. Acting on that consensus is deferred to existing processes: Individual actions that are not endorsed can be reversed by any editor or administrator; Permissions granted at WP:PERM may be revoked by an administrator if XRV finds them to be misused; Repeated or egregious misuse of permissions may form the basis of an WP:AN, WP:ANI, or WP:RFARB report, as appropriate.

References

Support 6C Administrative action review

1. As proposer. I put a longer rationale on the talk page, but then WTT summarised it much better: the idea is to create a middle ground between AN/I and arbitration, where any admin decision can be reviewed, keeping it low drama and away from ANI, but equally reducing the high stakes atmosphere. Importantly, PRV (or whatever we called it) will only focus on individual actions, not long-term conduct patterns, and will not directly handle desysops/PERM removals, to encourage constructive and depersonalised discussions. – Joe (talk) 17:36, 31 October 2021 (UTC)
2. Sounds good to me.  – John M Wolfson (talk • contribs) 16:14, 31 October 2021 (UTC)
3. I am open to something like this. —valereee (talk) 17:39, 31 October 2021 (UTC)
4. I'm open to trying this. Dreamy Jazz ^{talk to me | my contributions} 18:43, 31 October 2021 (UTC)
5. Support. This introduces, at least, some formal basis by which ArbCom can actually measure whether the community as a whole oppose an admin's actions, as their current case systems are limited by selective bias of participants and an overwhelming proportion of contributions coming from a small number of highly invested INVOLVED editors. It improves upon the WP:PERM system, which has no consistent way to remove rights when needed, and indeed often fails to do so at AN(I), where discussions are derailed or trail off. While not directly introducing any additional methods to remove permissions (therefore making it pretty uncontroversial), this proposal succeeding would give a mandate for a more consistent framework that could be built upon in any number of ways, once the community sees PRV proving useful in practice. (And conversely, if PRV fails then it can be marked {{Historical}} or simply left to become disused, no harm done.) — Bilorv (talk) 19:32, 31 October 2021 (UTC)
6. Editors should read the longer rationale on the talk page. It's a clever idea that I'm actually very excited to try. Bilorv lays out the benefits better than I think I could, but in general I think there's a lot of promise here that could lead to long-term beneficial change. — Wug·a·po·des​ 20:36, 31 October 2021 (UTC)
7. Yup.—S Marshall T/C 22:41, 31 October 2021 (UTC)
8. Okay, I'm in. I misinterpreted this as a desysop procedure after reading 6B. It isn't; it's a fine way for the community to express support or opposition to a specific tool usage. We may actually need this. ~ ToBeFree (talk) 22:51, 31 October 2021 (UTC)
9. Sounds like an improvement on the current systems (AN/ANI thread or Arbcom). Also it would give a good place for people to self-request reviews if they're not sure about their tool usage and get some valuable feedback (better than they'd get at ANI). Levivich 00:46, 1 November 2021 (UTC)
10. It's worth a try, we don't lose a lot if it doesn't work. --Rschen7754 04:21, 1 November 2021 (UTC)
11. I fully support this, and I really hope that adding a way to review decisions will lower the high stakes atmosphere. However, it will take a long time to see results at the RfA end. Oh, and I prefer XRV as the acronym and something to make it clear that it's a specific review, not a general one in the name. (Eg Miscellaneous decision review or Administrative action review) Worm^TT(talk) 08:22, 1 November 2021 (UTC)
12. Might help. What's being suggested isn't very different from deletion review, which is capable of undoing bad deletions and delivering trout slaps to admins who make them. Hut 8.5 09:49, 1 November 2021 (UTC)
13. Sounds good to me. I wonder if this could be used for self-review after a particularly "courageous" IAR use of the admin tools, such as the desysop of Fred Bauder I brought up above. Ritchie333 ^{(talk) (cont)} 14:26, 1 November 2021 (UTC)
14. Nice idea. Improves accountability, as well as being a good venue for feedback where hopefully the lower temperature will encourage the permissions holder to be more receptive to the issues and sort them out early on. Further, it lets non-admin permission holders build a track record of considerate permissions use. A combination of these ideas might have a positive effect on RfA, but seem useful to have regardless. ProcrastinatingReader (talk) 14:40, 1 November 2021 (UTC)
15. Support, as long as it is also open to accepting reviews of actions by non-admins. I'm particularly interested in complaints about new page patrollers and that this may be a way to catch infiltrating spammers. MER-C 19:17, 1 November 2021 (UTC)
16. I like the idea, with the caveat that I think it would be a good bit of work to rewrite our guidelines to determine what the appropriate forum is. We already have plenty of forums as it is and it can rapidly get confusing for newer editors. However if people are willing to do that work, then this could be a definite improvement. Ganesha811 (talk) 19:24, 1 November 2021 (UTC)
17. Assuming this is geared towards content, rather than conduct (i.e. the potential result of this should be overturning the admin's decision, rather than sanctioning the admin). This is basically the MfD version of DRV/RM; anything that does not have a formal appeals process goes here. -- King of ♥ ♦ ♣ ♠ 19:56, 1 November 2021 (UTC)
18. DRV works fairly well (better than ANI, certainly), so it makes sense to have a similar system for other uses of permissions. I'm skeptical that this will go very far toward resolving RfA's problems, but it certainly won't hurt. Extraordinary Writ (talk) 20:11, 2 November 2021 (UTC)
19. This would go a long way toward addressing frustrations with how difficult it is to hold recalcitrant admins accountable. LEPRICAVARK (talk) 06:37, 3 November 2021 (UTC)
20. Weakly interested. I'm wary of Just-Another-F(riendly)-Dramaboard (per Beebs below), but having a specific, non-ANI place for "yeah you're good" or "not cool" could be helpful. I'd hope it'd make sysop Arb cases more meaningful, possibly getting more of the right cases and fewer of the wrong ones. It'd have to be congenial. ~ Amory (u • t • c) 14:34, 3 November 2021 (UTC)
21. DRV and move review both work well for what they are so I am all for another noticeboard like this. In general we should try to de-escalate things in a low stakes environment first before any other actions. ANI and Arbcom should be the reserved for the worst-case scenario only. Swordman97 ^{talk to me} 04:05, 4 November 2021 (UTC)
22. I support a trial of this. ― Qwerfjkltalk 20:39, 4 November 2021 (UTC)
23. Each admin action should be reviewable, but I recommend reusing existing process. We have WP:DRV and block review. Where does one go to complain about page protection? WP:RPP? Are we missing any? Jehochman ^Talk 08:19, 5 November 2021 (UTC)

Oppose 6C Administrative action review

1. Per my intervention for 6B. In addition, this is already covered at AN and ANI where regular admin actions can be challenged. Long-term issues, if they are present, are best left to ArbCom anyways. Cheers, RandomCanadian (talk / contribs) 17:08, 31 October 2021 (UTC)

   The difference between this and AN/I is that the discussions will have a structured format and be restricted in scope. The idea is that when editors are asked to reach a consensus on a specific question (like at WP:DRV or a good RfC) they are much more likely to reach a resolution than when faced with an open-ended issue which could end in anything from a tailored topic ban to a boomerang-block for the person that brought it up (like at AN/I). – Joe (talk) 17:43, 31 October 2021 (UTC)

   Discussions like this, if we want to have them as a community rather than in front of ArbCom, are more suitable for ANI/AN than a separate, low-visibility page, as the quality of the discussion strongly depends on the amount of eyes watching it. ~ ToBeFree (talk) 17:21, 31 October 2021 (UTC)

   I don't understand how you can tell this will be "low-visibility", since it hasn't been created yet. – Joe (talk) 17:43, 31 October 2021 (UTC)

   I'd add to Joe's comment: if it turns out to be low-visibility then why would it not be sufficient to use any of the many things we already have to increase visibility of discussions that need it: {{Please see}}, listing at WP:CENT, appropriate notification procedures and so on? — Bilorv (talk) 19:32, 31 October 2021 (UTC)

   I agree, there's no reason to believe this would be a low-visibility page. In fact I suspect most highly-engaged editors would be watching it from the start. —valereee (talk) 21:05, 31 October 2021 (UTC)

   Okay. ~ ToBeFree (talk) 22:50, 31 October 2021 (UTC)

2. Not sure what this proposal attempts to resolve, or what it has to do with improving RfA. Any action can can already reversed by an administator. This also moves the goalposts. Actions should not need a consensus that they are correct, this is an unreasonable standard. The standard should remain that a consensus that they are wrong. HighInBC ^{Need help? Just ask.} 23:01, 31 October 2021 (UTC)

   @HighInBC: If you haven't seen it, I tried to explain what problems this solves and how it will improve RfA on the talk page (there's a narrow word limit here). – Joe (talk) 08:32, 1 November 2021 (UTC)

3. Drama fest full of everyone who feels they've been wrong. No, this is what Arb is for, and filing an Arb case is trivial if there is any misuse. Dennis Brown - 2¢ 11:43, 1 November 2021 (UTC)
4. We already use AN/ANI to review admin actions and I don't see the need to create a new venue for the same purpose. If we're going to create it, give it some teeth. -- Calidum 16:42, 1 November 2021 (UTC)
5. Another noticeboard is obviously not the solution. Might as well mark it as historical on day one... Beeblebrox (talk) 20:11, 1 November 2021 (UTC)
6. Not a helpful solution. Participation in XRV is open to all editors: It would just create yet another noticeboard like ANI where everyone and other Wikipolice hopefuls would have their say. And does the frequency of disputed admin actions demand a dedicated noticeboard for this purpose? WP:AN exists as a slightly more disciplined place for such discussion. Kudpung กุดผึ้ง (talk) 00:50, 2 November 2021 (UTC)
7. Redundant to AN/ANI, and I suspect a dedicated noticeboard would actually result in more drama. We've tried something similar in the past, and it was ultimately discontinued as grossly ineffective. -FASTILY 02:07, 2 November 2021 (UTC)
8. WQA and RFC/U died for a good reason --Guerillero ^{Parlez Moi} 10:39, 2 November 2021 (UTC)
9. We need more admins, not fewer! 🐔 Chicdat  ^{Bawk to me!} 10:57, 2 November 2021 (UTC)

   @Chicdat, this isn't a desysop proposal; it's simply extending processes such as DRV and move review to other actions. While, yes, overturned actions here could be cited at Arbcom, it's no different than citing actions overturned at AN or DRV. 68.193.40.8 (talk) 14:55, 7 November 2021 (UTC)

10. Sounds like another ducking stool / public stocks venue or, alternatively, a place where Admins will circle the wagons. Doesn't address the issue of an alleged shortage of admins. Leaky caldron (talk) 11:19, 2 November 2021 (UTC)
11. More bureaucracy, also not very connected to the problem we're trying to solve (we make admins more accountable and hope that magically voters become more trusting?) —Kusma (talk) 14:55, 3 November 2021 (UTC)
12. Opposing based on the idea that dragging in yet another noticeboard seems like a mess - say Editor:X appears to be missusing massmessage; Admin:Y removes their access and they disagree. So now what, we need a PRV for if they should get it back, and another PRV if Admin:Y misused their rights managment rights - the former of which could reverse it, the later of which would then what, get an arbcom case opened? WP:AN is already equipped to deal with this situation, not seeing how this is any better. — xaosflux ^Talk 10:52, 4 November 2021 (UTC)
13. The "longer discussion" on the talk page has informed me that what is being talked about here is a return to the corrosive and soul-destroying era of the RFCs that cost us so many editors that we eventually did away with them. Risker (talk) 23:14, 6 November 2021 (UTC)

Discussion 6C Administrative action review

• Open to this idea, but I'd need to see more specifics first. I am also somewhat concerned this will duplicate the functions of AN and ANI. Trainsandotherthings (talk) 16:56, 31 October 2021 (UTC)
• I'm not convinced this will improve meaningfully on how ANI already does this type of review. User:力 (power~enwiki, π, ν) 19:14, 31 October 2021 (UTC)

  After reading more comments, I think that even if this is just "ANI reform" it probably is still a good thing. Still too many details to work out for me to vote, but I am optimistic. Regarding the name: maybe "Logged Action Review"? I'd straight-up suggest Code review except that would probably be too confusing. User:力 (power~enwiki, π, ν) 22:58, 31 October 2021 (UTC)

• I don't see overlap with AN(I) to be an issue. The pages have been subject to possibly the most monumental scope creep of any pages on Wikipedia, and are now both: (1) the most toxic pages on the website; and (2) the default place to achieve a mandate for substantial and potentially disastrous actions (such as removing rights, blocking and agreeing on mass actions), as well as moderating petty disputes and taking care of very simple issues that need quick attention. It is an advantage to have a dedicated forum for structured discussion designed to answer a specific question, rather than a meandering argument driving a user to either say "fuck it, I'm ignoring all of you and continuing on with no change to my behaviour" or to escalate their actions to the point where they are indefinitely blocked and/or choose to leave. — Bilorv (talk) 19:32, 31 October 2021 (UTC)
• Maybe this is bikeshedding territory, but it really can't be named WP:PRV. Not unless you want its participants to be regularly labelled prverts. —Cryptic 20:08, 31 October 2021 (UTC)
  • There was discussion on the talk page about the name. I think the name and shortcut are still up for discussion in the RfC. — Wug·a·po·des​ 20:13, 31 October 2021 (UTC)

    I agree the name should be changed, as discussed on the talk page, as it's not the permissions (or if they should continue to be assigned) that is being reviewed. isaacl (talk) 21:52, 31 October 2021 (UTC)

    I always thought that such a forum should be called Users for discussion. –MJL ‐Talk‐^☖ 03:20, 1 November 2021 (UTC)

    It's not the users that are the subject of discussion, but a specific decision they made. isaacl (talk) 05:35, 1 November 2021 (UTC)

  PReview? PerView? PermRev? —valereee (talk) 21:09, 31 October 2021 (UTC)

• It would make more sense if it was an uninvolved bureaucrat for advanced perms that require it, given that the crats giveth and the crats taketh away. It doesn't make much sense to say that the consensus of granting of adminship (or pc reviewer or whatever) is determined by bureaucrats but the consensus of (possible) revocation of adminship can be closed by any admeme acting on their own. Chess (talk) (please use {{reply to|Chess}} on reply) 03:52, 1 November 2021 (UTC)
  • @Chess: revocation of adminship is not one of the possible outcomes of the proposed PRV, nor would this change that only ArbCom can revoke adminship (except for inactivity). This could only possibly be an additional form for community input that ArbCom could decide for themselves whether/how to take into account. — Bilorv (talk) 11:48, 1 November 2021 (UTC)
• Is this process purely advisory or can it also enact topic bans or desysops or anything? If desysops are on the table, it's probably best to have bureaucrats be the closers. Jo-Jo Eumerus (talk) 11:21, 1 November 2021 (UTC)
  • The idea is that it would be advisory and, like e.g. WP:DRV, focused on determining whether a specific action was appropriate rather than coming up with 'remedies'. I imagine that if an admin had a series of PRV/XRVs closed against them, it might form the basis of an arbitration request where their wider conduct would be reviewed and a desysop considered. Or better yet, that they would change course before it reached that point! It seems this has been a source of confusion for a few people, perhaps at least partly because of the name, so I'll go ahead and update that per the talk page. – Joe (talk) 12:11, 1 November 2021 (UTC)
• I thoroughly agree with the accuracy of this part of Joe Roe's comment on the talk page: ... a middle ground between the free-for-all nature of AN/I, which is often said to generate "more heat than light" and peter out without resolution, and the all-or-nothing nature of arbitration cases, which is often said to be so highly charged that if an admin conduct case is accepted a desysop is a foregone conclusion. However, I still do not believe that admin accountability or length of tenure are in the back of the minds of most of the RfA voters. That said, if the current suite of debates is supposedly about RfA reform with a view to making an admin (s)election process kinder and more appealing to potential candidates, IMO, admin discipline is a proposal for another time and another place, such as for example WP:BARC was. Kudpung กุดผึ้ง (talk) 01:07, 2 November 2021 (UTC)
• I don't see any significant similarities between this process and WP:RFC/U or WP:WQA. If anything, it's ANI that currently functions as both those processes did, just without any procedural constraints. As King of Hearts puts it, XRV is to be "geared towards content, rather than conduct". – Joe (talk) 16:04, 2 November 2021 (UTC)

  I agree there are significant differences between comments on user conduct and the proposal—in particular, the outcome of RfC/U was strictly advisory. However RfC/U was not without procedural constraints, as can be seen at Wikipedia:Requests for comment/User conduct/Creation. isaacl (talk) 19:37, 2 November 2021 (UTC)

  Sorry, I mean, ANI currently functions as a version of RFC/U without procedural constraints. – Joe (talk) 20:01, 2 November 2021 (UTC)

• This has nothing to do with RFA reform. Why is it here? I don't buy the "it would be easier to get rid of problem admins" bit. It is far more likely to make candidates think twice if they're going to run a much more significant risk of being berated every time they do anything. This is a corrosive and negative concept. Risker (talk) 23:18, 6 November 2021 (UTC)

  @Risker: The text at the top of this section (Because RfA carries with it lifetime tenure, granting any given editor sysop feels incredibly important. This creates a risk-averse and high-stakes atmosphere.) was one of the points that found consensus in the last phase of this RfC. You might not "buy" it, but that is obviously the link to RfA, and I think it is unfair of you to insinuate that there is some sort of ulterior motive. – Joe (talk) 10:58, 7 November 2021 (UTC)

Issue 7: Admin permissions and unbundling

Rough consensus There is a large gap between the permissions an editor can obtain and the admin toolset. This brings increased scrutiny for RFA candidates, as editors evaluate their feasibility in lots of areas.

7A Limited adminship

Editors may make a "request for limited adminship" stating a specific task and duration between 1 and 12 months for which they need administrator tools. Requests for limited adminship will follow the normal RfA process. Comments on the request should be closely related to the suitability of the candidate to perform the specified tasks, rather than a holistic assessment of the candidate for all areas of adminship.

Further details

If the request is successful, bureaucrats will grant sysop rights for the duration requested. Near the expiration of the grant, the same process may be used to renew the limited request or the normal RfA process may be used to request an indefinite grant. Using tools for a purpose other than the requested task is tool misuse. Editors may raise complaints about tool misuse on the Administrators' Noticeboard to discuss whether the limited admin used their tools in excess of their agreed limitation. If there is a consensus that the tools were misused then a bureaucrat will desysop citing the community consensus. Limited administrators are also subject to existing Arbitration Committee procedures on desysopping.

Support 7A Limited adminship

1. I don't know if this will genuinely help. It even has the potential of making it harder to generate non-limited admins. But I do think it has the possibility of success and certainly some potential use-cases. As such, it warrants a chance to run. Nosebagbear (talk) 16:33, 31 October 2021 (UTC)
2. I think this could help; I'm sure non-limited admins will have enough trust and competence under their belts to still pass.  – John M Wolfson (talk • contribs) 16:38, 31 October 2021 (UTC)
3. Like other user rights, we provide temporary grants to see if they can be trusted to use the tools. The temporary nature means that the user needs to use the rights and so we have users who can show that they can be effective admins. Many other projects have time limited admin rights, and although enwiki is different to these wikis I don't see why trialing this would be an issue. Furthermore, this means that if a particular editor is helpful in one area (let's say copyvio) but has no experience in deletion discussions, the editor doesn't need to demonstrate to the community that they are trusted enough to also be able to delete articles in deletion discussions. However, this does run the risk of making the current RfA harder (as people might oppose as they want to see a candidate go for the limited first). On the other hand, this might make running for a full RfA easier after a limited length adminship. Dreamy Jazz ^{talk to me | my contributions} 16:46, 31 October 2021 (UTC)
4. Count me in. With a duration of 12 months, it practically becomes a mandatory recall after a year, for those who chose this path. I'd be willing to evaluate adminship performance and vote based on actual actions after a year. Less than a year, however, would be overly optimistic: People do need some time to make errors and learn from them without immediately facing a new election. ~ ToBeFree (talk) 17:09, 31 October 2021 (UTC)
5. Sure, seems fine and fits in to the current structure without any large process or technical changes needed. That being said, I'm not sure how useful it will be (I don't expect a high number of candidates needing this). — xaosflux ^Talk 17:22, 31 October 2021 (UTC)
6. Yes, works like a sort of internship or trainee program, candidate gains experience and trust and later can request permanent tools at RfA. Since RfA reforms were unable to address problems with standard requirements and level of scrutiny raises, we need different paths to get sysop flags. Carlosguitar ^{(Yes Executor?)} 17:56, 31 October 2021 (UTC)
7. Support. I see this as a "catch-all unbundling" process, to cover the gaps that are not big enough for us to establish a mandate for a specific unbundling. That is, it's useful where a user has a genuine need, but the need may not be shared by hundreds of people. Once we see this succeeding in action, I'd likely support a longer term limit than 12 months, as well. I see others consider this as more of a "trial period admin", which is a perfectly fine reason to support the proposal as well. Most dissent is over this making RfA harder. Given that the community has literally just established a mandate that "No need for the tools" is a poor reason as we can find work for new admins, and that I so rarely see "no need for the tools" as a reason to oppose nowadays, I do not believe these concerns will be realised in practice, nor that we couldn't address it only if it actually turns out to be true (e.g. RfC for closing crats to discount "should have run for limited adminship" as a valid oppose). — Bilorv (talk) 19:54, 31 October 2021 (UTC)
8. We routinely have unbundling proposals premised on the fact that many competent editors refuse to go through RfA just to get access to one or two tools (see my replied in the comments section). That is, in fact, an issue which achieved consensus in phase 1. We have editors who need tools, a broken process they refuse to use, and a reluctance to create new user groups to get them those tools. If the community refuses to create new permissions because those editors should just become admins, what options do we have left? This process grants access to editors interested in only a subset of the tools and because of that restricted nature avoids the most toxic elements of review at RfA that prevent these editors from running. As others have mentioned, there may be additional benefits for other use cases, but minimally we have a class of highly trusted editors who need tools and will not endure our existing hazing procedures. Other attempts to get them the tools they need failed, so this strikes me as the last best option. — Wug·a·po·des​ 20:44, 31 October 2021 (UTC)
9. Other wikis do this without issue. --Rschen7754 02:43, 1 November 2021 (UTC)

   I will add: I see this as permitting adminship for a narrowly defined task such as "editing protected pages related to the Main Page", not for such larger remits as "blocking vandals". That more closely aligns to what Meta uses this for. --Rschen7754 00:08, 2 November 2021 (UTC)

10.  ― Qwerfjkltalk 07:21, 1 November 2021 (UTC)
11. Per Wugapodes. ProcrastinatingReader (talk) 09:32, 1 November 2021 (UTC)
12. I certainly like this idea more than unbundling the admin tool set. Limited adminship is a thing on metawiki and to my knowledge it has worked well there. This may also finally prove to the community that doing a few niche things as an admin can still make you a very valued and productive admin. If a limited admin went a year and blocked hundreds of vandals without opposition, who cares if they are good at writing articles? That sort of change of mindset is what I'm hoping most will come out of RFA2021. — MusikAnimal ^talk 19:32, 1 November 2021 (UTC)
13. Per MusikAnimal. KevinL (aka L235 · t · c) 23:25, 4 November 2021 (UTC)

Oppose 7A Limited adminship

1. I'm afraid this will make it more difficult to gain full adminship. Furthermore, it will put additional bureaucracy in place (having to go through RfA twice if full adminship is required afterwards). These limited admins cannot help out at will at places with backlogs if that is not part of their purpose. If we have a large fractions of admins in this category, the resilience of the admin corps will further decrease. Femke (talk) 16:50, 31 October 2021 (UTC)
2. I am fundamentally opposed to creating different "tiers" of admins. This is unneeded bureaucracy and creates second-class admins. The "limited admins" would still go through RfA anyways, so what is the benefit here? I don't foresee many cases where someone who could pass for a limited adminship would not also pass for a full adminship. Trainsandotherthings (talk) 16:56, 31 October 2021 (UTC)
3. Per Femke. I can already envision the comments on full RfAs "Why wouldn't limited adminship be sufficient for that?" Soon enough, running first for limited adminship becomes a de facto requirement, and then candidates have to endure two RfAs rather than just one. If someone can't be fully trusted with the tools, they shouldn't have the tools; there shouldn't be some in-between state. {{u|Sdkb}} ^talk 17:34, 31 October 2021 (UTC)
4. Oppose. Per Femke, Trainsandotherthings, and Sdkb. Kudpung กุดผึ้ง (talk) 20:07, 31 October 2021 (UTC)
5. Oppose more or less per Femke. Unbundling is seductive, but counterproductive. Vaticidalprophet 21:51, 31 October 2021 (UTC)
6. Per Femke and Sdkb, I fear that this would only worsen the dearth of admins. Extraordinary Writ (talk) 22:12, 31 October 2021 (UTC)
7. Oppose, this would become a de facto requirement creating just another reason for arbitrary opposes. It will reduce the ability for new volunteers to actually help in a dynamic way(we don't know where the work will be in the future). This treats new admins as a lower tier and old timers as a sort of super admin. HighInBC ^{Need help? Just ask.} 23:03, 31 October 2021 (UTC)
8. In practice, I think this would end up just being another hoop to jump through in order to become a full fledged admin. We need less hoops, not more. -- Tavix ^(talk) 00:32, 1 November 2021 (UTC)
9. I'm afraid this will result in editors voting oppose during "full" RfAs and telling the candidate to seek a "limited" permission first before trying for the full thing. Isabelle ^🔔 03:09, 1 November 2021 (UTC)
   • Just to comment on this point, as many have raised it: the same concept exists on metawiki (for example) and isn’t a de facto requirement and it remains a minority of requests. While metawiki is not enwiki, the closest to evidence we have without implementing it is by looking at other wikis. ProcrastinatingReader (talk) 09:32, 1 November 2021 (UTC)
10. Per above. Sounds nice in principle, but I foresee this leading to increased drama and becoming a barrier to "full" adminship -FASTILY 04:55, 1 November 2021 (UTC)
11. I suspect this will make things worse. Candidates will be given a small subset of the admin toolkit and requests to give someone the current admin toolkit will be treated very suspiciously. Hut 8.5 09:46, 1 November 2021 (UTC)
12. If I'm reading this right, limited adminiship would only last for 12 months. What happens after that? If we allow editors the chance to seek a specific admin tool or tools -- blocking, deletion, page protection, etc. -- fine. But I see no reason for having a time limit on it. -- Calidum 16:37, 1 November 2021 (UTC)
13. Oppose. Agree fully with what was said by Trainsandotherthings, Femke, and Sdkb. Ganesha811 (talk) 19:22, 1 November 2021 (UTC)
14. Solution in search of a problem. We don't need partial admins, we need actual admins. Beeblebrox (talk) 20:13, 1 November 2021 (UTC)

    @Beeblebrox, and so 'partial' admins wouldn't be useful? Because it's all or nothing? DYK needs more people who can move preps to queues. I don't really care if they aren't interested in doing other adminny duties. —valereee (talk) 21:20, 1 November 2021 (UTC)

    Yeah, that gets brought up every time someone proposes something like this. I don't think that's anywhere near enough to merit such a fundamental change, and there's no reason to be certain doing this would automatically solve that specific problem. Beeblebrox (talk) 21:28, 1 November 2021 (UTC)

15. I get less thrilled with this idea as I get more experience as an admin. Look, either you can be trusted to be an admin, or you can't. And you don't have to use all the tools. Dennis Brown - 2¢ 00:01, 2 November 2021 (UTC)
16. Likely will make it more difficult for us to find actual full admins (compare template editors, rollbackers etc.) —Kusma (talk) 14:58, 3 November 2021 (UTC)
17. WP:SLOP 🐔 Chicdat  ^{Bawk to me!} 10:56, 5 November 2021 (UTC)
18. Something tells me that this will lead to even fewer full time administrators. Scorpions13256 (talk) 16:33, 5 November 2021 (UTC)

Discussion 7A Limited adminship

• Why do we care whether it limits requests for "full" adminship if all "full" adminship means is "admin for life"? Why do we care about tiers, ditto? —valereee (talk) 17:45, 31 October 2021 (UTC)
  • To split hairs, "full" isn't simply an indefinite grant. It's also an unrestricted grant. Limited administrators may only use their tools in specific areas for predefined tasks stated in their request and if they want to use the rest of the toolkit, they need an full RfA to evaluate that. It's not about creating tiers, but addressing a gap. As I mention in my comment below, many editors would like to help in particular areas but are not interested in a full RfA or in being an administrator at all. Proposals to unbundle tools so that we can accommodate those editors routinely fail. If the community will not unbundle permissions and editors needing tools refuse to go through a full RfA (for the reasons established in phase 1), this seems like the only possibility remaining. — Wug·a·po·des​ 20:10, 31 October 2021 (UTC)
• Can we get a list of a few examples of "specific tasks" that could justify a limited RFA? User:力 (power~enwiki, π, ν) 17:49, 31 October 2021 (UTC)

  Move prep to queue at DYK. This simply requires someone who is experienced at DYK and is trusted to edit through protections at the level of the main page. It's an area often in short supply of admins. —valereee (talk) 19:51, 31 October 2021 (UTC)

  Editors interested in main page curation (see the failed Wikipedia:Main page editor proposal from 2020); deletion of copyright violations (see discussion at issue P in phase 1); editors doing antivandalism response (see failed Wikipedia:Vandal fighters proposal from 2015 and failed unbundling semi-protection proposal from 2018). These usually fail for some variation of "anyone who would use these should just be an admin" without regard for the fact that lots of people who would use these perms don't actually want to be an admin or go through a full RfA (explained in more depth at the main page editor RfC). — Wug·a·po·des​ 20:09, 31 October 2021 (UTC)

• A crat could give the details of how this works, but I recently discovered that granting adminship for a time-limited duration is something the current software already supports. We already have several examples of granting temporary use of various tools for special projects. Don't arbcom election scrutinizers get temporary checkuser access? And WP:Event coordinators get some temporary admin-ish abilities. -- RoySmith (talk) 01:03, 1 November 2021 (UTC)

  @RoySmith: as far as mechanics: the "expiration" part would be handled by the software automatically (when granting the access, the expiration would be specified by the 'crat); the limits on usage would simply be policy based (e.g. If you asked for this access to just work on a project to delete old versions of PDF files, then started blocking people - you would be held accountable - likely blocked by other admins - pending access removal discussion). — xaosflux ^Talk 11:36, 1 November 2021 (UTC)

  Hell, I currently have temporary page mover rights. WP:PERM is allowed to give out temporary rights as a trial period. — Bilorv (talk) 11:50, 1 November 2021 (UTC)

• @Rschen7754: "Other wikis do this without issue." Would be nice to hear of some examples. I did apply for Global Rename on Meta a while back; is that the sort of thing you were thinking of? Ritchie333 ^{(talk) (cont)} 14:48, 1 November 2021 (UTC)
  • @Ritchie333: the only project that comes to mind that uses only rules to restrict limited admins is meta-wiki. Here we have adminbots, which slightly touch this (they have access to all tools, but are limited by rules to only use certain tools in certain cases - of course we also only allow these to be run by full admins). Several other projects have advanced usergroups such as interface-editor (not to be confused with global interface editor), eliminator, and engineer which are limited administrator types that also have technical controls. — xaosflux ^Talk 15:23, 1 November 2021 (UTC)
  • There are some arbcoms (I think dewiki is one) that have non-admins, where adminship is granted for the duration of their term and removed thereafter. Even we do it with the ArbCom steward scrutineers - they only have it for a limited time and can't go around CUing editors at will, they can only use it for the scrutineering. Test administrators on Incubator [2] is another example - while technically they have near-full admin access, they can only use the tools on their test. --Rschen7754 18:14, 1 November 2021 (UTC)
• In response to "If a limited admin went a year and blocked hundreds of vandals without opposition, who cares if they are good at writing articles?" Theoretically, that's not an issue, but if and only if they are 100% correct all the time. Then I'm interested in how they manage mistakes (do they apologise and make amends, or ignore it and dig their heels in) and that is what makes a difference. Ritchie333 ^{(talk) (cont)} 22:22, 1 November 2021 (UTC)
• @Kusma: Sure, but how many template editors actually would be admins right now if the TE user-right didn't exist? There are 190 template editors; it's unclear how many, at the time they requested TE, would've (a) passed RfA; (b) actually ran for RfA in the first place. I suspect a small portion though (20?). Ultimately, if TE didn't exist, we'd perhaps have marginally more admins and probably substantially worse widely-used templates, on balance a net - for the project. Similar logic but to a more extreme degree for rollbacker, since that permission is currently shall-grant. ProcrastinatingReader (talk) 23:50, 3 November 2021 (UTC)

  I'm not sure -- without TE, we'd have far more editprotected requests, and would notice people who should be admins (so they can do more work ) more easily? In any case, before unbundling, we had more successful RfAs and wouldn't have people with 2 years experience and 25k+ edits all over the encyclopaedia who haven't been nominated for RfA a few times. (But correlation is not causation). —Kusma (talk) 06:45, 4 November 2021 (UTC)

7B Researcher userright

Unbundle the WP:RESEARCHER userright, still to be awarded by the community at RfA. It's hoped that the community would apply different standards for researchers than for those with access to the rest of the toolset. This would be appropriate for editors with a need to view deleted revisions, such as those who fight socking or review deletions, who don't want to undergo a full RfA.

Further details
To implement this idea, the RFA page would be expanded include WP:RFR as well as RFA and RFB. Thresholds for passing, duration of discussion and all other rules would be identical to RFA initially -- if the idea is successful we could have a subsequent discussion about changing them.

Support 7B Researcher userright

1. Support practically-automatic granting of this right to SPI clerks who have finished their training and are trusted by checkusers. ~ ToBeFree (talk) 17:02, 31 October 2021 (UTC)
2. Support, as proposer.—S Marshall T/C 17:18, 31 October 2021 (UTC)
3. The reasons an editor might want access to deleted content are often different from the rest of the toolkit. Also, the reasons to restrict access to deleted content are different from the rest of the toolkit. This permission won't be super-common, but that's a good thing -- it avoids the concerns that successfully obtaining the researcher userright will become an unofficial pre-requisite for RFA. User:力 (power~enwiki, π, ν) 17:43, 31 October 2021 (UTC)
4. I have always seen viewing deleted content as a part of the toolkit which often is an outlier to other admin rights. By viewing deleted text you do not get any resulting admin like action which effects other users (except from maybe being able to share the deleted text, but this requires an extra step). Although in theory you could "undelete" the text by copying the wikitext into an edit window and then saving it, this would be something which IMO should lead to removal of the userright. For most really bad stuff (like privacy breaches) oversight is used. It allows users with a real need to see deleted content (like SPI clerks) to get access without having to become an admin (and all the extra work / stuff that comes with). I think that anyone with this right should have appropriate account security in place and should go through some sort of community discussion (as this is a requirement from the WMF I think). Dreamy Jazz ^{talk to me | my contributions} 18:40, 31 October 2021 (UTC)
5. Support. Use cases include for SPI and anti-vandal fighting, as referenced above. For XfD, DRV and other deletion-related processes, it is necessary to participate in a discussion with full information; its usage in copyright-related areas like CCI should be obvious. Currently, G4 is a silly CSD criterion because a non-admin can't know whether an article is eligible or not, unless they happen to (a) have seen and (b) remember in near-perfect detail the content of a page that is now deleted. This would also expand democracy in the cases where we are discussing misconduct issues, like vandals whose vandalism is mostly on now-deleted pages. It would be particularly important in cases of admin misconduct relating to now-deleted pages, where it is currently only admins and any non-admin who saw and remembers the page content who can properly contribute to the discussion and form a consensus. (A decision about admin conduct made only by admins will have obvious systemic biases.)
   It would be useful to me on a content creation basis: I often want to view the content of deleted drafts or AfD'd or CSD'd articles when recreating the same topic or a related one. The first use case is in establishing that I have new references to present to improve upon the declined draft or AfD'd article—without this, I'm potentially wasting several hours of my time rewriting content that was already considered by another editor and decided to fail GNG. The second usage is that viewing old drafts or content that was since redirected often gives me leads to look for or references I can re-summarise in my own words. As such I can either go to WP:REFUND (generally by the point it's refunded it will no longer be of use to me, as I'm past my initial search for sources) or lose out on useful information, just because the page happened to be deleted, not redirected. — Bilorv (talk) 20:24, 31 October 2021 (UTC)
6. Support. Net +ve change. If the researcher discussions turn out to be lower voltage than regular RfAs, there may even be a calming effect on standard requests. So this could even indirectly help us get more admins. FeydHuxtable (talk) 14:32, 7 November 2021 (UTC)

Oppose 7B Researcher userright

1. I think this is a bit too much bureaucracy. The law of the instrument applies, and I feel that if I can't trust someone to block or protect, then I can't trust them to view deleted material, which has some actual legal implications.  – John M Wolfson (talk • contribs) 16:16, 31 October 2021 (UTC)
2. Weak oppose because I don't think this is going to fix anything, I'm all for making another group of people with some tools to do some work - but this doesn't sound like the right tool bag to make a process for. — xaosflux ^Talk 17:19, 31 October 2021 (UTC)
3. Strong oppose. It invites too many opportunities to be used for personal agenda. Kudpung กุดผึ้ง (talk) 20:10, 31 October 2021 (UTC)
4. I agree with xaosflux. If the goal is to grant viewdeleted etc to certain editors, I would rather we craft a user group tailored to the particular use cases with all the necessary tools rather than co-opt a user group meant for something completely different. From a meta-perspective, this will also create problems for oversight by polluting the namespace. As it is, we can see who is researching our deleted contributions and easily keep tabs on the WMF research activities. If we start granting this for other purposes we make it harder to observe actual researchers and their activities by hiding them amongst editors doing completely different things. I would be very willing to create a new user group, but I'm opposed to scope creep for the researcher user group. — Wug·a·po·des​ 20:53, 31 October 2021 (UTC)
5. Sorry but these are some of the most sensitive userrights in the admin bundle. Looking through deleted revisions of a userpage often yields sensitive information and is not logged. What is more these researcher admins will not really be solving the lack of admin problem, because they will not be doing anything productive. There is no way at all to vet if they are using the tools in a way that would support greater access in the future. HighInBC ^{Need help? Just ask.} 23:05, 31 October 2021 (UTC)
6. On the surface this seems like a good thing and it is just going by the policies, but WP:REVDEL has been used in too many cases where oversight should have been used instead for me to be comfortable with allowing broader access to it. Chess (talk) (please use {{reply to|Chess}} on reply) 04:05, 1 November 2021 (UTC)
7. No. Researcher should only ever be granted by WMF. I have no desire to expand the audience of deleted edits. Anarchyte (talk) 06:32, 1 November 2021 (UTC)
8. Viewdelete is a dangerous thing to nonadmins. If you want viewdelete, don't ask the WMF for an obscure user right, run for adminship. 🐔 Chicdat  ^{Bawk to me!} 10:47, 1 November 2021 (UTC)
9. I had a longer write-up, but it ultimately comes down to the fact that I can't think of a single user who is trustworthy enough to be granted this right but not trustworthy enough to be granted full adminship. Extraordinary Writ (talk) 18:44, 1 November 2021 (UTC)
10. I'm not buying that this actually solves any real problems. Beeblebrox (talk) 20:16, 1 November 2021 (UTC)
11. It was interesting until you said they wouldn't have to go through RFA. Yes they would. The Foundation has made it very clear that anyone that has access to copyright infringing material (deleted) or other deleted material must go through an RFA like process. Their legal dept. has pretty much said it is required to shield the Foundation from legal recourse for these copyright infringing edits. You can check if you like, but I would bet my lunch money the the WMF is NOT going to allow that bit to be flipped without an RFA. This is one of those times I agree with them. Dennis Brown - 2¢ 00:06, 2 November 2021 (UTC)

    Dennis Brown, may I respectfully request that you re-read this proposal? I think you may have misunderstood how it would work.—S Marshall T/C 08:36, 2 November 2021 (UTC)

    I did. It talks about RFA and then says "such as those who fight socking or review deletions, who don't want to undergo a full RfA.". A full RFA is what the Foundation requires (or granting by them using their own vetting) to get access to deleted material. Dennis Brown - 2¢ 12:59, 2 November 2021 (UTC)

12. I doubt users would subject themselves to an RFA only for the ability to see deleted content. -- Calidum 16:52, 2 November 2021 (UTC)
13. Not a terrible idea, but I think viewing deleted on content is too niche a need to justify the overhead from unbundling it. Bilorv does point to some plausible use cases above, but the typical SPI clerk, vandal fighter, or CC investigator is already going to be on the 'admin track' and would be better encouraged to just go for a full RfA. – Joe (talk) 11:47, 3 November 2021 (UTC)
14. This is a potentially dangerous userright because the action is not logged. Its an invisible action that could be silently abused without any scrutiny. Imagine bad Wikipedia content being harvested and then republished elsewhere. Jehochman ^Talk 08:24, 5 November 2021 (UTC)

    FWIW requests are probably logged at a WMF sysadmin level, in the server's access logs. If copious amounts of deleted content were being republished somewhere, I think the WMF could check their logs and identify the admin responsible pretty soon. ProcrastinatingReader (talk) 14:07, 5 November 2021 (UTC)

    Even if it were logged at the server level, the information still gets out. Deletion operates on a security-by-obscurity basis, so any potential leak is a catastrophic failure for the system; if the horses have already bolted from the stable, it doesn't if you close the doors. Like EFH and TPE, this would be a dangerous userright and the limited oversight only makes it more so. — Wug·a·po·des​ 07:29, 6 November 2021 (UTC)

    Perhaps, but the right is still granted by the community at RfA. I imagine the scrutiny of a 2021 Researcher RfA would be greater than that of a 2007 Admin RfA. Certainly, the volume of the former will be less than the latter. So I’m not personally convinced this proposal really increases the risk surface; tens more editors with access doesnt compare much to the hundreds of inactive admins who currently have access. ProcrastinatingReader (talk) 11:35, 7 November 2021 (UTC)

Discussion 7B Researcher userright

• I'd have to query to John as to how the law of the instrument applies here. Viewdelete doesn't offer any methodology to enact an outcome (where a different tool would usually be used) because it has to executive action inherent. Additionally, while I agree as to the "trust" issue, adminship necessitates both "trust" (which is across the board) and "competence" (which can differ in areas). Someone could meet the trust aspect, but not say sufficient competence you'd want them deleting, but more than enough to act safely with hidden edits. Nosebagbear (talk) 16:29, 31 October 2021 (UTC)
  • I'd say that being able to view deleted material without yourself being able to delete material would be a bit of a waste, and if I'm not mistaken only 3(!) users actually have the userright. While it wouldn't be as bad as the true "law of the instrument" due to its lack of ability to do anything, it would still be such a waste that I would still oppose.  – John M Wolfson (talk • contribs) 16:34, 31 October 2021 (UTC)
• Need to have a further think about this. Dreamy Jazz ^{talk to me | my contributions} 16:41, 31 October 2021 (UTC)
  • Now voted support. Dreamy Jazz ^{talk to me | my contributions} 18:40, 31 October 2021 (UTC)
• I recall stumbling across Wikipedia:Arbitration Committee/June 2008 announcements/Activation of view-deleted-pages, presumably written by a 2008 ArbCom. I think the premise there remains true and this is a useful tool to unbundle, although probably not have it called "researcher". I'm not sure about giving it to XfD regulars; it's a valid use-case on the surface, but then it creates a distinction between a "noticeboard regular" and everyone else, namely by providing technical advantages to the former group to review cases the latter might not be able to. It would just solidify a cabal. I prefer the current system, where pages are generally temporarily undeleted for everyone to see. I wouldn't want to see that become less common just because more DRV regulars were able to see deleted text. ProcrastinatingReader (talk) 18:45, 31 October 2021 (UTC)
  • There's already such a cabal (administrators) in all areas where viewing a deleted page is relevant to a decision but the page cannot be undeleted. The request is about expanding membership of the cabal, which would hopefully make it less cabal-like. In cases where the page in question can be undeleted, we do need to see people asking for temporary undeletion and I hope such requests would not decrease, except where they are genuinely no longer needed by anyone participating in the discussion. — Bilorv (talk) 20:24, 31 October 2021 (UTC)
• I'd support this idea in theory, but I'd be curious to first hear whether or not the WMF Office has any objections to this, legal or otherwise, since they currently control access to the group if I'm not mistaken (I believe only stewards and Jimbo have the ability to actually manage this group). Taking Out The Trash (talk) 19:02, 31 October 2021 (UTC)

  @Taking Out The Trash: they won't; they care more about the underlying permissions than the "group" - and we are already allowed to issue those permissions after a showing of community support (e.g. at RfA). There is already plenty of precedent for more powerful non-admin groups that include this access on other projects. (e.g. eliminator@fawiki and arbcom@fiwiki) — xaosflux ^Talk 19:21, 31 October 2021 (UTC)

7C Unbundle blocking from the admin rights

I may be wrong, but it seems like the most contentious ability that admins have is the power to block editors. If we unbundle blocking, and move it to a new user group, perhaps that will make adminship "no big deal", like it was always supposed to be. All existing admins would be grandfathered into the blockers user group (or whatever it might be called).

Support 7C Unbundle blocking from the admin rights

1. I think I would support some form of this -- specifically, unbundling admin tools related to content maintenance, and tools related to user behaviour enforcement. In the past several years we've already tiered things -- EFM's and techadmins. Why not further separate "gnome" adminship and "blocker" admins. Speaking from experience, I'd want the former but not the latter, if that was a choice that was technically feasible. Let us do histmerges and viewdelete and let someone more vetted do the rangeblocks and user-right removals. I dunno, I get it may be hard to draw a line (protection?) and this might not be a worthwhile solution, but RfA has had for a decade consensus about the issues and no solution that any solution is "worthwhile" so who knows. Separating janitors and security guards seem like a step in the right direction. Ben · Salvidrim! ✉ 20:36, 1 November 2021 (UTC)
2. A moral support I guess, since this proposal is too thin on details to actually be put into practice (how is blocker requested and granted? is it only for admins?) But Ben makes a really good point above: there are two broad categories of admin work, and the qualities needed to be a good 'janitor' or 'content admin' (diligence, knowledge of policy, ability to read consensus) are different from the qualities needed to be a good 'guard' or 'conduct admin' (calmness, knowledge of IP ranges, emotional intelligence). I've felt I needed to oppose more than one RfA because the candidate has only one and not the other, and I think splitting the two roles is worth thinking about. – Joe (talk) 12:03, 3 November 2021 (UTC)
3. Moral support – you should have said unbundle the right to block extended-confirmed users – send that upstairs to a special group like the checkusers and suppressors – and I would also support unbundling the right to block new editors that are not yet autoconfirmed to a new "vandal blocker" group. wbm1058 (talk) 00:43, 7 November 2021 (UTC)

Oppose 7C Unbundle blocking from the admin rights

1. Sorry, this proposal is way to vague to support as it is. — xaosflux ^Talk 17:17, 31 October 2021 (UTC)

   Once a bit more became available: While I'd be open to consider ways to extend permissions like 'block' to others, I'm very opposed to actually removing that permission from sysops - being able to stop active disruption is an important task that all admins should be able to do. — xaosflux ^Talk 10:45, 4 November 2021 (UTC)

2. Blocking and unblocking should be held by the same groups. I do not support allowing any user group to block without the power to unblock as well. Accidental blocks do happen. Trainsandotherthings (talk) 17:21, 31 October 2021 (UTC)

   @Trainsandotherthings: There is no unblock right. Blocking and unblocking are both controlled by the "block" right, AFAIK. Nosferattus (talk) 18:00, 31 October 2021 (UTC)

   If so, and you are probably right, that would eliminate my original oppose reason. I do also oppose it on the basis that blocking and unblocking are fundamental parts of the admin toolkit that should not be unbundled. Trainsandotherthings (talk) 18:05, 31 October 2021 (UTC)

   Interestingly, MediaWiki lacks documentation about this. I have now created phab:T294710 asking for this to be fixed. ~ ToBeFree (talk) 18:24, 31 October 2021 (UTC)

3. I could possibly support unbundling some subset of the blocking permission (along the lines of this), but the ability to block anyone at all should, if anything, be harder rather than easier. Extraordinary Writ (talk) 17:26, 31 October 2021 (UTC)

   Why do you assume it would be easier? I very much doubt that would be the case. Nosferattus (talk) 17:55, 31 October 2021 (UTC)

   See below; let's keep the discussion there ~ ToBeFree (talk) 18:06, 31 October 2021 (UTC)

4. I oppose any more unbundling, almost on principle.  – John M Wolfson (talk • contribs) 17:27, 31 October 2021 (UTC)
5. I strongly suspect this will lead to blocking being treated as a big deal. The block button really shouldn't be that contentious. Take a look at the people who are actually getting blocked: the vast majority are vandals, spammers or sockpuppets, and the rest are largely very new users who are doing something obviously disruptive. Hut 8.5 17:37, 31 October 2021 (UTC)
6. Half-baked idea. Creating a cadre of admins that can't patrol AIV is not an improvement. There is a perennial suggestion to limit blocking of extended-confirmed users; though even there admins should have a break-glass ability to block compromised or stealth-vandalism accounts. User:力 (power~enwiki, π, ν) 17:57, 31 October 2021 (UTC)
7. In it's current form, I don't support this. Dreamy Jazz ^{talk to me | my contributions} 18:24, 31 October 2021 (UTC)
8. Oppose. Like John M Wolfson, I oppose on principle any further unbundling of what's left in the admin toolset. Otherwise what's the point in having admins? And most definitely the power to block. Such a user right is what all the hat collectors would be standing in line for. Kudpung กุดผึ้ง (talk) 20:16, 31 October 2021 (UTC)
9. This is a non starter. The phrase half-baked has come up and I agree. Once again this idea creates lesser admins and old timer super admins. HighInBC ^{Need help? Just ask.} 23:07, 31 October 2021 (UTC)
10. I would never support such an outrageous proposal; blocking has always been one of the three core admin tasks: Block, delete, protect. Giving it to others would wreck the encyclopedia. 🐔 Chicdat  ^{Bawk to me!} 10:44, 1 November 2021 (UTC)
11. No way. If somebody vandalises today's featured article page with Nazi insignia or hardcore pornography (I've seen both), you don't want to wait - you hit the block button there and then so they can't easily retaliate. Ritchie333 ^{(talk) (cont)} 14:28, 1 November 2021 (UTC)
12. I think #7A Limited adminship is the better proposal. To do counter-vandalism properly you need to be able to also protect and delete pages. — MusikAnimal ^talk 19:50, 1 November 2021 (UTC)
13. Terrible idea. Admin tools are a set, an admin that can't block anyone might as well not be an admin at all. Beeblebrox (talk) 20:17, 1 November 2021 (UTC)
14. Not to pile on, but blocking is a core tool that every admin needs, even if they do not use it much. And I wouldn't want an admin that only had the block tool, obviously, so there isn't use for debundling it. Dennis Brown - 2¢ 00:08, 2 November 2021 (UTC)
15. As above. Blocking is probably the least unbundleable. ~ Amory (u • t • c) 14:29, 3 November 2021 (UTC)
16. Spencer^T•C 20:54, 3 November 2021 (UTC)
17. Blocking is highly scrutinized and frequently reversed. No need to unbundle. Jehochman ^Talk 08:26, 5 November 2021 (UTC)
18. Even if this came with the understanding that the group would only be granted to admins. Every admin task needs access to blocking. —Cryptic 08:36, 6 November 2021 (UTC)
19. Block, protect, and delete are too related to each other to unbundle any of them. -- Tavix ^(talk) 17:03, 6 November 2021 (UTC)

Discussion 7C Unbundle blocking from the admin rights

• How would someone apply for membership in the blocking usergroup? Wouldn't the result be easier access to the blocking usergroup than to the sysop usergroup? That doesn't match the reasoning, then. ~ ToBeFree (talk) 17:05, 31 October 2021 (UTC)

  The same way you apply for membership to other usergroups. Why do you assume it would be easier? I imagine it would be harder as the scrutiny previously used for admins would be transferred to the new blockers user group. Nosferattus (talk) 17:53, 31 October 2021 (UTC)

  Ah. I think your argument is based on the – I'd say incorrect! – assumption that more than half of RfA's scrutiny is caused by the blocking permission alone. Page deletion, history modification and even editing access to the main page are bundled. Additionally, if this really works like WP:PERM, all that's needed to receive the permission is one single administrator who trusts the user enough. That's much easier than passing RfA. ~ ToBeFree (talk) 18:03, 31 October 2021 (UTC)

• Do we really want anyone blocking people who thinks, "I'd like to block people! Think I'll apply for that right!" When I ran RfA, I though blocking anyone would be a rare occasion. It's not something I do a lot of, but I do use that tool. —valereee (talk) 18:47, 31 October 2021 (UTC)
• If the admin user group is unbundled, block/protect should be together in one group, and delete/viewdeleted in another. We wouldn't need to have an RfA for the first group. (If we wanted to do that.) Levivich 21:13, 31 October 2021 (UTC)

  @Levivich, sorry, I'm stupid today...we wouldn't need an RfA for block/protect? —valereee (talk) 21:19, 31 October 2021 (UTC)

  IIRC the WMF wants "community vetting" for the viewdeleted permission, but not for block or protect. So we could have a system where the "delete admins" give the block/protect perm out like it was Template Editor or Page Mover. Or where everyone gets block/protect after hitting some criteria like 10k edits and two years without sanction. I think that would be very interesting, and would lead to quicker resolution of chronic disruption between veteran editors. :-) Levivich 21:20, 31 October 2021 (UTC)

  ~ ToBeFree (talk) 22:27, 31 October 2021 (UTC)

  Giving out block automatically is scary to me. I see too many editors with 10k edits who still don't understand the speedy deletion process or WP:BITE and make a hash of things -- having them also be able to block anyone who didn't get their first attempt at a page perfect will scare off every possible new editor for sure.--Fabrictramp | talk to me 00:34, 3 November 2021 (UTC)

• Shameless plug for Wikipedia:Requests for comment/Responder role. Enterprisey (talk!) 01:20, 4 November 2021 (UTC)

7D Remove autopatrolled from default toolkit

I would suggest removing the autopatrol user right from the default sysop toolkit, but still leaving the autopatrolled user group assignable by admins (including to themselves). This would be a similar concept to how edit filter manager permissions are not included in the greater sysop toolkit, but EFM can be self-assigned by sysops.

Support (7D Remove autopatrolled from default toolkit)

1. As proposer. Taking Out The Trash (talk) 18:56, 31 October 2021 (UTC)

   I feel like that removing autopatrolled from the toolkit by default would decrease the pressure/expectations of candidates having a large amount of content creation/content work/GA/FA/whatever under their belt. If admins did not become autopatrolled by default, it would open the door to having admin candidates that are exclusively or almost exclusively technical or countervandalism or some other non-content focus. Now before anyone says that having autopatrolled able to be self-assigned by admins doesn't actually alleviate the concerns, we don't currently expect candidates to demonstrate proficiency in managing edit filters even though they can assign EFM to themselves. This would be along similar lines. Moved from collapsed box as non-neutral explanation by proposer. Barkeep49 (talk) 19:00, 31 October 2021 (UTC)

2. Support. I have seen definite cases of extremely sub-standard articles created by admins, particularly those who passed RfA long ago but have somehow not noticed that notability standards have increased since 2005 (and by "somehow not noticed" I mean "deliberately ignored every polite notification of this"). Passing RfA does not demonstrate competence at creating articles to a sufficiently high standard that we don't need a second pair of eyes on it, nor should it. We expect admins not to be fully proficient in all actions they can technically perform, but to read up on new areas before plunging in, and learn from constructive feedback they receive and consequences they observe. How can they do that in page creation without sufficient scrutiny in their actions? Autopatrolled is somewhat unique in that all it does is remove a vector of feedback you get, so we shouldn't be handing it out to someone with 3 page creations and 1 GA when the same person would not be granted it at WP:PERM. — Bilorv (talk) 20:42, 31 October 2021 (UTC)
3. Letting admins self-assign autopatrolled instead of granting by default is, I think, a reasonable idea. I wasn't opposed for my article creations, but the relationship between my creations and autopatrolled was a point of discussion in my RfA. Like EFM, it's just not a tool that everyone needs, and if you do, you can give it to yourself. If not, let your contributions go through NPP. Personally, I might actually prefer that for myself since I don't create articles at a high volume. Regardless of the OP rational, I think it's just a good idea to let admins customize their toolkit a bit more and see very little downside. — Wug·a·po·des​ 20:59, 31 October 2021 (UTC)
4. That's okay; I don't need it and wouldn't self-assign it. I was very relieved when my low amount of content creation didn't lead to many opposes. ~ ToBeFree (talk) 22:30, 31 October 2021 (UTC)
5. I don't see why autopatrolled needs to stay as the default for admins, especially since many admins would not otherwise meet the autopatrolled criteria, and there have been issues with admins having autopatrolled in the past.Jackattack1597 (talk) 23:05, 31 October 2021 (UTC)
6. I see no reason why this right should be auto-applied to admins. Administrative actions are carefully separated from content matters. If they are qualified for it then there is no reason they just can't get it the normal way. I don't see how this would help RfA, but it would probably help a little with article patrol.
   I don't believe it should be taken away from existing users without reason, though asking if they really need it is fine. HighInBC ^{Need help? Just ask.} 23:09, 31 October 2021 (UTC)
7. Certainly an improvement; my only concern was that it was too trivial to justify the increased rule burden. Enough admins (or potential admins) appear interested in not having this permission, so this isn't an idle change. User:力 (power~enwiki, π, ν) 23:14, 31 October 2021 (UTC)
8. Per above. -FASTILY 04:55, 1 November 2021 (UTC)
9. This won't change anything about RfA, but I do like the idea of autopatrolled not being a part of the admin toolset. Anarchyte (talk) 06:57, 1 November 2021 (UTC)
10. Very strong support. RfA is about administrative competence (sensibly) and doesn't really assure us that an editor can create articles that don't need a second pair of eyes. In general we have far too many autopatrolled accounts and far too low a standard for granting it, but that's definitely out of scope of an RfA RfC... – Joe (talk) 08:53, 1 November 2021 (UTC)
11. I see no problem with this idea. Admins who frequently and appropriately create new articles can request autopatrolled (or even assign it to themselves) to avoid being a burden on NPP. Those who do so more infrequently probably could benefit from having a quick once-over on it when they do create one. Hopefully, this will reduce the "Oppose due to content creation" bit; that's not particularly relevant to being an admin and hopefully this change will make it clear that it is not. Seraphimblade ^{Talk to me} 10:10, 1 November 2021 (UTC)
12. There have been a few discussions in the past year about autopatrolled (eg Carlos Suarez 46), and the ability to have autopatrolled separate from the admin toolset appeals to me a lot. 🐔 Chicdat  ^{Bawk to me!} 10:42, 1 November 2021 (UTC)
13. Eh, I am not entirely convinced that this would have any effect. OTOH, it's always struck me as a little odd that autopatrol [which is a totally passive userright] is part of the default package. And I can't think of a reason why it would be bad if admins didn't have autopatrol. So, support. Jo-Jo Eumerus (talk) 11:23, 1 November 2021 (UTC)
14. Don't see why not. You can still do plenty of article writing and convince the community of it at RfA without actually creating any new pages in mainspace. Ritchie333 ^{(talk) (cont)} 14:30, 1 November 2021 (UTC)
15. Support. Also slightly reduces the adverse consequences in the inevitable circumstance when spammers become admins. MER-C 17:41, 1 November 2021 (UTC)
16. Autopatrolled is chiefly about patrolling mainspace articles. Insufficient experience in content writing is a common excuse to oppose an otherwise great candidate at RfA. Thus, not having autopatrolled automatically in the sysop group may alleviate those concerns. Sure, you'll probably get conditional support !votes like "support if the candidate agrees not to make themselves autopatrolled", and similar social implications, but if the net result is adminship is less about content building than it is perceived by many today, it's a win to me. — MusikAnimal ^talk 19:58, 1 November 2021 (UTC)
17. Support. I know I prefer having my articles reviewed personally despite being otherwise qualifying for autopatrolled. If I was an admin, I would prefer to still see that as I tend to write about topics which can edge the lines of notability and could always use a second opinion. –MJL ‐Talk‐^☖ 20:34, 1 November 2021 (UTC)
18. This is a good idea primarily because there's little or no connection between what RfA assesses (whether a user has the trust of the community to carry out certain maintenance tasks) and what autopatrolled requires (whether a user can categorize, tag, format, etc. his own articles without needing help). Since it might have an additional effect of lowering incrementally the RfA standards (I'm skeptical but it certainly won't hurt), I support it. Extraordinary Writ (talk) 00:32, 2 November 2021 (UTC)
19. Seems reasonable --Guerillero ^{Parlez Moi} 10:33, 2 November 2021 (UTC)
20. Entirely orthogonal to the debate IMO, but is not a terrible idea on its own. Will definitely create more work across the board, but perhaps there are minor confidence gains? Weak support. ~ Amory (u • t • c) 15:22, 2 November 2021 (UTC)
21. I've supported this before, with a rationale similar to that of MJL. (But it seems a bit offtopic here). —Kusma (talk) 17:40, 3 November 2021 (UTC)
22. Per above. ― Qwerfjkltalk 20:45, 4 November 2021 (UTC)
23. Weak support. Dreamy Jazz ^{talk to me | my contributions} 13:24, 7 November 2021 (UTC)

Oppose (7D Remove autopatrolled from default toolkit)

1. No thanks, this minute tweak isn't going to solve the increased scrutiny for RFA candidates problem; I can't think of the last time someone got opposed for fear that they were incapable of creating a page that didn't meet the minimum acceptance criteria. — xaosflux ^Talk 19:04, 31 October 2021 (UTC)

   @Xaosflux: There seemed to be quite a few opposes related to "insufficient content work to be trustworthy with autopatrolled" at Wikipedia:Requests_for_adminship/1997kB. Granted, I wasn't active at that time, so there may be other context I'm missing. Taking Out The Trash (talk) 19:06, 31 October 2021 (UTC)

   @Taking Out The Trash: thanks for the note, regardless if I trust someone to assign patrol and autoparol to others, I trust them to use it appropriately themselves. That being said, I am in support of phab:T280890 (which would allow any autopatrolled page creator to unpatrol a page they create if they think it should have more scrutiny). — xaosflux ^Talk 19:10, 31 October 2021 (UTC)

   Assigning autopatrol seems very simple and uncontroversial if someone meets the requirements and has not gathered negative feedback from other editors. Being able to determine if an article is excellent is not the same skill as writing an excellent article. But, voting support at RfA is not saying "this person currently has the skills to work at Wikipedia:Requests for permissions/Autopatrolled", but "if this person chose to work there, I trust they would learn and prepare sufficiently by themselves to do so". As for opposition at RfA, one might expect that "oppose: no content creation" would be used and replied to a little bit differently if the most major content creation-related right is removed from the kit. — Bilorv (talk) 20:50, 31 October 2021 (UTC)

2. Nope. If you don't have enough content work to be autopatrolled, you don't have enough to be a sysop, end of, full stop. This would be a nuisance for admin content creators such as myself, as well.  – John M Wolfson (talk • contribs) 19:08, 31 October 2021 (UTC) Too minor in any event to be of help, will only be a nuisance to admin content creators such as myself. – John M Wolfson (talk • contribs) 19:25, 31 October 2021 (UTC)

   To be fair, candidates pass RfA without autopatrolled all the time: it's not usually granted without at least 25 newly created articles, which is a far higher threshold than even the most ardent pro-content-creation !voter demands. Extraordinary Writ (talk) 19:19, 31 October 2021 (UTC)

   Fair enough, and I consider myself rather lenient on content creation so long as it's not "frighteningly negligible". Struck and replaced with a better oppose rationale. – John M Wolfson (talk • contribs) 19:25, 31 October 2021 (UTC)

3. The autopatrolled right means that your creations don't need to be reviewed by NP patrollers, who are largely interested in filtering out articles which obviously need to be deleted and applying obvious maintenance tags (unreferenced, uncategorised etc). A candidate who genuinely can't manage that shouldn't be an admin. Nor do I see any argument that this will actually solve any issues with RfA. Are people actually more concerned about the autopatrolled right than block, delete or protect? This would also increase the workload of NP patrollers (a perpetually backlogged area), for no particular reason. Hut 8.5 09:42, 1 November 2021 (UTC)
4. What Hut said. There is only one admin in recent history that caused problems with autopatrol, and once it was FINALLY caught, he was more or less run out of town on a rail. Mainly because he was a jerk about it. If an admin can't be trusted with autopatrol, he can't be trusted with the other bits. Dennis Brown - 2¢ 00:11, 2 November 2021 (UTC)
5. Pointless bureaucracy that does nothing to solve the problem. What was the problem this section intends to address again? wbm1058 (talk) 00:53, 7 November 2021 (UTC)

Discussion (7D Remove autopatrolled from default toolkit)

• In response to John in the oppose section, my whole point is that sysops don't need content experience, frankly at all, in order to be an effective admin. Users who are exclusively dedicated to countervandalism efforts or other technical aspects would still make effective admins. Producing content doesn't actually involve the admin tools most of the time, and so whether or not someone can write an article to X standard isn't really indicative of their ability to use the (mostly technical-based) sysop tools properly. However, people expect sysop candidates to have content experience because the toolkit comes with autopatrolled. If it didn't this expectation wouldn't be necessary. Taking Out The Trash (talk) 19:35, 31 October 2021 (UTC)
  • I'm sorry, but I'm going to have to disagree with that point, as are many people. The fact that content creation is de facto required for adminship has nothing to do with autopatrolled, but is there because Wikipedia is an encyclopedia far before it's a technical/social clique w/ AN, ANI, ArbCom, etc.; all of that is built on our encyclopedic content. Indeed, as Amakuru said during the 1997kB RfA, candidates should have experience in the "coal face" boiler room before ever approaching the mop. People adamantly dislike restaurant owners who were not themselves chefs and don't take seriously club managers who never themselves played the sport; analogously, someone who is "running" Wikipedia without any experience with what Wikipedia actually does is generally not going to get very far. – John M Wolfson (talk • contribs) 19:47, 31 October 2021 (UTC)
    • I strongly agree with this comment, John M Wolfson, but not the argument you are using it to make. An autopatrolled level of content creation is not required for adminship, even though substantial content creation is. It seems you too don't require this in your votes, and have acknowledged that many RfAs pass with less than this level of ability. — Bilorv (talk) 20:54, 31 October 2021 (UTC)
      • Fair enough, but I do think it's minor and a slight net negative per my new oppose rationale, as well as per Power. – John M Wolfson (talk • contribs) 20:57, 31 October 2021 (UTC)
• This seems like it is nominally an improvement, but possibly not enough of an improvement to justify the rules creep. Are there any admins who would prefer not to have autopatrolled? Or editors who want an admin to not have autopatrolled? There's also the issue of whether "creating low-quality articles" should be considered "use of the admin tools" in finding cause to de-sysop. User:力 (power~enwiki, π, ν) 20:48, 31 October 2021 (UTC)
  • On the latter: yes, all admins who don't qualify by the normal WP:PERM requirements. — Bilorv (talk) 20:54, 31 October 2021 (UTC)
  • @力: Your small-question reminds me of Wikipedia:Arbitration/Requests/Case/Carlossuarez46. – Joe (talk) 08:57, 1 November 2021 (UTC)
• This idea could use a bit more research and refinement. I believe some other wikis have a similar setup, but I think those use pending changes. --Rschen7754 03:50, 1 November 2021 (UTC)
• Keep in mind that autopatrol applies to all pages, and all pages are subject to new page review. It has some additional impact on new "articles", but that doesn't take away from new pages - and admins often create a lot of miscellaneous pages that shouldn't also need patrolling. — xaosflux ^Talk 11:31, 1 November 2021 (UTC)

  Ping to proposer: @Taking Out The Trash: - seems like this component was skipped in the review and this was presented as only being about "articles" when it actually applies to "pages". — xaosflux ^Talk 15:06, 1 November 2021 (UTC)

Not really sure what's being asked of me here. Taking Out The Trash (talk) 00:07, 2 November 2021 (UTC)

@Taking Out The Trash: it seems that the only thing presented about "autopatrol" is that it has to do with self-authoring new encyclopedia articles, however it actually has to do with the creation of all pages - everything from a new user talk welcome or warning, to many maintenance operations that an admin could run in to that deal with pages (including those in article space). — xaosflux ^Talk 00:11, 2 November 2021 (UTC)

Well, the impetus for this proposal/idea was the issue of candidates being opposed at RFA for lack of content creation because adminship comes with becoming autopatrolled (a theme heavily brought up in the 1997kB case but also in several others), even though that's not really necessary to be an effective admin. I realize that all page creations have to be patrolled, but I don't think that many members of NPP are really focused on backend pages. Besides the admin toolkit includes New Page Reviewer permissions, so I would think that admins could just manually self-patrol maintenance edits that they do that they know are uncontroversial. I don't quite meet the criteria to officially join NPP just yet, but I'm curious as to what the traditional backlogs of unpatrolled pages outside of article space are. Not sure if that really clarified anything - I'm signing off for the night now but I'll take another crack at this in the morning if necessary. Taking Out The Trash (talk) 00:19, 2 November 2021 (UTC)

In my experience, most people really only focus the content creation part of WP:NPP. There is kind of a gap there as the Page Curation tool/NewPagesFeed are only available for article content parts. Compare [3] to [4]. That this and this are in two separate logs kind of shows part of the problem.

Honestly, autopatrolled itself should be split to really only focus on the content creation part, so things like Wikipedia:New pages patrol/Redirect whitelist wouldn't be needed. –MJL ‐Talk‐^☖ 17:37, 4 November 2021 (UTC)

7E New "Semi-protector" role

Create a new role, available to sufficiently experienced editors, that allows them to semi-protect pages for up to an appropriate duration, e.g., 72 hours.

Extended content

It seems to me that allowing experienced, non-admin editors to temporarily semi-protect pages would help keep the WP:RfPP backlog down and would have less risk of abuse than handing out the ability to block. The permission could be granted in the fashion described at Wikipedia:Requests for comment/Responder role (no self-noms, discussion at WP:AN, at least 1 year and 1,000 edits experience required, etc.).

Support (7E New "Semi-protector" role)

1. As proposer. XOR'easter (talk) 00:11, 7 November 2021 (UTC)

Oppose (7E New "Semi-protector" role)

1. Oppose due to the implementation method, this design depends on these "group members" making a request to another admin, who would run a bot to just grant the requests. I'd prefer this be done software side, by splitting the protect permissions to be more granular with wgRestrictionLevels (e.g. permission protect-n can protect to restriction levels [array]), and maybe building the time controls in there too (though I'd be fine with that being just a policy); alternatively an extension that can handle some sort of short term protect/block could be a solution as well. — xaosflux ^Talk 00:48, 7 November 2021 (UTC)
2. Definitely not. This would lead to many editors with this right protecting articles when blocking would be far more appropriate. This would cause a lot of collateral damage for IPs on these articles, and the disadvantages this proposal brings far outweigh the advantages. 🐔 Chicdat  ^{Bawk to me!} 12:18, 7 November 2021 (UTC)
3. Blocking can be be more useful than protection in many cases. As such, giving some users the ability to semi-protect may lead to these editors semi-protecting because they can't block, where blocking is more useful and better for the article. For example, for an article which is in the current news there may be one static IP or new account who is vandalising which would be prevented from editing by semi-protection, but by protecting it stops many IPs and new editors from contributing to the article. As such I don't think this would really help. Dreamy Jazz ^{talk to me | my contributions} 13:28, 7 November 2021 (UTC)

Discussion (7E New "Semi-protector" role)

• Having been around for a few news events, my expectation is that those are exactly the situations where many-to-most edits by IP's and new accounts are bad, or at the very least need filtering through the edit-request mechanism on the Talk page. The news can bring multiple disruptive individuals editing from different IP's or under different account names. Deny the trolls the satisfaction until the event passes from the headlines, and everything goes much more smoothly. Of course, I've had the idealism burned out of me, so I'm not likely to be optimistic about such things; YMMV. XOR'easter (talk) 14:52, 7 November 2021 (UTC)

Issue 8: RfA should not be the only road to adminship

Rough consensus Right now, RfA is the only way we can get new admins, but it doesn't have to be.

8A PROD-style adminship

Phase in a "PROD-style adminship" process analogous to our proposed deletion (PROD) process for articles.

Further details

Anyone may nominate a candidate, except that self-noms are not permitted and no one may nominate someone who has run before at RfA or this process. These "PROD RfAs" are advertised on watchlists and WP:CENT just like standard RfAs, and placed on the same table(s) with their PROD status marked. On each page there is only the nomination statement(s) and a section for opposers to list and explain their objections; no questions, supports, neutrals, or general discussion. A PROD RfA passes when, at the end of seven days, there are fewer than 15 opposes. This number is calculated by noting that every successful RfA since the mid-to-late 2010s has had at least 150 supports, and defining 90%+ as "non-controversial". If a PROD RfA reaches 15 opposes before the 7 days are up, the candidate has the choice, and 48 hours to make it, of whether to continue the process of a normal RfA (with the 7-day timer being reset) or not, with the latter incurring no prejudice against a run for standard RfA in the future. People say that there are people who oppose every RfA on principle, which would render this process useless, however I have yet to see any evidence of that since at least 2019. Just in case that is indeed a valid concern, each editor is limited (across all accounts) to one oppose a month; if this gets adopted, this is a value that can be modified as seen fit, and does not in any event apply towards standard RfAs.

Support 8A PROD-style adminship

1. As proposer. Any issues brought up are probably surmountable.  – John M Wolfson (talk • contribs) 16:17, 31 October 2021 (UTC)
2. Support as a trial period, and I'll agree to be a guinea pig for it if it passes. I think the base idea is workable after seeing what the process would actually produce if left to run, and then tweaking thresholds/rules appropriately. We have just agreed as a community that "RfA should not be the only road to adminship". So, we need to experiment with alternatives to RfA through practice, not by endless discussions on the topic.
   The advantages of the proposal are that less commentary and slower-moving discussion addresses "Level of scrutiny", which we have communally agreed is an issue with RfA, but without removing the constructive feedback an editor gets from the process. Blind pile-on oppositions that we have seen tank at least one recent RfA that should have passed will be discouraged in a system where the numerical threshold and consequences are clear: 15 votes and the candidate is out, and you can't oppose for the rest of the month. Disadvantages do not include the below scares that "one oppose per month" would lead to people passing by gaming the system—the community are not stupid and we already have to watch RfA for suspicious voting activity. Given how few people we have willing to be admins, I also can't imagine so many candidates running that all opposition would be naturally exhausted. — Bilorv (talk) 23:36, 31 October 2021 (UTC)

Oppose 8A PROD-style adminship

1. Opposing on the basis of "1 oppose a month". Currently, that would be fine, but because any policy change to update the value would take time, the current ruleset doesn't cover what to do in the event where a multiple need arise at once. Possibly something like "if the 15-cap is met, then the oppose is "refunded" might work Nosebagbear (talk) 16:32, 31 October 2021 (UTC)

   I guess, if the 15 cap is met, an opposer has ~12-24 hours to "refund" an oppose for later use in the month. As said before, specific details would have to be sussed out if this gets consensus.  – John M Wolfson (talk • contribs) 16:37, 31 October 2021 (UTC)

2. I am deeply skeptical of any proposal that would create multiple concurrent pathways to adminship. I worry that the effect may be that admins who pass based on this PROD-style system are treated differently than those who pass via the existing process. I also have concerns about the viability of this proposal on its own merits. The existing RfA system has plenty of problems, but I'm worried that this will not provide enough possibility of discussion. Trainsandotherthings (talk) 16:46, 31 October 2021 (UTC)

   I am deeply skeptical of any proposal that would create multiple concurrent pathways to adminship – This may be your opinion, but in phase 1 of this project we have established consensus that RfA should not be the only road to adminship. — Bilorv (talk) 23:36, 31 October 2021 (UTC)

   Read more closely. I oppose multiple concurrent pathways. I'm not opposed to a new process that replaces the existing RfA process. And I am allowed to voice my opinions on the matter regardless. Trainsandotherthings (talk) 23:52, 31 October 2021 (UTC)

3. I strongly oppose this suggestion because I think it has several problems. First even the title is misleading - this is nothing like the prod process which is designed for uncontroversial maintenance, any single editor can stop a prod - even after the fact. Second, lack of a showing of some level opposition does not equate to a showing of actual community support necessary to get past the global expectations for access to deleted content. Third, barring bona fine objectors simply because they participate in other discussions is a bit much for me - and related to that the objectors can be eliminated by simply creating many of these in a short period (possibly in bad faith) - such that then we would need to have other discussions about voiding them. — xaosflux ^Talk 17:06, 31 October 2021 (UTC)
4. This won't necessarily be harmful but I don't think it will do anything to resolve the issues with RfA. The only people who would put themselves up for PROD-style adminship are those who think they will pass easily with little opposition. Those people are exactly the people who will have the least reservations about using the existing RfA process. People who are intimidated by the existing RfA process won't use it and we won't end up with any more admins. I can also see the experience being even more negative for candidates as they will only get negative feedback. Hut 8.5 17:30, 31 October 2021 (UTC)
5. This is a non-starter. A lack of opposition is not the same thing as community support. This will create a second class of admins that never got the support of the community, but rather just did not upset enough people along the way. HighInBC ^{Need help? Just ask.} 23:14, 31 October 2021 (UTC)

   A lack of opposition is not the same thing as community support – Except that this is exactly how RfA is at present, where there's guaranteed to be a large turnout and a majority of people who reflexively say "no big deal, not a jerk, has a clue" (if they are unconvinced by opposes), and the opposition or lack thereof is what actually determines the outcome. — Bilorv (talk) 23:36, 31 October 2021 (UTC)

   I believe that most take a careful look at the candidate and that your characterization is unfairly trivializing those participants. The reality is that unsuitable candidates are often opposed by those who support suitable candidates. If you look at historical RfAs you will see that, with few exceptions, the supporters and opposers are the same people. HighInBC ^{Need help? Just ask.} 23:54, 31 October 2021 (UTC)

   I personally do not, and simply support unless I see glaring issues. That said, I do agree that people often unfairly oppose. – John M Wolfson (talk • contribs) 23:55, 31 October 2021 (UTC)

6. The "one oppose per month" is a complete non-starter with me, but it seems clear that won't actually be allowed to make a substantial impact. The bigger problem is that the flood of "supports" is the fun part of RFA (for both candidates and voters) and I'm not sure why to get rid of it. A "RFA without candidate participation" (like 4A but without the sortition aspect) seems like a better option to allow people to become admins with a lesser burden of participation. User:力 (power~enwiki, π, ν) 00:09, 1 November 2021 (UTC)

   The correct plural, per Italian, is adminabili, although adminabiles is good Latin. – John M Wolfson (talk • contribs) 00:17, 1 November 2021 (UTC)

   The lack of support 'flood' that you point out here is interesting. Seems like it has the chance to poison the well for candidates who get 15 opposes and then choose to pivot to a full RFA - the community will already have been primed with negatives and no positives. Retswerb (talk) 05:06, 6 November 2021 (UTC)

7. This differs from PROD in two critical ways, and that makes the title indeed misleading, as well as the process likely not workable. The first is that PROD is designed to be lightweight—it is easy to propose a deletion under it, and just as easy to prevent or undo it. Even if the deletion already took place, a single objection results in an uncontested undeletion. Secondly, the "one oppose a month" criteria is subject to gaming—a candidate could just wait until a lot of their likely opposers have already used theirs, and then run. With PROD, conversely, an editor may object to and thereby stop as many PROD proposals as they believe warranted. So far as the process itself, the lack of even questions severely limits the community's ability to evaluate the candidate, as does the lack of discussion. Seraphimblade ^{Talk to me} 03:35, 1 November 2021 (UTC)
8. I appreciate the sentiment, but... no. RFA is supposed to be a discussion. This moves further away from that instead of closer. Beeblebrox (talk) 20:19, 1 November 2021 (UTC)
9. The Foundation has made it pretty clear that an RFA like we currently use is required to give someone access to deleted material. Dennis Brown - 2¢ 00:12, 2 November 2021 (UTC)
10. Doesn't really seem to solve the issue, just provide another, slightly easier path for those already on a glide path. ~ Amory (u • t • c) 15:17, 2 November 2021 (UTC)
11. Opposing this as I don't think solves the issue at hand. Dreamy Jazz ^{talk to me | my contributions} 13:31, 7 November 2021 (UTC)

Discussion 8A PROD-style adminship

• Other avenues is a good starting point for brainstorming but it is waaaaayyy to easy to find 15 editors with misogynistic and racist behaviors on this platform for this to be effective at resolving the problem. Hmlarson (talk) 16:23, 31 October 2021 (UTC)
  • Editors are limited to one oppose a month. Also, I fail to see how racism or misogyny would play into it; if there are editors who would really oppose a female/non-white admin, a) they would already be present at RfA, and b) 'crats would (rightfully) throw such !votes out.  – John M Wolfson (talk • contribs) 16:25, 31 October 2021 (UTC)
• As the opposes-per-month limit is optional, it does not disqualify this idea for me. I'm slightly concerned about what appears to be an idea behind this proposal: Is this for nominating people who would refuse running for adminship themselves? Like, for nominating someone who I think qualifies but explicitly refused to start an RfA? ~ ToBeFree (talk) 17:00, 31 October 2021 (UTC)
• Am I correct to assume that the nominee must accept it before this "prodminship" process can actually begin? Aside from that, the idea is interesting, but I'm not sure I can support it with the current oppose limit. If there is indeed a number of editors who !oppose every RfA, we should work to solve that issue separately, as an oppose limit could lead to gaming of this system. Isabelle ^🔔 12:21, 1 November 2021 (UTC)

8B Admin elections

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

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

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

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

Support 8B Admin elections

1. I think is a good idea. It is fairly simple, free of bureaucracy and would take a lot of heat of the whole process. scope_creep^Talk 16:31, 31 October 2021 (UTC)
2. This idea addresses two potential problems at once: A) By combining many RfAs into one big election, the entry barrier is lowered for each candidate. It doesn't hurt to join the election and to see what happens; one isn't the target of all the spotlights. B) By having a secret voting process after an initial round of comments, the bandwagon effect is reduced. While this will reduce the unanimity of successful RfAs (opposition does not require a reason anymore), it may cause good candidates to run for adminship who would otherwise avoid the toxicity of the public opposition. ~ ToBeFree (talk) 16:51, 31 October 2021 (UTC)
3. I similarly think this idea addresses multiple issues, as pointed out by Tobias above, and I see no reasonable difficulties with implementation (after all, we already use the same process with ArbCom elections, and this if anything is simpler and likely to require less intervention from election commissioners than other methods). RandomCanadian (talk / contribs) 17:12, 31 October 2021 (UTC)
4. I'm willing to support this at least on a trial period (maybe do it twice, then require a confirmation to continue) - keep in mind that I expect that there will be some significant technical challenges to getting it running for the first time. — xaosflux ^Talk 17:15, 31 October 2021 (UTC)

   I'd rather that Three days for discussion and questions... be 7, not all editors are here every 3 days - but this isn't a showstopper for me. — xaosflux ^Talk 17:45, 31 October 2021 (UTC)

5. I think this is absolutely worth a try: at least in theory, it has the potential to reduce corrosiveness, scrutiny, and hesitancy to run. I agree with Xaosflux that some sort of trial period would be good since unanticipated consequences are always a possibility, but this seems to address many of the problems that plague RfA. Extraordinary Writ (talk) 17:23, 31 October 2021 (UTC)
6. Worth a try, but would also like a trial period. Femke (talk) 17:25, 31 October 2021 (UTC)
7. Also think it's worth a try, it might reduce the pressure involved in the process. Hut 8.5 17:46, 31 October 2021 (UTC)
8. Yes, worth to try. It may also reduce level of scrutiny and create a better atmosphere at RfA. Carlosguitar ^{(Yes Executor?)} 18:21, 31 October 2021 (UTC)
9. Worth a try. By bundling everyone together it reduces the amount of spotlight that an editor will feel going through an RfA. This is already partly achieved by nominators grouping their candidates together in small groups. Also by providing a system where editors can only simply vote for or against anonymously this means that there is likely to be less permanent to see negative scrutiny for a candidate who ends up failing. This is because the discussion and question stage lasts for less time, and generally only a few people will mention this issue in a comment unlike many voters who use it as a rationale to oppose. Dreamy Jazz ^{talk to me | my contributions} 18:30, 31 October 2021 (UTC)
10. Worth trying as an additional route (rather than replacement of current RfA). —valereee (talk) 18:49, 31 October 2021 (UTC)

    Support trial per xaosflux — Wug·a·po·des​ 21:00, 31 October 2021 (UTC)

    The opposition, especially by Risker, BusterD, and Jo-Jo Eumerus, has made me rethink my support even on a trial basis. — Wug·a·po·des​ 22:28, 1 November 2021 (UTC)

11. Support. This is the only real way to decrease perceived scrutiny for the candidate without decreasing actual scrutiny to a level where the RfA is not rigorous enough. Questions can still be asked but the candidate is not on the hook to respond to all drama that arises on a discussion solely about them and lasting a week. Additionally, ArbCom is roughly speaking a much higher position of power than adminship, so if the suffrage conditions and success percentage are no more lenient than for ArbCom (and as proposed they aren't) then no-one can object to admin elections unless they also object to how ArbCom elections are currently done. I suspect the value that will need to be changed is a reduction in the support percentage required to pass, but this is something to discuss again when we have some concrete outcomes from a trial. (I don't see a need to codify how many "trial runs" we do before re-discussion, as such a thing is contingent over whether the elections are successful or not.) — Bilorv (talk) 21:11, 31 October 2021 (UTC)
12. So, I put this together and therefore obviously support - though I won't take credit for it, it's something that has been suggested in the past a few times. My hope here was to put together something that may actually work. I certainly agree with Cryptic on the support percentages - though those are something that can be adjusted with some based on some trial and error. I'll add more tomorrow. Worm^TT(talk) 21:50, 31 October 2021 (UTC)
13. This seems like a good idea as an alternative route to adminship, but the support percentage may need to be adjusted after a couple of runs of the system.Jackattack1597 (talk) 23:11, 31 October 2021 (UTC)
14. To an extent I agree with Cryptic below, but I think our current system is collapsing so badly that we need to do something that really changes it, and this is, in my view, the only sufficiently radical proposal on the table.—S Marshall T/C 00:05, 1 November 2021 (UTC)
15. I think this has potential. A longer question period and lower pass percentage would probably be better, but this is probably the right alternative to the traditional method. Aircorn (talk) 02:30, 1 November 2021 (UTC)
16. I like this idea. I agree with all above me who requested for a longer period of discussions. Isabelle ^🔔 03:20, 1 November 2021 (UTC)
17. Support with a week or more for the discussion; the other details can be debated later. I carefully considered the opposes. The toothpaste is already out of the tube on it being a consensus-driven activity. RfA isn't (any longer) a good use-case for a consensus-based discussion. The outcome is binary; there can be no compromises. There's no way for a solution to anything to gradually evolve; there's only accusations and defenses. Bilorv put it well: decrease perceived scrutiny without decreasing actual scrutiny. As for other concerns: I imagine candidates already think RfA is quite imposing enough; for suffrage requirements, the voter rolls are public; for gaming, the same concerns apply to ACE; and for difficulty of implementation, I'm sure something can be figured out and I would hate to see a good idea die just because implementing it is tough. Enterprisey (talk!) 07:21, 1 November 2021 (UTC)
18. This is a very smart idea that has the potential to square the circle around the desire to spare candidates public humiliation and the necessity of open discussion. If it's successful, I could see it replacing RfA entirely, but it's sensible to start it in parallel as a sort of trial. I agree that three days is too short, especially if the community has to assess multiple candidates. But that can be tweaked as we go. – Joe (talk) 09:01, 1 November 2021 (UTC)
19. With significant caveats about thresholds. Vaticidalprophet 12:59, 1 November 2021 (UTC)

    Nice idea. Hopefully substantially less animus. ProcrastinatingReader (talk) 14:34, 1 November 2021 (UTC)

    Risker's comment in the discussion section gives me pause. ProcrastinatingReader (talk) 14:09, 5 November 2021 (UTC)

    Struck per the above. Risker's later comment, on the substantive issues, makes me feel this won't work as intended. ProcrastinatingReader (talk) 03:32, 6 November 2021 (UTC)

20. Yes, let's give it a go Ritchie333 ^{(talk) (cont)} 14:38, 1 November 2021 (UTC)
21. I support giving this a try, though there are technical issues that will need to be resolved. Trainsandotherthings (talk) 14:44, 1 November 2021 (UTC)
22. Support as trial only - I would prefer to have two or three elections before the next RFC but would also support a mandate for only one election. There are legitimate details that must be worked out, but the idea is good and we will only find out by trying. Regarding the concerns: if the WMF can't support us using SecurePoll even once, the community must simply write our own balloting tool. The voter rolls will be public, so I don't see any particular concerns about socking beyond what we have at RFA today; presumably some local checkusers could abstain from voting and scrutineer if necessary. If it is harder for candidates to pass a secret ballot than a public one, we will either adjust the standards or candidates will be motivated to use a public vote. And while there won't be bolded votes in the initial discussions, editors should be able to be clear about where they stand; there is no need for voter guides. User:力 (power~enwiki, π, ν) 16:55, 1 November 2021 (UTC)
23. Per ToBeFree and Bilorv, I think this is a good proposal. Some of the details may need to be adjusted after a time period, but I believe this could seriously improve the atmosphere for RfAs and lead to a larger number of high-quality editors getting through the process. Ganesha811 (talk) 19:18, 1 November 2021 (UTC)
24. Worth trying. MER-C 19:24, 1 November 2021 (UTC)
25. Weak support, mostly due to agreeing with Risker's concerns. I think xaosflux' idea of a trial run or two would be ideal. ~ Amory (u • t • c) 15:16, 2 November 2021 (UTC)
26. If it's good enough for arbcom it's good enough for admins. I'm not sure that oppose rationales are a feature and not a bug, particularly, as pointed out below, given the community's opinion on issues 1 and 2. The SecurePoll technical limitation is easily resolved (hello, it's the 21st century, we can run more than one poll on a website) and should not be a barrier to a good idea. I don't see the harm in trying this. Levivich 16:10, 2 November 2021 (UTC)
27. It's worth a shot at least. -- Calidum 16:53, 2 November 2021 (UTC)
28. We should try this. —Kusma (talk) 10:34, 3 November 2021 (UTC)
29. This is the only proposal that both fundamentally fixes the issue and has a chance in hell of passing. Riskers argument below leaves me unmoved. If the SecurePoll infrastructure cannot accommodate our admin elections, the WMF should update it. If they do not update it, we will hack together our own version. People below also talk about voter guides like they're a bad thing - they're fundamentally not, they're a healthy part of the process, and the solution to how to inform voters of late-discovered issues. This proposal takes enough of the unpleasantness out of the process that people may actually run. Tazerdadog (talk) 17:20, 3 November 2021 (UTC)
30. RFA currently has too much drama in it and people are scared to use it. As others have said, RFA is already a poll anyways so using a secret ballot here is the obvious answer. RFA needs a replacement or at least some kind of major change, this has been a problem for FAR too long. If this continues it will harm the long-term health of the wiki. Swordman97 ^{talk to me} 04:16, 4 November 2021 (UTC)
31. I don't think technical concerns should be an issue. ― Qwerfjkltalk 20:47, 4 November 2021 (UTC)
32. Support: This seems to be a clean solution. —¿philoserf? (talk) 00:38, 5 November 2021 (UTC)
33. I'd be willing to give this a chance. -- Tavix ^(talk) 20:08, 5 November 2021 (UTC)
34. This would be particularly good coupled with a sortition process (as in 4A above) but even on its own would be an improvement. --JBL (talk) 18:49, 6 November 2021 (UTC)
35. Worth a shot, and the technical issues seem surmountable. If they aren't, I'd rather find that out from actual experience; better to try and fail than fail to try. To echo Tazerdadog, if SecurePoll is so terrible, we ought to be forcing the WMF's hand to improve it anyway. I concur with Enterprisey's observation above that RfA isn't (any longer) a good use-case for a consensus-based discussion. It's not like AfD, say, where the nuances of the discussion can lead to an intermediate outcome like selective merging, and the closer's conclusion can be reviewed in a more-or-less straightforward way. And since the goal is to improve the atmosphere, the votes don't have to be super-secret. For example, an editor could vote by creating a subpage of the RfA. At a sufficiently rapid interval, a bot could come along and delete the subpage, transmitting its contents to the 'crats. That way, seeing how any editor voted would in practice be difficult enough that the ballot would be sufficiently secret for the purpose at hand. Frankly, how the discussion page looks is more important than whether Eve can enumerate the results by scraping the Recent Changes feed or whatever. We don't need to clone the ArbCom election process; we need to match the tool to the problem. XOR'easter (talk) 21:53, 6 November 2021 (UTC)
    • RfA's a discussion, not a vote. Besides... we need more admins, not fewer! 🐔 Chicdat  ^{Bawk to me!} 10:54, 7 November 2021 (UTC)
      • This proposal is for a new system in addition to the existing RfA process. Why would it lead to fewer admins rather than more? XOR'easter (talk) 14:28, 7 November 2021 (UTC)

Oppose 8B Admin elections

1. I think I brought up something like this at phase 1, but overall way too much bureaucracy for my tastes. An ArbCom election is this whole annual shindig, and while I'm proud to serve as a reserve election commissioner this year I think introducing that level of bureaucracy and pomp into something that's supposed to be quite commonplace like RfA would have the opposite effect and make it more intimidating and formalized. I much prefer the "in-and out", "bada-bing-bada-boom" aspect of the RfA status quo.  – John M Wolfson (talk • contribs) 16:21, 31 October 2021 (UTC)
2. There was a large drop in average support when arbcom elections moved from open to closed voting. (I want to say it was something around 15 or 20 points, but I'm too lazy to go look.) I'll grant that there's people who refuse to run an RFA because of the atmosphere who'd likely pass in the 90% range. I can think of two offhand. But I'd lay odds that there are far more that would pass a traditional RFA, get universal support in the public discussion period where people are accountable for what they say, and not even break 50% in the safely-anonymous voting. Being able to name and shame people who oppose for poor reasons is a feature, not a bug. —Cryptic 20:49, 31 October 2021 (UTC)

   Regarding Being able to name and shame people who oppose for poor reasons is a feature, not a bug. Issues 1 and 2 above are clear that the community believes it is a bug. There is a balance to be found, where issues can be raised, but not with shame. Worm^TT(talk) 08:04, 1 November 2021 (UTC)

   If the community truly thinks that opposes like the first (struck-through) one here should have been treated with less contempt, then there really isn't any hope. —Cryptic 10:12, 1 November 2021 (UTC)

3. Wikipedia was build on the concept of WP:CONSENSUS, and we rather pointedly avoid voting on things. The suffrage requirements are very easily gamed. Drive by opposes for reasons normally not acceptable by the community will increase as they will go unchallenged. People need to give their reasons for support or opposition and they certainly should not be able to support or oppose anonymously. Frankly I don't think arbcom should be doing that way either.
   With the recent issue of a sockmaster almost becoming an admin I am very concerned that short of every participant getting a CU(something the checkusers have said they cannot do) that it would not be hard to push an RfA over the limit through sock puppetry. Arbcom election standards state This process includes using the checkuser tool to view voter IP addresses. This process requires checking every user who voted and takes a couple of weeks. We can't be checkusering every voter at RfA and we certainly can't be doing a couple of weeks work for each RfA. This has not been thought through.
   This is no replacement for our current human vetting of participants. HighInBC ^{Need help? Just ask.} 23:16, 31 October 2021 (UTC)

   Almost 2000 votes were cast in the 2020 ArbCom election, compared to 150–300 at modern RfA, so there is no reason why scrutinising would take 2 weeks. Your impression might be that we can't be checkusering every voter at RfA, but mine is that checkusers essentially informally scrutinise every voter at RfA at present, with suspicious voters regularly struck after a mysterious checkuser block. (This is not to say we're all being CU'd, as the CU tool itself is primarily useful to augment behavioural evidence.) — Bilorv (talk) 00:37, 1 November 2021 (UTC)

4. I never liked going to secret ballots for ArbCom, and certainly don't like it here. We've always been built on a consensus model, not a balloting one. If you have something to say about a given proposal, say it publicly and state your reasoning behind it. Seraphimblade ^{Talk to me} 03:40, 1 November 2021 (UTC)
5. Would have considered supporting proposal without the addition of secret ballots. Next we will have to decide on whether we allow guides for the elections. --Rschen7754 03:48, 1 November 2021 (UTC)
6. Elections are easily gamed. If a long-term abuser can almost make it to adminship, why wouldn't the next attempt involve a team of sleepers preparing for the vote? There are many contentious topics where teams of people would be motivated to try that. Also, three days is not sufficient time for problems to be unearthed. Per WP:NOTFISHING and a lack of magic pixie dust, we cannot rely on checkusers to unearth sleepers who passively wait for the vote. Voters should engage with issues raised on the RFA page. It's ok for a vote of arbitrators since no one arb has the power to act alone, and there is a grueling Q&A and discussion period. Johnuniq (talk) 03:53, 1 November 2021 (UTC)
7. I'm concerned about any change from an admin run to an admin race, especially a race that runs on a schedule. Just like the arbcom process, nobody can stop a user from creating !voter guides for such a race. Worse, timed admin elections may have the unintended consequence of giving off-wiki actors and others who are WP:NOTHERE clear and targeted opportunities to coordinate, disrupt and possibly manipulate !voting information. These sorts of issues render the admin process more politicized. Despite our frequent disagreements, so far wikipedians have been able to avoid overt partisanship in formal processes. If it is broken, the RFA process is at least now a screening/approval process (like choosing a doctor or accountant), not a contest (like choosing a representative). Making adminship any sort of competition makes us vulnerable to organized opposition from inside and especially outside the pedia. Lowering our typical measure of consensus is a bad thing. Politics and voting is a pandora's box we should never open. BusterD (talk) 04:01, 1 November 2021 (UTC)
8. Per above. Not a fan of the private voting aspect, could be trivially gamed (especially by a competent sockmaster), and formalizes RfA as a vote, which imo runs counter to WP:CONSENSUS. -FASTILY 05:05, 1 November 2021 (UTC)

   @Fastily: in the SecurePoll method, the list of voters is public, with timestamps. As such, what is public is no different to during RfA except the votes themselves. As such, I'm confused as to why this system could be "trivially gamed" but current RfA cannot (or can it be?). — Bilorv (talk) 12:02, 1 November 2021 (UTC)

   Yes, that's precisely my concern: RfA is a consensus building exercise, and as such, "!votes" and their accompanying rationales need to be public so we may discuss their merits. And yes, this proposed system could be trivially gamed. I won't get into specifics for obvious reasons, but I will say that our methods/tools for identifying/stopping sockpuppets are crude and often ineffective. Checkuser isn't pixie dust, and competent sockmasters regularly slip beneath the radar. If we can't see how accounts are voting (or their rationale), how exactly are we as a community supposed to curtail abuse? Like it or not, the tools can be used to gain the upper hand during disuptes and/or in contentious topic areas, so there is already a lot of incentive for bad actors to gain admin access. Why should we make it easier for them to abuse our community? I can see the appeal of alleviating some of the stressful aspects of the RfA process, but I think this proposal has significant drawbacks that would ultimately lead to greater harm than benefit. -FASTILY 01:57, 2 November 2021 (UTC)

9. Aside from several of the previously mentioned points, the reality is that the SecurePoll infrastructure is already near capacity, has almost zero technical support, and will significantly impede other projects from using SecurePoll for more important things like their local Arbcom elections. SecurePoll is limited to one instance at a time throughout the Wikimedia-world; it is not possible for there to be two or more simultaneous elections using it. (I note that the recent MCDC election had a significant impact on the Arab Wikipedia arbcom election, both delaying the arbcom election, and requiring the MCDC election to be "dumped" much earlier than initially planned, in order for the arbcom election to be set up.) I get that we on English Wikipedia don't really consider the impact on other projects when we come up with ideas. But this one would create a fair amount of animosity. Risker (talk) 05:41, 1 November 2021 (UTC)

   @Risker: I fully agree that this is a concern, however, the reason is that it is all managed from one place, a private wiki. It does not seem excessive to request an expansion Of the system from the WMF. I'll ask them about it directly. Worm^TT(talk) 07:16, 1 November 2021 (UTC)

   Sorry quick pedantic note (because what are we as Wikipedians if not all kinds of pedenants?) but MCDC impacted Farsi Wikipedia not Arabic Wikipedia. It is hardly unusual for these two languages and ethnicities to be confused which is one reason I try to get it right and to point it out when I see it. That said SecurePoll scarcity is an issue as I noted below when it was suggested it be even more frequent. Best, Barkeep49 (talk) 15:29, 1 November 2021 (UTC)

   Conversely, a large project like us using SecurePoll more often might spur the WMF into allocating resources to improve it. – Joe (talk) 15:58, 1 November 2021 (UTC)

   Barkeep is correct, and I apologize for mixing the two up. And I have a hard time imagining that the WMF is going to put a lot of resources into SecurePoll, or allow it to be devolved to individual projects. There's been some recent tinkering which has been a net negative from what I understand. Heck, they won't resource 2FA or any other security measures, either. Risker (talk) 23:38, 1 November 2021 (UTC)

10. Too many unknown unknowns, in addition to the known knowns already identified. Leaky caldron (talk) 08:09, 1 November 2021 (UTC)
11. I just hate secret ballots. Influencing others' !votes is part of RfA, and an important part at that. 🐔 Chicdat  ^{Bawk to me!} 10:39, 1 November 2021 (UTC)
12. No, per what Risker said - there are technical limitations to SecurePoll that would significantly problematic if we used it in this manner. Also, what do people do if they find a significant problem with a candidate after the three days but can't publicize it with an "Oppose: [Significant issue]" rationale? Jo-Jo Eumerus (talk) 11:25, 1 November 2021 (UTC)

    Either you canvass or you write a guide. Both of which open up more cans of worms. --Rschen7754 18:19, 1 November 2021 (UTC)

13. My concern is with the fact that it's only every six months. That just makes it feel more bureaucratic, and means people who want to become admins have to plan their life around the admin elections, rather than planning their RfA for a time they can handle. Invalid^OS_talk 12:59, 1 November 2021 (UTC)

    The proposal suggests that the normal RfA process will remain an option. ProcrastinatingReader (talk) 14:37, 1 November 2021 (UTC)

    How is this equitable? This already sounds like a 2-tiered system in which folks who happen to have more time during election months will be subject to an easier adminship process than those who opt for the standard RfA. -FASTILY 02:26, 2 November 2021 (UTC)

14. I want to like this idea, but Risker's reasoning is hard to ignore. I have to admit I had no idea that SecurePoll was limited in that way. It would be a jerk move to do this. Beeblebrox (talk) 20:29, 1 November 2021 (UTC)
15. Risker makes very valid points, but I would also add that RFA has always been a discussion with the goal of establishing a consensus. Changing it to a blind vote removes the discussion, the Crat, the community really. We have to for Arb, for various reasons, but they are the final say. Admin are mop holders. There simply isn't a need for a super sekret vote. Dennis Brown - 2¢ 00:16, 2 November 2021 (UTC)
16. The stewards are willing to review our elections once a year. I don't see them or the CUs doing it once every 3 months --Guerillero ^{Parlez Moi} 10:37, 2 November 2021 (UTC)
17. I don't think secret voting would be an improvement to the RfA process. LEPRICAVARK (talk) 06:42, 3 November 2021 (UTC)
18. I am reticent about secret votes in general, and I also dislike the issues that may arise from late-detected issues, amongst others. Risker's well-phrased concerns with Securepoll (and my recent up-close experience with the MCDC process has internalised just HOW bad it is) take it from a likely oppose to a strong one. Nosebagbear (talk) 18:43, 4 November 2021 (UTC)
19. A supporter I was of the concept of elections during the brainstorming phase; but I now oppose per HBC and Risker. JavaHurricane 03:39, 5 November 2021 (UTC)
20. I strongly oppose this, mainly because it is at serious risk of abuse by a sockmaster. YttriumShrew (talk) 07:55, 6 November 2021 (UTC)
21. It's a lot easier to oppose someone with a secret ballot, as it takes away accountability for your vote. It's not just the candidates that are scrutinized in RfAs, the voters are open to scrutiny too. wbm1058 (talk) 01:08, 7 November 2021 (UTC)

    When an opposing voter is forced to defend their opposition, they will a) always find something negative enough to allow opposition and b) describe the candidate as negatively as possible to maximize the strength of their argument. That's a rather ugly form of "accountability". ~ ToBeFree (talk) 01:42, 7 November 2021 (UTC)

Discussion 8B Admin elections

• This is an interesting idea, but I'm not sold on the 6 month interval. I'd prefer every other month, or even once a month, though I could also get behind once per quarter. Trainsandotherthings (talk) 16:48, 31 October 2021 (UTC)

  I am neutral on the overall concept but getting access to SecurePoll, at least based on how it is setup now, is resource intensive and requires active WMF support. Twice yearly is probably a reasonable limit to how often we could expect that. Best, Barkeep49 (talk) 16:51, 31 October 2021 (UTC)

  I'm not sure if we'd have enough candidates for this approach. ~ ToBeFree (talk) 16:52, 31 October 2021 (UTC)

  Perhaps instead have it be every 6 months, or as needed? For example, if there are ten candidates after 3 months, it would make sense to schedule an election then rather than waiting another 3 months. It's unlikely that would happen, but we should be prepared for the possibility. Trainsandotherthings (talk) 17:16, 31 October 2021 (UTC)

  Having a well-known, regular time of adminship voting may increase the amount of voters and candidates. I think we shouldn't give up this positive aspect of the proposal. Also, another logistical concern: How would you know that there are already 10 candidates if nominations are twice per year? ~ ToBeFree (talk) 17:26, 31 October 2021 (UTC)

  I concur about having a well-known, regular time of adminship. My concern is that if it is too infrequent, it may instead reduce the number of applicants. What if outside circumstances at the time of an election dissuade candidates from running at that time (for an extreme example, the fallout from our most recent RfA). Trainsandotherthings (talk) 17:35, 31 October 2021 (UTC)

  If it works, we can certainly decrease the interval between runs - but I think there is a lot of technical challenges that would need to be overcome first. Worm^TT(talk) 08:07, 1 November 2021 (UTC)

  That's good enough to move me into the support column. Trainsandotherthings (talk) 14:46, 1 November 2021 (UTC)

• To be clear, my reading of this is that it will be a new, additional, process to adminship - and that the current RfA process will continue for anyone that wants to go that route. — xaosflux ^Talk 17:31, 31 October 2021 (UTC)

  I could support this if it is in addition to the normal RfA process, not a replacement of it. Trainsandotherthings (talk) 17:36, 31 October 2021 (UTC)

  Per Wikipedia:Requests for adminship/2021 review/Proposals/Admin elections, it is indeed "an alternative route to adminship". However, I hope (and guess) most candidates will try it. ~ ToBeFree (talk) 17:36, 31 October 2021 (UTC)

  I have now clarified this in the proposal text. It seems relatively clear that Worm That Turned meant this ([5]). ~ ToBeFree (talk) 17:40, 31 October 2021 (UTC)

  Thank you, just making sure nothing changed since the prior discussion. I'm not sure if "most" will try it, as you have to wait for the event - but that's not a "problem" for me. — xaosflux ^Talk 17:42, 31 October 2021 (UTC)

• I think the idea has merit but that we run the risk of either making this too bureaucratic and too much of a hassle for voters. I would support something along the lines of quarterly elections (although we really would need a better word), similar to the Steward elections on Meta. Maybe something like a 5-day question & discussion period, and then a 5 day voting period. Using SecurePoll quarterly (or even bianually) could be difficult, so possibly a simple onwiki support/oppose/neutral, with a prohibition on discussion during voting would work. Giraffer ^{(talk·contribs)} 18:22, 31 October 2021 (UTC)

  The anonymity of SecurePoll does seem to be an advantage that can't be replicated this way. Advantage for the voters: Free voting without risk of offending anyone. Advantage for the candidate: A simple number as a result, not a list of specific people that seem to dislike them. ~ ToBeFree (talk) 18:48, 31 October 2021 (UTC)

• As a lot of the votes are explicitly "support as a trial", can we agree on language to add to the proposal on how many of these elections to hold before a mandatory follow-up RFC? Presumably it would be 1-3 elections before the next RFC. User:力 (power~enwiki, π, ν) 18:35, 31 October 2021 (UTC)

  Three sounds sensible, as this would cover a 1 year period and should give good data. Though, I think it quite plausible that the community would reject this after one major failure. Worm^TT(talk) 08:10, 1 November 2021 (UTC)

  What's not really clear is what happens to those who were elected should the trial be deemed a failure. Are they always going to have a cloud over them as we often give those who were elected in <2007 RFA? (Or even worse, by mailing list)? --Rschen7754 00:06, 2 November 2021 (UTC)

• I think this has merit, but I'm concerned about thresholds. Observationally, anonymous polling seems to draw far less support than open. The 70% threshold we apply to RfA is unlikely to be applicable to a hidden-ballot admin election, considering how even the most popular candidates in hidden-ballot ArbCom elections draw far more opposition than we see in equivalent RfAs. Vaticidalprophet 21:54, 31 October 2021 (UTC)
  • @Vaticidalprophet: I would urge you to support. No-one will be made to go through this process, and those who do in the first instances will surely understand that it is an experimental process and that a failure to be elected could simply be a failure in the process. A threshold can never be successfully worked out a priori: we didn't arrive at 65–75% at RfA that way, nor was that percentage appropriate for RfA when it began. To work out the threshold, we need this proposal to pass, and to see what happens in practice. — Bilorv (talk) 23:45, 31 October 2021 (UTC)
• With the minimum participation standard shifted to an anonymous vote, there's a high chance of most voters ignoring most or all of the discussion. There are pros and cons to this, of course. We should however not harbour any illusions about the significant consequences of changing to a voting system. isaacl (talk) 22:07, 31 October 2021 (UTC)

• We cannot user arbcom suffrage standards as they involve a multiple week process of checkusering every participant. Doing this for each RfA would a) be a huge workload for our CUs, and b) probably go against the foundation's CU policy. Without this step the process is very much open to gaming as it would be trivial to make sleeper accounts that meet the remaining suffrage requirements. I don't believe this has been considered with the current proposal.
  Did anyone ask the checkusers if they are willing and able to do this?HighInBC ^{Need help? Just ask.} 00:01, 1 November 2021 (UTC)

  The list of voters will be public, with timestamps of every vote, just like it is today. Only their votes become secret. You can already "make sleeper accounts" and use them for RfA voting. For some reason, we're currently not concerned enough to change this, for example by introducing RfA voting requirements or checkusering every RfA voter. ~ ToBeFree (talk) 00:32, 1 November 2021 (UTC)

  The proposal as written says to use arbcom suffrage standards, as written the proposal has this problem to address. If there was a different proposal then I would assess it based on its own merits. HighInBC ^{Need help? Just ask.} 00:35, 1 November 2021 (UTC)

  HighInBC, are you saying that because the proposed requirements are higher than today, the proposal will be more open to sockpuppetry issues? ~ ToBeFree (talk) 00:38, 1 November 2021 (UTC)

  No I would have used those words if I meant that, I am saying that the proposal as written has problems because it saying it would use standards that require a few weeks of work for each RfA and a radical change to our checkuser policy. HighInBC ^{Need help? Just ask.} 03:16, 1 November 2021 (UTC)

  Is this a dictionary/word issue? To me, "Voter suffrage would initially match Arbcom elections" means that voters have to be "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", which is the wording used at the details page of the proposal. None of this requires a change to our checkuser policy. Regarding SecurePoll voting, the additional work is purely technical (setting up SecurePoll), not scrutiny-related. As the current voter criterion at RfA is "registered over 1 second, 0 edits by election" and the voter list is public (with timestamps) during SecurePoll elections, the concern seems to be illogical. ~ ToBeFree (talk) 03:48, 1 November 2021 (UTC)

  HighInBC, we are limited to 75 words on the proposals, so I used the word "suffrage" to refer to the requirements to vote, and matched to Arbcom elections because they are already something that the community accepts. However, I do fully expect that a full Rfc on the election would take place before the first election so everything could be clarified. Worm^TT(talk) 08:17, 1 November 2021 (UTC)

• One thing to consider with elections on a set calendar date is you may be disenfranchising a group of people for whom that time of year is always inconvenient. It might be a major religious holiday, or exams week at universities, or peak tropical storm season, or whatever. Letting people run at a time of their own choosing avoids that problem. -- RoySmith (talk) 00:28, 1 November 2021 (UTC)

  The date doesn't need to be the same from year to year. We can deliberately choose to move the scheduled period around to mitigate calendar issues. (I am conveniently ignoring technical issues; as described in Risker's comment, there are challenges in implementation.) isaacl (talk) 05:48, 1 November 2021 (UTC)

  The intention of multiple dates was to allay that problem, though we could absolutely move the dates each year as isaacl suggest. Alternatively, the standard RfA process would be available. Worm^TT(talk) 08:20, 1 November 2021 (UTC)

• I think the references to Wikipedia:Requests for adminship/Eostrix are a red herring. Even if Eostrix had passed his RfA because Arbcom took another four days to make a solid and firm decision, he would have been desysopped anyway. Ritchie333 ^{(talk) (cont)} 14:43, 1 November 2021 (UTC)

Yep. There was a very real possibility that is exactly what would've happened, in which case the committee would have done a desysop per procedure. Beeblebrox (talk) 20:24, 1 November 2021 (UTC)

• @Chicdat: "I just hate secret ballots." Any particular reason why? I assume it's not because you think voter intimidation is a good thing (and I can well believe Trump pulling that stunt out of the bag). Ritchie333 ^{(talk) (cont)} 14:44, 1 November 2021 (UTC)
  • @Ritchie333: I see that I didn't make myself clear; I hate secret ballots on Wikipedia. I'm perfectly fine with them elsewhere. Now, why? I believe I already explained that in my !vote. During the 7 days of voting, if new information is brought to light, since the election is closed, no one can see the new information. And besides, I don't support Trump, quite the contrary... 🐔 Chicdat  ^{Bawk to me!} 10:18, 2 November 2021 (UTC)
• @Risker: regarding the SecurePoll limitations - any reason we can't run this locally instead of over on votewiki? Especially if our polls don't require data at rest encryption - and possible if we don't even use it to collect the private data (we can always locally checkuser accounts that seem suspicious in and of themselves). — xaosflux ^Talk 23:20, 1 November 2021 (UTC)

  @Worm That Turned: please provide any other dev feedback you got on this. — xaosflux ^Talk 23:21, 1 November 2021 (UTC)

  I haven't got any dev contacts :) I was planning to have a chat with T&S tomorrow, as I'm in a meeting with them, and go from there! Worm^TT(talk) 09:42, 2 November 2021 (UTC)

  As far as the SP is a nightmare to manage - for plain Jane polls w/o encryption I never had a problem when we could do these on testwiki. — xaosflux ^Talk 23:22, 1 November 2021 (UTC)

I think what you're saying here is that you want to have non-public voting, and that the software and the security of such software isn't important. In that case, we could just use google polling and save everyone a lot of time and energy. Risker (talk) 23:49, 1 November 2021 (UTC)

Oh, certainly, except there are a lot of Wikipedians who wouldn't touch Google with a barge pole. Worm^TT(talk) 09:47, 2 November 2021 (UTC)

• I'm not gonna further discuss the technical issues with SecurePoll. I will, however, point out that when we switched from onwiki voting to SecurePoll for Arbcom elections, we saw a very, very significant drop in the amount of support for all candidates, and wound up lowering the accepted level of support for successful candidates by a large margin. This is not a positive result. More importantly, the one time we used SecurePoll to run CU/OS elections, it was an almost complete failure; we desperately needed more people in both roles, and only one OS candidate met the mandated support level. SecurePoll was dropped after that one attempt, because we can't allow the effective management of the project to be dictated by some abstract philosophical points that have nothing to do with anything. I foresee the same problem here; that because there's no need to substantiate opposes, good candidates who'd pass onwiki RFAs will fail. I think it's a feature, not a bug, that one has to be willing to provide serious reasons for opposing admin candidates. With SecurePoll, we remove that feature. Risker (talk) 23:47, 1 November 2021 (UTC)
• I don’t like the idea of elections for adminship, but I am not exactly opposed to it. But if we want, we can have elections whose results will be non-binding, the standard RfA process will be followed, and the results of said election may or may not be private. If we want to determine the “popularity” of the admin-prospect. Also, I feel elections might turn this into a contest, and not an examination, with the comments being public, as they are now. Not opposed to having elections as a supplementary measure, or something as a new variable to use in various situations. MxWondrous (talk) 09:14, 2 November 2021 (UTC)
• Just to be clear: I agree that SecurePoll is a technical nightmare to the degree that that by itself is a reasonable reason to oppose this proposal. I will defer to those voters to explain why. User:力 (power~enwiki, π, ν) 22:36, 1 November 2021 (UTC)

8B.alt Trial Admin election

Per 8B Admin elections, but a limited trial of 1 election, to be made at a time that SecurePoll is available and with volunteer English Wikipedia CUs acting as scrutineers. Following this single attempt, an RfC will be set up to look at what needs to change going forward if the process is to be successful.

Support (8B.alt Trial Admin election)

1. As proposer. Many of the supporters above are suggesting a trial, and much of the opposition is reasonable regarding how well such a system will work and the unknowns that will be encountered. As such, recommend a single election based on layout in 8B, and then going forward we can have an RfC to answer questions raised as part of the trial. Worm^TT(talk) 16:19, 2 November 2021 (UTC)
2. Per my !vote above. Extraordinary Writ (talk) 16:48, 2 November 2021 (UTC)
3. No harm done. People are arguing that this might cause technical issues. Well, the simple solution is to make a trial, to have at least some data to be able to appreciate any problems (or the lack thereof) which might arise. I don't see what is "not clear what happens to successful and to unsuccessful candidates after the trial": as I understand it, the trial is for the election method / technical implementation, not for the admin candidates (a successful would be an admin, unsuccessful ones wouldn't be). RandomCanadian (talk / contribs) 18:31, 2 November 2021 (UTC)

Oppose (8B.alt Trial Admin election)

1. I oppose 8B for reasons unrelated to technical concerns and will thus oppose here, but if it must be a done a trial seems okay. – John M Wolfson (talk • contribs) 16:28, 2 November 2021 (UTC)
2. Per above. Also not clear what happens to successful and to unsuccessful candidates after the trial. --Rschen7754 18:03, 2 November 2021 (UTC)

   @Rschen7754 per 8B, successful candidates would become admins, unsuccessful would not. Worm^TT(talk) 18:47, 2 November 2021 (UTC)

   I don't think it's that simple. As I asked above, will such elected admins always have a "cloud" over their election, much like admins do who were elected <2007 (or even worse, by mailing list?) --Rschen7754 00:04, 3 November 2021 (UTC)

3. This just makes no sense. We can't use it all the time no matter what, so a trial serves no purpose. What problem are we solving by making the RFA a secret vote instead of an open discussion? More importantly, what problems are we creating by doing so? Dennis Brown - 2¢ 19:00, 2 November 2021 (UTC)
4. As premature, and per my reasoning above. We can discuss this in a followup RfC if 8B gains consensus. -FASTILY 21:17, 2 November 2021 (UTC)

   Well it would all depend on the wording close but an important piece of the structure of this discussion is that no subsequent RfC should be necessary to implement any proposal. If 8B passes some discussion might be necessary about the first date but this is already a huge multi-month process and not having it become even larger is quite important so an expectation that there would be some sort of follow-up RfC is not what people should expect (support or oppose). Best, Barkeep49 (talk) 22:45, 2 November 2021 (UTC)

   I disagree. Monumental changes to an almost two decade old process are being proposed, and I think all aspects need to be carefully considered and thoroughly discussed. I see you've been involved with the 2021 review since the beginning, and while I sympathize with what must be discussion fatigue, I think we would be doing a massive disservice to the project by rushing to/through the implementation steps. -FASTILY 23:35, 2 November 2021 (UTC)

5. RfA is a discussion, not a vote. SecurePoll is not for adminship. 🐔 Chicdat  ^{Bawk to me!} 10:53, 3 November 2021 (UTC)
6. RfA needs more discussion not less. HighInBC ^{Need help? Just ask.} 23:31, 4 November 2021 (UTC)

Discussion (8B.alt Trial Admin election)

• 8B is fine enough despite all concerns. If SecurePoll is broken, it needs to be fixed. It will surely be fixed if there is a clear need to do so, so we clearly demonstrate a need. Problem solved. ~ ToBeFree (talk) 21:18, 2 November 2021 (UTC)
  • This. I don't see the core of 8B being about the specific polling software or version of the polling software - it could be approved even if implementation is delayed pending software to catch up. — xaosflux ^Talk 10:42, 4 November 2021 (UTC)
• I recommend that this be moved to the talk page. 8B can already establish a mandate for a one-off trial if that is the consensus view. This proposal serves no additional purpose, but confuses the process quite a bit. — Bilorv (talk) 20:19, 5 November 2021 (UTC)

General discussion

Related discussion, discussion about the process, or general discussion about RfA should happen on the talk page.