Revision as of 11:01, 8 November 2021

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: Misplaced Pages policies and guidelines WikiProjects and collaborations Misplaced Pages 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.

• WP:RFA2021/P

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

Introduction and format

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

A 30-day discussion identified 8 issues which have community consensus. In a second phase, we will now be considering solutions that address these identified issues.

To attempt to ensure the most editors possible could supply feedback for ideas, for 7 days prior to Phase 2, and during the first 7 days of phase 2's 30-day discussion period, editors could propose changes, without voting. As these periods have ended, no new proposals will be accepted for voting in phase 2. To help editors navigate proposals, proposed changes are 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 November 7th 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 closers

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

Issues identified

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

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

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

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

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

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

Issue 1: Corrosive RfA atmosphere

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

1A Formal moderation of RfA

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

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

1B Zero tolerance for incivility or personal attacks

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

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.

1C Semiprotect all RFAs/voter requirements

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

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.

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 their edit history with the chance that some event, possibly a relatively trivial event, becomes the focus of editor discussion for up to a week.

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

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

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

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

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

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

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

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

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

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

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

• Not a fan but I don't see any harm so I won't explicitly oppose. That said, I don't see how this is any better than just letting the candidate respond inline or just reminding them that they can ask themselves questions. — Wug·a·po·des​ 20:22, 31 October 2021 (UTC)
  • Letting candidates directly respond to opposes breaks purdah and invites badgering. Also, a candidate asking themselves a question seems rather odd in my view, although this is just a formalized version of it. – John M Wolfson (talk • contribs) 20:26, 31 October 2021 (UTC)
    • But candidates do respond to opposes, and if the concern is that they are looked down for it (something I haven't really seen in recent years) why not just change our guidance to reflect that community expectation? Why formalize a new process that duplicates something candidates can already do? If candidates asking themselves questions is odd, asking them to ask themselves a question is just as odd. — Wug·a·po·des​ 22:12, 31 October 2021 (UTC)
• I'm also neutral. Not sure this is better than "candidates or their nominators can also ask questions", which is apparently already allowed by policy and thus wouldn't even need an RFC. User:力 (power~enwiki, π, ν) 23:20, 31 October 2021 (UTC)
• Neither pro nor con on this one; I don't know that it will make a difference in attracting either candidates or voters, but I also don't see any harm to this. In fact, it could be phased in informally simply by someone/a few people making it a practice to ask this question routinely. Risker (talk) 23:27, 7 November 2021 (UTC)
• Some rationale for the proposal would be nice. --SmokeyJoe (talk) 06:56, 8 November 2021 (UTC)

2C Cohorts of candidates

Withdrawn and moved to talk

2D Quarterly elections

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

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

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

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

Status quo:

• Misplaced Pages:Requests for adminship/Example
• Misplaced Pages:Requests for adminship/Example 2
• Misplaced Pages:Requests for adminship/Example 3
• Misplaced Pages:Requests for adminship/Example 4

Proposal:

• Misplaced Pages:Requests for adminship/Example 2009
• Misplaced Pages:Requests for adminship/Example 2014
• Misplaced Pages:Requests for adminship/Example 2014 2
• Misplaced Pages:Requests for adminship/Example 2021

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

1. As proposer. This was one of my concerns before starting my first RfA, so perhaps I've found a convenient, simple improvement in the spirit of 5A's simplicity. It's not a huge change, but it may make a tiny positive difference.
   Edit: Sorry for the ambiguity. I had "every future RfA" in mind. I'm fine with moving the old ones as well, leaving redirects behind, if there's an additional consensus for that among the supporters. ~ ToBeFree (talk) 20:05, 6 November 2021 (UTC)
2. These seems a simple, stigma reducing, solution. —¿philoserf? (talk) 20:29, 6 November 2021 (UTC)
3. This is an interesting idea; it might help to some extent. – John M Wolfson (talk • contribs) 20:37, 6 November 2021 (UTC)
4. I think the "2" is pretty much a mark of shame. The one issue with this is that it is valid to want to look at previous RfAs, but that can be done in the little right pop-out box. Also handles the issue of people renaming and doing multiple RfAs. Also, would existing RfA be moved or no? Naleksuh (talk) 22:37, 6 November 2021 (UTC)
5. Simple and worth trying; I would support moving previous RFAs for consistency reasons. — Wug·a·po·des​ 22:38, 6 November 2021 (UTC)
6. At the very least, it would make page titles more informative. XOR'easter (talk) 22:40, 6 November 2021 (UTC)
7. I don't see any downsides to this, and it would indeed be more informative than the current system. Trainsandotherthings (talk) 22:41, 6 November 2021 (UTC)
8. Sure. My preference would be using parentheses similar to how we disambiguate for articles. --Rschen7754 23:04, 6 November 2021 (UTC)
9. Weakly. This could possibly have an incrementally positive effect, and it certainly wouldn't make things worse. It's clearly not a panacea, but that's not a reason to oppose. I do think that moving all of the old RfAs would likely be more trouble than it's worth. Extraordinary Writ (talk) 23:10, 6 November 2021 (UTC)
10. Definitely in the "tinkering around the edges" category, but that doesn't mean it's not a good idea. – Joe (talk) 10:46, 7 November 2021 (UTC)
    • #No major problems with this proposal. It also provides more information in the page title as it gives the year of a RfA. Dreamy Jazz 13:01, 7 November 2021 (UTC)
      • Reconsidering my vote here due to convincing oppose rationales. Dreamy Jazz 19:54, 7 November 2021 (UTC)
11. Weak support per above. I oppose changing past RfAs - this would be too much effort for a small benefit. ― Qwerfjkltalk 16:56, 7 November 2021 (UTC)
12. Support. Opposes along the lines of "there is no stigma and nobody cares about this" are extremely unconvincing as a response to a proposal by someone who recently ran for RfA and described a stigma that they felt. This rings true to me from comments I have read over the years with subtext indicating "I saw there was a '2' in the title of this RfA and came here with a bag of popcorn to read about the humiliating past failure of the candidate", though the level of sympathy/spite varies from comment to comment. I don't see the value of doing it retroactively, so I'd prefer this not be done. — Bilorv (talk) 17:20, 7 November 2021 (UTC)
13. This seems like a sensible proposal even though it is unlikely to have any significant effect on RfA. --JBL (talk) 17:44, 7 November 2021 (UTC)
14. Support on the condition that it's formatted with a month, too, to make sure people can run more than once in a year. theleekycauldron (talk • contribs) (they/them) 19:08, 7 November 2021 (UTC)
15. Per Joe. ProcrastinatingReader (talk) 22:24, 7 November 2021 (UTC)
16. Support with the condition of also adding a month, not only to address stigma, but also to tidy things up and further clarify the process. 🐶 EpicPupper 22:26, 7 November 2021 (UTC)
17. Weak support: Noting as little harm and possibly some good. Noting EpicPupper above using YYYY-MM-DD for all would stop the second RFA in a year standing out like a sore thumb, obviously don't need that level of granularity but we are probably more comfortable with yyyy-mm-dd than yyyy-mm. But thats a small point. Djm-leighpark (talk) 00:21, 8 November 2021 (UTC)
18. Support. I always prefer disambiguation by date over a counting number, the date means something. --SmokeyJoe (talk) 06:58, 8 November 2021 (UTC)

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

1. Stigma against failing an RFA doesn't come from a scarlet number in the page URL, it comes from the community. And the current proposal doesn't solve enough of the edge cases to overcome the inertia against change. User:力 (powera, π, ν) 23:59, 6 November 2021 (UTC)
2. Moving previous RFAs for consistency reasons is a good reason to oppose. Sounds like a lot of work, for dubious benefit, distracting whoever does this from working on something more useful. Is the point to try to hide the fact that a second-attempt is a second attempt, and hope the community forgets the first try? You could rename the first attempt to "2", then "3" on the third try, numbering down from oldest to newest, so that the current attempt never has a number. wbm1058 (talk) 00:32, 7 November 2021 (UTC)

   Is the point to try to hide the fact that a second-attempt is a second attempt ... yes, to omit that fact from the title. and hope the community forgets the first try? ... no, obviously nobody would expect the first run to go unmentioned. Your suggestion would fix the raised issue, but be (IMO) more confusing when reading archives, as you need to know when the naming system was changed and when the RfAs happened to know whether 2 (of 2) came first or second. (Unless the renaming happens retroactively.) — Bilorv (talk) 17:20, 7 November 2021 (UTC)

3. Nugatory value. If you're on a +1 RfA the earlier RfAs are disclosed in plain sight. If you're contemplating a 1st RfA but are concerned that a failure will result in any subsequent attempt being numbered... well, seriously!? In reality, to be blunt, this is a pretty poor attempt to disguise that a candidate has previously attempted an RfA and failed. There's not much stigma in that - many Admins have come through that root. Leaky caldron (talk) 08:29, 7 November 2021 (UTC)
4. This is the most WP:SLOPpy proposal I have ever seen. I am astonished that anyone could ever support it. 🐔 Chicdat   11:28, 7 November 2021 (UTC)
5. Weak oppose - Don't think this is going to fix anything, especially since a list of all of your prior RfA's is in a big box right at the top of subsequent RfA's (and in Special:PrefixIndex/Wikipedia:Requests for adminship/Example). That being said, so long as all the prior discussions are still prominent I don't really care what they are called - not sure if it will break some reports but we don't need to build around report writers. — xaosflux 13:22, 7 November 2021 (UTC)
6. Even if the number in the title is removed, the RFA will and should still mention the previous attempt(s) prominently, so it won't fix any of the "stigma" problems mentioned. Plus, if someone attempted RfA in January and December, they'd still get a "2" but now their second attempt will be more stigmatizing because the number of attempts with "2" (or another number) in the title will be less numerous. Add to this the confusion if someone has a number in their username, the amount of old requests that would have to be renamed and the potential to break a lot of stuff relying on the current scheme and you get a proposal that will not really solve anything but create a huge amount of work. Regards SoWhy 16:40, 7 November 2021 (UTC)
7. No point. Candidates can and should address the reasons for their previous fail in a new nomination. Trying to hide a previous nomination will be discovered and instantly sink the second nom as well. SpinningSpark 17:17, 7 November 2021 (UTC)
8. Do we have any evidence whatsoever that using the current system (a) scares candidates away or (b) impacts on the likelihood of a candidate succeeding? Has it occurred to people that candidates who have not been successful at their first RFA may have a fundamental issue that isn't going to be fixed by multiple RFA attempts? This looks like a make-work project, and immediately becomes problematic when a candidate runs at RFA more than one time in a calendar year. I don't see this solving any problems here. Risker (talk) 17:25, 7 November 2021 (UTC)
9. This effectively presumes !voters are stupid enough not to realize there is a second RfA if it isn't made obvious by the title. * Pppery * _{it has begun...} 18:29, 7 November 2021 (UTC)
10. I don't agree with the premise that there is a stigma with a repeated request for administrative privileges, below a certain threshold. However if there is a problem, then this ought to be addressed directly. Changing the name of the request page won't alter the level of scrutiny faced by the candidate, and thus this proposal does not address the scrutiny issue established in phase 1. isaacl (talk) 21:47, 7 November 2021 (UTC)
11. Oppose per everyone else here. This is a solution looking for a problem. Kudpung กุดผึ้ง (talk) 23:06, 7 November 2021 (UTC)

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

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

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

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

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

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

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

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

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

The first sentence is rather confusing given that this proposal is such an expression of concerns, by an admin directly affected by it. — Bilorv (talk) 17:20, 7 November 2021 (UTC)

My apologies for being imprecise. I should have said I was unaware (prior to this proposal) of anyone considering making a repeat request who was concerned about the naming convention. Note the proposer isn't directly affected yet, as there hasn't been an occasion to consider a second RfA. Nonetheless, I disagree that the level of scrutiny will be affected by the request page name. isaacl (talk) 21:43, 7 November 2021 (UTC)

Issue 3: Standards needed to pass keep rising

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

3A Add clear criteria for users to start an RfA

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

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

Issue 4: Too few candidates

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

4A Opt-out sortition to nominate candidates

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

Support 4A Opt-out sortition to nominate candidates

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

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

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

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

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

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

Oppose 4A Opt-out sortition to nominate candidates

1. I disagree with nominating candidates who have not indicating their willingness to serve prior to the nomination. I also feel the process is better served by having a dialogue with the candidate. I'd prefer a revived admin nominators wikiproject to use whatever criteria they want to find potential candidates, and then work with them on following the standard request process. isaacl (talk) 21:48, 31 October 2021 (UTC)
2. The Jargon file story about Sussman and Minsky comes to mind. Randomness may cultivate a mystique for the process, but I see no reason it will find more or better admins. The community has struggled for decades to find reasonable criteria to determine adminabiles; if these criteria manage to find wide acceptance why not just write a bot to suggest a nomination to anyone who reaches the threshold? User:力 (power~enwiki, π, ν) 22:39, 31 October 2021 (UTC)
3. The given criteria does not demonstrate suitability for being an admin. The most crucial criteria is that they want to be an admin. I don't believe the solution is closing our eyes and throwing darts at a list of names. As 力 suggests you could write a bot right now with no change in policy that suggests RfA to such people, go for it. HighInBC 22:46, 31 October 2021 (UTC)
4. Per 力 and HighInBC. I don't think it makes sense to nominate editors unless they have actually expressed an interest in being an admin. Having a bot inform editors that they might be good candidates seems like a better idea. Nosferattus (talk) 23:32, 31 October 2021 (UTC)
5. RfA should be opt-in, not opt-out. No one should come back from a vacation in Hawaii to find out that they were involuntarily nominated for adminship, let alone read an RfA that sank like a rock and laid out all the reasons they weren't suitable for it, if they never wanted to serve in that capacity anyway. Adminship is a volunteer position, and so an RfA should only be initiated once the candidate has actually volunteered. Seraphimblade 01:43, 1 November 2021 (UTC)
6. Per Seraphimblade. Doesn't actually solve an existing problem, and I can't imagine this would be a good experience for anybody who gets sent on a surprise trip to RfA. -FASTILY 04:25, 1 November 2021 (UTC)
7. Unimplementable as proposed. Not even one of the seven separate criteria can be automated, and each individually has far too many matches for the group as a whole to be done manually. —Cryptic 04:28, 1 November 2021 (UTC)

   @Cryptic: have you expanded on this somewhere? I don't follow. For instance, for (1), we've already got a similar list and the code could presumably be altered to add the namespace conditions. (4) is logged at Misplaced Pages:Editing restrictions. For (7), you just need to test if Misplaced Pages:Requests for adminship/Example exists (for User:Example). And so on. None strike me as beyond the feasibility of getting a list that works well enough (and someone could appeal if they're not in it, or wrongly in it). — Bilorv (talk) 17:29, 7 November 2021 (UTC)

   1. Sorting by total number of edits is possible because there's a column in the database specifically for total number of edits. There's no way to get a count of edits that aren't to the user namespace and aren't to Misplaced Pages:Sandbox except to query the billion-row revision table, like we had to before that column was added in 2007. If you go digging through the history of WP:MOSTEDITS, you'll find that updating it then was a major project that happened maybe two or three times a year; and it would be much worse, since there were barely a tenth as many total edits on the project then as there are now. —Cryptic 19:14, 7 November 2021 (UTC)
   2. "Active editing" isn't defined. First edit was more than 20 months ago? Then it should've been phrased like that, and everyone would be opposing because the criterion selects specifically for sleeper socks instead of against them. Some variant of the WMF's absurdly-low metric of 3 and a third edits per day? That's only efficiently measurable averaged over the whole of a given time period, and only if you use a similarly low cutoff; otherwise, it's nearly as expensive as counting edits above as in #1.
   3. Manually excluding accidental blocks only works if you have a (relatively short) list of otherwise qualified users.
   4. I'll admit I was wrong on this one, if you assume that WP:Editing restrictions is comprehensive. It's still of limited usefulness, since it only excludes roughly 300 accounts by itself.
   5. There's no way to programmatically find out who was responsible for promoting a good/featured article/list; and while you can - somewhat inefficiently - query for created pages, and whether they're currently categorized as stubs, you can't see whether they were at creation; or whether the same editor was the one to expand them. Criteria other than categorization (which I'll preemptively agree is terrible) to figure out whether a page is a stub fare worse - number of words or sentences or so on isn't queryable; and while page length is, there are freakin' redirects more than 100k chars long.
   6. What counts as participation? Having at least one edit to 35 different pages starting ] can be automated, but do you really intend to include people who only deletion sort with a script?
   7. Checking for ] only works if you don't care about accounts that have changed their username since their last RFA, since the way the rename log is set up makes it prohibitively expensive to walk backwards to a user's prior names. —Cryptic 19:14, 7 November 2021 (UTC)

