Please consider joining the feedback request service. An editor has requested comments from other editors for this discussion. This page has been added to the following lists: Wikipedia policies and guidelines WikiProjects and collaborations Wikipedia proposals When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.

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

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:

==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.

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:

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.

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

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)[reply]
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)[reply]
3. Per all. Unnecessary and won't necessarily help.  – John M Wolfson (talk • contribs) 18:35, 31 October 2021 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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

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

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

• @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)[reply]
  • 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)[reply]
    • 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)[reply]
• 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)[reply]
• 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)[reply]
  • Agreed, on all points. —Cryptic 03:34, 1 November 2021 (UTC)[reply]

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

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

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

• 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)[reply]
• I think this (redacted, admins only) is a good example of the problem. Ritchie333 ^{(talk) (cont)} 14:53, 1 November 2021 (UTC)[reply]

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.

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)[reply]
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)[reply]
3. Seems positive without negative Nosebagbear (talk) 16:20, 31 October 2021 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
9. Support, but why wait 24H? Anyway, support +1Paradise Chronicle (talk) 04:52, 1 November 2021 (UTC)[reply]
10. Support Lomrjyo (publican) ^(taxes) 15:26, 1 November 2021 (UTC)[reply]

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)[reply]
2. Candidates can already make any statement they want at any time. Hut 8.5 17:50, 31 October 2021 (UTC)[reply]
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)[reply]
4. Unnecessary. Would not add anything of a net benefit to process. Kudpung กุดผึ้ง (talk) 19:16, 31 October 2021 (UTC)[reply]
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)[reply]
6. Per Hut 8.5. Unnecessary process creep with no obvious benefits -FASTILY 04:22, 1 November 2021 (UTC)[reply]
7. No demonstrable need. Anarchyte (talk) 06:14, 1 November 2021 (UTC)[reply]
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)[reply]
9. Too WP:CREEPy. Also a WP:SLOP. 🐔 Chicdat  ^{Bawk to me!} 10:59, 1 November 2021 (UTC)[reply]
10. WP:CREEP without tangible benefits. Dennis Brown - 2¢ 11:33, 1 November 2021 (UTC)[reply]
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)[reply]
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)[reply]

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

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

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

Withdrawn and moved to talk

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

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

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

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

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

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.

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

Support (3A Add clear criteria for users to pass 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)[reply]

Oppose (3A Add clear criteria for users to pass 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)[reply]

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

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

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

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

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)[reply]
2. If this became policy, Wikipedia:Requests for adminship/Cyberpower678 2 would have failed. Ritchie333 ^{(talk) (cont)} 14:13, 1 November 2021 (UTC)[reply]

Discussion (3A Add clear criteria for users to pass 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)[reply]
  • 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)[reply]
    • 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)[reply]
• 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)[reply]
  • 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)[reply]

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.

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.

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

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

4. Worth trying. —valereee (talk) 17:20, 31 October 2021 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)[reply]
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)[reply]
3. I agree that this is a better question. Dreamy Jazz ^{talk to me | my contributions} 16:21, 31 October 2021 (UTC)[reply]
4. Seems like an improvement over the current wording. Isabelle ^🔔 17:16, 31 October 2021 (UTC)[reply]
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)[reply]

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

6. I'd remove Q1 altogether, but I'm fine with revising it to this. —valereee (talk) 17:29, 31 October 2021 (UTC)[reply]
7. Yes, that would work. – filelakeshoe (t / c) 🐱 17:33, 31 October 2021 (UTC)[reply]
8. Good idea. – Joe (talk) 17:52, 31 October 2021 (UTC)[reply]
9. Sensible. MER-C 18:16, 31 October 2021 (UTC)[reply]
10. I support this non-controversial minor change. User:力 (power~enwiki, π, ν) 18:32, 31 October 2021 (UTC)[reply]
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)[reply]

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

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)[reply]
13. Good idea. Certainly beats insisting on, or even inviting an additional self-nomination statement. Kudpung กุดผึ้ง (talk) 19:34, 31 October 2021 (UTC)[reply]
14. CaptainEek ^{Edits Ho Cap'n!}⚓ 20:10, 31 October 2021 (UTC)[reply]
15. — Wug·a·po·des​ 20:28, 31 October 2021 (UTC)[reply]
16. Makes sense. DanCherek (talk) 20:59, 31 October 2021 (UTC)[reply]
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)[reply]
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)[reply]
19. Levivich 00:42, 1 November 2021 (UTC)[reply]
20. Certainly an improvement in the current wording. Seraphimblade ^{Talk to me} 01:45, 1 November 2021 (UTC)[reply]
21. Okay. --Rschen7754 03:51, 1 November 2021 (UTC)[reply]
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)[reply]
23. Anarchyte (talk) 06:17, 1 November 2021 (UTC)[reply]
24.  ― Qwerfjkltalk 07:12, 1 November 2021 (UTC)[reply]
25. Support. MichaelMaggs (talk) 07:46, 1 November 2021 (UTC)[reply]
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)[reply]
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)[reply]
28. Sounds good to me — Preceding unsigned comment added by Ritchie333 (talk • contribs) 14:16, November 1, 2021 (UTC) (diff). BusterD (talk) 16:52, 1 November 2021 (UTC)[reply]

Oppose 5A Revise standard Question 1

Discussion 5A Revise standard Question 1

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.

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".

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

Oppose 6A Binding recall criteria

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

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

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

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

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

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

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

5. This could result in de facto bullying: "Oppose unless you agree to XYZ". --Rschen7754 02:41, 1 November 2021 (UTC)[reply]
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)[reply]
7. We need more admins, not fewer! 🐔 Chicdat  ^{Bawk to me!} 10:50, 1 November 2021 (UTC)[reply]
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)[reply]

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

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)[reply]
  • @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)[reply]