8. This pressures people to run for RFA and puts them in uncomfortable positions they don't want to be in. --Rschen7754 07:20, 1 November 2021 (UTC)
9. Strongest possible oppose: RfA should be opt-in, not opt-out. Sure, find some automated way to get a list of all users that match these (or some other) criteria, but then talk to them to see if they would be interested in running for adminship. --rchard2scout (talk) 09:20, 1 November 2021 (UTC)
10. I strenuously oppose any route to adminship that explicitly allows a candidate to ignore any questions by the community. There is, rightly, an expectation that candidates are responsive to its concerns. If people want to maintain VOLUNTARY, they should mandate that a candidate accepts the nomination instead of this baffling process where you're given a week to object. Sdrqaz (talk) 10:49, 1 November 2021 (UTC)
11. Random? No, no, no. What if the user doesn't want to be an admin? 🐔 Chicdat   10:54, 1 November 2021 (UTC)
12. Wow, just no. Many people who would quality prefer to stay out of the spotlight, and this could end up running people off the site. No. Not everyone wants to be an admin, or even noticed. Dennis Brown - 2¢ 11:39, 1 November 2021 (UTC)
13. I think it would be a good idea to write a bot that would identify editors that meet your criteria and post a message on their talk page encouraging them to run. Or put them on a list or something. But nominate people without their explicit consent? Absolutely not. Can you imagine how you would feel if you took a break from Misplaced Pages for a few months, only to come back and find that in your absence, you'd been scrutinised by hundreds of fellow editors for a position you didn't even ask for? – Joe (talk) 14:46, 1 November 2021 (UTC)
14. Don't see a point in nominating people who have not expressed any interest in being an admin. Will add more in talk section. - wolf 17:15, 1 November 2021 (UTC)
15. As soon as a process is used to identify, select and contact editors minding their own business seeking to thrust them into the unexpected spotlight of RfA, that is applying pressure well in breach of WP:VOLUNTARY Leaky caldron (talk) 17:38, 1 November 2021 (UTC)
16. Basically drafting admins? No thanks. Beeblebrox (talk) 21:23, 1 November 2021 (UTC)
17. Users have the right not to be admins, as absurd as this comment would be in any other context. Trainsandotherthings (talk) 04:20, 2 November 2021 (UTC)
18. We're having this discussion because RfA has become sufficiently unpleasant that few people want to go through it. Putting people through it at random, without them even having volunteered, would be practically a hazing ritual. Hut 8.5 20:08, 2 November 2021 (UTC)
19. I can't imagine that very many people would be pleased by a surprise nomination. LEPRICAVARK (talk) 06:33, 3 November 2021 (UTC)
20. Opposing on the basis that it sets up a murky expectation that the candidates should ignore discussion or other interaction with the community - I'd expect opposition to rise along the "Won't answer my question that I'm concerned with", while leaving it vague to the closing 'crat if this is something that is expected to be discounted. — xaosflux 10:57, 3 November 2021 (UTC)
21. As per above, being willing to volunteer to do admin work is an essential characteristic of an admin, and this could discourage candidates from running without being randomly selected. — csc 21:54, 3 November 2021 (UTC)
22. Like others have said, I don't like the idea of forcibly nominating candidates. Yes, they can opt out, but it is putting undue pressure on them. A bit like giving young men and boys a white feather in the WWI. SpinningSpark 17:26, 7 November 2021 (UTC)
23. Among other concerns, this risks entrenching hard numeric criteria for adminship. * Pppery * _{it has begun...} 18:31, 7 November 2021 (UTC)
24. I think sortition is a fantastic process for populating legislatures or juries - i.e. a small representative body that votes on important decisions. But the role of an admin on Misplaced Pages is more like that of a judge. In most cases we rely on them to independently make wise decisions about the application of policy. The criteria here do not guarantee that selected editors can be trusted to be impartial, competent interpreters of policy.Also, as a side note, some of the criteria strike me as overly narrow. e.g. 10k edits is a lot, and will tend to select for editors who do lots of small, high-frequency edits (e.g. adding categories, adding Wikiproject templates, mass fixes to typos or dab wikilinks, etc.) rather than editors who focus on content creation, where a single edit might represent hours of work. If we were to use sortition for this process (though again, I don't think it's a good fit for the role), I would suggest much simpler criteria, such as: no blocks or active restrictions, and at least X distinct days in which they have made at least one edit. Colin M (talk) 18:34, 7 November 2021 (UTC)
25. The underlying cause of a lack of RfA candidates is that RfA is a scary, grueling process that isn't inviting to users. I don't think this process does anything to address that. Furthermore, the adminship is not for those who reluctantly answer a request to serve. To over-dramatically quote Toby Ziegler from the seventh season of The West Wing, pointing out that the Democratic presidential candidate had to be convinced and presented with the option to run for office:

    The man in that job shouldn't have to be presented with anything! It's for someone who grabs it and holds on to it, for someone who thinks the gods have conspired to bring him to this place, that destiny demands of him this service! If you don't have that kind of drive, that hubris, how in the hell are you going to make the kind of decisions that stump every other person in this country? How in the hell are you going to hold that kind of power in your hand?

    The quote's a bit much, to be sure, but the adminship is a trust. The balance of confidence and humility needed to make sane decisions is not one achieved by randomly nominating editors who look qualified. theleekycauldron (talk • contribs) (they/them) 18:39, 7 November 2021 (UTC)
26. No, just no. It would certainly not encourage more users to run the gauntlet for a week, and as such the idea does not belong in this suite of reform discussions. Kudpung กุดผึ้ง (talk) 23:17, 7 November 2021 (UTC)
27. Difficult to implement and could possibly lead to lots of bad RfAs, as mentioned above, but beyond that, it might erode trust in admins in the general editor population to think that no one wants to be an admin to the extent that sortition is necessary.--Ithinkiplaygames (talk) 06:02, 8 November 2021 (UTC)

Discussion 4A Opt-out sortition to nominate candidates

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The page already differentiates between active and inactive users, so you only need the first category really when trying to find potential candidates. The bot could probably be expanded to add more information about the editors listed (like edit count, article creations etc.) but the main problem is disuse, not lack of usefulness. I also don't think people not being aware that the userbox feeds into Category:Misplaced Pages administrator hopefuls is really a large problem. The list is just a converted version of that category with some info added for usefulness. Regards SoWhy 17:03, 7 November 2021 (UTC)

• I've opposed this as stated, but I would support some sort of sortition being used to make an approach to a potential candidate. The candidate should make the decision to put forward a nomination. If they do nothing, then the default is it doesn't happen, not that it does happen. SpinningSpark 17:30, 7 November 2021 (UTC)

  Sure, this can be done now without needing any community ratification. When Anna Frodesiak initiated the creation of the optional RfA candidate poll, she requested that anyone come up with lists of potential candidates using whatever criteria they thought reasonable, and she invited everyone on the lists to consider starting a poll. The same can be done by, for instance, a revived WikiProject Admin Nominators, where interested parties can engage with the potential candidates and figure out the best path forward for them. isaacl (talk) 00:57, 8 November 2021 (UTC)

• How would accidental blocks be manually excluded? 🐶 EpicPupper 22:30, 7 November 2021 (UTC)

4B Establish an optional admin school with approved curriculum

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

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

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

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

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

4D Sortition variant

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

Support 4D Sortition variant

1. Sure. – John M Wolfson (talk • contribs) 14:03, 7 November 2021 (UTC)
2. As proposer. Basically, this would institutionalize and automate the idea that long-time productive editors should consider running for RfA, and automatically group them into a cohort. (It would go particularly well when combined with a version of 8B (making the voting process secret ballot) and also with an initial adminship term of finite duration, but I think that even without these things it would be a significant step towards increasing the pool of potential administrators.) Precise details of the invitee pool and frequency of elections could be modified later. --JBL (talk) 15:54, 7 November 2021 (UTC)
3. Support for the same reason that I supported 4A. — Bilorv (talk) 17:22, 7 November 2021 (UTC)
4. Support at least a trial run. --SilverTiger12 (talk) 21:31, 7 November 2021 (UTC)

Oppose 4D Sortition variant

1. As mentioned regarding proposal 4A, I 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) 15:57, 7 November 2021 (UTC)
2. No, for the same reasons as above. — xaosflux 16:14, 7 November 2021 (UTC)
3. As above, this can't possibly automate anything, because none of the criteria are automatable. —Cryptic 16:27, 7 November 2021 (UTC)

   @Cryptic: The automated aspect is irrelevant to the goal and value of the proposal; if it requires a few hours of someone's time every few months, it will still be worth it. I also think "support on the condition that the requirements are replaced with something that can be done in an automated way" would be an excellent and constructive !vote on this proposal. --JBL (talk) 18:21, 7 November 2021 (UTC)

4. Per my oppose and those of many others at 4A. Trainsandotherthings (talk) 16:33, 7 November 2021 (UTC)
5. Oppose. This still has the same problem. SpinningSpark 17:32, 7 November 2021 (UTC)

   The problem you identified above is "forcibly nominating candidates" -- anyone who doesn't want to be nominated in this model can just ignore it. --JBL (talk) 01:40, 8 November 2021 (UTC)

6. Per 4A; also this shouldn't even need an RFC. There is nothing stopping a determined editor from nominating 10 candidates for adminship without this proposal (other than the limited pool of candidates who both want to run and are likely to succeed). User:力 (powera, π, ν) 17:33, 7 November 2021 (UTC)

   @力: There is a world of difference between one person randomly nominating 10 people (everyone will correctly identify that one person as a crank behaving in crank ways) and making an institutional decision that that will happen on a regular basis. Accepting the nomination of someone who is acting in an abnormal or even ridiculous way has obvious negative connotations; accepting the nomination of a community-supported process is entirely different (even if the criteria of selection are exactly the same). --JBL (talk) 18:21, 7 November 2021 (UTC)