• 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)[reply]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)[reply]
2. I'd support this, given details can be worked out. —valereee (talk) 17:35, 31 October 2021 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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

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

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

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

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

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

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)[reply]
  • Voted oppose for now. Dreamy Jazz ^{talk to me | my contributions} 18:44, 31 October 2021 (UTC)[reply]
• 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)[reply]
• @Valereee and Nosebagbear: which details are absent from the proposal? — Bilorv (talk) 18:30, 31 October 2021 (UTC)[reply]

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

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

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

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

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

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

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

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

  @力: 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)[reply]

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

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

Create a new process, Wikipedia:Permissions review (PRV) Wikipedia:Administrative action review (XRV),^[1] 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.

Support 6C Permissions 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)[reply]
2. Sounds good to me.  – John M Wolfson (talk • contribs) 16:14, 31 October 2021 (UTC)[reply]
3. I am open to something like this. —valereee (talk) 17:39, 31 October 2021 (UTC)[reply]
4. I'm open to trying this. Dreamy Jazz ^{talk to me | my contributions} 18:43, 31 October 2021 (UTC)[reply]
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)[reply]
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)[reply]
7. Yup.—S Marshall T/C 22:41, 31 October 2021 (UTC)[reply]
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)[reply]
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)[reply]
10. It's worth a try, we don't lose a lot if it doesn't work. --Rschen7754 04:21, 1 November 2021 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

Oppose 6C Permissions 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)[reply]

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

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

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

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

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

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

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

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

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

Discussion 6C Permissions 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)[reply]
• 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)[reply]

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

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

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

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

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

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

• 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)[reply]
  • @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)[reply]
• 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)[reply]
  • 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)[reply]

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.

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.

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
9. Other wikis do this without issue. --Rschen7754 02:43, 1 November 2021 (UTC)[reply]
10.  ― Qwerfjkltalk 07:21, 1 November 2021 (UTC)[reply]
11. Per Wugapodes. ProcrastinatingReader (talk) 09:32, 1 November 2021 (UTC)[reply]

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)[reply]
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)[reply]
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)[reply]
4. Oppose. Per Femke, Trainsandotherthings, and Sdkb. Kudpung กุดผึ้ง (talk) 20:07, 31 October 2021 (UTC)[reply]
5. Oppose more or less per Femke. Unbundling is seductive, but counterproductive. Vaticidalprophet 21:51, 31 October 2021 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
   • 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)[reply]
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)[reply]
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)[reply]
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)[reply]

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

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

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

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

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

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

• @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)[reply]
  • @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)[reply]

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.

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)[reply]
2. Support, as proposer.—S Marshall T/C 17:18, 31 October 2021 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]
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)[reply]
3. Strong oppose. It invites too many opportunities to be used for personal agenda. Kudpung กุดผึ้ง (talk) 20:10, 31 October 2021 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]
  • 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)[reply]
• Need to have a further think about this. Dreamy Jazz ^{talk to me | my contributions} 16:41, 31 October 2021 (UTC)[reply]
  • Now voted support. Dreamy Jazz ^{talk to me | my contributions} 18:40, 31 October 2021 (UTC)[reply]
• 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)[reply]
  • 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)[reply]
• 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)[reply]

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

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

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

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

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

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

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

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

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

4. I oppose any more unbundling, almost on principle.  – John M Wolfson (talk • contribs) 17:27, 31 October 2021 (UTC)[reply]
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)[reply]
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)[reply]
7. In it's current form, I don't support this. Dreamy Jazz ^{talk to me | my contributions} 18:24, 31 October 2021 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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

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

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

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

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

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

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

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

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

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
8. Per above. -FASTILY 04:55, 1 November 2021 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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

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

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

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

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

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

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

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

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)[reply]
  • 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)[reply]
    • 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)[reply]
      • 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)[reply]
• 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)[reply]
  • On the latter: yes, all admins who don't qualify by the normal WP:PERM requirements. — Bilorv (talk) 20:54, 31 October 2021 (UTC)[reply]
  • @力: Your small-question reminds me of Wikipedia:Arbitration/Requests/Case/Carlossuarez46. – Joe (talk) 08:57, 1 November 2021 (UTC)[reply]
• 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)[reply]
• 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)[reply]

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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)[reply]
6. Worth a try, but would also like a trial period. Femke (talk) 17:25, 31 October 2021 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
10. Worth trying as an additional route (rather than replacement of current RfA). —valereee (talk) 18:49, 31 October 2021 (UTC)[reply]
11. Support trial per xaosflux — Wug·a·po·des​ 21:00, 31 October 2021 (UTC)[reply]
12. 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)[reply]
13. 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)[reply]
14. 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)[reply]
15. 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)[reply]
16. 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)[reply]
17. 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)[reply]
18. 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)[reply]
19. 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)[reply]
20. With significant caveats about thresholds. Vaticidalprophet 12:59, 1 November 2021 (UTC)[reply]
21. Nice idea. Hopefully substantially less animus. ProcrastinatingReader (talk) 14:34, 1 November 2021 (UTC)[reply]
22. Yes, let's give it a go Ritchie333 ^{(talk) (cont)} 14:38, 1 November 2021 (UTC)[reply]
23. 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)[reply]
24. 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)[reply]

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

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

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

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

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

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

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

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

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

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

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

10. Too many unknown unknowns, in addition to the known knowns already identified. Leaky caldron (talk) 08:09, 1 November 2021 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 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)[reply]
  • @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)[reply]
• 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)[reply]

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

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

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

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

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

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

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

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

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

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

• 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)[reply]
• @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)[reply]

General discussion

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