7. Does not address my concern with the original proposal. * Pppery * _{it has begun...} 18:31, 7 November 2021 (UTC)
8. Does not solve the issues with the original proposal. HighInBC 09:31, 8 November 2021 (UTC)
9. What if the user doesn't want to be an admin? 🐔 Chicdat   10:57, 8 November 2021 (UTC)

Discussion 4D Sortition variant

I would urge people who take the view that the problem with this proposal is the particular criteria rather than the structure of the proposal to make a !vote of the form "conditional support, if the criteria are changed to ". --JBL (talk) 18:22, 7 November 2021 (UTC)

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

5A Revise standard Question 1

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

Support 5A Revise standard Question 1

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

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

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

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

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

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.

6A Binding recall criteria

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

Support 6A Binding recall criteria

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

Oppose 6A Binding recall criteria

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

12. Community de-adminship should operate on consistent standards, not bespoke criteria which could depend not on the merits of the admin but on how hard they were pressured into signing up for recall at their RfA. -- King of ♥ ♦ ♣ ♠ 20:17, 1 November 2021 (UTC)
13. Per King of Hearts, plus I doubt (based on the comments at WP:BN) that the crats would be willing to execute this proposal in any way true to its intent. Extraordinary Writ (talk) 03:52, 2 November 2021 (UTC)
14. I got rid of my recall criteria because it is a useless process --Guerillero 10:26, 2 November 2021 (UTC)
15. per Anarchyte. Isabelle 16:15, 2 November 2021 (UTC)
16. I think a recall process would be fine, but not this one. Specifically, all of the mandatory secret prescreening and approval by bureaucrats parts here are a no go for me, not just as a 'crat - but because these shouldn't require any secret proceedings. I'd prefer a standard community-wide recall criteria. — xaosflux 10:52, 3 November 2021 (UTC)
17. I don't believe we should be encouraging the creation of bespoke recall criteria, any community recall process should be universal. — csc 22:05, 3 November 2021 (UTC)
18. Recall is inherently a mess. ArbCom is very effective at removing admin access when necessary, and sometimes when not. Jehochman 08:11, 5 November 2021 (UTC)
19. Agree with the first comment here. If the problem we are trying to address is that there are not enough admins and that it is too difficult to recruit more, then making more ways to remove admins is hardly going to help. SpinningSpark 17:35, 7 November 2021 (UTC)
20. Per Beeblebrox and Rschen. Evidence shows recall doesn't work, and whether candidates sign up to this would be entirely arbitrary (i.e. whether they were bullied into it). I don't see why a realistic prospective RfA candidate would decide (before starting their RfA) that having a mandatory, immutable recall criteria is the only way the RfA will pass. ProcrastinatingReader (talk) 23:17, 7 November 2021 (UTC)
21. Per Beeblebrox, and unless the question (a Catch-22 question anyway) is asked at RfA: 'Will you be open to recall?', it's probably not in the back of the minds of most voters. Secondly, Recall has been used so rarely that the sample size is too small to know if it would ever be effective as a community desysoping process or pre-process and some admins have refused to abide by their own criteria. Finally, as WP:BARC demonstrated, it's not in the Bureaucrats' job description - it's not what they signed up for. Building a new league of 'crats would take years at the rate of RfB. Kudpung กุดผึ้ง (talk) 23:40, 7 November 2021 (UTC)

Discussion 6A Binding recall criteria

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

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

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

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

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

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

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

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

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

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

• Recall in principle is a good idea, but it should be the same for all, not opt in. There have been a number of general recall proposals, but they have all had flaws. Recall by ArbCom is recall, and it works. —SmokeyJoe (talk) 09:21, 8 November 2021 (UTC)

Crat comments on their role

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

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

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

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

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

• When recall criteria are met, any user can notify the bureaucrats at Misplaced Pages: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(talk) 09:18, 1 November 2021 (UTC)

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

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

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

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

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

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

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

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

6B Desysop at AN(I)

A discussion at either Misplaced Pages:Administrators' noticeboard (AN) or Misplaced Pages: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 Misplaced Pages:Bureaucrats' noticeboard. The user may then only regain adminship through the standard process for non-admins.)

Support 6B Desysop at AN(I)

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

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

10. Support. What's good for the goose is good for the gander. The reasons for why ANI would be unfair to administrators are the same reasons that make it sometimes unfair for everyone else. If this passes admins may be motivated to improve ANI. Plus...we actually already have the ability desysop by consensus per IAR, we just have to decide on the forum. Kolya Butternut (talk) 21:22, 7 November 2021 (UTC)
11. Would prefer somewhere other than AN/I, but this is a good start. 🐶 EpicPupper 22:33, 7 November 2021 (UTC)
12. If consensus can give someone sysop privileges, consensus should be good enough to take them away.--Ithinkiplaygames (talk) 06:05, 8 November 2021 (UTC)

Oppose 6B Desysop at AN(I)

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

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

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

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

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

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

12. I mention in #Oppose 6A Binding recall criteria that we need a process outside of ArbCom to remove adminship, and while ANI looks like the most obvious avenue, I wouldn't trust it in its current state. It's completely disorganised and full of people with vengeances and drama seekers with a spare fifteen minutes. Similarly, many of the discussions over there are closed by non-admins which is a completely different environment to requiring a bureaucrat to close an RfA. I think we should explore using RfA for both assigning adminship and removing it. Of course, some may argue that RfA is better than ANI, but at least we have some semblance of process at the former. Anarchyte (talk) 06:28, 1 November 2021 (UTC)
13. ANI is a crazy place that is not the way to solve the problem. Why, we need more admins, not fewer! 🐔 Chicdat   10:49, 1 November 2021 (UTC)
14. I worked on this, including several proposals, over the last decade. ANI/AN is a horrible place for this. Dennis Brown - 2¢ 11:42, 1 November 2021 (UTC)
15. AN/ANI alone should not be used as a venue for desysopping. I support a Commons-style de-adminship process: get rough consensus first at AN/ANI, and then open a formal de-RfA. After a week, the de-RfA will be successful if a simple majority votes for removal. -- King of ♥ ♦ ♣ ♠ 19:04, 1 November 2021 (UTC)
16. I cannot support a process where as few as three admins could desysop anyone after a discussion on a forum that many Wikipedians avoid on principle. While I am open to the idea of a community de-sysop procedure, this proposal would not appreciably improve the RfA process or adminship in general. Ganesha811 (talk) 19:16, 1 November 2021 (UTC)
17. ANI is a cesspit --Guerillero 10:26, 2 November 2021 (UTC)
18. Per Guerillero: ANI is bad and this just makes a rough process worse. ~ Amory (u • t • c) 15:54, 2 November 2021 (UTC)
19. To overcome our shortage of admins and to make things surrounding adminship suck less, let's allow one of our most sucky boards to remove even more of them? Sounds wonderful. Not. —Kusma (talk) 15:01, 3 November 2021 (UTC)
20. Every problem editor eventually get summoned to ANI. The selection of users watching that page is strongly biased towards troublemakers. I wouldn't be an admin if I hadn't been summoned to ANI in 2005. Jehochman 08:14, 5 November 2021 (UTC)
21. Has nothing to do with RFA reform, no idea why anyone would think this would make candidates more likely to run for RFA. AN/I is the home of some of the most disruptive and anti-admin users on the project. Thanks, no. Risker (talk) 23:21, 6 November 2021 (UTC)
22. So we are going to encourage more candidates to go through the hell of RFA by offering them the prospect of later going through the hell of a ANI desysop? Don't see how that is meant to work. SpinningSpark 17:40, 7 November 2021 (UTC)
23. Absoltely not. AN(I) is a snakepit at best. But in judging the fitness of an administrator, it would be a disaster. Decisions would be made based on how many editors the admin in question has offended (by doing their job effectively), and how many of their friends they could get to come and vote against the person. If this was the case, administrators would probably think twice before doing any of the necessary but unpopular tasks that come with the job. This method would be like judging the fitness of an umpire by a vote of the team. -- MelanieN (talk) 22:48, 7 November 2021 (UTC)
24. "I'll take 'How to make ANI even worse for $500, Alex.'" Jclemens (talk) 05:30, 8 November 2021 (UTC)
25. Very strong oppose ANI. It’s a fast moving drama board. Oppose AN, unless clear cut, although clear cut would mean not even the admin is protesting, and so BN would be better. Eg possibly compromised account, or no longer cares. For a controversial contested desysop, use ArbCom, or set up some sort of reverse RfA (but note devils in details). —SmokeyJoe (talk) 09:26, 8 November 2021 (UTC)

Discussion 6B Desysop at AN(I)

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

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

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

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

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

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

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

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

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

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

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

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

6C Administrative action review

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

References

1. Proposed name changed at 18:36, Thursday, January 23, 2025 (UTC) per talk page discussion.

Support 6C Administrative action review

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

Oppose 6C Administrative action review

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

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

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

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

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

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

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

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

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

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

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

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

Discussion 6C Administrative action review

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

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

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

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

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

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

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

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

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

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

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

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

  Hi Joe. I'm not insinuating an ulterior motive. The entire concept here is what is problematic. What is suggested is that *unknown entities* are not participating at RFA because they have a philosophical issue with a core aspect of the Administrator role. We used to know what to do with people who opposed RFAs because of such philosophical concepts: we ignored their vote, rolled our eyes, and told them to take it to the right venue, which was discussion about administratorship. What you're proposing here doesn't have anything to do with RFA. It has to do with the general concept of the administrator bit. I've gone back and read a lot of RFAs in recent months, and I can't see any evidence whatsoever that (a) candidates are refusing to participate at RFA because of the absence of some sort of special, additional way to complain about admins, or that (b) anyone's oppose on general philosophical concepts is having an effect on RFA. I'm not saying that the concept is entirely wrong, it just has nothing to do with RFA. As best I can tell, this is something that gets discussed amongst a few RFA groupies, not the community as a whole, and most RFA participants do not care. Risker (talk) 17:18, 7 November 2021 (UTC)

  Joe Roe, I have to concur with the points Risker is making. Because RfA carries with it lifetime tenure, granting any given editor sysop feels incredibly important. This creates a risk-averse and high-stakes atmosphere, it might have got consensus but it was based purely in anecdotal evidence and that is why Misplaced Pages management often fails - consensus building is often based on pure opinions rather than facts and a pragmatic approach. And whether or not there is a similarity between this idea and the deprecated WP:RFC/U, the last thing Misplaced Pages needs for addressing admin or user behaviour is yet another drama board - and it won't increase the number of candidates for RfA. Kudpung กุดผึ้ง (talk) 00:41, 8 November 2021 (UTC)

  I doubt it will increase the number of candidates, no. What I suggest is that it will (eventually) decrease the cautiousness of RfA voters, and thereby the success rate at RfA. Still, the time to object to the existence of the problem was phase I. This phase is about proposing solutions. – Joe (talk) 06:32, 8 November 2021 (UTC)

• I don't think this is such a bad idea. But how is this supposed to be addressing the problems at RFA? It doesn't do anything in that respect. SpinningSpark 17:45, 7 November 2021 (UTC)
• What would be more helpful is a routine process for non-administrative administrative action reviews. "Non-administrative closes" are running rampant in many phases of the project (I'm particularly aware of this at requested moves). We should review the non-administrative administrative actions of non-administrators performing such actions beyond a certain amount, with the idea of encouraging those who are performing these in an acceptable manner to run for administrator, and discouraging those who aren't from taking these on. If you're looking for an "alternate path" to become an official administrator, this would be it. – wbm1058 (talk) 02:04, 8 November 2021 (UTC)

  Now the proposals are fixed I suppose this has to be left for later discussion (if the proposal finds consensus), but I think it would absolutely make sense to review NACs, as a kind of quasi-administrative action, at XRV. – Joe (talk) 06:34, 8 November 2021 (UTC)

• Admin review can and does and should occur at WP:AN. If it doesn’t find joy, go to ArbCom with the evidence having been discussed at AN. —SmokeyJoe (talk) 09:29, 8 November 2021 (UTC)

6D Initial probationary term (mandatory)

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

Initial election as administrator is for a 2-year probationary term. At the end of the 2-year probationary period, candidates may run (in another RfA or whatever process is being used) for a permanent position; otherwise, admin permissions automatically removed.

Support 6D Initial probationary term (mandatory)

1. As proposer -- makes the initial selection of administrators lower-stakes, and candidates for lifetime position have a concrete record as administrator to run on. --JBL (talk) 16:01, 7 November 2021 (UTC)

Oppose 6D Initial probationary term (mandatory)

1. Oppose in that requiring everyone to go through an entire second RfA again seems excessive. I'd be fine with having an option for candidate to make a RfPA for a one year term if they wanted to opt-in to that though (then they do a normal RfA or another RfPA when their term is coming up). — xaosflux 16:19, 7 November 2021 (UTC)
2. Oppose per Xaosflux. SpinningSpark 17:46, 7 November 2021 (UTC)
3. Oppose. Don't think it would help with increasing the number of admins. RfA is already a stressful enough experience that I don't think new admins going through it essentially twice would help. Dreamy Jazz 19:40, 7 November 2021 (UTC)
4. Unless there's some scheme that means the second RFA will actually be considered pleasant for all involved, I don't think making this mandatory helps anything. I'm still undecided/lean support on 6E (the optional proposal), and there is always the possibility that an optional probationary term will become de facto mandatory. If that happens, so be it. User:力 (powera, π, ν) 20:22, 7 November 2021 (UTC)

Discussion 6D Initial probationary term (mandatory)

@Xaosflux and Spinningspark: please see new option (E) below. --JBL (talk) 17:55, 7 November 2021 (UTC)

Thanks to all the opposes for convincing me that there is no advantage whatsoever to this over the optional version 6E; I am withdrawing it to simplify everyone's lives. --JBL (talk) 20:26, 7 November 2021 (UTC)

6E Initial probationary term (optional)

A candidate may choose to run for election as temporary administrator for a 2-year probationary term. At the end of the 2-year probationary period, candidates may opt to run (in another RfA or whatever process is being used) for a permanent position or for additional 2-year terms; otherwise, admin permissions automatically removed.

Support 6E Initial probationary term (optional)

1. As proposer -- makes the initial selection of administrators lower-stakes, and candidates for lifetime position may have a concrete record as administrator to run on. --JBL (talk) 16:01, 7 November 2021 (UTC)
2. Support per JBL. This has the potential to dial back the pressure of RfA by lowering the intensity. It also empowers editors who have a specific project they want to accomplish requiring admin tools but have no desire for infinite adminship. Chetsford (talk) 18:24, 7 November 2021 (UTC)
3. I like this proposal—it lowers the stakes a bit, and allows qualified candidates to specialize for a limited period of time. theleekycauldron (talk • contribs) (they/them) 18:42, 7 November 2021 (UTC)
4. Sure. – John M Wolfson (talk • contribs) 18:53, 7 November 2021 (UTC)
5. Conditional Support: I'm OK for this with a one-year term, as an opt-in only option. OK with any RfA that is opened be converted TO a RfPA (RfTA - dunno someone will come up with a name for it) mid-flight, but never the reverse. — xaosflux 19:08, 7 November 2021 (UTC)

   I hadn't contemplated the possibility of someone trying to change mid-flight; I agree with you that "RfPA -> RfA" mid-process should absolutely not be allowed. --JBL (talk) 01:33, 8 November 2021 (UTC)

6. Support 1-year terms. It should be an improvement in enough situations to be a permissible option. If a minority of the community unreasonably forces everyone to use this their first time (or forces editors to run every year for years on end) we can change it then. User:力 (powera, π, ν) 21:03, 7 November 2021 (UTC)
7. Sure. Allows the community a chance to review the admin again before installing them permanently, thus reducing the stakes. ProcrastinatingReader (talk) 22:42, 7 November 2021 (UTC)
8. Sure, opt-in, 1 year or 2. Lowers scrutiny. 🐶 EpicPupper 22:45, 7 November 2021 (UTC)
9. Support 1 year. Would have preferred a system like this which isn't opt-in, as I doubt many would opt-in for, but it is better than nothing. This allows the community to see how exactly the admin has used their tools, if they actually did work or were just active the first few weeks after the RfA.— Preceding unsigned comment added by Gonnym (talk • contribs)

Oppose 6E Initial probationary term (optional)

1. Why would anyone want to do that? And how does it help recruit more admins? SpinningSpark 18:31, 7 November 2021 (UTC)

   @Spinningspark: what is the point of asking rhetorical questions like this as a !vote? If they are actual questions to which you want answers, put them in the discussion section. Or read the !votes in the support section, which already contain the answers. --JBL (talk) 18:51, 7 November 2021 (UTC)

   Since (as you correctly divined) it is a rhetorical question, the clue is in the question. No one will want to do it and it won't help recruit more admins. SpinningSpark 19:02, 7 November 2021 (UTC)

   Thanks: by making an affirmative statement instead of asking a rhetorical question, you enable others to discuss the actual content of your position (viz., it is now possible to say "I agree with Spinningspark" or "Spinningspark is wrong"). --JBL (talk) 19:16, 7 November 2021 (UTC)

2. I don't see how this helps the situation I thought this suite of reform proposals was supposed to address: the dearth of candidates / the environment at RfA. Besides which, being 'optional' it would probably not have many takers. Kudpung กุดผึ้ง (talk) 01:00, 8 November 2021 (UTC)

   @Kudpung: I think that what will happen if this is implemented is that voters at "RfPA" will be more lenient with candidates than they are currently at RfA (because obviously), that will make the environment at RfPA less forbidding, and it will induce more people to run for RfPA. Some of those people will then run for RfA, and with a year or two of successful adminship under their belt, the RfA will be a smoother discussion because voters will not have to imagine what someone would be like as an admin. (Also, I will admit to being a little perplexed trying to reconcile your last sentence with your comment below: I can see how a person could worry that no one will take advantage of this, and also how a person could worry that everyone will be forced to do it -- but not how a person can be concerned about those two things simultaneously.) -JBL (talk) 01:27, 8 November 2021 (UTC)

3. I think this could well lead to a two-tier admin system whereby any future admins end up having to run for reconfirmation every two years. The fact it's optional doesn't mean it won't become a de facto requirement, with editors treating requests for permanent adminship more suspiciously, insisting the candidate justify getting permanent adminship as opposed to the two year variety, or outright opposing requests for permanent adminship. This would lead to people having to run for the two year period to have any chance of passing. Then we would have the disadvantages of reconfirmation which have shot down all previous proposals for it - the unpleasantness of forcing people to go through RfA regularly, substantial pressure against taking any controversial or unpopular admin actions, time wasted by the community considering people who are qualified, etc. I would be more in favour of a proposal which made it clear the probationary term was a one time thing and wasn't to be renewed indefinitely. Hut 8.5 08:58, 8 November 2021 (UTC)

   @Hut 8.5: If your support is contingent on people only being allowed to run for a single temporary term before running for the full thing, I invite you to make a support !vote that states that contingency clearly. I don't think it is appropriate to change the proposal at this point, but I consider that amendment to be totally consistent with the major goals of this proposal. (A couple of support !votes are contingent on the term being reduced to 1 year, and I feel the same about that.) --JBL (talk) 10:48, 8 November 2021 (UTC)

4. This will give us less admins, we need more admins. HighInBC 09:32, 8 November 2021 (UTC)

   @HighInBC: Currently (for the past 12 months) the only people who get elected admin all get 95% support. Do you think it's plausible that suddenly people will vote against them, but not plausible that what I wrote in response to Kudpung above will happen? What are your personal answers to the questions I posed in my response to Isaacl below? --JBL (talk) 10:53, 8 November 2021 (UTC)

Discussion 6E Initial probationary term (optional)

• 2 years seems long, but this would eliminate the "tools are difficult to remove and I don't trust them enough" oppose rationale. That said, I'd need to see what number of RfAs have actually failed or been significantly impacted by it before I could support this. Giraffer 19:06, 7 November 2021 (UTC)
  • @Giraffer: what does I'd need to see what number of RfAs have actually failed or been significantly impacted by it mean? --JBL (talk) 19:18, 7 November 2021 (UTC)

    It means that before I support this, I would like to know how many (or just some recent examples of) RfAs which have failed on the basis that removing tools from an abusive administrator is too difficult (and therefore that the opposers didn't want to take the risk). Does this clarify my comment? Thanks, Giraffer 20:12, 7 November 2021 (UTC)

    As a hypothetical, if I nominated a former co-worker who I am sure would be excellent at adminship, but only has 1000 edits on enwiki, this might aid their chances of passing. User:力 (powera, π, ν) 20:17, 7 November 2021 (UTC)

    (edit conflict) Thanks, yes, that clarifies. But perhaps it slightly misses the point of this proposal: RfPA (or whatever) will be a lower-stakes process, and therefore (hopefully) more inviting to people who are not willing to go through the current process with the attendant level of scrutiny. Thus, when evaluating its merit, one should consider the pool of people who decide not to run for RfA but might do so in a lower-stakes environment, not just the people who already have run for RfA. --JBL (talk) 20:22, 7 November 2021 (UTC)

• I am concerned this may lead to voters expecting most or all candidates to go through this process before doing a full RfA, even if on paper it is strictly optional. Trainsandotherthings (talk) 20:24, 7 November 2021 (UTC)

  It is easy to imagine a world in which most people who go through RfA feel it is necessary to start off with a 1- or 2-year adminship term, except the people who can get really overwhelming support. But since all successful RfAs over the past 12 months have closed with > 95% support, though, it's not clear that this would represent a reduction of options for anyone. --JBL (talk) 20:38, 7 November 2021 (UTC)

  • I'm concerned about this, too. If passed, this is all but guaranteed to become a de facto requirement:

  • Oppose: I'd want to see what they're like as a temporary admin before giving them permanent tools. We just don't know enough about how they'd behave. ~~~~
  • Oppose: The fact they aren't running for temporary adminship makes me think they're planning to do something unpopular once given the tools and don't want to face the backlash. ~~~~
  • Oppose: They've given no justification for why they'll need the tools in 2024 so they ought to have run for limited adminship. I'd switch to a support if they changed their run to a TRfA. ~~~~
  • Oppose: Opting for a full RfA on your first run is exactly the sort of power-grabbing behavior good admins eschew. The candidate is a guaranteed mushroom. ~~~~

  And then candidates will have to endure two RfAs rather than just one. Isn't the goal here to reduce the pressure, not to double it? I'm on the fence about this, but one thing I would certainly want to see before I could support it is eliminating the option to run for a second two-year term. If, after having admin tools for two years, the community still doesn't trust you enough to make you a full admin, you shouldn't be an admin. {{u|Sdkb}}  23:55, 7 November 2021 (UTC)

  Right now, the de facto requirement is that support be so incredibly overwhelming that there is only token opposition, and as a result we have only a handful of people bother to try. For the small number of people per year who can get 95% support (which is what every passing candidate in the last 12 months has received), do you really believe this would be a problem? For everyone else, this presents an option that will subject them to a lower standard (because voters should be more willing to take a chance on someone when it's temporary). Then when people run again, they'll have an affirmative record as an administrator to run on.
  Anyhow, if your support is contingent on people only being allowed to run for a single temporary term before running for the full thing, I invite you to make a support vote that states that contingency clearly. --JBL (talk) 01:15, 8 November 2021 (UTC)

• I'm not sure about the duration. If it's "the admin is limited in how much damage they can do before another vote", 2 years seems long. If it's "the admin does an RFA every few years for life", 2 years seems short. Maybe that means 2 years is the right number, maybe not. User:力 (powera, π, ν) 20:29, 7 November 2021 (UTC)

  A couple of support votes above are contingent on changing the duration to 1 year; I'm not going to tinker with the proposal, but I think it's likely that if it passes it will be with consensus for 1 year, not 2. --JBL (talk) 20:38, 7 November 2021 (UTC)

• Consensus creep: I am also concerned that if passed, it would be all but guaranteed to become a de facto requirement. Kudpung กุดผึ้ง (talk) 01:06, 8 November 2021 (UTC)

  Right now, consensus has crept to the point where no one has passed an RfA with less than 95% support in the last 12 months. --JBL (talk) 01:15, 8 November 2021 (UTC)

  JBL, that is not consensus creep. That is a direct result of the Dec 2015 reform allowing every RfA to be as widely advertised as possible resulting in a huge number of drive-by support votes. I am fairly confident that only the established regular voters do any in-depth due diligence before voting. Kudpung กุดผึ้ง (talk) 02:11, 8 November 2021 (UTC)

  "Lots of drive-by support votes" could theoretically explain many things but it definitely cannot explain why no one has gotten more than 70% and less than 95% support in the last 12 months, nor why no one who has passed in the last 12 months has had more than 10 oppose votes. --JBL (talk) 02:29, 8 November 2021 (UTC)

  JBL, no one will ever really know until someone runs a search for stats. Misplaced Pages used to be a very stats-hungry place but nowadays people prefer anecdotal evidence. There is already a perfect model of the kind of stats that would reveal all this, but since the last reasonable year for RfA passes the sample size is now so small that it would be hard to call any result a trend, but it would show how old the voter's accounts are, what experience they have, and how often they vote at RfA. I just don't understad the reluctantce to run the search to either confirm or deny the conjecture (I don't mind being proven wrong). Kudpung กุดผึ้ง (talk) 08:39, 8 November 2021 (UTC)

  This is not a statistical question, it's a causal question: is there a process by which "lots of drive-by support votes" could cause there to be no one getting between 70% and 95%, and no one getting more than 70% with more than 10 opposes? The answer is no, it is not possible that adding a bunch of drive-by support votes could have that effect, because the effect is much more complicated than "a bunch of extra support votes". Anyhow, this is my last word on this thread; if you post something more, I promise to read it but I won't respond unless explicitly requested. --JBL (talk) 10:29, 8 November 2021 (UTC)

• Regarding JBL's question on how the proposed change could fail to produce the desired effect in multiple ways: it could become a de facto prerequisite to an unlimited admin term, while failing to attract significant numbers of new candidates beyond the current pool of hopefuls. However, personally I don't think it will become a de facto requirement. I don't think the community will stop approving requests from the same type of editors that are getting approved at present, and require them to request temporary adminship first. isaacl (talk) 01:41, 8 November 2021 (UTC)

  Isaacl, thanks for this comment. Everyone who has expressed the concern that it could become a de facto prerequisite to an unlimited admin term is failing to make the appropriate comparison, which is with the situation right now. The situation right now is that the de facto requirement of becoming an admin is you get 95% support and 10 or fewer opposes. As you say, it is not plausible that the tiny number of people who currently get 95% support will suddenly start drawing widespread opposition. You are also correct about what the actual potential failure mode here is: voters might continue to apply absurd standards even for limited terms, the process might be equally unpleasant, and so no one will want to go through it. And the best test for this is for each voter to ask themself two questions: "would I apply the same standard to someone running for a 2-year term as admin as I would to someone running for a permanent position?" and "would I scrutinize someone running for a permanent admin position who already had 2 years of experience in the same way that I scrutinize someone running with 0 years of experience?" Now, the internet is a strange place, and maybe Misplaced Pages is full of lots of people who have completely different answers to these questions than I do -- but those are the questions that people should be engaging with in judging whether this proposal is likely to help or not. --JBL (talk) 10:44, 8 November 2021 (UTC)

Issue 7: Admin permissions and unbundling

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

7A Limited adminship

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

Support 7A Limited adminship

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

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

10.  ― Qwerfjkltalk 07:21, 1 November 2021 (UTC)
11. Per Wugapodes. ProcrastinatingReader (talk) 09:32, 1 November 2021 (UTC)
12. I certainly like this idea more than unbundling the admin tool set. Limited adminship is a thing on metawiki and to my knowledge it has worked well there. This may also finally prove to the community that doing a few niche things as an admin can still make you a very valued and productive admin. If a limited admin went a year and blocked hundreds of vandals without opposition, who cares if they are good at writing articles? That sort of change of mindset is what I'm hoping most will come out of RFA2021. — MusikAnimal 19:32, 1 November 2021 (UTC)
13. Per MusikAnimal. KevinL (aka L235 · t · c) 23:25, 4 November 2021 (UTC)
14. I'm aware that this is a perennial proposal, but I'm behind this one—from my experience at DYK, I've learned there are jobs that are too important to let anyone partake that still don't attract many admins, such as DYK queue promotion and copyvio revdel. Adminship is trust in an editor's competence, sane judgement, and experience. We don't need to pile on "jack-of-all-trades competence to use every single tool in the toolbox". theleekycauldron (talk • contribs) (they/them) 18:55, 7 November 2021 (UTC)
15. A better alternative than unbundling admin tools. I have doubts about whether this will work, but it's certainly worth a try. 🐶 EpicPupper 22:45, 7 November 2021 (UTC)
16. After reading some of the comments by other editors, and thinking more about it, I've decided to support this. This might help solve the issue of users needing the tools for very specific tasks, but afraid of having their RfA opposed for not wanting/knowing how to use for more broad tasks. Isabelle 00:40, 8 November 2021 (UTC)

Oppose 7A Limited adminship

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

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

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

15. I get less thrilled with this idea as I get more experience as an admin. Look, either you can be trusted to be an admin, or you can't. And you don't have to use all the tools. Dennis Brown - 2¢ 00:01, 2 November 2021 (UTC)
16. Likely will make it more difficult for us to find actual full admins (compare template editors, rollbackers etc.) —Kusma (talk) 14:58, 3 November 2021 (UTC)
17. WP:SLOP 🐔 Chicdat   10:56, 5 November 2021 (UTC)
18. Something tells me that this will lead to even fewer full time administrators. Scorpions13256 (talk) 16:33, 5 November 2021 (UTC)
19. This is just another version of the two RFA process. This makes it harder, not easier, to become an admin. SpinningSpark 18:34, 7 November 2021 (UTC)
20. (edit conflict) This violates the principle of least privilege and runs into the same problems as befell the attempt to create a main page editor usergroup * Pppery * _{it has begun...} 18:38, 7 November 2021 (UTC)
21. With some regret. I don't support permanent "limited-scope adminship", but "limited-scope and limited-time adminship" should be feasible. Yet the desire seems to be to create a permanent class of "main page only" admins. Hopefully 6E will do limited-time adminship in a more advantageous way. User:力 (powera, π, ν) 20:26, 7 November 2021 (UTC)

    @力: To be clear, these aren't permanent admins. The maximum request duration is 12 months. They could try to renew after, if the task requires it. If it does, I suspect it would be more common for them to just request full adminship and hope their tenure as a limited admin provides an additional reason to support. ProcrastinatingReader (talk) 21:21, 7 November 2021 (UTC)

    The proposal I want to support would allow "I'm going to do this admin task for a short while and then stop", not "I'm going to do this admin task for a while and then ask to keep doing it" User:力 (powera, π, ν) 21:31, 7 November 2021 (UTC)

Discussion 7A Limited adminship

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

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

  seconded—queue promotion is important, but also not an attractive job for those outside of DYK. Understaffing at the queues isn't as bad of a problem as was in years past, but it is still chronic. theleekycauldron (talk • contribs) (they/them) 18:48, 7 November 2021 (UTC)

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

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

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

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

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

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

• I've long felt a time-limited, say 2 year, apprentice admin role would be useful. Some capabilities, especially long term blocks, would not be available and some supervision would be imposed, e.g. a notice board for any short term blocks. The apprenticeship would be awarded on request based on some simple objective criteria, such as number of edits, minimum time as an editor, no dings for past editing, etc. A few months before the apprenticeship time was up, the user could apply at RfA. The current RfA evaluation criteria would be used, enhanced by the candidate's record as an apprentice. In other words, why not let editors interested in becoming an admin work with the tools for a while and then judge them on what they do?--agr (talk) 19:03, 7 November 2021 (UTC)
• No compelling reason why this, optional or otherwise, would induce more candidates to come forward for RfA. An apprentice role does not force the candidate to make a significant number of admin actions to make a large enough sample to satisfy any arbitrary metrics.What is being forgotten here is that the en.Wiki has a far greater number of admins than even the next nearest big Misplaced Pages. Limited terms and/or limited tool access would only add a monumental new pile of bureaucracy to be addressed by the community and there is no statistical evidence that it would be a net benefit. Bilorv, WP:PERM is allowed (since recently) to give out temporary rights as a trial period because 1) those requesting do not come under anything like the scrutiny an RfA candidate does, and because 2) it has been proven, especially in the case of WP:NPR, that not only is it useful, but essential. It has already weeded out hat collectors, and reviewers with a personal agenda. Kudpung กุดผึ้ง (talk) 01:52, 8 November 2021 (UTC)

  and there is no statistical evidence that it would be a net benefit How do you propose getting statistical evidence without an implementation? ProcrastinatingReader (talk) 02:04, 8 November 2021 (UTC)

7B Researcher userright

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

Support 7B Researcher userright

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

Oppose 7B Researcher userright

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

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

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

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

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

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

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

15. No rationale has been given why a group of editors might need the researcher right. Let alone a rationale why this is going to help improve the RFA process. I'm not against giving researcher rights to non-admins who need it, but that is irrelevant to the issue this review is meant to be addressing, and in any case RFA is the wrong process to oversee it. SpinningSpark 18:40, 7 November 2021 (UTC)
16. There's a reason there are only three dedicated researchers on the English Misplaced Pages and why the user right as a whole isn't that well understood by many. Far too risky, could cause controversy if given to non-admins. Liamyangll (talk to me! | My contribs!) 07:36, 8 November 2021 (UTC)

Discussion 7B Researcher userright

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

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

7C Unbundle blocking from the admin rights

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

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

7D Remove autopatrolled from default toolkit

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

Support (7D Remove autopatrolled from default toolkit)

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

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

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

Oppose (7D Remove autopatrolled from default toolkit)

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

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

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

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

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

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

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

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

   @Wbm1058: This section intends to address a combination of issues, primarily the "standards keep rising" and "too much scrutiny". The idea is that if autopatrolled doesn't come bundled with the sysop kit by default, hopefully people will stop opposing qualified candidates simply because they don't have enough content creation/FAs/GAs/DYKs/whatever. This would open the door for purely technical or countervandalism admins who just want to do the maintenance tasks without getting involved in drama, and therefore may not have adequate content creation to be trusted with autopatrolled permissions. IMO not qualifying for autopatrolled is a poor reason to oppose an admin candidate who would otherwise be trustworthy with the other core sysop tasks. Taking Out The Trash (talk) 16:51, 7 November 2021 (UTC)

   @Taking Out The Trash: I told you earlier, the expectation of admins to have done some content work has nothing to do with the autopatrolled tag, and removing that tag will not eliminate that expectation. That said, it looks like this proposal will pass for different reasons. – John M Wolfson (talk • contribs) 16:57, 7 November 2021 (UTC)

6. Oppose. My understanding has always been that 90% of the point of autopatrolled is to stop defamatory BLPs from making their way into mainspace. If there's a concern a candidate for admin is so unhinged that they might start peppering mainspace with defamatory BLPs, they shouldn't have any of the other tools either. Chetsford (talk) 18:29, 7 November 2021 (UTC)
7. I feel the number of editors who might decrease their scrutiny if administrators no longer had the autopatrolled privilege is sufficiently low that it would not affect the outcome of a request for administrative privileges. Thus I do not support this proposal in the context of RfA reform. isaacl (talk) 21:54, 7 November 2021 (UTC)
8. I'm all for decreasing scrutiny, and stopping editors from opposing candidates without X GAs/FAs/DYKs/etc, but I don't think this will help, and it'll increase work for patrollers. 🐶 EpicPupper 22:39, 7 November 2021 (UTC)
9. Oppose as irrelevant to solving any problems at RfA. ProcrastinatingReader (talk) 02:07, 8 November 2021 (UTC)

   Also the proposal's assumption of why some editors at RfA have content requirements seems incorrect. It isn't because article creations by admins are autopatrolled. I'm pretty sure it's just due to a philosophical belief that admins should have the ability to create referenced prose. Regardless of whether that belief is a good thing or bad, this proposal to unbundle autopatrolled doesn't affect it one bit. ProcrastinatingReader (talk) 02:10, 8 November 2021 (UTC)

Discussion (7D Remove autopatrolled from default toolkit)

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

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

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

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

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

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

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

• So let me get this right. "Autopatrolled does not give one the ability to mark pages as reviewed, or patrolled; one must apply for the new page reviewer right at PERM in order to do this." There are currently 704 New page reviewers, which makes the total number of users with this permission 1,778 (the rest are administrators, who automatically have this permission). So my page creations need patrolling, but as an admin I'm automatically granted the right to patrol my own creations. Wouldn't it make more sense to remove the new page reviewer right from the toolkit? But then you would need to push the ability to grant that up to the Arbitration Committee or some other higher level of review. I was ridiculously hammered at my RfA over my creation of redirects – some voters' standards are way higher than auto-patrolled... they expect good articles and maybe even featured articles! wbm1058 (talk) 17:58, 7 November 2021 (UTC)
• Just curious... do we have any non-admin new page reviewers who do not have autopatrolled status? wbm1058 (talk) 17:58, 7 November 2021 (UTC)

  Yes. If you look at the people who are active with NPP you'll see many who don't have the autopatrolled PERM. BEst, Barkeep49 (talk) 18:14, 7 November 2021 (UTC)

• Why on earth was this not filtered out as irrelevant to the issue of RFA before live voting started? SpinningSpark 18:44, 7 November 2021 (UTC)

7E New "Semi-protector" role

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

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

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

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

1. Oppose due to the implementation method, this design depends on these "group members" making a request to another admin, who would run a bot to just grant the requests. I'd prefer this be done software side, by splitting the protect permissions to be more granular with wgRestrictionLevels (e.g. permission protect-n can protect to restriction levels ), and maybe building the time controls in there too (though I'd be fine with that being just a policy); alternatively an extension that can handle some sort of short term protect/block could be a solution as well. — xaosflux 00:48, 7 November 2021 (UTC)
2. Definitely not. This would lead to many editors with this right protecting articles when blocking would be far more appropriate. This would cause a lot of collateral damage for IPs on these articles, and the disadvantages this proposal brings far outweigh the advantages. 🐔 Chicdat   12:18, 7 November 2021 (UTC)
3. Blocking can be be more useful than protection in many cases. As such, giving some users the ability to semi-protect may lead to these editors semi-protecting because they can't block, where blocking is more useful and better for the article. For example, for an article which is in the current news there may be one static IP or new account who is vandalising which would be prevented from editing by semi-protection, but by protecting it stops many IPs and new editors from contributing to the article. As such I don't think this would really help. Dreamy Jazz 13:28, 7 November 2021 (UTC)
4. Too immature a proposal - this cannot be implemented without a follow-up RFC. If this is going to be bot-intermediated, it should allow for rules like "two trusted non-admins must approve this" and should also allow for limited IP blocking. If this is going to be in MediaWiki, the extension should be written before we vote. User:力 (powera, π, ν) 17:40, 7 November 2021 (UTC)
5. When all you have is a hammer... We already have a systemic problem with all admins incorrectly applying the protection policy so as to advantage ECP or autoconfirmed editors in editing disputes. I am sympathetic to the fact that some "hammer problem" unbundlings still work well in practice (NACs at AfD) but I do not believe this is one of those cases. You should only get most of the way through evaluating an RfPP case before deciding what action is needed, and if by that point you only have "semi-protect" or "decline" or "leave it for someone else" then you will be, even unconsciously, pushed towards the first option where something else ((partial) blocking, a different protection) is correct. — Bilorv (talk) 17:43, 7 November 2021 (UTC)
6. No clear case for only PP. It needs to be one tool of several for dealing with disruption and the person doing the dealing needs to have all of them available. By the way, I'm not following the discussion about bots – the proposal says nothing about that. SpinningSpark 18:52, 7 November 2021 (UTC)

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

• Having been around for a few news events, my expectation is that those are exactly the situations where many-to-most edits by IP's and new accounts are bad, or at the very least need filtering through the edit-request mechanism on the Talk page. The news can bring multiple disruptive individuals editing from different IP's or under different account names. Deny the trolls the satisfaction until the event passes from the headlines, and everything goes much more smoothly. Of course, I've had the idealism burned out of me, so I'm not likely to be optimistic about such things; YMMV. XOR'easter (talk) 14:52, 7 November 2021 (UTC)
• Well, I didn't expect the community to be looking at the "responder role" proposal this soon :) If anyone would like to collaborate or leave their thoughts on the proposal, the talk page is just down the block. And I do concur that blocking is an essential part of it. I still think the proposal should get its own RfC, at least because we may want to have some options available. Enterprisey (talk!) 20:32, 7 November 2021 (UTC)
  • What do you mean by the proposal should get its own RfC? I assume you mean "don't vote on it here and now, have a separate RFC in early 2022", which I agree with. User:力 (powera, π, ν) 20:54, 7 November 2021 (UTC)

    Yup. Enterprisey (talk!) 20:58, 7 November 2021 (UTC)

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

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

8A PROD-style adminship

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

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

8B Admin elections

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

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

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

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

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

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

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

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

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

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

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

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

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

Oppose 8B Admin elections

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

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

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

3. Misplaced Pages 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 23:16, 31 October 2021 (UTC)

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

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

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

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

9. Aside from several of the previously mentioned points, the reality is that the SecurePoll infrastructure is already near capacity, has almost zero technical support, and will significantly impede other projects from using SecurePoll for more important things like their local Arbcom elections. SecurePoll is limited to one instance at a time throughout the Wikimedia-world; it is not possible for there to be two or more simultaneous elections using it. (I note that the recent MCDC election had a significant impact on the Arab Misplaced Pages 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 Misplaced Pages don't really consider the impact on other projects when we come up with ideas. But this one would create a fair amount of animosity. Risker (talk) 05:41, 1 November 2021 (UTC)

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

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

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

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

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

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

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

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

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

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

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

22. I'm told that there are perennial opposers who pile on to many, many RfAs and start opposing right off the bat. I don't think participation should be as easy as clicking a button—it would only exacerbate that problem. Also, Risker's point about SecurePoll's design makes this idea technically infeasible. theleekycauldron (talk • contribs) (they/them) 18:09, 7 November 2021 (UTC)
23. I oppose very weakly. I very much like this proposal, overall. My concern, however, is that it will invite floods of candidates, many of whom are patently unqualified, which will limit the opportunity to properly vet the potentially qualified. Also, a six month cycle seems aggressive. I would be more likely to support a variation of this in which votes occurred annually, rather than semi-annually, and in which an external nominator (e.g. an EC editor) were required versus self-nomination, just to cut down on the chaff. Chetsford (talk) 18:33, 7 November 2021 (UTC)
24. Adminship is not a political position and secret ballots are not an appropriate selection method. A good candidate could miss out and then have to wait six months for another chance. SpinningSpark 18:56, 7 November 2021 (UTC)

Discussion 8B Admin elections

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• I think the references to Misplaced Pages: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 14:43, 1 November 2021 (UTC)

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

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

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

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

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

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

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

@Worm That Turned: There are FOSS alternatives (example list, there are more), although sadly they are all missing from our Comparison of survey software. I'd be pretty surprised if none of them (can be modified to) fit our purpose while something by Google does. Daß Wölf 17:28, 7 November 2021 (UTC)

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

8B.alt Trial Admin election

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

Support (8B.alt Trial Admin election)

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

Oppose (8B.alt Trial Admin election)

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

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

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

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

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

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

5. RfA is a discussion, not a vote. SecurePoll is not for adminship. 🐔 Chicdat   10:53, 3 November 2021 (UTC)
6. RfA needs more discussion not less. HighInBC 23:31, 4 November 2021 (UTC)
7. Of course it would need a trial, but unless and until 8B is approved in principle (which I'm also against) this proposal is quite pointless. SpinningSpark 18:59, 7 November 2021 (UTC)

Discussion (8B.alt Trial Admin election)

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

General discussion

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

• Misplaced Pages requests for comment