Wikipedia

Wikipedia:Requests for adminship/2021 review/Proposals

< Wikipedia:Requests for adminship | 2021 review

This is an old revision of this page, as edited by Primefac (talk | contribs) at 11:23, 10 December 2021 (→6C Administrative action review: passed). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.


Shortcut

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

While the 30-day RFC listing is over, discussion on some proposals continues. Please do not close any discussions without first reading the talk page.

Introduction and format

The last comprehensive examination of our Requests for Adminship (RfA) system occurred in 2015. Nearly six 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:

  1. 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.
  2. 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.
  3. 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.

Closed: 1A Formal moderation of RfA

Moved to talk page for further detailing per requirement that no subsequent RfC should be required for implementation. Barkeep49 (talk) 17:45, 31 October 2021 (UTC)[reply]

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

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

Extended content
The gist of the idea is that formal moderators would police RfAs, with the power to remove uncivil comments, bad questions, and in general fight the corrosive atmosphere present. I would suggest that moderators who are active on an RfA be required to abstain from voting on said RfA.

Addition, 17:43, 31 October 2021 (UTC) Moderators would either be appointed from a group of admins who have opted in to moderating RfA discussions, or elected from the community at large in an election process.

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

Closed: 1B Zero tolerance for incivility or personal attacks

SNOW closed as unsuccessful. Barkeep49 (talk) 16:08, 7 November 2021 (UTC)[reply]

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.

Extended content

Support 1B Zero tolerance for incivility or personal attacks

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

Oppose 1B Zero tolerance for incivility or personal attacks

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

Discussion 1B Zero tolerance for incivility or personal attacks

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

I am saying that adding this rule will not make discussions more civil. User:力 (power~enwiki, π, ν) 18:08, 31 October 2021 (UTC)[reply]
To expand on that: without making clear *who* will do the enforcement (bureaucrats if you can get them to agree to it, some new group otherwise), *what* is an inappropriate comment (something like "bad CSD tagging" must not be considered a personal attack), and *where* the inevitable disagreements over whether comments should be removed should be litigated (somewhere far away from the RFA, hopefully) this will certainly just make things worse. If you try to explain all that, we just have the (still being drafted) 1A proposal. User:力 (power~enwiki, π, ν) 23:57, 31 October 2021 (UTC)[reply]
  • @Nosferattus: who do you think should remove the comments? How could the commenter "appeal" to get the comment reinstated, if the comment was necessary (albeit unpleasant) as part of scrutinising a candidate, and not incivility upon closer inspection? If a comment is removed, is it removed without comment or any evidence that it was ever left, or with a {{Redacted}} message or some other notice, and if a vote consists entirely of a personal attack then is the vote left behind? — Bilorv (talk) 18:44, 31 October 2021 (UTC)[reply]
    • Anyone could remove the toxic comment. To appeal, the poster would ask to have the comment reinstated. This isn't a new process. The only thing that's new is that the existing policies would be strictly enforced at RfA rather than laxly enforced (as they are now). Nosferattus (talk) 23:28, 31 October 2021 (UTC)[reply]
      • The problem is that trying to legislate a culture change will not work, particularly when the old culture is the one voting on the legislature and decides that no, actually, they'd prefer to keep the personal attacks and incivility around, thanks for asking. — Bilorv (talk) 12:18, 1 November 2021 (UTC)[reply]
  • RfA is a discussion about a person's trustworthiness and competence. My default support vote text is "Trusted, competent". Any opposition from me is practically a personal attack about trustworthiness and competence, but I'd expect not to be sanctioned for not writing my usual text. "Talk about content, not the contributor" works on article talk pages, but not at RfA. ~ ToBeFree (talk) 18:54, 31 October 2021 (UTC)[reply]
    @ToBeFree: I think the intent of this is not to prohibit commenting on such issues, but to enforce it being done in a constructive and polite fashion. You can very well say that you don't think X is skilled enough without saying "X is an incompetent [...]"; and you can certainly also explain why you think so (hence giving constructive criticism and not pile-on incivility). RandomCanadian (talk / contribs) 14:54, 2 November 2021 (UTC)[reply]
  • These policies already apply, so I'm not sure it's worth opposing. However I don't believe this proposal as written will achieve its goal for the reasons others have given. I do support moderation by bureaucrats per the 2015 RfC. — Wug·a·po·des​ 20:18, 31 October 2021 (UTC)[reply]
  • RFA is kinda sorta an exemption in that it is manifestly a discussion of a specific users fitness for a particular role, but personal attacks are already not allowed anywhere on the project. Beeblebrox (talk) 21:51, 1 November 2021 (UTC)[reply]
    I disagree an exemption is necessary to discuss a user's suitability for a role. This can be done in a constructive manner and centred on the user's behaviour, not the underlying motivations. isaacl (talk) 22:21, 1 November 2021 (UTC)[reply]
    @RandomCanadian: I said that I disagree that an exemption is necessary. isaacl (talk) 14:49, 2 November 2021 (UTC)[reply]
    Noted, fixed. RandomCanadian (talk / contribs) 14:51, 2 November 2021 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Closed: 1C Semiprotect all RFAs/voter requirements

SNOW closed as unsuccessful. Barkeep49 (talk) 16:08, 7 November 2021 (UTC)[reply]

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.

Extended content

Support (Semiprotect all RFAs/voter requirements)

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

Oppose (Semiprotect all RFAs/voter requirements)

  1. I don't think that at RfA or RfB IPs or newby accounts have a substantial negative impact, myself - they aren't really the main reason for the poor reputation of these processes. Also, the tendency of people to want to apply semi/extended confirmed protection everywhere that's not article space bothers me, as there is usually little evidence of a substantial benefit. Jo-Jo Eumerus (talk) 11:19, 1 November 2021 (UTC)[reply]
  2. More of a solution looking for a problem. Policy allows for IPs to opine, just not be counted in the !vote. SP would break this tradition without really solving any major problem. Dennis Brown - 2¢ 11:32, 1 November 2021 (UTC)[reply]
  3. Not currently an issue, nor is there a reason to exclude the possibility of long-term IP editors contributing in cases where they may have novel input (e.g. raising the issue of a candidate having an attitude of biting IP editors). — Bilorv (talk) 12:32, 1 November 2021 (UTC)[reply]
  4. Per all. Not necessary, especially as IPs already can't !vote, and won't necessarily help. – John M Wolfson (talk • contribs) 12:49, 1 November 2021 (UTC)[reply]
  5. We don't protect pages unless we need to and I have yet to see disruption at RfA that can be handled with reverts and the odd block. – Joe (talk) 14:28, 1 November 2021 (UTC)[reply]
    You're forgetting the occasional revdel or suppression, which (in the case of doxxing) happens after the privacy violation. --Rschen7754 18:07, 1 November 2021 (UTC)[reply]
  6. Fully agreed with Dennis Brown - this is a solution looking for a problem. Ganesha811 (talk) 19:12, 1 November 2021 (UTC)[reply]
  7. New editors participating is best handled on a case by case basis. HighInBC Need help? Just ask. 01:06, 2 November 2021 (UTC)[reply]
  8. Per above. IP editors already cannot !vote in RfA's, but I see no reason to prevent them from commentating. -FASTILY 05:44, 2 November 2021 (UTC)[reply]
  9. Not an issue, and non-accounts can provide (and have provided) valuable contributions. Prohibiting !voting is sufficient. ~ Amory (u • t • c) 15:26, 2 November 2021 (UTC)[reply]
  10. Preemptive protection is unnecessary, and would be counterproductive by preventing any meaningful input from IPs. — csc-1 21:42, 3 November 2021 (UTC)[reply]
  11. Protection is overkill, and I think there's an argument that this proposal is out of process altogether given that phase 1 section L rejected the proposition that "the kind of editors who participate in RfA are ill-suited for the task". I could support raising the suffrage requirements (sans protection), but this isn't the way to do it. Extraordinary Writ (talk) 23:16, 6 November 2021 (UTC)[reply]

Discussion (Semiprotect all RFAs/voter requirements)

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

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

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.

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

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
Failed. The proposal had generally weak support and generally weak opposition. Some commenters thought a rationale was needed or that, perhaps, this proposal wasn’t fully defined. — Preceding unsigned comment added by Philoserf (talk • contribs) 22:50, 2 December 2021 (UTC)[reply]

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

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

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

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

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

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

  1. Unnecessary instruction creep and I don't see how it solves the purported problem. If there are questions the candidate feels should be answered they are free to answer them in their opening statement, or on their RfA's talk page at any time. I don't follow the idea that if there is already too much scrutiny the candidate should further increase that scrutiny by asking themselves a question that they then must answer. This also implies a restricted time window, outside of which the candidate's ability to participate in their own RfA is limited, and I don't think limiting a candidate's rights to participation is helpful. – wbm1058 (talk) 16:27, 31 October 2021 (UTC)[reply]
  2. Candidates can already make any statement they want at any time. Hut 8.5 17:50, 31 October 2021 (UTC)[reply]
  3. Meh, weak oppose - mostly per Hut 8.5. This seems too formal, but be fine with updating the directions to remind candidates that they can amend their statements as needed. — xaosflux Talk 19:12, 31 October 2021 (UTC)[reply]
  4. Unnecessary. Would not add anything of a net benefit to process. Doesn't solve any of the problems that are the root causes for needing a reform of RfA, e.g. lack of candidates (whatever the reason), and the toxic environment of the process Kudpung กุดผึ้ง (talk) 19:16, 31 October 2021 (UTC)[reply]
  5. In general, administrators must be able to find a way to convey their points without seeming unduly defensive or non-responsive. There are already avenues with the current requests for adminship format that candidates can take advantage of, thus demonstrating their communication skills. isaacl (talk) 21:41, 31 October 2021 (UTC)[reply]
  6. Per Hut 8.5. Unnecessary process creep with no obvious benefits -FASTILY 04:22, 1 November 2021 (UTC)[reply]
  7. No demonstrable need. Anarchyte (talk) 06:14, 1 November 2021 (UTC)[reply]
  8. This isn't a game show. If it really is necessary for a particular candidate, the candidate can do it themselves. --Rschen7754 06:44, 1 November 2021 (UTC)[reply]
  9. Too WP:CREEPy. Also a WP:SLOP. 🐔 Chicdat  Bawk to me! 10:59, 1 November 2021 (UTC)[reply]
  10. WP:CREEP without tangible benefits. Dennis Brown - 2¢ 11:33, 1 November 2021 (UTC)[reply]
  11. Not a bad question, but I really don't see the point in making it mandatory, especially with the weird time-lag that will make it yet another formality someone has to remember to do (or write a bot for). If the nine people who have supported so far just agree to ask it themselves at the next nine RfAs, we'll be covered for a couple of years. – Joe (talk) 12:27, 1 November 2021 (UTC)[reply]
  12. Optional questions are not really optional until about 24 hours before an RfA closes. The usual procedure is 1. Silly question asked 2. Question criticised as silly. 3. Criticism rebuked as unacceptable 4. Rinse and repeat 5. Question finally answered. Optional: 6. Questioner blocked not long after the RfA closes due to sockuppetry, NOTHERE or both. Ritchie333 (talk) (cont) 14:12, 1 November 2021 (UTC)[reply]
  13. Don't see a need to add additional rules/instructions without a clear tangible need. - wolf 16:59, 1 November 2021 (UTC)[reply]
  14. Doesn't solve any real problems. Beeblebrox (talk) 21:20, 1 November 2021 (UTC)[reply]
  15. The question is fine, but there's no real need for it to be codified in policy. — csc-1 21:44, 3 November 2021 (UTC)[reply]
  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)[reply]
  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)[reply]
  18. As others have said, this is unnecessary. I think it would already add confusion to an already-confusing process. The reason that this "generic question" is being proposed (I gather) is to give RfA candidates a chance to talk about a positive aspect of themselves or their work. This is supposedly necessary because the RfA Q&A process is too rigid as is...so we are going to make it more rigid by adding a "generic question" at an elapsed time into the RfA? That doesn't make sense. – voidxor 22:38, 8 November 2021 (UTC)[reply]
  19. Little if any benefit. Neutralitytalk 05:30, 9 November 2021 (UTC)[reply]
  20. Huh? —⁠ScottyWong⁠— 06:18, 11 November 2021 (UTC)[reply]
  21. No demonstrable need. –Davey2010Talk 13:54, 11 November 2021 (UTC)[reply]
  22. "Optional" is a misnomer - we know that candidates who don't write and answer the "optional" question will be regarded by some as lacking the right attitude. And I don't see the benefit in getting the candidate to jump through even more hoops than they have to at present. This would become one more reason why people wouldn't want to go through a RfA. SilkTork (talk) 15:57, 11 November 2021 (UTC)[reply]
  23. This idea looks okay in principle, but seems quite unnecessary. If a candidate wants to add or clarify something in general, then they can add a separate statement anytime they want at their RfA. TheGeneralUser (talk) 02:27, 30 November 2021 (UTC)[reply]
  24. Weak oppose per above. ― Qwerfjkltalk 20:29, 1 December 2021 (UTC)[reply]
  25. In the context of the exercise to encourage more RfA candidates to come forward, this proposal does literally NOTHING. In fact, once seen in operation, seems more likely to hinder than help due to confusion it will cause. Leaky caldron (talk) 08:18, 2 December 2021 (UTC)[reply]

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

If I recall correctly, someone did that once and ironically put their foot in it and consequently lost their bid for the mop. Kudpung กุดผึ้ง (talk) 19:18, 31 October 2021 (UTC)[reply]
  • Not a fan but I don't see any harm so I won't explicitly oppose. That said, I don't see how this is any better than just letting the candidate respond inline or just reminding them that they can ask themselves questions. — Wug·a·po·des​ 20:22, 31 October 2021 (UTC)[reply]
    • Letting candidates directly respond to opposes breaks purdah and invites badgering. Also, a candidate asking themselves a question seems rather odd in my view, although this is just a formalized version of it. – John M Wolfson (talk • contribs) 20:26, 31 October 2021 (UTC)[reply]
      • But candidates do respond to opposes, and if the concern is that they are looked down for it (something I haven't really seen in recent years) why not just change our guidance to reflect that community expectation? Why formalize a new process that duplicates something candidates can already do? If candidates asking themselves questions is odd, asking them to ask themselves a question is just as odd. — Wug·a·po·des​ 22:12, 31 October 2021 (UTC)[reply]
  • I'm also neutral. Not sure this is better than "candidates or their nominators can also ask questions", which is apparently already allowed by policy and thus wouldn't even need an RFC. User:力 (power~enwiki, π, ν) 23:20, 31 October 2021 (UTC)[reply]
  • 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)[reply]
  • Some rationale for the proposal would be nice. --SmokeyJoe (talk) 06:56, 8 November 2021 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Withdrawn: 2C Cohorts of candidates

Withdrawn and moved to talk

Closed: 2D Quarterly elections

SNOW closed as unsuccessful. Barkeep49 (talk) 16:10, 7 November 2021 (UTC)[reply]

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

Extended content

Support (Quarterly elections)

  1. This is an attempt to address some of the objections brought up in 2C and 8B in a different proposal. At four times a year, hopefully all prospective candidates can make one of those times. There is no indeterminate waiting period as was proposed with the cohorts. And the opposes to 8B based on the SecurePoll go away. --Rschen7754 06:38, 1 November 2021 (UTC)[reply]
    I will also note that we already make candidates wait up to a year to apply for CU/OS (appointments are held only once a year), so this is not entirely unprecedented. --Rschen7754 18:24, 1 November 2021 (UTC)[reply]
  2. The September 2020 RfA flight was a forerunner to this and it went very well. I imagine that regular admin elections would eliminate the "singling out" problem that makes so many RfAs get stressful. 🐔 Chicdat  Bawk to me! 10:58, 1 November 2021 (UTC)[reply]
  3. Support. This just formalises an existing informal process where candidates tend to run in groups, whether co-ordinating this behind the scenes or deciding to pull the trigger when they see someone else is running. There is no need for RfAs to be done ad hoc at random intervals anymore, when we have so few RfAs. This would be better for voters too, as they would know when they need to schedule in some time to research candidates. (Rather than, say, a sockpuppet running for adminship with no warning and ArbCom having to privately decide if they are a sock within the week...) It is surprising to me that opposers think that anybody runs for RfA with less than three months of preparation and planning. — Bilorv (talk) 12:13, 1 November 2021 (UTC)[reply]
  4. Might be worth trying. Of course, informal versions of this are easily possible within the current structures. —Kusma (talk) 15:05, 3 November 2021 (UTC)[reply]

Oppose (Quarterly elections)

  1. Another proposal that seems like a solution looking for a problem. I fail to see how this will bring more quality candidates or solve problems with the system itself. If anything, it will discourage a few quality candidates. It isn't like we have SOOOO many RFAs that we need to corral them. Thinking this will make observers "nicer" and less likely to single anyone out? This doesn't change how observers react, just when. Dennis Brown - 2¢ 11:36, 1 November 2021 (UTC)[reply]
    This overlooks the historical record that, as of late, a large number of candidates do prefer delaying their RfAs in order to run alongside other candidates, and even sometimes manage to co-ordinate this themselves behind the scenes while not making it public that any of them are planning to run. Do you think the five candidates running within a week of each other in January 2020 or September 2020 was a coincidence? Have you asked them why they chose to do so? — Bilorv (talk) 12:13, 1 November 2021 (UTC)[reply]
    Leaving things as they are will not remove their ability to do so. As to why, I can think of several reasons, but I didn't ask those particular candidates, which represent a very small number of candidates anyway. Dennis Brown - 2¢ 23:47, 1 November 2021 (UTC)[reply]
    The problem I have with that is how does one know or find out about a bunch of people planning to run? It's really just who you know and word of mouth through Discord or IRC or email. We need some way to level the playing field - maybe it's not this, but then we need to come up with something. --Rschen7754 04:17, 2 November 2021 (UTC)[reply]
    Potential candidates can let a point of contact know, who could co-ordinate amongst the editors. isaacl (talk) 04:23, 2 November 2021 (UTC)[reply]
    And who is that point of contact? --Rschen7754 04:26, 2 November 2021 (UTC)[reply]
    Last time, Barkeep49 volunteered. We can create an appropriate page for it and solicit volunteers. Also see Wikipedia talk:Requests for adminship/2021 review/Brainstorming § Status check, where I discussed the idea of having a volunteer week where those involved in any Wikipedia initiative could solicit volunteers. (I suspect uptake will be embarrassingly low, but I'd be willing to try to slowly build it up over time if there's any interest at all.) isaacl (talk) 04:47, 2 November 2021 (UTC)[reply]
    In terms of how I found candidates it was through posts to WT:RFA and AN that candidates and their noms found me. I announced it well in advance and would mention it when appropriate in other places too. There were another 5 or so editors who explored a run at various levels of seriousness beyond the five who did, including John Wolfson who I would go on to nominate a few weeks after. I have been skeptical of doing another of these owing to the loss of two editors who I am not sure would have left the project absent the initiative and zero who passed who I think wouldn’t have run without it. However, based on the feedback given in this process, not to mention the data I found, if no reform passes that would rendered such an effort moot, including this one, I will commit to doing this a second time. Best, Barkeep49 (talk) 08:30, 2 November 2021 (UTC)[reply]
  2. I agree with Dennis Brown here. I also think candidates could end up being unable to participate in RfA just because they got unlucky. This really doesn't seem ideal to me, at all. InvalidOStalk 12:05, 1 November 2021 (UTC)[reply]
  3. The good part of #8B Admin elections is the election format, not the schedule. That's just a practical constraint on holding SecurePoll elections. If the only benefit is running at the same time as someone else, we can, and do, do that under the current system just as well. – Joe (talk) 12:25, 1 November 2021 (UTC)[reply]
  4. Agree with Dennis Brown. I wouldn't want a candidate to run because it's the right time window for others, if it's not suitable for them. Ritchie333 (talk) (cont) 14:13, 1 November 2021 (UTC)[reply]
  5. This seems like a solution without a problem. - wolf 17:01, 1 November 2021 (UTC)[reply]
  6. Nope, candidates shouldn't have to wait months to apply for access as the only path to adminship, and if this was simply an option instead of a replacement it can already happen now so no change is needed. — xaosflux Talk 18:15, 1 November 2021 (UTC)[reply]
  7. This seems like an extra rule that does not solve any problem. HighInBC Need help? Just ask. 01:07, 2 November 2021 (UTC)[reply]
  8. Definitely not. We don't need more rules that increase complexity without actually solving any of our existing problems. -FASTILY 05:42, 2 November 2021 (UTC)[reply]
  9. I can see a lot of downsides to this for candidates (who can't schedule their rfa at their convenience but have to do it at set times) and for voters (who have more work to review multiple candidates at once), and I do not think last September's flight went well at all, we lost editors, and I think it's because the flight format may have encouraged some to run who should not have run. Generally speaking, I'm not sure that lowering the barriers to entry is a good idea if we don't also lower the barriers to a successful exit. In other words, don't do things to encourage people to run if we're not going to lower the bar for passing. Levivich 15:40, 3 November 2021 (UTC)[reply]
    @Levivich: Which editors did we lose? As far as I can tell, all those editors are chugging along perfectly fine. 🐔 Chicdat  Bawk to me! 11:47, 7 November 2021 (UTC)[reply]
  10. Candidates should be able to schedule their RfA at their own convenience. — csc-1 21:47, 3 November 2021 (UTC)[reply]
  11. Per Joe: this takes the bad part of 8b and leaves out the good. Extraordinary Writ (talk) 23:12, 6 November 2021 (UTC)[reply]

Discussion (Quarterly elections)

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

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

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

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
There is no consensus to implement this proposal, with the numerical count at just under 50% support. Those in support largely echo the proposer in agreeing that it will reduce a perceived stigma and potentially make the title more informative (since a reader could see the size of gaps between RfA runs). Those opposed do not seem to think there is any major stigma attached to successive runs (i.e. it comes from the community) and that the new numbering system will actually reduce the information gained by the new naming convention as it will no longer be obvious if there were previous RfAs by the candidate. Primefac (talk) 09:12, 3 December 2021 (UTC)[reply]

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

Status quo:

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

Proposal:

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

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

  1. As proposer. This was one of my concerns before starting my first RfA, so perhaps I've found a convenient, simple improvement in the spirit of 5A's simplicity. It's not a huge change, but it may make a tiny positive difference.
    Edit: Sorry for the ambiguity. I had "every future RfA" in mind. I'm fine with moving the old ones as well, leaving redirects behind, if there's an additional consensus for that among the supporters. ~ ToBeFree (talk) 20:05, 6 November 2021 (UTC)[reply]
  2. These seems a simple, stigma reducing, solution. —¿philoserf? (talk) 20:29, 6 November 2021 (UTC)[reply]
  3. This is an interesting idea; it might help to some extent. – John M Wolfson (talk • contribs) 20:37, 6 November 2021 (UTC)[reply]
  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)[reply]
  5. Simple and worth trying; I would support moving previous RFAs for consistency reasons. — Wug·a·po·des​ 22:38, 6 November 2021 (UTC)[reply]
  6. At the very least, it would make page titles more informative. XOR'easter (talk) 22:40, 6 November 2021 (UTC)[reply]
  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)[reply]
  8. Sure. My preference would be using parentheses similar to how we disambiguate for articles. --Rschen7754 23:04, 6 November 2021 (UTC)[reply]
  9. 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)[reply]
  10. 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)[reply]
  11. 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)[reply]
  12. 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)[reply]
  13. 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)[reply]
  14. Per Joe. ProcrastinatingReader (talk) 22:24, 7 November 2021 (UTC)[reply]
  15. 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 (he/him | talk) 22:26, 7 November 2021 (UTC)[reply]
  16. 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)[reply]
  17. Support. I always prefer disambiguation by date over a counting number, the date means something. --SmokeyJoe (talk) 06:58, 8 November 2021 (UTC)[reply]
  18. Seems like an incremental improvement over the numbering system, per above. Levivich 14:40, 9 November 2021 (UTC)[reply]
  19. Support. I offer stronger support to the year with the month, but I also support the original proposal. This offers a good way to destigmatize multiple proposals.  Mysterymanblue  05:31, 12 November 2021 (UTC)[reply]
  20. Support with the condition of also adding a month and date, per EpicPupper and Djm-leighpark. We don't need to go back and change the old RFAs necessarily, but it would be helpful going forward. ReaderofthePack(formerly Tokyogirl79) (｡◕‿◕｡) 13:28, 12 November 2021 (UTC)[reply]
  21. Support per nom //Lollipoplollipoplollipop::talk 10:10, 13 November 2021 (UTC)[reply]
  22. Support I think that would be easier to categorise HelpfulPi (talk) 21:12, 14 November 2021 (UTC)[reply]

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)[reply]
  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)[reply]
    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)[reply]
  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)[reply]
  4. This is the most WP:SLOPpy proposal I have ever seen. I am astonished that anyone could ever support it. 🐔 Chicdat  Bawk to me! 11:28, 7 November 2021 (UTC)[reply]
  5. Weak oppose - Don't think this is going to fix anything, especially since a list of all of your prior RfA's is in a big box right at the top of subsequent RfA's (and in Special:PrefixIndex/Wikipedia:Requests for adminship/Example). That being said, so long as all the prior discussions are still prominent I don't really care what they are called - not sure if it will break some reports but we don't need to build around report writers. — xaosflux Talk 13:22, 7 November 2021 (UTC)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  11. Oppose per everyone else here. This is a solution looking for a problem. Kudpung กุดผึ้ง (talk) 23:06, 7 November 2021 (UTC)[reply]
  12. Oppose, I don't personally see a wide stigma concerning multiple RfAs. There would also be significant work to rename previous RfAs. JackFromWisconsin (talk | contribs) 15:11, 8 November 2021 (UTC)[reply]
  13. Oppose, makes it harder to find people's RfAs by typing in the URL, and the potential benefits are smaller than even this issue. —Kusma (talk) 13:29, 9 November 2021 (UTC)[reply]
  14. I think this is a net negative. This will make it harder to find individual RfAs and require much renaming. I also don't think this would solve the stigma from having multiple RfAs given that a previous RfAs will still show prominently in the "RfAs for this user" box in subsequent RfAs. -- Tavix (talk) 15:06, 9 November 2021 (UTC)[reply]
  15. Oppose. Impossible to watchlist a future RfA if the page name is no longer in sequential order but use the year instead. OhanaUnitedTalk page 17:42, 9 November 2021 (UTC)[reply]
  16. There is no reason to believe that this is a problem. GABgab 17:48, 9 November 2021 (UTC)[reply]
  17. On further reflection, I agree that this game isn't worth the candle. SoWhy explains well how no one is going to be tricked into missing the previous RfA, and the increase in the difficulty of watchlisting a future RfA is also worth noting. While the possible harm is small, the possible benefit is even smaller. Extraordinary Writ (talk) 19:01, 10 November 2021 (UTC)[reply]
  18. oppose went through all the support comments, but didnt read all the opposes. The suggestion is basically bought forward because of stigma/prejudice. But we do disclose previous RfAs in the current RfA, even if there was a namechange. So no matter what you do with the title, the previous RfAs will always be visible. No point in going through all the trouble. Keep it as it is. —usernamekiran • sign the guestbook • (talk) 21:35, 10 November 2021 (UTC)[reply]
  19. This is a solution in search of a problem. There's no reason to alter the longstanding title format of these pages, and there is no problem caused by the current format. Whoever is proposing things at this RfC should be required to explain what problem they're purporting to solve with each proposal. —⁠ScottyWong⁠— 06:20, 11 November 2021 (UTC)[reply]
  20. If one needs to check someones RFA it's a lot easier going from 3>1 than going from say 2019-2010 .... so from that perspective I have to Oppose, I agree to a certain point that there may be some stigma in the current numbering but as Xaosflux correctly points out previous RFAs are shown anyway so there's not much benefit to changing it from numbers to years. –Davey2010Talk 14:01, 11 November 2021 (UTC)[reply]
  21. Changing the name or letter string doesn't change the fact. You can't make a fart smell any sweeter by calling it a pètes, or a rose smell less sweeter by calling it a hồng. SilkTork (talk) 16:09, 11 November 2021 (UTC)[reply]
    @SilkTork: whats a pètes, and hồng? —usernamekiran • sign the guestbook • (talk) 08:42, 13 November 2021 (UTC)[reply]
    Alternative names. Pètes is French for fart, as in Le Pétomane, the fart maniac, but it sounds lovely. Hồng is from the Vietnamese for rose - Hoa hồng, and by itself conjures up "pong" and "honk", both slang terms for stink. They are words people would not know, so people would not have a connotation with them either positively or negatively - though the sounds and look of them may point us in a certain direction. However, once you start using them they take on the significance of the item they represent. Essentially, whatever you call a fart, it still remains a fart, and the word used will come to signify the fart and all connotations with it. The word or term used cannot change what it is referring to. What words can do is give us an initial impression of something, so we can be attracted or repelled by something because of unrelated associations with the word - like the word rape for Brassica napus, is quite unpleasant, with nasty connotations, while in reality a field of rape looks beautiful, so the word is not going to prevent us enjoying the view, and while we may not like the word, we use it ("Oh look, a field of rape"), and everyone understands what it represents, for good or bad. SilkTork (talk) 12:16, 13 November 2021 (UTC)[reply]
  22. Per SilkTork, unconvinced this will change anything. JavaHurricane 13:17, 13 November 2021 (UTC)[reply]
  23. Per above. Wouldn't solve any actual problems and would make our existing cataloguing system even more complicated than it already is. -FASTILY 01:10, 14 November 2021 (UTC)[reply]
  24. Oppose. The previous RfA is always going to be important, as one needs to see whether the candidate has fixed the issues identified. In addition to the cogent issues raised above, the current system has the feature that one can watchlist the redlink for editors whose editing behaviour one is very familiar with (either positively or negatively), which would need reconsideration. If this does pass, then I'd strongly suggest not moving old RfAs (a redirect in the new system could be used). Espresso Addict (talk) 03:20, 14 November 2021 (UTC)[reply]
  25. Oppose This way just seems more convenient. Scorpions13256 (talk) 00:22, 17 November 2021 (UTC)[reply]
  26. Oppose as per Scotty Wong; This is a solution in search of a problem.--Whiteguru (talk) 07:01, 29 November 2021 (UTC)[reply]
  27. Although the idea seems okay, it won't solve any real problem and will just add extra layer of unnecessary work. TheGeneralUser (talk) 04:01, 30 November 2021 (UTC)[reply]
  28. Oppose. Obfuscates useful information. Slightly less organized. And as someone mentioned above, makes it more difficult to watchlist future RFAs. –Novem Linguae (talk) 07:30, 30 November 2021 (UTC)[reply]

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

@Wugapodes: My reasoning for wanting to use slashes is because they are RfAs for the same user, and also makes it clear the name of the account and makes conflicts impossible. It's less important with years than with numbers, but still relatively important. It looks like you passed your first RfA, but lets say you had a second one at Wikipedia:Requests for adminship/Wugapodes 2. This could be an RfA for an account called User:Wugapodes 2. I don't think that specifically has happened before ever (an existing username with a single-digit number, both of whom have RfAed before), but there are RfAs for account names ending in numbers, and it is confusing. The new system (partially) addresses this, because instead it will be Wikipedia:Requests for adminship/Wugapodes 2021 and an account called User:Wugapodes 2021 would RfA at Wikipedia:Requests for adminship/Wugapodes 2021 2021- but I think slashes "bundle" them and look better than spaces which are unorganized and prone to conflicts. Plus, if no slashes, why not Wikipedia:Requests for adminship Wugapodes or just Wikipedia:Wugapodes' request for adminship?
I hope this sums up my thoughts. If you disagree please let me know. Naleksuh (talk) 22:59, 6 November 2021 (UTC)[reply]
Why not Wikipedia:Requests for adminship/2021/Example as the page name format? User:力 (powera, π, ν) 23:57, 6 November 2021 (UTC)[reply]
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)[reply]
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)[reply]

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

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)[reply]
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)[reply]
  • Use both, RfA count for the person (do not reset the count for change of username), and date of transclusion:
Wikipedia:Requests for adminship/Example 2 (2 February 2014)
--SmokeyJoe (talk) 06:06, 30 November 2021 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

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.

Closed: 3A Add clear criteria for users to start an RfA

SNOW closed as unsuccessful. Barkeep49 (talk) 16:14, 7 November 2021 (UTC)[reply]

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.

Extended content

A set of stringent criteria for RfA should be passed, for instance, at least:

  • 5,000 edits
  • 1 year of experience
  • One non-stub article creation or one case of significant article improvement
  • Twenty edits in preferred admin area
  • No active restrictions
  • No non-accidental blocks in the last year

If these standards are all passed, the regular seven days of !voting will occur. If they are not, the editor cannot proceed with RfA until the standards are met.

Discussion

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

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

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

Oppose. This seems like it'd encourage gaming the system, which is definitely something we don't need in RfA. InvalidOStalk 12:08, 1 November 2021 (UTC)[reply]
@InvalidOS: I can only assume you have misread the proposal. A candidate still has to pass a normal RfA under this proposal. They just additionally have to meet some minimum criteria to start an RfA. — Bilorv (talk) 12:29, 1 November 2021 (UTC)[reply]
@Bilorv: I didn't. Though, thinking about it a bit more, if someone did try to game the system to start an RfA, there'd probably be a WP:SNOW close so people wouldn't have to waste their time. InvalidOStalk 12:48, 1 November 2021 (UTC)[reply]
@InvalidOS: currently, we already experience WP:NOTNOWs as extended confirmed is the only (implicit) requirement to run. How would increasing the standards to start an RfA and leaving the standards to pass unchanged involve "gaming" in any sense, shape or form? It is not "gaming" to meet the minimum criteria exactly and then decide to run. That's just a perfectly reasonable course of action. If you can pass RfA, you haven't "gamed" anything, and SNOW closes could only decrease under this proposal. — Bilorv (talk) 12:56, 1 November 2021 (UTC)[reply]
@Bilorv: Fair point, though I was just saying that in the case someone did decide to try to game the system in some way, there'd likely be a SNOW close. Also struck out my original post. InvalidOStalk 13:05, 1 November 2021 (UTC)[reply]
  1. Strong oppose per the rest of discussion. I feel like this would have the effect of eliminating individual criteria, which would inappropriately make RfA seem like GAN or FAC. – John M Wolfson (talk • contribs) 13:37, 1 November 2021 (UTC)[reply]
  2. If this became policy, Wikipedia:Requests for adminship/Cyberpower678 2 would have failed. Ritchie333 (talk) (cont) 14:13, 1 November 2021 (UTC)[reply]
  3. This simply won't work, people will still have their own standards. Beeblebrox (talk) 21:22, 1 November 2021 (UTC)[reply]
  4. This isn't improving anything or increasing the number of quality admin. We have a long standing tradition of letting anyone run, and a long standing tradition of handling it just fine. I don't think we've ever "elected" a newb with 100 edits by accident, so this really doesn't solve anything. It will cause drama, however, as everyone has different ideas on what the criteria should be. This is good. We leave it wide open, and let them apply their own criteria by voting in the RFA. We know that system works. Dennis Brown - 2¢ 23:52, 1 November 2021 (UTC)[reply]
  5. We need to increase the number of admins, not create new barriers. We have never agreed on admin criteria, that is why RfAs are often full of different opinions. HighInBC Need help? Just ask. 01:08, 2 November 2021 (UTC)[reply]
  6. If we could agree on a set of criteria to pass RfA, then we wouldn't need RfA! Differing criteria and opinions, and the fact that they do not and cannot fully capture the entirety of a person's contributions and behavior, are why this can't work. As xaos says below, this looks like "criteria to start" not "pass," which isn't needed. ~ Amory (u • t • c) 15:30, 2 November 2021 (UTC)[reply]
  7. This is too prescriptive - there are countless edge cases where a candidate could well exceed some of these criteria while still missing one. This is the sort of thing that is most useful in a descriptive nature to warn candidates about what they may likely expect. — xaosflux Talk 11:01, 3 November 2021 (UTC)[reply]
  8. [DISCLAIMER: I'm the nominator] We need more admins, not fewer. 🐔 Chicdat  Bawk to me! 11:07, 3 November 2021 (UTC)[reply]
  9. What we don't need is prescriptive criteria. — csc-1 21:53, 3 November 2021 (UTC)[reply]
  10. I don't see how this is a positive for RfA. WormTT(talk) 11:24, 5 November 2021 (UTC)[reply]
  11. In the extended content the proposer suggests "we already have heterodox voters at RfA and I think this proposal would lessen their influence". My challenge to them is why? Anyone can edit WP, so why should unorthodox editors have less (opportunity to) influence in RfA than orthodox editors? Leaky caldron (talk) 12:31, 5 November 2021 (UTC)[reply]
  12. I don't think setting this many hard rules is a benefit to RfA. This may reduce the number of WP:SNOW closes, but I think it does not model what the community wants from a candidate well enough to be seen as a imposed prerequisites. Dreamy Jazz talk to me | my contributions 13:05, 7 November 2021 (UTC)[reply]

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

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

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.

Closed: 4A Opt-out sortition to nominate candidates

This proposal did not achieve consensus. (non-admin closure) --JBL (talk) 16:54, 1 December 2021 (UTC)[reply]

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.

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

Full details

The process is as follows:

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

Support 4A Opt-out sortition to nominate candidates

  1. Sounds good to me, I think many problems are surmountable.  – John M Wolfson (talk • contribs) 16:12, 31 October 2021 (UTC)[reply]
  2. Curious to see whether this will work. Worth a try. The problem of not having enough candidates is urgent enough to try more radical measures. Femke (talk) 16:54, 31 October 2021 (UTC)[reply]
  3. I support this idea in concept, though I'd potentially want to change the numbers of candidates and timeframe. Not entirely sure how. Trainsandotherthings (talk) 17:19, 31 October 2021 (UTC)[reply]
    I'm sure RfCs could change numbers/exact criteria if any prove to be a problem, but establishing a mandate for the sortition in some form is the most important priority. — Bilorv (talk) 19:07, 31 October 2021 (UTC)[reply]
  4. Worth trying. —valereee (talk) 17:20, 31 October 2021 (UTC)[reply]
  5. Strong support for an excellent proposal. Without some institutionalised/formalised process to encourage nomination, no method can improve on the existing system of a few highly-respected admins reaching out to individuals offering to nominate them, which has—due in no part to these admins—been an astounding failure in the last few years. We have had 10 RfAs in this calendar year, which have produced 6 currently-active admins ("active" generously construed), and we need at least 100 successful RfAs per year if we expect to maintain over 1,000 admins and expect every single new admin to contribute for the next 10 years and no admin to be desysopped.
    A sortition is a good way of eliminating human bias that arises from such things as a few elite admins being responsible for a supermajority of RfA nominations, to address 力 below, and could plausibly see a new diversity of admins promoted that would encourage existing editors who had never considered running ("I don't see why I'd want to be admin" / "I don't work in any of the 'admin areas'") to do so.
    The sortition also has very well thought out criteria, timings and associated processes, but I would be supporting it nonetheless if it didn't, as it is far more important to get some sort of process like this off the ground, and it can be refined as the community sees fit once we've had a couple of runs of it and understanding which criteria/bureaucracy can be improved upon. — Bilorv (talk) 19:07, 31 October 2021 (UTC)[reply]
  6. Qualified support on the condition that this be a one year trial, after which a subsequent RfC is required for it to continue. I think this is worth a try, but I'm uncomfortable with authorizing it and just hoping it works. I would like the community to have a chance to evaluate whether it worked and what changes could be made to improve it. — Wug·a·po·des​ 20:26, 31 October 2021 (UTC)[reply]
  7. Support As the proposer. Regarding HighInBC oppose comment, I would submit for consideration this MFD and {{User wikipedia/Administrator someday}}. As most people there agreed, most folks think that using the userbox which actively states you want to be an admin will most likely result in you not becoming one for longer (something literally written in WP:RFAADVICE). –MJL ‐Talk‐☖ 01:11, 1 November 2021 (UTC)[reply]
  8. The best leaders are the people who don't really want it. Dragging more people to RfA is a good system. Chess (talk) (please use {{reply to|Chess}} on reply) 03:35, 1 November 2021 (UTC)[reply]
  9. Support. But I am curious to know what the needs are to be qualified for being considered a Sysop candidate.Paradise Chronicle (talk) 05:04, 1 November 2021 (UTC)[reply]
    @Paradise Chronicle: have you read the "Full details" that propose the initial set of criteria? — Bilorv (talk) 12:58, 1 November 2021 (UTC)[reply]
    Now I have. Thanks. Seems fair. Paradise Chronicle (talk) 15:09, 1 November 2021 (UTC)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  13. This is a really good idea. --JBL (talk) 18:42, 6 November 2021 (UTC)[reply]
  14. Support at least a trial run. --SilverTiger12 (talk) 21:29, 7 November 2021 (UTC)[reply]
  15. Support But based on AfD and discussions the list will be small; as it is an unlikely combination of talents - NPP, AfD, FA, No blocks, x thousand edits, agreement that some current procedures is correct, ideological purity, Proposals, Village pump .. Suggest instead that selection of Opt outs be done by most active Wikiprojects by their members; they can choose who polices them and assign them a day each week to do so. Wakelamp d[@-@]b (talk) 10:37, 10 November 2021 (UTC)[reply]
  16. conditional support. Instead of five years clean backlog, it should be three. And the candidate should not be aloowed to ignore the RfA. Also, the process should be simple. Simply make a list of eligible candidates using a bot, ask them "yo, wanna run for RfA?": "Y/N". Rest of the advocate/no nom stuff seems good. —usernamekiran • sign the guestbook • (talk) 21:48, 10 November 2021 (UTC)[reply]
    struck my own vote after some thinking, and reading the oppse votes. —usernamekiran • sign the guestbook • (talk) 21:57, 10 November 2021 (UTC)[reply]
  17. Support, however you should be aware that some of the criteria you listed for potential candidates is not practically obtainable by an automated process. So, if your goal is to search through millions of users for those that meet these criteria, that almost certainly won't be possible (with an automated process) using the current set of criteria. In particular, an automated process cannot determine if a block was accidental, if a user is under any restrictions like interaction bans, or if the article a user created is a stub. —⁠ScottyWong⁠— 06:26, 11 November 2021 (UTC)[reply]
  18. I like much about this idea. Needs to be ironed out, but is the most exciting proposal I have yet seen to improve admin uptake. It sort of combines what we have now, with the original Jimbo, "no big deal", random selection of suitable people. I like that it is opt out, as many suitable candidates (and probably the best ones) hesitate to put themselves forward. Also that underlines that being an admin is a duty role on Wikipedia, not a privilege. People are being thanked for what they have done, and are being requested to do a little bit more. In the same vein as the donation requests that are made. As part of the ironing out of the proposal, there could be an option to not be selected, so a user who really doesn't want to be an admin, would not be part of the scheme, unless they later removed the opt out. Problems and hesitations with this proposal could and should be ironed out rather than the proposal dismissed simply because it's so radical. SilkTork (talk) 16:24, 11 November 2021 (UTC)[reply]
  19. Support - great way to field more qualified candidates. If the user does not want it, they can decline the nomination - no big deal.  Mysterymanblue  05:35, 12 November 2021 (UTC)[reply]
  20. Support - this worked in Ancient Athens :) Sortition as a procedure is a great way of solving the problem that sometimes people who want the tools aren't the ones who would wield them best. Ideally I would see it paired with temporary adminships. Alaexis¿question? 12:10, 12 November 2021 (UTC)[reply]
  21. Support - As long as the user can say no, I see nothing wrong with automatically proposing clearly experienced users. Fieari (talk) 00:32, 19 November 2021 (UTC)[reply]

Oppose 4A Opt-out sortition to nominate candidates

  1. I disagree with nominating candidates who have not indicating their willingness to serve prior to the nomination. I also feel the process is better served by having a dialogue with the candidate. I'd prefer a revived admin nominators wikiproject to use whatever criteria they want to find potential candidates, and then work with them on following the standard request process. isaacl (talk) 21:48, 31 October 2021 (UTC)[reply]
  2. The Jargon file story about Sussman and Minsky comes to mind. Randomness may cultivate a mystique for the process, but I see no reason it will find more or better admins. The community has struggled for decades to find reasonable criteria to determine adminabiles; if these criteria manage to find wide acceptance why not just write a bot to suggest a nomination to anyone who reaches the threshold? User:力 (power~enwiki, π, ν) 22:39, 31 October 2021 (UTC)[reply]
  3. The given criteria does not demonstrate suitability for being an admin. The most crucial criteria is that they want to be an admin. I don't believe the solution is closing our eyes and throwing darts at a list of names. As 力 suggests you could write a bot right now with no change in policy that suggests RfA to such people, go for it. HighInBC Need help? Just ask. 22:46, 31 October 2021 (UTC)[reply]
  4. Per 力 and HighInBC. I don't think it makes sense to nominate editors unless they have actually expressed an interest in being an admin. Having a bot inform editors that they might be good candidates seems like a better idea. Nosferattus (talk) 23:32, 31 October 2021 (UTC)[reply]
  5. RfA should be opt-in, not opt-out. No one should come back from a vacation in Hawaii to find out that they were involuntarily nominated for adminship, let alone read an RfA that sank like a rock and laid out all the reasons they weren't suitable for it, if they never wanted to serve in that capacity anyway. Adminship is a volunteer position, and so an RfA should only be initiated once the candidate has actually volunteered. Seraphimblade Talk to me 01:43, 1 November 2021 (UTC)[reply]
  6. Per Seraphimblade. Doesn't actually solve an existing problem, and I can't imagine this would be a good experience for anybody who gets sent on a surprise trip to RfA. -FASTILY 04:25, 1 November 2021 (UTC)[reply]
  7. Unimplementable as proposed. Not even one of the seven separate criteria can be automated, and each individually has far too many matches for the group as a whole to be done manually. —Cryptic 04:28, 1 November 2021 (UTC)[reply]
    @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 Wikipedia:Editing restrictions. For (7), you just need to test if Wikipedia: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)[reply]
    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 Wikipedia: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)[reply]
    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 [[Wikipedia:Articles for deletion/]] can be automated, but do you really intend to include people who only deletion sort with a script?
    7. Checking for [[Wikipedia:Requests for adminship/{{username}}]] 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)[reply]
  8. This pressures people to run for RFA and puts them in uncomfortable positions they don't want to be in. --Rschen7754 07:20, 1 November 2021 (UTC)[reply]
  9. Strongest possible oppose: RfA should be opt-in, not opt-out. Sure, find some automated way to get a list of all users that match these (or some other) criteria, but then talk to them to see if they would be interested in running for adminship. --rchard2scout (talk) 09:20, 1 November 2021 (UTC)[reply]
  10. I strenuously oppose any route to adminship that explicitly allows a candidate to ignore any questions by the community. There is, rightly, an expectation that candidates are responsive to its concerns. If people want to maintain VOLUNTARY, they should mandate that a candidate accepts the nomination instead of this baffling process where you're given a week to object. Sdrqaz (talk) 10:49, 1 November 2021 (UTC)[reply]
  11. Random? No, no, no. What if the user doesn't want to be an admin? 🐔 Chicdat  Bawk to me! 10:54, 1 November 2021 (UTC)[reply]
  12. Wow, just no. Many people who would quality prefer to stay out of the spotlight, and this could end up running people off the site. No. Not everyone wants to be an admin, or even noticed. Dennis Brown - 2¢ 11:39, 1 November 2021 (UTC)[reply]
  13. I think it would be a good idea to write a bot that would identify editors that meet your criteria and post a message on their talk page encouraging them to run. Or put them on a list or something. But nominate people without their explicit consent? Absolutely not. Can you imagine how you would feel if you took a break from Wikipedia for a few months, only to come back and find that in your absence, you'd been scrutinised by hundreds of fellow editors for a position you didn't even ask for? – Joe (talk) 14:46, 1 November 2021 (UTC)[reply]
  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)[reply]
  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)[reply]
  16. Basically drafting admins? No thanks. Beeblebrox (talk) 21:23, 1 November 2021 (UTC)[reply]
  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)[reply]
  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)[reply]
  19. I can't imagine that very many people would be pleased by a surprise nomination. LEPRICAVARK (talk) 06:33, 3 November 2021 (UTC)[reply]
  20. Opposing on the basis that it sets up a murky expectation that the candidates should ignore discussion or other interaction with the community - I'd expect opposition to rise along the "Won't answer my question that I'm concerned with", while leaving it vague to the closing 'crat if this is something that is expected to be discounted. — xaosflux Talk 10:57, 3 November 2021 (UTC)[reply]
  21. As per above, being willing to volunteer to do admin work is an essential characteristic of an admin, and this could discourage candidates from running without being randomly selected. — csc-1 21:54, 3 November 2021 (UTC)[reply]
  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)[reply]
  23. Among other concerns, this risks entrenching hard numeric criteria for adminship. * Pppery * it has begun... 18:31, 7 November 2021 (UTC)[reply]
  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 Wikipedia 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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  28. Oppose - IMO, potential admins should demonstrate an interest in the role and a requirement for having access to the toolset. The criteria could be used to identify possible candidate who can be sounded out. BennyOnTheLoose (talk)
  29. Oppose This could lead to all kinds of trouble: unworthy editors reaching adminship (which I would find undesirable even for a short tenure), admins that don't really care to do anything with their admin privilege's. Debresser (talk) 22:59, 8 November 2021 (UTC)[reply]
  30. Good idea in principle, but I disagree with the proposed criteria. Neutralitytalk 05:44, 9 November 2021 (UTC)[reply]
  31. Sortition § Incompetence should indicate to us why this is not a good idea. And as others have said, it contradicts the voluntary nature of this enterprise. On the other hand, I would have no objection to a bot choosing candidates through agreed upon parameters, after a person has indicated interest in the position through a userbox, list, or some sort. StonyBrook (talk) 22:15, 9 November 2021 (UTC)[reply]
  32. Oppose per Dennis and SpinningSpark - Not everyone wants to be an admin and my sentiments are the same as Sparks - I don't like the idea of forcibly nominating candidates either. –Davey2010Talk 14:07, 11 November 2021 (UTC)[reply]
  33. Oppose This is a volunteer project. Also, the criteria are way out of line with current standards at RFA; Even if you added the criteria that three of those active months have to be the last three months. My experience as a nominator is that potential candidates need a private chat not a public approach - plenty of candidates have a non obvious/private reason why now is not the right time for them to run. ϢereSpielChequers 16:59, 11 November 2021 (UTC)[reply]
  34. Oppose for all the reasons given above. MichaelMaggs (talk) 17:50, 11 November 2021 (UTC)[reply]
  35. Oh hell no. If I want the tools, I'll ask for them. RecycledPixels (talk) 08:42, 12 November 2021 (UTC)[reply]
  36. No. It's important that admins are true volunteers, not draftees who didn't manage to say no firmly enough. (Or were not at their computer!) Espresso Addict (talk) 03:30, 14 November 2021 (UTC)[reply]
  37. I generally like the concept of sortition, but it was already established that RfA has an unpleasant atmosphere and levels of scrutiny. Forcing people to go through that runs too much risk of a negative experience driving them away. Yes they can opt out, but I'm not sure all will fully understand the level of scrutiny that they might face. the wub "?!" 02:03, 17 November 2021 (UTC)[reply]
  38. As per Trainsandotherthings, Users have the right not to be admins. --Whiteguru (talk) 07:03, 29 November 2021 (UTC)[reply]
  39. This website is a volunteer project. There is no point in making people do something they don't want to, and no mechanisme to make them do it. Sandstein 20:15, 29 November 2021 (UTC)[reply]
  40. Oppose - This is a volunteer project and an editor must be able to freely decide on their own if they want to become an admin or not. Like other people have said, RfA should be opt-in, not opt-out. A person should always have the complete freedom of deciding on how and when they want to run for their RfA/RfB. TheGeneralUser (talk) 07:02, 30 November 2021 (UTC)[reply]
  41. Per my !vote on 4D. Extraordinary Writ (talk) 19:13, 30 November 2021 (UTC)[reply]

Discussion 4A Opt-out sortition to nominate candidates

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, –Davey2010Talk 20:44, 1 November 2021 (UTC)[reply]
@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)[reply]
(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)[reply]
@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)[reply]
@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)[reply]
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:Wikipedia 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)[reply]
  • 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)[reply]
    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)[reply]
    @Spinningspark: You wrote this comment and then 2 minutes later opposed a proposal below that is exactly what you suggested. --JBL (talk) 11:11, 8 November 2021 (UTC)[reply]
    That's not how I read the variant proposal. It says it is the same as 4A except the candidate must positively affirm. That reads to me like the nomination is made (which is what 4A says) but does not proceed any further until the candidate endorses the nomination. That's still got the same problem – the candidate is being put under pressure by a nomination being in esse rather than in posse. If that is not what the author meant then it is a poorly thought through, badly worded proposal thrown together in a hurry in a desperate attempt to save this crap proposal. SpinningSpark 14:17, 8 November 2021 (UTC)[reply]
    I have added clarification just for you. (I guess I should not be surprised that your response is to shift the goalposts and move to pure insult, given the evident bad faith with which you are engaging in the whole process.) --JBL (talk) 14:30, 8 November 2021 (UTC)[reply]
    Excuse me for giving an honest opinion. I don't believe this proposal is a good idea and neither are a lot of the others. It is not bad faith to say so, but it is extreme bad faith to accuse me of bad faith for doing that. What exactly do you think my bad faith agenda is here? SpinningSpark 16:32, 8 November 2021 (UTC)[reply]
    I think it is bad faith to say "I would support ..." when in fact there is nothing that could have been proposed here that you would have supported. And I think it's clear from your votes and comments here and on the talk page that that's the case. (Maybe I am using the phrase incorrectly; perhaps I should have just said that your contributions are dishonest and unconstructive.) --JBL (talk) 18:39, 8 November 2021 (UTC)[reply]
    Give it a rest with the personal attacks. I've made clear on the talk page what I would support. I am perfectly entitled to not support other proposals or ones that I think irrelevant. There is nothing dishonest in rejecting ALL changes if that is ones position. It's not my position, but it would not be dishonest to do that. To be clear here on my position relative to this proposal; I think it is fine to approach editors individually to find out how they feel about running for adminship. That can and does already happen. It's fine to run some kind of algorithm to find likely candidates. What is not fine is starting any kind of process, either formal or informal, BEFORE the potential candidate has agreed to it. SpinningSpark 17:46, 9 November 2021 (UTC)[reply]
  • How would accidental blocks be manually excluded? 🐶 EpicPupper (he/him | talk) 22:30, 7 November 2021 (UTC)[reply]
  • Aside from all the other objections, this has been done before, multiple times, with less stringent and more practical criteria. Two representative examples. They're consistently either so overbroad as to have no predictive value as to whether someone could pass RFA (as in the first), or so narrow as result in no more than a few dozen candidates. To my memory, none of them have ever produced someone who went on to pass an RFA. I'd expect the criteria proposed here - even if they were practical, and I maintain they are not - to have both problems: too few total matches, and too little relevancy to passing RFA. —Cryptic 06:03, 12 November 2021 (UTC)[reply]
    @Cryptic: You are not wrong. For me, the criteria matter less than the other parts of the process. I wanted to see an alternative process that would fundamentally change the dynamic present at RFA. While a lot of opposes feel otherwise, I genuinely think people would be a lot less cruel in a discussion clearly divorced from the candidate's initiative. I mean there obviously other problems present with 4A/4D sortition, but I did want to respond to the criteria concern just for my own sake. –MJL ‐Talk‐☖ 01:43, 20 November 2021 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Withdrawn: 4B Establish an optional admin school with approved curriculum

This idea may be discussed on the talk page

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

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

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

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

This idea may be discussed on the talk page

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

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

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

Closed: 4D Sortition variant

This proposal did not achieve consensus. (non-admin closure) --JBL (talk) 16:55, 1 December 2021 (UTC)[reply]

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.

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

Added 14:26, 8 November 2021 (UTC): apparently the meaning of (2) was not entirely clear. It replaces the sentence "Following the drawing, candidates would have one week before the RFA goes live to do a final opt-out." of 4A with "Following the drawing, candidates would have one week before the RFA goes live to affirmatively accept nomination."

Support 4D Sortition variant

  1. Sure. – John M Wolfson (talk • contribs) 14:03, 7 November 2021 (UTC)[reply]
  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)[reply]
  3. Support for the same reason that I supported 4A. — Bilorv (talk) 17:22, 7 November 2021 (UTC)[reply]
  4. Support at least a trial run. --SilverTiger12 (talk) 21:31, 7 November 2021 (UTC)[reply]
  5. Support as an alternative to 4A. –MJL ‐Talk‐☖ 23:19, 11 November 2021 (UTC)[reply]
  6. Support for the same reasons as 4A. Alaexis¿question? 12:15, 12 November 2021 (UTC)[reply]

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)[reply]
  2. No, for the same reasons as above. — xaosflux Talk 16:14, 7 November 2021 (UTC)[reply]
  3. As above, this can't possibly automate anything, because none of the criteria are automatable. —Cryptic 16:27, 7 November 2021 (UTC)[reply]
    @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)[reply]
  4. Per my oppose and those of many others at 4A. Trainsandotherthings (talk) 16:33, 7 November 2021 (UTC)[reply]
  5. Oppose. This still has the same problem. SpinningSpark 17:32, 7 November 2021 (UTC)[reply]
    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)[reply]
  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)[reply]
    @力: 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)[reply]
  7. Does not address my concern with the original proposal. * Pppery * it has begun... 18:31, 7 November 2021 (UTC)[reply]
  8. Does not solve the issues with the original proposal. HighInBC Need help? Just ask. 09:31, 8 November 2021 (UTC)[reply]
    What if the user doesn't want to be an admin? 🐔 Chicdat  Bawk to me! 10:57, 8 November 2021 (UTC) Vote struck. 🐔 Chicdat  Bawk to me![reply]
    @Chicdat: Then, by the simple method of not affirmatively accepting nomination, they will not become an administrator. --JBL (talk) 11:04, 8 November 2021 (UTC)[reply]
    @JayBeeEll: Even so, the only problem with RfA is that nobody wants to run. 🐔 Chicdat  Bawk to me! 11:06, 8 November 2021 (UTC)[reply]
    @Chicdat: I think that you should reconsider the behavior that is leading you to write rationales that suggest you haven't understood what you're voting on, let alone taken the time to consider their potential advantages and disadvantages. --JBL (talk) 11:10, 8 November 2021 (UTC)[reply]
    @JayBeeEll: You're right. I rushed through making my !vote. I've struck it now; my new one is below. 🐔 Chicdat  Bawk to me! 11:13, 8 November 2021 (UTC)[reply]
  9. This is a WP:SLOP. It is a proposal that solves no problem, and creates a few in itself. 🐔 Chicdat  Bawk to me! 11:13, 8 November 2021 (UTC)[reply]
    I guess it's better that you replaced a transparently ridiculous vote, made in haste, without reflection, and without engaging with any of the discussion with ... one that is all of those things except not transparently ridiculous? But maybe you could figure out how to un-bork the numbering in this section? --JBL (talk) 11:17, 8 November 2021 (UTC)[reply]
  10. Better but I don't think it solves the issues with 4A. The fact that someone meets these very bare-bones criteria doesn't mean they'd have any chance of passing RfA. Someone who accepted one of these auto-nominations and didn't do very well would likely have a very negative experience of the process and of Wikipedia generally. At least with a human nominator somebody has checked the candidate and thinks they have a realistic chance of passing.
    More generally, I don't think it's a good idea to try to solve the "not enough candidates" problem in isolation. There aren't enough candidates because prospective candidates don't think they'll pass, don't want to go through the process or don't want to be admins. If those problems were fixed then the number of candidates would go up. Keeping the process as unpleasant as ever and herding more people towards it won't solve much. Hut 8.5 17:55, 8 November 2021 (UTC)[reply]
  11. Per my reasoning in 4A -FASTILY 01:11, 14 November 2021 (UTC)[reply]
  12. Doesn't address my concerns with 4A. the wub "?!" 02:04, 17 November 2021 (UTC)[reply]
  13. Conscription / draft / mass cold-calling is directly repugnant to WP:VOLUNTARY. Leaky caldron (talk) 19:07, 18 November 2021 (UTC)[reply]
  14. I think Hut 8.5 summarizes the problems with this idea well. While it's an interesting concept, I don't think it would work as intended: large numbers of minimally qualified candidates would fail, exacerbating RfA's unpleasantness. Extraordinary Writ (talk) 19:02, 19 November 2021 (UTC)[reply]
  15. Oppose - Although this sortition variant is slightly different from 4A, the fact remains that this is a volunteer project and an editor must be able to freely decide on their own if they want to become an admin or not. Like other people have said, RfA should be opt-in, not opt-out. A person should always have the complete freedom of deciding on how and when they want to run for their RfA/RfB. TheGeneralUser (talk) 07:11, 30 November 2021 (UTC)[reply]

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 [list the qualities you care about here]". --JBL (talk) 18:22, 7 November 2021 (UTC)[reply]

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

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

Passed: 5A Revise standard Question 1

PASSED
Near-unanimous (taking into account the three neutral/abstentions) support to this proposal. RandomCanadian (talk / contribs) 04:26, 1 December 2021 (UTC)[reply]

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.


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

Support 5A Revise standard Question 1

  1. Sounds good to me.  – John M Wolfson (talk • contribs) 16:13, 31 October 2021 (UTC)[reply]
  2. This is a better way to ask the question. Admin candidates should not feel pressured to only work in certain areas, as experience shows the areas admins work in can and do change. This wording makes the question more about the candidate, which is how it should be. Trainsandotherthings (talk) 16:18, 31 October 2021 (UTC)[reply]
  3. I agree that this is a better question. Dreamy Jazz talk to me | my contributions 16:21, 31 October 2021 (UTC)[reply]
  4. Seems like an improvement over the current wording. Isabelle 🔔 17:16, 31 October 2021 (UTC)[reply]
  5. Sure, but don't want to set some precedent that future improvement of this area would need a multi-stage, multi-month RfC. — xaosflux Talk 17:24, 31 October 2021 (UTC)[reply]
    In theory none of the changes need a multi-stage RfC to pass. In reality large changes often take that process to form consensus. I certainly agree that this, and other similar tweaks, can happen successfully outside a process like this. It just so happened to come through in this process. Best, Barkeep49 (talk) 18:11, 31 October 2021 (UTC)[reply]
  6. I'd remove Q1 altogether, but I'm fine with revising it to this. —valereee (talk) 17:29, 31 October 2021 (UTC)[reply]
  7. Yes, that would work. – filelakeshoe (t / c) 🐱 17:33, 31 October 2021 (UTC)[reply]
  8. Good idea. – Joe (talk) 17:52, 31 October 2021 (UTC)[reply]
  9. Sensible. MER-C 18:16, 31 October 2021 (UTC)[reply]
  10. I support this non-controversial minor change. User:力 (power~enwiki, π, ν) 18:32, 31 October 2021 (UTC)[reply]
  11. A fantastic proposal from (I think) Barkeep49, which I have been waiting a week to properly praise. It directly addresses the statement that received widespread support in the first phase with a simple but effective wording change that still gives candidates the same (if not better) opportunity to communicate relevant thoughts they want RfA participants to know, but without the same implicit assumption of a requirement that the community no longer thinks is necessary for candidates. — Bilorv (talk) 18:35, 31 October 2021 (UTC)[reply]
    It is Wugapodes who wrote it as the idea emerged from the brainstorming process. I did propose it here so there would be an example proposal when the page went live. Best, Barkeep49 (talk) 18:48, 31 October 2021 (UTC)[reply]
  12. I doubt that this will cure RfA's problems in any real sense, but it is indeed incrementally better than the current wording. Extraordinary Writ (talk) 19:08, 31 October 2021 (UTC)[reply]
  13. Good idea. Certainly beats insisting on, or even inviting an additional self-nomination statement. Kudpung กุดผึ้ง (talk) 19:34, 31 October 2021 (UTC)[reply]
  14. CaptainEek Edits Ho Cap'n!⚓ 20:10, 31 October 2021 (UTC)[reply]
  15. — Wug·a·po·des​ 20:28, 31 October 2021 (UTC)[reply]
  16. Makes sense. DanCherek (talk) 20:59, 31 October 2021 (UTC)[reply]
  17. The difference to the current "What administrative work do you intend to take part in?" doesn't seem to be as large and meaningful as some of the support appears to imply, but it's fine. ~ ToBeFree (talk) 22:42, 31 October 2021 (UTC)[reply]
  18. A positive and sensible change. The fact is no user needs to be an admin, it is simply a way for them to contribute to the project in a different way. This question has always been loaded and I agree with the proposed change. HighInBC Need help? Just ask. 22:48, 31 October 2021 (UTC)[reply]
  19. Levivich 00:42, 1 November 2021 (UTC)[reply]
  20. Certainly an improvement in the current wording. Seraphimblade Talk to me 01:45, 1 November 2021 (UTC)[reply]
  21. Okay. --Rschen7754 03:51, 1 November 2021 (UTC)[reply]
  22. An elegant edit. I see it lowering the entry-point to the candidate's willingness without lowering the criteria for the candidate's responsibility. I don't see a downside. As of this datestamp, no opposes. BusterD (talk) 05:13, 1 November 2021 (UTC)[reply]
  23. Anarchyte (talk) 06:17, 1 November 2021 (UTC)[reply]
  24.  ― Qwerfjkltalk 07:12, 1 November 2021 (UTC)[reply]
  25. Support. MichaelMaggs (talk) 07:46, 1 November 2021 (UTC)[reply]
  26. I sincerely hope that this isn't the only thing that comes out for RFA2021, but yes. WormTT(talk) 08:40, 1 November 2021 (UTC)[reply]
  27. Any user running for adminship with enough experience, civility, and ability, by default, does have a need for the tools. 🐔 Chicdat  Bawk to me! 10:52, 1 November 2021 (UTC)[reply]
  28. Sounds good to me — Preceding unsigned comment added by Ritchie333 (talk • contribs) 14:16, November 1, 2021 (UTC) (diff).
  29. Sure - wolf 17:30, 1 November 2021 (UTC)[reply]
  30. Sounds great. However I must add that what bothers me more is not oppose !votes saying "no need for the tools" when the candidate isn't already doing admin-y things, but rather when the candidate is doing lots of admin-y things but they don't have significant mainspace edits or enough AfD !votes, etc., and people use that as a reason to oppose. Anyway changing the wording of Q1 as proposed I think can help this side of the issue as well, as it sort of broadens the scope of adminship. — MusikAnimal talk 18:02, 1 November 2021 (UTC)[reply]
  31. Support. Need for the tools is secondary to not being likely to misuse them. · · · Peter Southwood (talk): 18:24, 1 November 2021 (UTC)[reply]
  32. Sure, seems a worthwhile focusing. ~ Amory (u • t • c) 15:33, 2 November 2021 (UTC)[reply]
  33. LEPRICAVARK (talk) 06:33, 3 November 2021 (UTC)[reply]
  34. SpencerT•C 20:07, 3 November 2021 (UTC)[reply]
  35. Looks good. — csc-1 21:55, 3 November 2021 (UTC)[reply]
  36. Support: I think the proposed open question should prompt better answers. —¿philoserf? (talk) 00:34, 5 November 2021 (UTC)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  40. Meaningful edit. The new version seems more welcoming. 🐶 EpicPupper (he/him | talk) 22:31, 7 November 2021 (UTC)[reply]
  41. Seems reasonable. Djm-leighpark (talk) 00:23, 8 November 2021 (UTC)[reply]
  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)[reply]
  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)[reply]
  44. Concur. DS (talk) 14:36, 8 November 2021 (UTC)[reply]
  45. Support. JackFromWisconsin (talk | contribs) 15:18, 8 November 2021 (UTC)[reply]
  46. Yes. —pythoncoder (talk | contribs) 17:20, 8 November 2021 (UTC)[reply]
  47. Beeblebrox (talk) 18:11, 8 November 2021 (UTC)[reply]
  48. Agree. Neutralitytalk 05:32, 9 November 2021 (UTC)[reply]
  49. ProcrastinatingReader (talk) 10:19, 9 November 2021 (UTC)[reply]
  50. There is (and will) always be work to do. Just because there's little or no backlog now doesn't mean there won't be one in the future. OhanaUnitedTalk page 17:51, 9 November 2021 (UTC)[reply]
  51. Support. I really dislike "no need for the tools" opposes. Nobody needs the admin tools because none of us is indispensable and all of us can contribute productively without the tools. On the other hand, long term productive level headed editors who are willing to accept the tools and the responsibilities that go along with them should get the tools. I had no idea when I became an administrator that WP:UAA would be an area that appeals to me. A more open ended phrasing is better, because a frank, thoughtful response is more useful than a constrained response. Cullen328 Let's discuss it 01:36, 10 November 2021 (UTC)[reply]
  52. —⁠ScottyWong⁠— 06:32, 11 November 2021 (UTC)[reply]
  53. Support. –Davey2010Talk 14:15, 11 November 2021 (UTC)[reply]
  54. Yes. Or no question at all. Suitability and experience is what counts, not what motivates someone to do something. That is, well, a bit personal, and somewhat intrusive. People sometimes want to be an admin as a sense of wanting to help out on this project a bit more, to feel more involved, because this is the most significant thing ordinary people have done collectively since building the Hoover Dam or the Pyramids or Stonehenge. But asking people to reveal that can be a little embarrassing. It's enough that they have offered to do the work. And nobody is going to put: "I wanna be an admin because I wanna see blood and gore and guts and veins in my teeth. Eat dead burnt bodies. I mean kill, Kill, KILL, KILL." SilkTork (talk) 16:51, 11 November 2021 (UTC)[reply]
  55. Per SilkTork immediately above. Vanamonde (Talk) 17:21, 12 November 2021 (UTC)[reply]
  56. Support. This is always a very weak oppose reason on RFAs, I'd be glad to see it gone. //Lollipoplollipoplollipop::talk 10:15, 13 November 2021 (UTC)[reply]
  57. Support. Or even no question. Motivation is important but so many ultimately-desysopped-with-cause admins cheerfully went through RFA in days gone by talking about how enthusiastic they were and how ready they were to do certain tasks, who then did not focus on those tasks and turned out to have poor attitudes. FOARP (talk) 10:21, 14 November 2021 (UTC)[reply]
  58. A small but definite improvement. the wub "?!" 02:05, 17 November 2021 (UTC)[reply]
  59. It's an open question. It will bring interesting responses. --Whiteguru (talk) 07:07, 29 November 2021 (UTC)[reply]
  60. This is a very good change and I support it. TheGeneralUser (talk) 01:01, 30 November 2021 (UTC)[reply]
  61. Solid improvement, however small. Anyone ready to call consensus on this one yet? Retswerb (talk) 02:32, 30 November 2021 (UTC)[reply]

Oppose 5A Revise standard Question 1

Discussion 5A Revise standard Question 1

  • I'm not going to oppose this because I think it's harmless. But it seems to me that, to the extent that it'll impact "no need for admin tools"-esque opposition at all - its stated rationale - it's more likely to cause more of it than less. The current Q1 at least nudges candidates towards preemptively countering such opposition. —Cryptic 10:33, 9 November 2021 (UTC)[reply]
  • Per Cryptic. It would make a real difference if the community instructed Bureaucrats to give little or no weight to "no need for the tools" arguments. I'm not convinced that rewording Q 1 would make any difference. ϢereSpielChequers 17:06, 11 November 2021 (UTC)[reply]
  • Don't want to start an oppose section, but I don't think this is quite as wholly positive as the supporters appear to. The "No need for the tools" oppose is not going to go away and might, as Cryptic suggests, be exacerbated by the change. It also might encourage candidates to write non-specific statements about how much they love the Wikipedia concept, rather than to think carefully about which areas they are knowledgeable about or skilled in. As an aside, if this does pass, what is going to happen to optional questioners coming along and asking "What administrative work do you intend to take part in?" Espresso Addict (talk) 03:50, 14 November 2021 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

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.

Closed: 6A Binding recall criteria

Clearly did not achieve consensus RandomCanadian (talk / contribs) 23:02, 1 December 2021 (UTC)[reply]

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.


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

Full details

The process is as follows:

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

Support 6A Binding recall criteria

  1. Sounds good to me. Per the talk page, the effect of this is merely to prevent 'crats from refusing to abide by community consensus w/r/t desysopping criteria.  – John M Wolfson (talk • contribs) 16:14, 31 October 2021 (UTC)[reply]
  2. I'd support this, but I'd rather see a set of standardized binding recall criteria. —valereee (talk) 17:36, 31 October 2021 (UTC)[reply]
  3. Support as proposer. If someone wants to propose standardised recall criteria then feel free to do so separately, but I think the right path forward is a mandate for binding recall criteria, which would be groundbreaking. The fundamental issue we have that needs a formal RfC is that no recall criteria are enforced by crats, so candidates who want to set them can only pledge to follow them, and voters who want to support them are forced to either trust the candidate to act sensibly in a situation where they are unfit for adminship, or oppose because the criteria are not enforceable. This is the minimum viable proposal, with a lightweight stage of crat input to determine that crats can/will support the recall process in each case, and specific types of criteria approved/disapproved by the community ad hoc at each RfA (as opposing over someone for not being more easily recallable would be completely valid). — Bilorv (talk) 18:11, 31 October 2021 (UTC)[reply]
  4. (Moved from Oppose): One main problem with having many different recall criteria is the lack of standardization. In wikis with a standardized recall procedure for all administrators, recalls regularly happen because upset editors know which path to universally take to vote for a recall, and because every editor knows about the effectivity of that process, and because it is always properly enforced. The proposal does not provide the necessary standardization. It does not even enforce having recall criteria at all. But that's okay for now. At least it is an improvement per Bilorv's points. ~ ToBeFree (talk) 17:16, 31 October 2021 (UTC)[reply]
  5. Per Bilorv and TBF, this would be an incremental improvement, and there seems little downside of trying it. Levivich 00:41, 1 November 2021 (UTC)[reply]
  6. Per Bilorv. And per Valereee I'd also like to see a set of standardized binding recall criteria.Paradise Chronicle (talk) 05:21, 1 November 2021 (UTC)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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 (he/him | talk) 22:43, 7 November 2021 (UTC)[reply]
  11. Though this may seem like it would reduce the number of admins, I have a feeling that recall criteria may actually help retain them in the long run, in terms of editors becoming more interested in trying admin status out. It would have to be stringent - none of us wants to see admin status passed out like a free sample at the supermarket - but offering the potential for admin status to expire in whatever amount of time, and then asking after this period if they'd like to consider admin status for a longer period of time, such as ten years or indefinitely, may increase comfort with potential admin status and increase interest, too. Give people an easier in and an easier out, and it reduces stress for all involved, making it altogether a more comfortable experience that I'd hazard a guess to increase admin retention and admin numbers.
    Asking to be desysopped at the minute feels like it'd give editors an aura of shame, whereas rolling recall criteria into part of the process of becoming, staying or leaving administrator status would remove this shame to a degree, if not entirely, as it'd be a respected choice that would not put editors in the same league as those desysopped for violations of rules. I don't like the comparison of try before you buy, but I wonder how many editors may decide to stick around and commit to a longer period of admin status following a short, maybe one or two year period of such permissions. I know I'd actively consider it, whereas before I would never have considered an RfA. I don't think I'm alone in holding this view, and as such, I support this proposal.--Ineffablebookkeeper (talk) 14:20, 10 November 2021 (UTC)[reply]
  12. This is a neat idea. It would add "teeth" to the recall process, but still give us the flexibility to experiment with different recall criteria to see what works and what doesn't. That could help to lay the groundwork for an eventual community desysop process applying to all admins. Tim Smith (talk) 00:39, 24 November 2021 (UTC)[reply]

Oppose 6A Binding recall criteria

Moved to support. ~ ToBeFree (talk) 22:44, 31 October 2021 (UTC)[reply]
  1. This will only reduce the number of admins we have. Enforcing policy is not always a popular decision and it should not come down to criteria set out when the admin is at their lowest level of experience. There is a list as long as my arm of admins who have been desysopped with our existing process, it is a myth that admin is a lifetime tenure.
    Our desysop criteria is a careful analysis of behavior and how our policies and community norms relate to it and it is called ARBCOM. You are an admin until you do something that gets your mop taken away, or stop using it for a year. The 'crats have already made it clear they do not want to be in charge of determining if arbitrary criteria has been met. Binding recall criteria will create a whole new barrier to becoming an admin and we will have even less.
    This is also unfair to new admins because of the huge amount of old timers who get to be an admin without these criteria. HighInBC Need help? Just ask. 22:53, 31 October 2021 (UTC)[reply]
    @HighInBC: The 'crats have already made it clear they do not want to be in charge of determining if arbitrary criteria has been met – in this proposal, crats are contacted in advance of the RfA to agree that they are willing to enforce the criteria, which must be objective and enforceable (the opposite of arbitrary). If they do not want to determine if the criteria are met then they will reject them. The intention is that criteria are so obviously objective that any uninvolved bureaucrat should be able to determine uncontroversially whether they are met (it is no more difficult than determining to desysop for inactivity). — Bilorv (talk) 23:09, 31 October 2021 (UTC)[reply]
    Have any 'crats indicated that they would want to take this task on? Because as I have said they have indicated in the past that they are not willing to make judging binding recall part of their responsibilities. HighInBC Need help? Just ask. 23:19, 31 October 2021 (UTC)[reply]
    If this passes with substantial consensus and existing bureaucrats aren't willing to enforce it, it should be straightforward to promote new bureaucrats running on a platform that they are willing. —Cryptic 03:20, 1 November 2021 (UTC)[reply]
  2. The bureaucrats have already made very clear that they are unwilling to take on the role of judging or enforcing recalls. Unless they have changed their position with respect to that, we would be telling participants that the criteria are binding when in fact no one will enforce them. Seraphimblade Talk to me 01:47, 1 November 2021 (UTC)[reply]
  3. I was skeptical about fully bespoke criteria, and with at least one bureaucrat on the record against it I'm going to oppose. I might support a similar proposal with a small set of permissible recall criteria that would get pre-approval from the community (and bureaucrats). User:力 (power~enwiki, π, ν) 02:19, 1 November 2021 (UTC)[reply]
  4. Candidates already have the option to choose to be open to recall, I don't see what codifying this accomplishes. And with others stating above that the bureaucrats are unwilling to be the recall police force, this is impossible to enforce anyhow. Trainsandotherthings (talk) 02:21, 1 November 2021 (UTC)[reply]
    @Trainsandotherthings: candidates do not have the option to be open to binding recall, and indeed there have been instances in the past of people who simply refuse to abide by their recall criteria when the conditions are met (example given below). The point is to make recall binding, and this is the minimum viable codification to do this. If the crats are "unwilling" to enforce the criteria then they will simply reject them when a candidate requests them to. — Bilorv (talk) 11:39, 1 November 2021 (UTC)[reply]
  5. This could result in de facto bullying: "Oppose unless you agree to XYZ". --Rschen7754 02:41, 1 November 2021 (UTC)[reply]
  6. Not the right way to go about removing adminship. Forcing arbitrary processes onto people that haven't even got the tools yet will just make the process more hostile. We need to discuss reconfirmation RfAs and non-ArbCom sysop removal instead. Anarchyte (talk) 06:19, 1 November 2021 (UTC)[reply]
  7. We need more admins, not fewer! 🐔 Chicdat  Bawk to me! 10:50, 1 November 2021 (UTC)[reply]
  8. Unenforceable in a fair way. People have different criteria, and to enforce it, Crats would have to interpret individual "rules" which may or may not always be clear. If I were a Crat, I would refuse to participate in a recall petition because of this. Dennis Brown - 2¢ 11:25, 1 November 2021 (UTC)[reply]
    @Dennis Brown: I don't understand this comment. The proposal involves consulting the crats in advance, who must agree that the criteria are objective and enforceable (hence, not "may not always be clear"). How would a situation arise that the crats are asked to judge something unclear? — Bilorv (talk) 11:42, 1 November 2021 (UTC)[reply]
    They may not be the same crats. · · · Peter Southwood (talk): 18:33, 1 November 2021 (UTC)[reply]
  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)[reply]
    @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)[reply]
    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)[reply]
  10. I agree with Rschen7754. At my own RfA I felt pressured into being open to recall (Q4). I never wrote my criteria, as the whole concept of optional recall seems off to me. !Voters should support candidates because they trust them, not because of some criteria the 'crats may or may not actually enforce, or the candidate may or may not abide by. I think there should be standard recall criteria for everyone or none at all. — MusikAnimal talk 18:21, 1 November 2021 (UTC)[reply]
  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)[reply]
    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)[reply]
  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)[reply]
  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)[reply]
  14. I got rid of my recall criteria because it is a useless process --Guerillero Parlez Moi 10:26, 2 November 2021 (UTC)[reply]
  15. per Anarchyte. Isabelle 🔔 16:15, 2 November 2021 (UTC)[reply]
  16. I think a recall process would be fine, but not this one. Specifically, all of the mandatory secret prescreening and approval by bureaucrats parts here are a no go for me, not just as a 'crat - but because these shouldn't require any secret proceedings. I'd prefer a standard community-wide recall criteria. — xaosflux Talk 10:52, 3 November 2021 (UTC)[reply]
  17. I don't believe we should be encouraging the creation of bespoke recall criteria, any community recall process should be universal. — csc-1 22:05, 3 November 2021 (UTC)[reply]
  18. Recall is inherently a mess. ArbCom is very effective at removing admin access when necessary, and sometimes when not. Jehochman Talk 08:11, 5 November 2021 (UTC)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  22. Oppose. DS (talk) 14:20, 8 November 2021 (UTC)[reply]
  23. Oppose. Having the tools doesn't mean you need to use them. If a person is no longer interested in using the tools, they can resign. And if an admin were to abuse them, they would be blocked fairly quick. Lifetime tenure reduces bureaucracy (not having to run yearly RfAs), and allows Admins to make difficult decisions without a threat of their tools being stripped away. Making bad decisions would get their tools stripped away by our current processes anyway, and we don't need another way to remove admins, since this big RfC is about the opposite. JackFromWisconsin (talk | contribs) 15:23, 8 November 2021 (UTC)[reply]
  24. Pressure to commit to recall criteria would be very unhealthy for RFA. GABgab 18:26, 9 November 2021 (UTC)[reply]
  25. I like the idea of a standardized recall criteria, but this is not that, because it's optional and can be "bespoke", it would only add more complexity to the process. ASUKITE 16:35, 10 November 2021 (UTC)[reply]
  26. Pretty much per Rschen7754 and GAB, noms should not feel compelled to commit to arbitrary recall criteria. Cavalryman (talk) 01:40, 11 November 2021 (UTC).[reply]
  27. More bureaucracy won't help anything. —⁠ScottyWong⁠— 05:57, 11 November 2021 (UTC)[reply]
  28. Oppose per Kudpung & Dennis - Barely used process. –Davey2010Talk 14:24, 11 November 2021 (UTC)[reply]
  29. It's a no from me. SilkTork (talk) 16:52, 11 November 2021 (UTC)[reply]
  30. The first example given isn't even a recall criteria, it is a term length. Things change over the years, as do interests. A recall criteria of "I will hand in the mop if five of the ten most active admins at AIV support this" might make sense for an admin who starts out entirely focussed at AIV, but would look dated if three years later they are mostly a sock hunter. ϢereSpielChequers 17:12, 11 November 2021 (UTC)[reply]
  31. Per above. At best, this could lead to increased bullying, at worst, extortion. Bad idea. -FASTILY 01:25, 14 November 2021 (UTC)[reply]
  32. Having been involved in a desysopping via Arbcom, it does seem to work. I do not see how having a recall system instead/on-top of this adds anything. There seems to be pressure on nominees to accept re-call because they're afraid people will oppose them if they don't accept it. Quite what will happen if someone accepts the re-call criteria and then later on says "actually, no, I'm not going to just quit because of this recall petition, y'all have to take me to Arbcom" is not clear. The real problem is the "super-mario" problem where admins just get desysopped for bad behaviour that would otherwise have seen them banned, but this does not address that. FOARP (talk) 09:05, 14 November 2021 (UTC)[reply]
  33. Not convinced that bespoke recall criteria, whether binding or not, really help to address the problem. Additionally although the example criteria in the proposal are very straightforward, I looked at a few random examples from Wikipedia:Administrators open to recall/Admin criteria and many are far more complicated e.g. User:Lar/Accountability. I don't think it's fair to put it on bureaucrats to decide if these criteria and processes are "objective and enforceable", and the comments here and at BN suggest they don't desire this extra burden either. the wub "?!" 02:06, 17 November 2021 (UTC)[reply]
  34. Oppose - This would clearly be a very bad idea. Every editor would have their own arbitrary recall criteria which could be completely different from others. Also, an RfA is about finding the suitability of a person as an admin and a forced binding recall is a completely unrelated and counter productive idea to that. We all are here looking for ways to make the process easier and stress free for all potential candidates and this would be completely opposite of that. TheGeneralUser (talk) 03:01, 30 November 2021 (UTC)[reply]

Discussion 6A Binding recall criteria

  • Recall criteria are something which I proudly have, and will stick to. I'm unsure if making them unchangeable makes this a good idea as with change that will always come the recall criteria may need to be updated. For example, a user right mentioned in the recall criteria may cease to exist. Without having a way for the criteria to be changed, they could over time become un-useable. As such I'm not voting support unless there is a way to change the criteria. Such a way should include community discussion to make the change. If there was a way to change them, I would be supporting this. Dreamy Jazz talk to me | my contributions 16:51, 31 October 2021 (UTC)[reply]
    • @Dreamy Jazz: make a suggestion of the most lightweight process through which they could be changed (a discussion at AN? a new process at RFA?). Proposals can be altered within the first seven days and if no supporters object to the changes then we could introduce a measure to change the criteria, other than the method that would be available by default: run a reconfirmatory RfA with new recall criteria. — Bilorv (talk) 18:11, 31 October 2021 (UTC)[reply]
  • I strongly support the concept of admin recall. That being said, I haven't opted-in to recall because I find the whole process weird and complicated and confusing. There should be a standardized, mandatory, community-based admin recall process. WP:DESYSOP2021 failed, but it's worth putting the effort into figuring out why it failed and coming up with a better proposal. -- RoySmith (talk) 17:47, 31 October 2021 (UTC)[reply]
    PS, orthogonal to this discussion, I was just granted that most coveted of collectable hats, admin on testwiki. And what I discovered is that my mop is temporary ("Expires 17:35, 31 October 2022"). I didn't even know admin rights could be granted with a time limit in the currently software, and I'll bet most people didn't know that either, so mentioning it here as a PSA. -- RoySmith (talk) 17:56, 31 October 2021 (UTC)[reply]
    If you look at the archives for meta:SRP, you can see that on most small projects (the ones that don't have local 'crats), temporary adminship happens regularly. Some projects are apparently small enough to not even require a permanent administrator. --rchard2scout (talk) 09:31, 1 November 2021 (UTC)[reply]
    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)[reply]
    Ditto. I'm totally open to recall, have it as a category on my user, but I have zero idea what to put down as criteria. Levivich and EEng both tell me it's time to hand in the mop? —valereee (talk) 20:42, 31 October 2021 (UTC)[reply]
  • An unnecessary layer of buraucracy. Kudpung กุดผึ้ง (talk) 19:39, 31 October 2021 (UTC)[reply]
    @Kudpung: I'm confused about what this means you think about recall in general. Do you think the whole thing is a waste of time? That recall is fine as is, where an admin decides whether or not to stand by their own criteria after the conditions are met? Or that a standardised process could have less bureaucracy than this specific proposal? — Bilorv (talk) 19:43, 31 October 2021 (UTC)[reply]
    Bilorv, I haven't stated what this means I think about recall in general. I would have thought however, that an admin who subscribes voluntarily to their own recall criteria would abide by them. Kudpung กุดผึ้ง (talk) 20:03, 31 October 2021 (UTC)[reply]
    Sadly, there is historical precedent of admins not abiding by objective recall criteria once they are met. Here's a statement by an admin deciding to simply ignore the outcome of a successful recall discussion about them in 2008, and they remain an admin today. (If you think 2008 is too long ago, take a look at Wikipedia:Administrators open to recall/Past requests: very few recall attempts have been started since 2010, because the community understand that recall is useless with no power of a crat to enforce it.) — Bilorv (talk) 20:32, 31 October 2021 (UTC)[reply]
    Bilorv, I'm possibly more confused than you are, but probably because I did some research. What's not been mentioned, and is glaring by its absence, is the number of desysopings where the community didn't ask an admin to answer to his or her recall criteria, and just covered him/her with tar and feathers and dragged him/her straight to Arbcom. !Kudpung กุดผึ้ง (talk) 07:00, 1 December 2021 (UTC)[reply]
  • I've gone ahead and started a thread at WP:BN asking for an opinion on whether bureaucrats would be willing to enforce this. User:力 (power~enwiki, π, ν) 01:52, 1 November 2021 (UTC)[reply]
  • 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)[reply]
Agree to some extent with SmokeyJoe. Admins should for the most part be indistinguishable. Abiding by the same recall criteria, which inevitably means community imposed recall criteria (or none) is a major component of ensuring all admins are much the same. To do otherwise invites WP:ADMINSHOPping. I don't see that Arbcom needs to be the only route. Cabayi (talk) 10:02, 14 November 2021 (UTC)[reply]
  • I've always opposed recall because it asks too little of admins behaviourally, and too much of their time. If a community member has issues with my use of the tools, I feel obligated to listen and act accordingly. I will never set recall criteria because I believe it sends the message unless you get enough people on your side, I'm not going to listen. We need enforceable standards for admin behaviour, ones that anyone dragging an admin to ANI can point to. (WP:ADMINCOND isn't much help - it basically says "don't do things that other editors wouldn't get away with".) If we had more clearly defined standrds, iadmins who chose not to abide by them would have the option to resign, or we can ask the arbcom to decide. Recall, in my opinion, sets procedural standards for removal, not positive standards for behaviour. Guettarda (talk) 21:02, 13 November 2021 (UTC)[reply]

Crat comments on their role

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

  • Bureaucrats will decide on a way for them to be contacted privately e.g. by a centralised email. & A candidate who wants to be open to recall may contact them in advance of their RfA, laying out their recall criteria.
    We closed down the bureaucrat mailing list a while back, and it was never used for creating consensus (towards the end it was only for renames, and few crats did them from there). Crat's don't work as a committee, it's an individual thing, so I'm reluctant to start it back up. WormTT(talk) 09:18, 1 November 2021 (UTC)[reply]
    The community has on more than one occasion failed to agree a generic recall process. Delegating the decision to crats, and then asking us to determine it secretly, is not a process conducive to maintaining community confidence in the crat cadre. ϢereSpielChequers 17:24, 11 November 2021 (UTC)[reply]
  • The bureaucrats decide among themselves whether the criteria are objective and enforceable. & If they privately approve the criteria, the candidate can start an RfA with these criteria as public, unchangeable and binding if the RfA passes.
    So the crat's decide if the criteria is good enough? Not as written. The crat's role is to weigh consensus - we'd need something measurable that the crats can see if it works against. WormTT(talk) 09:18, 1 November 2021 (UTC)[reply]
    Objective and enforcable is not the same as "good enough", "likely to be useful" or even "relevant". "Desysop me if AOC becomes President of the USA or I change my username to a word that is obscene in Old Norse.", is objective, enforcable and about as much use as a chocolate tea pot. ϢereSpielChequers 17:34, 11 November 2021 (UTC)[reply]
  • When recall criteria are met, any user can notify the bureaucrats at Wikipedia:Bureaucrats' noticeboard with evidence that the criteria are met; any bureaucrat can verify this and remove admin rights.
    I have no issue with this part. WormTT(talk) 09:18, 1 November 2021 (UTC)[reply]
    Me neither, though I'm assuming that if the first crat to respond says at the crat noticeboard "criteria not met for reason x" another crat may disagree and question that or start a crat chat but not simply perform the desysop. ϢereSpielChequers 17:42, 11 November 2021 (UTC)[reply]
  • If a user has adminship removed by recall, they may only regain adminship through the standard process for non-admins.
    Nor this part, which is not really crat based. WormTT(talk) 09:18, 1 November 2021 (UTC)[reply]
@Worm That Turned: I don't understand why "objective and enforceable" are not "measurable" and, themselves, two objective criteria? The role would not be to say "these recall criteria do not meet community standards"—that's part of what participants would vote on at RfA—just to say "if the community agreed on this then it's logistically possible to implement". This is no different to if we gave specific recall criteria to choose from and the crats were consulted to say "yes, we would be willing to do this", except that it would be done on a case-by-case basis. As for the reason the system needs to be private, this is because candidates would object to it being public, as it gives the game away that they are about to run for RfA (and you'll have noticed as surely as I have that very few people are comfortable publicly declaring in advance when they are about to run for RfA). — Bilorv (talk) 11:36, 1 November 2021 (UTC)[reply]
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. WormTT(talk) 12:31, 1 November 2021 (UTC)[reply]
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)[reply]
The objections include that our problem is too few admins not too many, and something that reduced our number of admins arbitrarily would mean we had to cut more slack for marginally problematic admins because we couldn't afford to lose them. Solutions that would make sense if our number of mops was limited are not so helpful when our shortage is admins not mops for admins. ϢereSpielChequers 17:24, 11 November 2021 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Closed: 6B Desysop at AN(I)

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
There is clear opposition to this proposal at nearly 3:1 against. Primefac (talk) 09:18, 3 December 2021 (UTC)[reply]

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

Support 6B Desysop at AN(I)

  1. Sounds good to me. I think "bad-faith desysops" are far more a moral panic than an actual issue, and admins are nowhere near combat veterans.  – John M Wolfson (talk • contribs) 16:14, 31 October 2021 (UTC)[reply]
  2. I'd support this, given details can be worked out. —valereee (talk) 17:35, 31 October 2021 (UTC)[reply]
  3. Support as proposer. If admins can be elected by the community then the community must also be able to decide to remove admin permissions. It is insane that the community do not have this right. The proposal is relevant to the theme of this RfA review because much opposition and toxicity in RfA comes from a group of users who believe that admins are unaccountable and unable to be desysopped except in the most extreme cases, and therefore hold candidates to excessive standards (they need to prove that, even in 15 years, they will not be acting in a way that the community will oppose).
    The proposal is an extension of the existing processes we use in some cases to remove PERM-given rights and instate topic bans, interaction bans, or temporary or indefinite blocks. It, however, asks for substantially more scrutiny to prevent abuse: three administrators closing the discussion, which is now a common closure method for large-scale contentious RfCs that have much larger mandates than removing adminship from one user who can regain it with a successful RfA at any time.
    To support this proposal, you do not need to believe AN(I) is a good judge of community consensus. You only need to believe that if it achieves a mandate to remove adminship then an admin should be re-scrutinised by the community—as they are welcome to immediately stand for RfA again and will be reinstated if the community actually do support them (and this is the default appeal process). — Bilorv (talk) 18:30, 31 October 2021 (UTC)[reply]
  4. Weak support as noted in the discussion, I would strongly prefer these discussions to not be on WP:AN/WP:ANI, but a follow-up ANI reform RFC can hopefully fix that. The main question is "should the community be able to vote to de-sysop for any reason, or indeed no reason at all"? (to a certain extent, there is no distinction between voting to require a recall election, and voting for a de-sysop that can be over-ridden by a new consensus at RFA). A similar proposal failed earlier this year, and I doubt this one will do any better. But my personal vote is yes, the community should be able to do so. User:力 (power~enwiki, π, ν) 23:03, 31 October 2021 (UTC)[reply]
  5. Per Bilorv. If ANI can handle tbans and sitebans, then it can handle desysops, too. I never understood why desysop should be essentially exempt from the consensus process. We can use consensus discussions to make major decisions like end IP editing or banishing an editor or deleting a page, but not for -sysop? I just don't believe it. Levivich 00:40, 1 November 2021 (UTC)[reply]
  6. Don't think this really changes RfA, but support in principle because AN can siteban any editor, and it can strip any permissions other than +sysop, so I don't see why it can't -sysop. If AN is broken, why should only admins be exempt from its brokenness? Fix AN. If AN isn't broken, then there's no reason it can't handle -sysop. ProcrastinatingReader (talk) 14:15, 1 November 2021 (UTC)[reply]
  7. Support in principle; although I think we need to clarify exactly what "consensus" means, in general I trust the community to come to the right decision. Ritchie333 (talk) (cont) 14:18, 1 November 2021 (UTC)[reply]
  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)[reply]
  9. If longtime editors can be blocked at the Great Dismal Swamp, than so can admins be de-sysopped. It may be a cesspit, but that's a reason why ANI should be reformed, not why de-sysopping should be exempt from community consensus. — csc-1 22:08, 3 November 2021 (UTC)[reply]
    However, taking note of the lack of full community involvement at ANI, such a discussion should have to be listed on WP:CENT and run for 7 days just like an RfA. — csc-1 22:16, 3 November 2021 (UTC)[reply]
  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)[reply]
  11. Would prefer somewhere other than AN/I, but this is a good start. 🐶 EpicPupper (he/him | talk) 22:33, 7 November 2021 (UTC)[reply]
  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)[reply]
  13. Support I understand that there are no clear criteria. On the other hand, the criteria are obvious: a pattern of conduct unworthy of an admin. Since such a measure is long overdue, I am in favor! Should time show that there is need for more precise criteria, which I doubt, these can be worked out later. Debresser (talk) 23:03, 8 November 2021 (UTC)[reply]
  14. Support It seems clear at this stage of the discussion that this proposal probably will not pass. So my "Support" is moral or symbolic or whatever. I believe that if an ANI discussion is so persuasive that three uninvolved administrators agree to close the discussion as consensus to desysop, then that consensus ought to be implemented. I know that it is fashionable to bash ANI as cruel and unusual punishment but I happen to believe that ANI gets things right most (but not all) of the time. A community process that determines that Person A is no longer able to be an administrator on an online encyclopedia is bound to be painful to Person A, if they really want to edit as an administrator. I am 69 years old and acutely aware that people my age sometimes lose their mental acuity fairly rapidly. If three uninvolved administrators came to me and said I was no longer making good decisions, I would retire on the spot. Cullen328 (talk) 07:49, 29 November 2021 (UTC)[reply]
  15. In principal support, I think any desysop proposal would take some pretty strong evidence to be successful but I see no reason why not. Cavalryman (talk) 08:57, 1 December 2021 (UTC).[reply]

Oppose 6B Desysop at AN(I)

  1. Too little detail on some fairly relevant aspects, but also doesn't handle that it's not that there would be many problematic cases, but any problematic cases that an ArbCom wouldn't have suffered from is too many. Nosebagbear (talk) 16:25, 31 October 2021 (UTC)[reply]
  2. I don't see any reasons why arbcom cannot handle this. It is not often that admins are desysopped for cause. I'm also concerned that this proposal leaves no method of appeal and could lead to frequent spurious attempts to desysop admins. Trainsandotherthings (talk) 17:00, 31 October 2021 (UTC)[reply]
  3. Per the above, and per my previous opposition at the RfC about this a while ago. I see no evidence that ArbCom or the 'crats can't handle this on their own. RandomCanadian (talk / contribs) 17:04, 31 October 2021 (UTC)[reply]
    What do you mean by the crats handling desysops "on their own", RandomCanadian? They currently do not act to desysop involuntarily except when ArbCom requires them to, or purely procedurally in inactivity cases. (Or IAR, I suppose.) — Bilorv (talk) 18:30, 31 October 2021 (UTC)[reply]
    Here I was clearly grouping the two together, in the sense that 'crats and ArbCom can handle this on their (collective) own. There's no indication they are unable to do so, nor any need to add a process ripe for abuse on top of it. RandomCanadian (talk / contribs) 22:48, 31 October 2021 (UTC)[reply]
  4. Plenty of far better thought out community desysop proposals, with better safeguards against abuse, have failed. ANI generally does a terrible job of handling behavioural issues involving experienced editors, and it's also prone to lynch mobs. Hut 8.5 17:40, 31 October 2021 (UTC)[reply]
  5. AN(I) is a horribly ineffective at handling all but the most straightforward conduct issues. Decisions there are completely at the mercy of the (very non-representative and, despite the name, primarily non-admin) crowd of people that watchlist those pages; are susceptible to groupthink, witch-hunts and popularity contents; have a tendency to rush to conclusions, fizzle out, or spin off topic entirely; I could go on... but I assume these problems are obvious to most people who have experienced the place. I fully agree that the best way to make it easier to sysop people is to make it easier to desysop them if we make a bad call, but this isn't the way. It's unfair to subject a decision made by typically 100+ editors at an RfA to reversal by an arbitrarily sized, self-selected mob at AN(I). Admin conduct cases at ArbCom may have their faults but it at least attempts to provide due process and space for people to properly defend themselves. – Joe (talk) 18:11, 31 October 2021 (UTC)[reply]
  6. ANI often doesn't have the "full" community around. As such, especially in cases of low participation, the decision there may not reflect what the full community wants. Although having a three-admin panel closing the discussion does alleviate some of the concerns, without further details to prevent short length discussions and involved admin closure, I don't think I'd support this. Furthermore, for an admin to be desysoped at ANI like this I can see them being unwilling to go through another RfA to see if the "full" community supports them. I do though support the idea of having a community led way to desysop someone, but finding an appropriate way to achieve this is difficult. Dreamy Jazz talk to me | my contributions 18:47, 31 October 2021 (UTC)[reply]
  7. ANI is probably the one place that's more dysfunctional than RfA, and so I cannot support giving it desysop powers without (at a minimum) some serious procedural safeguards along the lines of this suggestion. Subjecting admins to removal via a single discussion by whichever capricious group happens to be congregating at ANI that week strikes me as a very bad idea that would, if anything, make candidates less likely to run at RfA. Extraordinary Writ (talk) 19:16, 31 October 2021 (UTC)[reply]
  8. Strong oppose. Concurring with Extraordinary Writ ANI was scientifically assessed a couple of years ago and established as being largely disfunctional. It would allow everyone in the public gallery to be judge, jury, and executioner. This would first require a strict reform of ANI. That doesn't mean that Arbcom is any better - it sometimes appears to simply read a perceived 'consensus' of all those who come to comment, involved or not. Kudpung กุดผึ้ง (talk) 19:55, 31 October 2021 (UTC)[reply]
  9. ANI is a circus and in no way setup to handle this sort of thing. Everyone with an ax to grind with an admin will show up out of the woodwork to try to come up with a convincing reason to take the mop away from the admin who blocked them from edit warring 6 months ago. HighInBC Need help? Just ask. 22:56, 31 October 2021 (UTC)[reply]
  10. Good God, no. In a case where an involuntary removal of tools is requested, it will be one of two situations. Firstly, the admin may be committing egregious, "bright line" violations (and the account may even potentially be compromised, given that this is presumably very out of character for them). When this happens, ArbCom already can and does perform a rapid desysop pending a full case. In these scenarios, the AN(I) process would take too long; the damage must be contained immediately. Conversely, the complaint may be a longstanding pattern of less egregious but still concerning lapses. In that case, the AN(I) process will be too short and scattershot to do a complete evaluation of the allegations, the evidence behind them, and the context surrounding them. I really can't see a scenario where such a process would be the appropriate one to handle a desysop, and I can see a thousand ways it could go wrong. Seraphimblade Talk to me 01:55, 1 November 2021 (UTC)[reply]
  11. And of course, the logical progression will be a non-admin closing such discussions. Besides what has been mentioned above. --Rschen7754 02:42, 1 November 2021 (UTC)[reply]
    Why would this be the logical progression, Rschen7754? There would need to be a later RfC to determine that even an admin could close the discussion, rather than three mandated at present. — Bilorv (talk) 11:45, 1 November 2021 (UTC)[reply]
    This is what has historically happened over the past, with the vast expansion of NAC. --Rschen7754 18:04, 1 November 2021 (UTC)[reply]
  12. I mention in #Oppose 6A Binding recall criteria that we need a process outside of ArbCom to remove adminship, and while ANI looks like the most obvious avenue, I wouldn't trust it in its current state. It's completely disorganised and full of people with vengeances and drama seekers with a spare fifteen minutes. Similarly, many of the discussions over there are closed by non-admins which is a completely different environment to requiring a bureaucrat to close an RfA. I think we should explore using RfA for both assigning adminship and removing it. Of course, some may argue that RfA is better than ANI, but at least we have some semblance of process at the former. Anarchyte (talk) 06:28, 1 November 2021 (UTC)[reply]
  13. ANI is a crazy place that is not the way to solve the problem. Why, we need more admins, not fewer! 🐔 Chicdat  Bawk to me! 10:49, 1 November 2021 (UTC)[reply]
  14. I worked on this, including several proposals, over the last decade. ANI/AN is a horrible place for this. Dennis Brown - 2¢ 11:42, 1 November 2021 (UTC)[reply]
  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)[reply]
  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)[reply]
  17. ANI is a cesspit --Guerillero Parlez Moi 10:26, 2 November 2021 (UTC)[reply]
  18. Per Guerillero: ANI is bad and this just makes a rough process worse. ~ Amory (u • t • c) 15:54, 2 November 2021 (UTC)[reply]
  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)[reply]
  20. Every problem editor eventually get summoned to ANI. The selection of users watching that page is strongly biased towards troublemakers. I wouldn't be an admin if I hadn't been summoned to ANI in 2005. Jehochman Talk 08:14, 5 November 2021 (UTC)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  24. "I'll take 'How to make ANI even worse for $500, Alex.'" [rip] Jclemens (talk) 05:30, 8 November 2021 (UTC)[reply]
  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)[reply]
  26. I do not believe that any RfA voter is going to think "well I'm not completely sure about this person, but if they do poorly then I can always go to ANI and get them de-sysopped". And if no one thinks this then the proposal would not achieve the goal of making RfA a lower-stakes environment. Also per Extraordinary Writ, "ANI is probably the one place that's more dysfunctional than RfA". I have less strong feelings about AN. --JBL (talk) 14:14, 8 November 2021 (UTC)[reply]
  27. Oppose. Probable more harm than good in my opinion. Djm-leighpark (talk) 14:38, 8 November 2021 (UTC)[reply]
  28. Oppose per above. JackFromWisconsin (talk | contribs) 15:25, 8 November 2021 (UTC)[reply]
  29. Oppose. The drama boards are bad now; this would take us back to the old quick polls were even worse. Jonathunder (talk) 04:44, 9 November 2021 (UTC)[reply]
  30. Agree with Melanie. Neutralitytalk 05:33, 9 November 2021 (UTC)[reply]
  31. Clearly counterproductive. GABgab 16:31, 9 November 2021 (UTC)[reply]
  32. After having read a fair number of ANI discussions, I feel that I agree with the above in that it would not be the most healthy venue for this, and I feel as though this shortcuts the due process afforded by Arbcom, and its thoroughly-vetted members. ASUKITE 16:40, 10 November 2021 (UTC)[reply]
  33. Using the drama board as a venue for a neutral investigation into whether or not to desysop someone is a bad idea. Arbcom currently fulfills that role far better than ANI ever could. —⁠ScottyWong⁠— 05:59, 11 November 2021 (UTC)[reply]
  34. Oppose per Extraordinary Writ - I can't think of anywhere worse in the world to hold a desysop request!, ANI is more dysfunctional than RFA so absolutely bloody not!. –Davey2010Talk 14:29, 11 November 2021 (UTC)[reply]
  35. Please, no. ANI is the most dysfunctional forum we have, and is frequented by any number of drama mongers whose participation in a desysopping discussion would be a net negative. Vanamonde (Talk) 17:24, 12 November 2021 (UTC)[reply]
  36. ANI is merely dysfunctional on a good day. Alarming to see folks seriously entertaining this. -FASTILY 01:25, 14 November 2021 (UTC)[reply]
  37. Haven't we just had a discussion that rejected this idea? Espresso Addict (talk) 04:02, 14 November 2021 (UTC)[reply]
  38. More or less per Extraordinary Writ. ANI is prone to jumping to conclusions and dogpiling at the best of times, a discussion involving admin behavior is never the best of times there, and any reasonably active admin is likely to attract enemies who would be motivated to shepherd any discussions in that direction. Arbcom has not demonstrated much willingness to de-admin when warranted, but this doesn't seem likely to be an improvement. —David Eppstein (talk) 08:30, 14 November 2021 (UTC)[reply]
  39. Wouldn't make RfA better, would make ANI worse (if that's even possible). the wub "?!" 02:06, 17 November 2021 (UTC)[reply]
  40. Wikipedia should not actively try to be more of an ochlocracy. Sandstein 20:12, 29 November 2021 (UTC)[reply]
  41. Strongest Possible Oppose - Like other people have mentioned above, AN and ANI is probably one of the worst ways to desysop an editor who has been properly and thoroughly community vetted through RfA. Arbcom already handles all cases of desysop through a proper case, review and investigation (along with a wide community input). The purpose of this RfC is to make it easier to find, make and keep admins, not to subject admins to more stress, torture and pain. TheGeneralUser (talk) 07:48, 30 November 2021 (UTC)[reply]
  42. Oppose ANI is one of the most unfair and dysfunctional procedures we have at Wp. Ot is subjetto efforts by sma;l coteries, and by bludgeoning and trying to swamp the discussion. It's probably even worse than RfA which has at least some semvblance of order and fairness. DGG ( talk ) 10:25, 2 December 2021 (UTC)[reply]

Discussion 6B Desysop at AN(I)

  • Leaning oppose, but need some more time to think. Dreamy Jazz talk to me | my contributions 18:21, 31 October 2021 (UTC)[reply]
  • Regarding, "Why can't arbcom handle this?", I think the answer is that arbcom is the ultimate in heavyweight processes. Slow and ponderous and high-stakes, not to mention opaque. More importantly, it's not community-based. If our goal is to make giving somebody a mop less of a big deal, it's important that we have a way for the community to say, "We gave you a mop, but now we realize that we made a mistake and are taking it back". Arbcom de-sysoppings are about breaking rules. Community de-sysoppings are about losing faith. As noted above, we need some way to keep it from turning into a witch hunt, but we also need something more lightweight than arbcom. -- RoySmith (talk) 18:22, 31 October 2021 (UTC)[reply]
    • 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)[reply]
  • @Valereee and Nosebagbear: which details are absent from the proposal? — Bilorv (talk) 18:30, 31 October 2021 (UTC)[reply]
    @Bilorv, off the top of my head...time discussion is open, announcements posted, ability of the admin in question to veto certain closers they feel might be biased? I'm not trying to complicate this, just to think of things that might make some admins wary of signing on. —valereee (talk) 18:42, 31 October 2021 (UTC)[reply]
    @Valereee: why are none of these things that need to be spelled out as rules for the existing discussions that determine removal of PERM-given rights or implementations of topic bans, interaction bans, or temporary or indefinite blocks? It seems to me that there is nothing new here to discuss in the case of admins, except discussions that would already need to take place for existing procedures. If an admin doesn't like that they could be desysopped in just a 72-hour discussion, why have they not been protesting against non-admins with over 50,000 edits being indefinitely blocked/banned after such discussions? As for the "veto certain closers", that's already a standard part of Wikipedia:Consensus. — Bilorv (talk) 18:51, 31 October 2021 (UTC)[reply]
    @Bilorv, I'm not trying to make the world fair. I'm trying to bulletproof the proposal, which I support. Politics being the art of the possible. —valereee (talk) 19:29, 31 October 2021 (UTC)[reply]
    @Valereee: the more conditions you add to a proposal, the more objections you gather over individuals opposing just one or two specific conditions that are immaterial to the broader mandate you are trying to achieve. That is why the proposal is as simple as possible. I don't see that further specification of the types you have named would help the proposal gain more support, but that doesn't mean I wasn't asking you the above questions earnestly and with interest in considering in your answer. — Bilorv (talk) 19:44, 31 October 2021 (UTC)[reply]
    @Bilorv, yes, and that's why I stated my support the way I did: "Given details can be worked out." I'm not asking for those details to be specified in the proposal. I'm just acknowledging that there might be concerns that needed to be worked out. —valereee (talk) 19:47, 31 October 2021 (UTC)[reply]
  • I'm undecided, and I have an implementation question that I am also undecided about: should these discussions be on structured sub-pages? On the one hand, it might decrease visibility; on the other, additional discussion structure (and not overwhelming the often-long ANI page) may aid in clarity of discussion. User:力 (power~enwiki, π, ν) 19:05, 31 October 2021 (UTC)[reply]
    Again, 力, I would ask: why only for these discussions, and not for discussions about indefinitely blocking experienced editors? AN(I) seems currently able to regulate its own discussion structure sufficiently to obtain consensus for much, much more wide-reaching and significant actions than removing admin status from an individual. — Bilorv (talk) 19:16, 31 October 2021 (UTC)[reply]
    I don't think some of those other ANI discussions function well either. Why should we extend a broken process? The whole "ARS" thing currently at ANI should probably be structured and on a subpage as well. User:力 (power~enwiki, π, ν) 19:18, 31 October 2021 (UTC)[reply]
    @力: would you prefer the proposal to forego any mention of specific pages at all, and simply say that desysopping could occur after any discussion where three admins agree consensus was obtained to do so? AN(I) and "a new subpage [of ???]" could then be listed as example pages where such a discussion could occur. (Of course, you'd expect no admins would make such a close if a discussion had low participation or mostly canvassed participants.) — Bilorv (talk) 19:44, 31 October 2021 (UTC)[reply]
    @Bilorv: I would personally prefer that, but I am not sure it would make the proposal more likely to pass. User:力 (power~enwiki, π, ν) 19:46, 31 October 2021 (UTC)[reply]
  • I would also prefer a different location for the discussion but won't withhold my support on the basis of using AN(I) alone. To offer a suggestion, perhaps open the discussion on a subpage of the RfA they succeeded in becoming an admin. Two points which do stifle my desire to support this proposal: 1. Please stipulate the minimum timeframe in which the discussion will remain open. And 2. Please stipulate how you will advertise the discussion. Here I'd like to suggest, amongst other things possible, that each person !voting at the RfA which they succeeded in becoming an admin, receive a talk page notification. I look forward to supporting this proposal if my concerns are allayed. Nevertheless, I will not oppose.--John Cline (talk) 11:37, 1 November 2021 (UTC)[reply]
  • I think we need some use cases. The one that comes to mind is when Neelix was found to have created a huge number of inappropriate redirects that needed to be deleted (indeed, a separate CSD criteria was created for them!) and we had to create an Arbcom case before he finally decided to relinquish the tools. The other use case was when Fred Bauder was IAR desysopped for self-unblocking and wheel warring; an Arbcom case was created as a formality, but there's no reason the consensus couldn't have been decided at ANI instead. Both of these (AFAIK) found an overwhelming consensus to desysop which was highly unlikely to be found controversial (and indeed wasn't). While I filed a number of ANI threads about RHaworth, I don't think there would have been consensus at ANI for a desysop; similarly I doubt RexxS would have got his tools stripped at ANI. Ritchie333 (talk) (cont) 14:23, 1 November 2021 (UTC)[reply]
    • 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)[reply]
  • I would like to see clearer standards for acceptable and unacceptable admin behaviour that would make it easier for a discussion at ANI to conclude that someone wasn't meeting the accepted standard. Failure to address concerns and abide by conclusions reached at ANI would create an clearer path for escalation to the arbcom. Guettarda (talk) 21:06, 13 November 2021 (UTC)[reply]
  • I am drawn to this idea. A potential way to ease some of the angst may be consensus at ANI can trigger a community Desysop process that is advertised and run like an RFA. Cavalryman (talk) 13:10, 14 November 2021 (UTC).[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Passed: 6C Administrative action review

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
There is consensus to implement this proposal. The consensus is expressed in the number of votes, but more importantly, we find the arguments of the supporters stronger. The main supporting argument is that we need a process which would be a middle ground between AN/ANI and arbitration cases; it is structured and aimed at discussing a single action, not the total contributions of a user. Many of those opposed state that such a process is not needed and is covered by existing processes. Clearly, the supporters think it is needed, and if it turns out to be useless it will naturally die. Furthermore, some of the opposers mention that the proposed process is similar to WP:RFC/U, which is considered to be not a net positive process due to its acerbic nature. However, there is a clear difference between the proposed process, which is about evaluating a single action, and RFC/U. Finally, we note that the process as proposed is not just about the evaluation of administrative actions, but about all advanced permissions, and thus also applies to non-administrators.--Ymblanter (talk) 08:58, 10 December 2021 (UTC) (also on behalf of Primefac and Lee Vilenski).[reply]

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

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

References

  1. ^ Proposed name changed at 12:17, 1 November 2021 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)[reply]
  2. Sounds good to me.  – John M Wolfson (talk • contribs) 16:14, 31 October 2021 (UTC)[reply]
  3. I am open to something like this. —valereee (talk) 17:39, 31 October 2021 (UTC)[reply]
  4. I'm open to trying this. Dreamy Jazz talk to me | my contributions 18:43, 31 October 2021 (UTC)[reply]
  5. Support. This introduces, at least, some formal basis by which ArbCom can actually measure whether the community as a whole oppose an admin's actions, as their current case systems are limited by selective bias of participants and an overwhelming proportion of contributions coming from a small number of highly invested INVOLVED editors. It improves upon the WP:PERM system, which has no consistent way to remove rights when needed, and indeed often fails to do so at AN(I), where discussions are derailed or trail off. While not directly introducing any additional methods to remove permissions (therefore making it pretty uncontroversial), this proposal succeeding would give a mandate for a more consistent framework that could be built upon in any number of ways, once the community sees PRV proving useful in practice. (And conversely, if PRV fails then it can be marked {{Historical}} or simply left to become disused, no harm done.) — Bilorv (talk) 19:32, 31 October 2021 (UTC)[reply]
  6. Editors should read the longer rationale on the talk page. It's a clever idea that I'm actually very excited to try. Bilorv lays out the benefits better than I think I could, but in general I think there's a lot of promise here that could lead to long-term beneficial change. — Wug·a·po·des​ 20:36, 31 October 2021 (UTC)[reply]
  7. Yup.—S Marshall T/C 22:41, 31 October 2021 (UTC)[reply]
  8. Okay, I'm in. I misinterpreted this as a desysop procedure after reading 6B. It isn't; it's a fine way for the community to express support or opposition to a specific tool usage. We may actually need this. ~ ToBeFree (talk) 22:51, 31 October 2021 (UTC)[reply]
  9. Sounds like an improvement on the current systems (AN/ANI thread or Arbcom). Also it would give a good place for people to self-request reviews if they're not sure about their tool usage and get some valuable feedback (better than they'd get at ANI). Levivich 00:46, 1 November 2021 (UTC) Update: Upgrading to strong support after reading the #Case study subsection. Levivich 00:14, 11 November 2021 (UTC)[reply]
  10. It's worth a try, we don't lose a lot if it doesn't work. --Rschen7754 04:21, 1 November 2021 (UTC)[reply]
  11. I fully support this, and I really hope that adding a way to review decisions will lower the high stakes atmosphere. However, it will take a long time to see results at the RfA end. Oh, and I prefer XRV as the acronym and something to make it clear that it's a specific review, not a general one in the name. (Eg Miscellaneous decision review or Administrative action review) WormTT(talk) 08:22, 1 November 2021 (UTC)[reply]
  12. Might help. What's being suggested isn't very different from deletion review, which is capable of undoing bad deletions and delivering trout slaps to admins who make them. Hut 8.5 09:49, 1 November 2021 (UTC)[reply]
  13. Sounds good to me. I wonder if this could be used for self-review after a particularly "courageous" IAR use of the admin tools, such as the desysop of Fred Bauder I brought up above. Ritchie333 (talk) (cont) 14:26, 1 November 2021 (UTC)[reply]
  14. Nice idea. Improves accountability, as well as being a good venue for feedback where hopefully the lower temperature will encourage the permissions holder to be more receptive to the issues and sort them out early on. Further, it lets non-admin permission holders build a track record of considerate permissions use. A combination of these ideas might have a positive effect on RfA, but seem useful to have regardless. ProcrastinatingReader (talk) 14:40, 1 November 2021 (UTC)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  21. DRV and move review both work well for what they are so I am all for another noticeboard like this. In general we should try to de-escalate things in a low stakes environment first before any other actions. ANI and Arbcom should be the reserved for the worst-case scenario only. Swordman97 talk to me 04:05, 4 November 2021 (UTC)[reply]
  22. I support a trial of this. ― Qwerfjkltalk 20:39, 4 November 2021 (UTC)[reply]
  23. Each admin action should be reviewable, but I recommend reusing existing process. We have WP:DRV and block review. Where does one go to complain about page protection? WP:RPP? Are we missing any? Jehochman Talk 08:19, 5 November 2021 (UTC)[reply]
  24. * Pppery * it has begun... 18:34, 7 November 2021 (UTC)[reply]
  25. Good idea, low-drama alternative to ANI. 🐶 EpicPupper (he/him | talk) 22:34, 7 November 2021 (UTC)[reply]
  26. Weak support, as long as this is not a desysop procedure. JackFromWisconsin (talk | contribs) 15:29, 8 November 2021 (UTC)[reply]
  27. Strongly support. This has most of the the benefits of the much needed bifurcation. This type of review needs to be considered "no big deal" and should be broadened to include review of simple errors which are a common form of admin mis-action. Knowing that actions of (particularly new) admins can get reviewed and that there is a process for doing so lowers the stakes for letting a new admin in thus helping the entire process. North8000 (talk) 22:08, 8 November 2021 (UTC)[reply]
  28. Fills a gap. Provides a venue and process for providing feedback to help ensure editors are using advanced perms in a manner supported by the community. Hopefully it motivates editors to adjust to community expectations before it reaches the chronic/intractable phase of ANI. Schazjmd (talk) 18:10, 9 November 2021 (UTC)[reply]
  29. Weak support - good idea, not sure if there'll be much participation. But I guess it's ok - if nobody objects, move on, nothign to see here. The point is, it opens the occasional problematic actions to scrutiny. Admins need to be reconfirmed every few years. --Piotr Konieczny aka Prokonsul Piotrus| reply here 23:13, 9 November 2021 (UTC)[reply]
  30. Although the rulings aren't necessarily "binding", and amount to a form of censure, this is a starting point, which will create a form of consensus that can be used to show whether specific action should be taken. I would like to see more-specific criteria for permission removal, but that doesn't have to happen right away. This might even have the effect of taking some workload (and drama) away from ANI. ASUKITE 16:46, 10 November 2021 (UTC)[reply]
  31. Worth a try. — J947 ‡ message ⁓ edits 00:30, 11 November 2021 (UTC)[reply]
  32. An avenue to examine the appropriateness of actions (especially en masse, a pattern over time, or particularly bad in a given circumstance) outside of the culture of AN/I or the bar of ARBCOM might be helpful. Some sort of discussion should take place with the administrator first, and raising trivial (e.g. non-repeating actions or small oversights) should be discouraged; however, the details can be hashed out later. This should be treated more as a way to deem whether such actions are appropriate to continue in the future rather than a place to seek sanctions or the removal of user rights. — Godsy (TALKCONT) 08:43, 11 November 2021 (UTC)[reply]
  33. Worth a shot. –Davey2010Talk 14:32, 11 November 2021 (UTC)[reply]
  34. Support on codition that blocks reviewed there cannot become WP:CBANs. –MJL ‐Talk‐☖ 06:28, 12 November 2021 (UTC)[reply]
  35. Support. I'm not keen on creating new venues but I think here it will be helpful to have a more structured review of admin actions. Alaexis¿question? 12:27, 12 November 2021 (UTC)[reply]
  36. Support, though if it turns into RFCU it shall get scrapped within 12 months. It needs to be a "blameless" forum - if you are claiming an editor/admin has a pattern of problematic actions, discussions should be moved to ANI. As another example of what could be posted, there seems to be some concern whether my close of Wikipedia:Articles for deletion/Kelli Stavast as "No consensus with no prejudice against speedy renomination" should have been "No consensus but with prejudice against speedy renomination"; apart from the existing ANI thread on 5 other topics (or talking to myself on my own talk page) there is no good place to discuss this. User:力 (powera, π, ν) 15:00, 12 November 2021 (UTC)[reply]
  37. Hesitant support. Tony and Risker make good points below, but it would indeed be helpful to have a venue to discuss admin actions that is less corrosive than AN/ANI. Would move to strong support if we had a trial period, or other mechanism to cut this short if it doesn't work. Vanamonde (Talk) 17:26, 12 November 2021 (UTC)[reply]
  38. Seems reasonable to me, and if it turns into another ANI it can be marked as historical. Cavalryman (talk) 13:31, 14 November 2021 (UTC).[reply]
  39. Worth trying HelpfulPi (talk) 21:17, 14 November 2021 (UTC)[reply]
  40. Sounds like a good idea. I'd be interested to see how it'll do in a practice. Modussiccandi (talk) 20:20, 16 November 2021 (UTC)[reply]
  41. Honestly I wonder why we don't have this already: it seems perfectly accepted that we have deletion review so why not other admin actions? Agree that the focus should be on reviewing individual actions. Splitting this away from the chaos of ANI makes sense. the wub "?!" 02:07, 17 November 2021 (UTC)[reply]
  42. Seems like it could be useful, and I like the idea of it being a structured discussion with a clear process and outcome, more like DRV than ANI. Tim Smith (talk) 01:00, 24 November 2021 (UTC)[reply]
  43. I'm in favor of trying something new once in a while ... provided the support votes seem to indicate that we might get a critical mass of people trying to make it work. We might have that, here. - Dank (push to talk) 02:57, 29 November 2021 (UTC)[reply]
  44. As per[[User:Schazjmd this fills a gap. Provides a venue and process for providing feedback to help ensure editors are using advanced perms in a manner supported by the community. --Whiteguru (talk) 07:15, 29 November 2021 (UTC)[reply]
  45. Tentative support. We should give it a try at least, but after a while decide if it should be kept or shut down. Trainsandotherthings (talk) 19:57, 29 November 2021 (UTC)[reply]
  46. Full Support - This seems like a very good idea and is definitely worth implementing and using. A specific noticeboard where any and all kinds of administrative actions can be discussed and reviewed by the community as a whole is a very good idea. TheGeneralUser (talk) 02:01, 30 November 2021 (UTC)[reply]
  47. Support - useful with minimal downside. Much of the opposition angst appears to be unfounded and imagined.--John Cline (talk) 10:17, 3 December 2021 (UTC)[reply]
  48. A more structured forum for reviewing administrative actions would do a world of good. If you compare WP:ANI and WP:AE, even just looking at appeals, there's a huge difference. A more structured format leads to more constructive discussions. If this can capture some of what works WP:AE work so well, it'll be worth it. If not, at least we'll have crossed it off the list. Tamwin (talk) 09:44, 7 December 2021 (UTC)[reply]

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)[reply]
    The difference between this and AN/I is that the discussions will have a structured format and be restricted in scope. The idea is that when editors are asked to reach a consensus on a specific question (like at WP:DRV or a good RfC) they are much more likely to reach a resolution than when faced with an open-ended issue which could end in anything from a tailored topic ban to a boomerang-block for the person that brought it up (like at AN/I). – Joe (talk) 17:43, 31 October 2021 (UTC)[reply]
    Discussions like this, if we want to have them as a community rather than in front of ArbCom, are more suitable for ANI/AN than a separate, low-visibility page, as the quality of the discussion strongly depends on the amount of eyes watching it. ~ ToBeFree (talk) 17:21, 31 October 2021 (UTC)[reply]
    I don't understand how you can tell this will be "low-visibility", since it hasn't been created yet. – Joe (talk) 17:43, 31 October 2021 (UTC)[reply]
    I'd add to Joe's comment: if it turns out to be low-visibility then why would it not be sufficient to use any of the many things we already have to increase visibility of discussions that need it: {{Please see}}, listing at WP:CENT, appropriate notification procedures and so on? — Bilorv (talk) 19:32, 31 October 2021 (UTC)[reply]
    I agree, there's no reason to believe this would be a low-visibility page. In fact I suspect most highly-engaged editors would be watching it from the start. —valereee (talk) 21:05, 31 October 2021 (UTC)[reply]
    Okay. ~ ToBeFree (talk) 22:50, 31 October 2021 (UTC)[reply]
  2. Not sure what this proposal attempts to resolve, or what it has to do with improving RfA. Any action can can already reversed by an administator. This also moves the goalposts. Actions should not need a consensus that they are correct, this is an unreasonable standard. The standard should remain that a consensus that they are wrong. HighInBC Need help? Just ask. 23:01, 31 October 2021 (UTC)[reply]
    @HighInBC: If you haven't seen it, I tried to explain what problems this solves and how it will improve RfA on the talk page (there's a narrow word limit here). – Joe (talk) 08:32, 1 November 2021 (UTC)[reply]
  3. Drama fest full of everyone who feels they've been wrong. No, this is what Arb is for, and filing an Arb case is trivial if there is any misuse. Dennis Brown - 2¢ 11:43, 1 November 2021 (UTC)[reply]
  4. We already use AN/ANI to review admin actions and I don't see the need to create a new venue for the same purpose. If we're going to create it, give it some teeth. -- Calidum 16:42, 1 November 2021 (UTC)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  8. WQA and RFC/U died for a good reason --Guerillero Parlez Moi 10:39, 2 November 2021 (UTC)[reply]
  9. We need more admins, not fewer! 🐔 Chicdat  Bawk to me! 10:57, 2 November 2021 (UTC)[reply]
    @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)[reply]
    I invite you to look at the "case study" section below - as you can see, a desysop is not an option on the table, unless taken to Arbcom with evidence, which the case already. Ritchie333 (talk) (cont) 15:17, 10 November 2021 (UTC)[reply]
  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)[reply]
    As I understand it, an increased accountability and transparency over admin actions will make people more accommodating at RfA, because the stakes are no longer as high. Ritchie333 (talk) (cont) 15:17, 10 November 2021 (UTC)[reply]
  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)[reply]
  12. Opposing based on the idea that dragging in yet another noticeboard seems like a mess - say Editor:X appears to be missusing massmessage; Admin:Y removes their access and they disagree. So now what, we need a PRV for if they should get it back, and another PRV if Admin:Y misused their rights managment rights - the former of which could reverse it, the later of which would then what, get an arbcom case opened? WP:AN is already equipped to deal with this situation, not seeing how this is any better. — xaosflux Talk 10:52, 4 November 2021 (UTC)[reply]
  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)[reply]
  14. This seems to be a solution looking for a problem. Chetsford (talk) 18:22, 7 November 2021 (UTC)[reply]
  15. I would maybe be open to a structured, specific standalone process for administrative action reviews (sort of like AE). But as formulated, I don't see how this would be different from AN or ANI — especially if this proposed "XRV" would be "open to all editors," it would seem to be duplicative. Neutralitytalk 05:37, 9 November 2021 (UTC)[reply]
  16. Per Kusma and Risker's comments below. GABgab 16:18, 9 November 2021 (UTC)[reply]
  17. This would be redundant to ANI. If ANI is a problem, make it better, don't make another one. Tol (talk | contribs) @ 15:05, 10 November 2021 (UTC)[reply]
    @Tol: But that's not what we're proposing in the "case study" below. In the example given, the question is "are these administrative actions valid in this case", regardless of who actually made them? Anything talking about specific contributors is as off topic as doing it at WP:DRN, where it is clerked with swiftly escalating warnings. I think with that safeguard in place, drama can't happen - or at least it can't be sustained. Ritchie333 (talk) (cont) 15:14, 10 November 2021 (UTC)[reply]
    @Ritchie333: So it's meant to be structured like an arbitration case, rather than an ANI free-for-all? I'm worried that it'll end up as another ANI, and I still think improving ANI may be a better option. Tol (talk | contribs) @ 15:44, 10 November 2021 (UTC)[reply]
  18. There's a lot to be said here pro and con. But ultimately, I agree with Risker below: this is an inappropriate forum to suggest this in. Many admins, myself included, don't really care that much about RfA reform because to be blunt, RfA isn't really that broken. I almost didn't even read this RfC. This is basically a disciplinary measure tacked on to an RfC that it is completely unrelated to. It's not the appropriate forum to have this discussion, and if it was proposed independently, it'd fail.
    On the merits: no difference between this and AN. If there was a difference, it'd turn into RFCU, and there's a reason we got rid of that. If you could enforce decorum on it, you'd have a shot of it being better, but you couldn't do that without further claims of abuse or admins protecting their own.
    Tl;dr: wrong forum to propose this, and we already have a solution for the problem it is seeking to address. If it's not duplicative of AN, it'd be duplicative of a process we got rid of a decade ago for a reason. TonyBallioni (talk) 03:37, 11 November 2021 (UTC)[reply]
    Well Tony, this proposal is a specific response to a problem with RfA identified in the last phase of the RfC. If you thought that that problem was "unrelated" to RfA, then the time to make that case was in the last phase. Anyway, your and Risker's attempts at clairvoyance aside, I see no reason to believe that the discussion at this well-attended, CENT-advertised RfC would be substantially different to one at say, VPP. – Joe (talk) 07:17, 11 November 2021 (UTC)[reply]
  19. I'd consider supporting this under certain circumstances, but this proposal is far too vague. Ok, so you reach a consensus that an admin made a mistake or misused the tools. What then? If this is just going to be a place where you can decide whether there was misuse, but you can't decide what to do about that misuse, then it's kind of a silly place. We can already do this at ANI, we don't need a special place for it. —⁠ScottyWong⁠— 06:03, 11 November 2021 (UTC)[reply]
  20. I don’t believe this will work, because it is no different than the old process (RFC/U) which didn’t work. It becomes a drama-fest of pile-ons, and the admins typically have ample support to avoid any meaningful action being taken when they misuse tools. (Happened to me, clear abuse of revdel, RFC/U went nowhere because of pile-on effect, and I don’t see how this process is any different.) SandyGeorgia (Talk) 21:18, 13 November 2021 (UTC)[reply]
  21. I'm not sure what problem this is trying to solve, let alone which problem related to RFA. For deletions there is already DRV; and blocks, protections etc. can already be unilaterally undone by any admin, which they will be if they appear to be a bad idea. I might support it if this were a mandatory alternative to unilateral admin action reversals, but it is not. Sandstein 20:07, 29 November 2021 (UTC)[reply]
  22. I think this is covered by AN/I and AN. Doubt results here would be very different.--Wehwalt (talk) 14:25, 30 November 2021 (UTC)[reply]
  23. My first thought on reading this was "huh, what's the harm? I don't have any issues with my actions being reviewed." But my actions can already be reviewed on WP:AN or WP:ANI, where any editor can participate. I certainly sympathize with where this proposal is coming from, I just think it's superfluous. Well-meaning, but superfluous.--Aervanath (talk) 19:39, 8 December 2021 (UTC)[reply]
  24. AN can handle this (tends to be less toxic than AN/I in my experience).-- Pawnkingthree (talk) 19:52, 8 December 2021 (UTC)[reply]

Discussion 6C Administrative action review

Moved to support. Trainsandotherthings (talk) 19:58, 29 November 2021 (UTC)[reply]
  • I'm not convinced this will improve meaningfully on how ANI already does this type of review. User:力 (power~enwiki, π, ν) 19:14, 31 October 2021 (UTC)[reply]
    After reading more comments, I think that even if this is just "ANI reform" it probably is still a good thing. Still too many details to work out for me to vote, but I am optimistic. Regarding the name: maybe "Logged Action Review"? I'd straight-up suggest Code review except that would probably be too confusing. User:力 (power~enwiki, π, ν) 22:58, 31 October 2021 (UTC)[reply]
  • I don't see overlap with AN(I) to be an issue. The pages have been subject to possibly the most monumental scope creep of any pages on Wikipedia, and are now both: (1) the most toxic pages on the website; and (2) the default place to achieve a mandate for substantial and potentially disastrous actions (such as removing rights, blocking and agreeing on mass actions), as well as moderating petty disputes and taking care of very simple issues that need quick attention. It is an advantage to have a dedicated forum for structured discussion designed to answer a specific question, rather than a meandering argument driving a user to either say "fuck it, I'm ignoring all of you and continuing on with no change to my behaviour" or to escalate their actions to the point where they are indefinitely blocked and/or choose to leave. — Bilorv (talk) 19:32, 31 October 2021 (UTC)[reply]
  • Maybe this is bikeshedding territory, but it really can't be named WP:PRV. Not unless you want its participants to be regularly labelled prverts. —Cryptic 20:08, 31 October 2021 (UTC)[reply]
    PReview? PerView? PermRev? —valereee (talk) 21:09, 31 October 2021 (UTC)[reply]
  • It would make more sense if it was an uninvolved bureaucrat for advanced perms that require it, given that the crats giveth and the crats taketh away. It doesn't make much sense to say that the consensus of granting of adminship (or pc reviewer or whatever) is determined by bureaucrats but the consensus of (possible) revocation of adminship can be closed by any admeme acting on their own. Chess (talk) (please use {{reply to|Chess}} on reply) 03:52, 1 November 2021 (UTC)[reply]
    • @Chess: revocation of adminship is not one of the possible outcomes of the proposed PRV, nor would this change that only ArbCom can revoke adminship (except for inactivity). This could only possibly be an additional form for community input that ArbCom could decide for themselves whether/how to take into account. — Bilorv (talk) 11:48, 1 November 2021 (UTC)[reply]
  • Is this process purely advisory or can it also enact topic bans or desysops or anything? If desysops are on the table, it's probably best to have bureaucrats be the closers. Jo-Jo Eumerus (talk) 11:21, 1 November 2021 (UTC)[reply]
    • The idea is that it would be advisory and, like e.g. WP:DRV, focused on determining whether a specific action was appropriate rather than coming up with 'remedies'. I imagine that if an admin had a series of PRV/XRVs closed against them, it might form the basis of an arbitration request where their wider conduct would be reviewed and a desysop considered. Or better yet, that they would change course before it reached that point! It seems this has been a source of confusion for a few people, perhaps at least partly because of the name, so I'll go ahead and update that per the talk page. – Joe (talk) 12:11, 1 November 2021 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
    I agree there are significant differences between comments on user conduct and the proposal—in particular, the outcome of RfC/U was strictly advisory. However RfC/U was not without procedural constraints, as can be seen at Wikipedia:Requests for comment/User conduct/Creation. isaacl (talk) 19:37, 2 November 2021 (UTC)[reply]
    Sorry, I mean, ANI currently functions as a version of RFC/U without procedural constraints. – Joe (talk) 20:01, 2 November 2021 (UTC)[reply]
  • 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)[reply]
    @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)[reply]
    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)[reply]
    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 Wikipedia 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 Wikipedia 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)[reply]
    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)[reply]
    And furthermore, if it just makes people think administrators can be more accountable for their actions, it's a good thing generally, irrespective of RfA. Ritchie333 (talk) (cont) 15:20, 10 November 2021 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
    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)[reply]
  • 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)[reply]
  • Well, given the fact that this is essentially an RFC about RFA, having this chat here is false advertising. It's an admin issue, and nobody has bothered to tie it to RFA. So if you want to discuss it, start over again and label it properly so that the community can tell you that admin actions are regularly reviewed in all kinds of venues, and you don't need a special RFA proposal to do so. Risker (talk) 03:22, 11 November 2021 (UTC)[reply]
  • I'm relatively neutral on this one (as an admin who largely works in deletion, deletion review generally works quite well) but agree with Risker that this is the wrong forum for this discussion. Espresso Addict (talk) 04:17, 14 November 2021 (UTC)[reply]

Case study

Again, I think it would be useful to give an example case study (using some fictional details to avoid inadvertently causing offence).

Let's assume that Friggate Hall is a Grade I listed building in East Sussex used regularly for BBC period dramas since the 1960s. A brand new editor creates a policy compliant 800 character article as a stub, citing two reliable sources, before they are blocked as a checkuser-confirmed sock puppet of Icewhiz and the article deleted per WP:G5. At the same time, I spot the G5 at CAT:CSD, remove the tag and start improving it to DYK using a few local news sources, a dedicated history piece in The Guardian, and Amberley books either from a Google Books search or from my local library, but by the time I save my changes, the article is already deleted. Now irritated, I restore the article with the summary "bad / abusive G5, we are here to write an encyclopedia", and re-save my edit. The article is now 1,800 characters long, cites nine reliable sources in detail, and has a DYK nomination.

Four hours later, the deleting admin leaves a note on my talk page : "Why on earth did you restore work of one of the most abusive sock masters in history?" I'm in a bad mood, I had a car accident three days ago and the insurance company has just told me I'm at fault and I'll lose my no-claims bonus, but nobody else knows that, so I reply "We are here to write an encyclopedia, not to spank bad boys in new and excited ways." We've now got two admins irritated with each other, and so it escalates up to Admin Review.

So, the question is - what happens next? Ritchie333 (talk) (cont) 12:20, 10 November 2021 (UTC)[reply]

This is a helpful exercise, thanks Ritchie333. This is what I would see happening next (assuming XRV works as planned):
  1. The deleting opens an XRV about your restoration. Editors discuss whether it was appropriate, considering relevant policy etc.
  2. After X days, an uninvolved administrator closes the discussion. Here there are a few possible outcomes:
    1. Your restoration is endorsed. Nothing happens.
    2. There is no consensus on your restoration. Nothing happens, but maybe you're informally warned to be more polite about it next time.
    3. Your restoration is overturned. The closing admin therefore deletes the article again.
  3. If this is an isolated incident, probably it stops there. If it's not, there are some follow-up scenarios:
    1. If you keep getting restorations overturned at XRV, someone starts an ANI thread, "Ritchie doesn't know how to use the restore button" and we try to figure out how to avoid it happening again.
    2. If this is the umpteenth time you've had an action overturned, and ANI threads like that above have been ineffective, someone makes an arbitration request for your bit.
    3. Say it's not an admin action but the use of a PERM, and it's not the first time it's overturned, someone will probably revoke that PERM from you.
I see this as an improvement on the current process for a case like this in a few places:
  • In #1, the discussion is limited to one question: should you or should you not used your admin tools in this situation? This will discourage it being derailed into a general discussion of what a rude jerk you are; or what a rude jerk the deleting admin is; or how in 2016 you also sided with an Icewhiz-sock (before there even were Icewhiz-socks!); or how G5 is fundamentally not fit for purpose and should be scrapped, or split into G5a, G5b, G5c; or any of the other tangents AN/Is tend to go on.
  • In #2, the response is kept at one remove from the discussion about the correctness of the action: we're not simultaneously talking about if you are wrong and, if you are wrong, whether we should topic ban you or desysop you or assign you a G5 admin mentor.
  • In #3, subsequent ANI discussions or ArbCom cases benefit from a series of specific, formally closed prior discussions that give a fairer picture of what the community thinks of your use of the tools than an arbitrary selection of diffs submitted by your friends and foes.
Overall, once XRV has had a chance to establish itself, I hope it will give greater confidence that admins are being effectively and constructively held accountable, and thereby make RfA voters less cautious. – Joe (talk) 13:19, 10 November 2021 (UTC)[reply]
I think this is a really good answer, Joe Roe. — Bilorv (talk) 18:58, 10 November 2021 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Withdrawn: 6D Initial probationary term (mandatory)

Withdrawn in favor of 6E below. --JBL (talk) 20:26, 7 November 2021 (UTC)[reply]

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.

Extended content

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

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 Talk 16:19, 7 November 2021 (UTC)[reply]
  2. Oppose per Xaosflux. SpinningSpark 17:46, 7 November 2021 (UTC)[reply]
  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 talk to me | my contributions 19:40, 7 November 2021 (UTC)[reply]
  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)[reply]

Discussion 6D Initial probationary term (mandatory)

@Xaosflux and Spinningspark: please see new option (E) below. --JBL (talk) 17:55, 7 November 2021 (UTC)[reply]
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)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

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.

Further details
  • I have proposed a fixed term to avoid the inevitable difficulties / criticisms that will arise from people having the ability to propose their own term lengths. Obviously the specifics of the term length are flexible (I think any duration between 1 and 5 years would be reasonable) and if you would support certain lengths but not the 2 years I proposed I would encourage you to indicate that in your !vote. --JBL (talk) 17:54, 7 November 2021 (UTC)[reply]

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)[reply]
  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)[reply]
  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)[reply]
  4. Sure. – John M Wolfson (talk • contribs) 18:53, 7 November 2021 (UTC)[reply]
  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 Talk 19:08, 7 November 2021 (UTC)[reply]
    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)[reply]
  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)[reply]
  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)[reply]
  8. Sure, opt-in, 1 year or 2. Lowers scrutiny. 🐶 EpicPupper (he/him | talk) 22:45, 7 November 2021 (UTC)[reply]
  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)
  10. Support but for a shorter term, probably 12 months. This should decrease the scrutiny the nominee goes through, allowing for more editors to attempt a run, while at the same time giving them a better chance to run for a full adminship if they are truly ready. Isabelle 🔔 03:03, 9 November 2021 (UTC)[reply]
  11. Why not? I think this is worth a shot. GABgab 17:50, 9 November 2021 (UTC)[reply]
  12. The benefit I see in this option is that it gives editors whose work isn't widely known an opportunity to demonstrate their usefulness as an admin. !Voters who may be reluctant to support "lifetime" admin may be more willing to give them a chance at a probationary term. Schazjmd (talk) 18:16, 9 November 2021 (UTC)[reply]
  13. Yes. It should make people more at ease when they think "damn, I supported them at RfA and now look at them". Ritchie333 (talk) (cont) 18:19, 9 November 2021 (UTC)[reply]
  14. Sure, worth a shot. Tol (talk | contribs) @ 15:08, 10 November 2021 (UTC)[reply]
  15. Sure, per my comments (and the responses) below. Giraffer (talk·contribs) 18:41, 10 November 2021 (UTC)[reply]
  16. Support, whether 1 year or 2. Lowering the barrier to entry should encourage more people to run. And, of course, we have just agreed as a community that 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 is not a concern to me that the people who are currently passing RfA (controversy-free and incredibly talented individuals who also get a bit lucky) would choose or be pushed to a temporary term instead and then fail to get the tools in 2 years. They would still have community support 2 years later, even in the face of backlash that admins receive. — Bilorv (talk) 19:35, 10 November 2021 (UTC)[reply]
  17. I think this is a good way to filter admins while reducing the corrosive atmosphere and encouraging higher application rates. Strongly support. YttriumShrew (talk) 23:09, 10 November 2021 (UTC)[reply]
  18. This may encourage people to be less critical at RfA, which make encourage more candidates to come forward. Worth a shot. Nothing to lose. I like the 1 year option more than the 2 year. SilkTork (talk) 17:00, 11 November 2021 (UTC)[reply]
  19. I like the 1 year better, too. I'm not worried about it becoming a de facto requirement. If it does, so what? Maybe that's a good thing. Even if that means some people going through two RFAs, the second one should be a breeze because there'd be (presumably) a solid track record (or else they wouldn't run), and the first one should be better than what we have now, because it'd only be for a limited term and not a lifetime appointment. I think it's a clever solution and would like to see us try it. Levivich 00:34, 12 November 2021 (UTC)[reply]
  20. As the proposal is to add a new option for requests for administrative privileges, I think a better description is "fixed-term" rather than probationary. I don't think it would become a default requirement: given the high support percentage of current requests, it would take nearly half of those supporters to change their minds. I think it is worth making this option available to try to attract candidates from those who aren't sure if they want to commit to being part of the community long-term, and so don't want to be a permanent administrator. I don't know if this will appeal to many new candidates, but I feel it's a reasonable, incremental change to try. isaacl (talk) 01:05, 12 November 2021 (UTC)[reply]
  21. Sounds like a good way to have more candidates HelpfulPi (talk) 21:20, 14 November 2021 (UTC)[reply]
  22. We have regular, yearly steward confirmations at Meta, and I don't think it is reducing the number of candidates at the yearly elections. I daresay a similar principle might apply to enwiki; and, as is noted above: in most cases, the reconfirmation RfA will be a breeze, or the candidate will not stand again. JavaHurricane 17:15, 15 November 2021 (UTC)[reply]
  23. Support, with a preference for 1-year terms. Should encourage more users to run. the wub "?!" 02:08, 17 November 2021 (UTC)[reply]
  24. I'd like to see us give this a shot to see if it helps. —valereee (talk) 16:40, 19 November 2021 (UTC)[reply]
  25. Definitely. Brilliant idea. ProcrastinatingReader hits the nail on the head. A good proposal. --Whiteguru (talk) 07:17, 29 November 2021 (UTC)[reply]
  26. Tentative support, for 1 year term only. Trainsandotherthings (talk) 20:00, 29 November 2021 (UTC)[reply]
  27. Per 力 below, I think 1 year makes a lot more sense than 2 for the purpose of a one-time limited-run RfA. And per Levivich above, I think the possibility of this becoming a de facto requirement, if that turns out to be true, is actually ok. Still should result in lower stakes the first time around and a more informed conversation the second time around. Retswerb (talk) 03:57, 30 November 2021 (UTC)[reply]
  28. Full Support - I think this is a great idea which is worth trying out on a trial basis (for a year at least). I can also completely understand the concern that it may most likely become a de-facto requirement for the current RfA process where admins are chosen permanently (in theory). However, RfA itself is already a very tough and hard process and it usually takes years of planning and hard work to even pass it in the first place. This process should be able to give an easier chance to editors to prove their competence for adminship. I believe we should first do a trail of this process for a year and if it works out well enough, we can improve and standardize it further as per the need and requirement. TheGeneralUser (talk) 08:43, 30 November 2021 (UTC)[reply]
  29. Support—I think a 1 year term is best. This might be a way to vet without a mandatory probationary period (withdrawn). This might allow a candidate with some light opposition to prove themselves. —¿philoserf? (talk) 20:07, 30 November 2021 (UTC)[reply]
  30. Support - more in the no-big deal ethos. Alanscottwalker (talk) 20:35, 7 December 2021 (UTC)[reply]
  31. I would support this on a trial basis. Activate this option for a year and then hold an RFC to determine if it should continue. There are a lot of valid objections raised by the editors in opposition, but until we can see how that would work in practice, we're all operating on hypotheticals. With some solid data, we could come to firmer conclusions about what works and what doesn't.--Aervanath (talk) 20:01, 8 December 2021 (UTC)[reply]

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)[reply]
    @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)[reply]
    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)[reply]
    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)[reply]
  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)[reply]
    @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)[reply]
  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)[reply]
    @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)[reply]
    I'm not sure I would actively support the proposal with that change, to be honest, I meant more than I wouldn't oppose it. Hut 8.5 12:46, 8 November 2021 (UTC)[reply]
    @Hut 8.5: Fair enough! --JBL (talk) 14:33, 8 November 2021 (UTC)[reply]
  4. This will give us less admins, we need more admins. HighInBC Need help? Just ask. 09:32, 8 November 2021 (UTC)[reply]
    @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)[reply]
  5. We need more admins, not fewer! 🐔 Chicdat  Bawk to me! 11:02, 8 November 2021 (UTC)[reply]
    This proposal would create an alternate process by which people could become admins; it does not decrease the number of admins, does not make it possible to remove anyone who is already an admin, and does not foreclose any currently available process by which people can become admins. I think it is unfortunate that you have made a series of !votes without seemingly thinking about the issues raised by the proposals or the associated discussions. -JBL (talk) 14:22, 8 November 2021 (UTC)[reply]
  6. I don't think there is need for this. Anybody who passes probably fits the job. Especially if there will be a desysop procedure in place, no need for this. Debresser (talk) 23:04, 8 November 2021 (UTC)[reply]
    @Debresser: Anybody who passes probably fits the job. What does this mean? The proposal would create an alternate process by which people could become admins; it does not foreclose any currently available process by which people can become admins. (Also there are two proposed desysop procedures, both of which have 2-1 oppose-support !votes at the moment, so it seems rather unlikely at the moment that there will be any desysop procedure put in place as a result of this RfC.) --JBL (talk) 00:19, 9 November 2021 (UTC)[reply]
    The problems of RfA are really two-fold. The first is impressions caused to the prospective candidate. If they feel a certain change will make the atmosphere more pleasant for them, even if it wouldn't have been unpleasant in the first place, that's a positive change. It's impossible to know how an RfA will turn out before you start it. The second is a material change in behaviour in an RfA, and lower stakes may well cause changed behaviour at RfA.
    It's probably true that anyone who passes this should just be passing full RfA. But they aren't running. We've had 7 new admins so far in 2021. ProcrastinatingReader (talk) 10:16, 9 November 2021 (UTC)[reply]
  7. This would make process more complex, and for little gain. Neutralitytalk 05:31, 9 November 2021 (UTC)[reply]
  8. Useless. Would support the obligatory version above, not sure why it was withdrawn. --Piotr Konieczny aka Prokonsul Piotrus| reply here 23:14, 9 November 2021 (UTC)[reply]
    @Piotrus: Because the problem being addressed in point 6 is "Because RfA carries with it lifetime tenure, granting any given editor sysop feels incredibly important" -- the advantage of the probationary process over the current process in addressing this issue is independent of whether it is obligatory or optional. (There are other reasons for thinking that making it mandatory would be a good idea, but they are not related to solving the particular problem here.) --JBL (talk) 12:12, 10 November 2021 (UTC)[reply]
    @JayBeeEll Not sure if we agree or disagree; but making all admins stand up for re-election every two years or so would be my preferred solution to this (and a number of other problems). Piotr Konieczny aka Prokonsul Piotrus| reply here 12:25, 10 November 2021 (UTC)[reply]
    @Piotrus: I think we agree substantively but disagree about what conclusions to draw :). This process and the one you propose share an advantage (elections to finite-length positions would be lower-stakes). I think the proposal I've made is the narrowest possible proposal that captures that advantage; in particular, it does not endeavor to solve "a number of other problems" at the same time. (Non-substantively: it seems like you are applying an absolute test -- is this exactly the thing I want? -- but you could also consider a marginal test -- would this change the status quo to be more like the thing I want? -- particularly because the exact thing you want is not going to happen as a result of this monster RfC process.) --JBL (talk) 12:43, 10 November 2021 (UTC)[reply]
    @JayBeeEll You are right it's a step in the right direction, but I don't see why we need to take such baby steps. We need re-election for all admins, and at the very least we can introduce it for all new admins. Making it 'opt-in' only is pointless, as it will make this a toothless forgotten trivia, like Category:Administrators open to recall. Hence I see your proposal as duplicating an existing toothless concept already, and endorsing it would just create more noise. Think big or go home, I say. Piotr Konieczny aka Prokonsul Piotrus| reply here 12:56, 10 November 2021 (UTC)[reply]
    @Piotrus: I don't see why we need to take such baby steps The answer to this question is political, not substantive: because this community is extremely small-C conservative and resistant to large-scale changes. Anyone could have proposed the thing you suggest, but no one did; if someone had, it would not have received consensus. In this context, "go big or go home" just means maintaining the status quo. (I am badgering too much; if you write a response here I promise to read it, but I won't respond unless requested.) --JBL (talk) 13:44, 10 November 2021 (UTC)[reply]
    I agree with you except in this case I think the small step is so small it is meaningless. Piotr Konieczny aka Prokonsul Piotrus| reply here 15:13, 10 November 2021 (UTC)[reply]
    So then you feel that because preferred larger steps won't gain consensus, we should take no steps at all? ProcrastinatingReader (talk) 22:08, 10 November 2021 (UTC)[reply]
    @Piotrus: the recall process is "toothless" because it doesn't exist. It is a collective delusion in the minds of those "open to recall" and those who believe them. Anyone can simply decline to be recalled when their conditions are met (and people have). By contrast, this proposal would be enforceable. The comparison point to make is that people still sign up to be recallable, and I believe almost all do so in good faith with full intention of their conditions being binding. Similarly, people would sign up to this scheme, and if it is enforceable then the main recall problem is inapplicable. (See also 6A.) — Bilorv (talk) 19:35, 10 November 2021 (UTC)[reply]
  9. Needless complexity that would create less admins, not more. Also wouldn't solve the core problem because people would just be on their best behaviour for 3-6 months. Probationary period tend to not be that useful. TonyBallioni (talk) 03:12, 11 November 2021 (UTC)[reply]
    @TonyBallioni: sigh In Section 6, "the core problem" being addressed is that RfA is an extremely unpleasant process because it is so high-stakes. This proposal addresses that directly by creating an alternative, lower-stakes process. It does not foreclose any existing routes to adminship, so cannot create "less admins". (Also, the proposed period is 2 years, not "3-6 months". Also, people being on their best behavior seems ... good?) --JBL (talk) 11:13, 11 November 2021 (UTC)[reply]
  10. RfA is bad enough to go through once. If I knew I'd have to go through it twice, I probably wouldn't have bothered. This will only discourage new admins from applying. —⁠ScottyWong⁠— 06:05, 11 November 2021 (UTC)[reply]
    @Scottywong: The proposed process is optional, if this passes no one will have to do anything differently. Also, I can't help feeling that saying "RfA is terrible" [it is] without addressing the straightforward way that this would make RfA less terrible sort of misses the point. --JBL (talk) 11:13, 11 November 2021 (UTC)[reply]
    I'm highly skeptical that simply allowing people to run for temporary admin terms will substantially change the experience of going through an RfA and the attitudes of RfA voters. —⁠ScottyWong⁠— 04:14, 12 November 2021 (UTC)[reply]
    @Scottywong: Would you apply the same standard to someone running for a 2-year term as admin as you would to someone running for a permanent position? And would you scrutinize someone running for a permanent admin position who already had 2 years of experience in the same way that you currently scrutinize candidates with 0 years of experience? --JBL (talk) 11:41, 12 November 2021 (UTC)[reply]
    In the first case, absolutely yes, I would scrutinize someone thoroughly who was attempting to be an admin for 2 years. A lot of damage can be done in 2 years. In the second case, I'd probably scrutinize a bit less, and focus on different things. —⁠ScottyWong⁠— 14:01, 12 November 2021 (UTC)[reply]
    Thanks for responding. My hope and belief is that there will be a decent-sized group of people inclined to apply a softer standard to candidates for a fixed-length term than they currently do for a permanent position. But if it turns out that I'm wrong about that, I agree that this proposal will not improve things at RfA. --JBL (talk) 14:11, 12 November 2021 (UTC)[reply]
  11. Going through RFA once is gruelling enough ... definitely wouldn't make them to do it all again. –Davey2010Talk 17:39, 11 November 2021 (UTC)[reply]
    @Davey2010: This is an optional process, no one would be forced to go through it. But also please consider: would you apply the same standard to someone running for a 2-year term as admin as you would to someone running for a permanent position? And would you scrutinize someone running for a permanent admin position who already had 2 years of experience in the same way that you scrutinize someone running with 0 years of experience? Because I think it's obvious that this proposal would make the RfA process much less gruelling. --JBL (talk) 19:17, 11 November 2021 (UTC)[reply]
  12. We could put "This process is optional! No, really!" in <blink>, <marquee>, and three nested sets of <big> tags, and it would still be effectively mandatory to suffer through before becoming a "full" admin. —Cryptic 19:25, 11 November 2021 (UTC)[reply]
    @Cryptic: Right now (= in all cases over the last 12 months), the only people who suffer through the process of RfA and become admins get 95% support and < 10 opposes. The tiny number of people who can muster that level of support will have no problem skipping this process (or, if they choose to go through it, will have no problem generating the same enthusiastic support they do currently). Meanwhile, for everyone else who currently looks at RfA and says "hell no", it creates a process where the stakes will be lower, and consequently where voters will not demand absolutely flawless candidates. Then, two years later, those people can run for a full RfA with two years of accumulated evidence of their suitability as an admin. Please consider: would you apply the same standard to someone running for a 2-year term as admin as you would to someone running for a permanent position? And would you scrutinize someone running for a permanent admin position who already had 2 years of experience in the same way that you scrutinize someone running with 0 years of experience? (Do I keep repeating myself? Yes, of course -- because so far there is almost total failure to engage with how this proposal works from the people who vote !oppose.) --JBL (talk) 20:39, 11 November 2021 (UTC)[reply]
  13. I am concerned this would lead to inflation of criteria for "full" adminship, and also that we would be asking some users to subject themselves to multiple RfAs, which is counterproductive if we're looking to make RfA less unpleasant. Vanamonde (Talk) 17:31, 12 November 2021 (UTC)[reply]
  14. A more complicated rephrasing of 7A (which I also opposed). Also JayBeeEll, kindly refrain from badgering the opposition. -FASTILY 01:25, 14 November 2021 (UTC)[reply]
    @Fastily: (disclaimer:I supported both this and 7A); I think 7A was mostly about getting admin access - but only being allowed to use it for specific purposes, the timing part was an additional control; this is not usage bound, it is only time bound - it would still create otherwise "normal" administrators. You certainly can oppose them both for having a time bound, or separately for any reason though! — xaosflux Talk 02:19, 14 November 2021 (UTC)[reply]
    Yes, it's the time-limit aspect. My criteria for reviewing candidates is simple: if I trust them with the tools, then I'll support their RfA. A probationary period with a followup review would not convince me to lower my standards. -FASTILY 02:34, 14 November 2021 (UTC)[reply]
  15. Per Hut 8.5. Espresso Addict (talk) 04:28, 14 November 2021 (UTC)[reply]
  16. Not convinced. I guess probationary adminship might be a possible consensus outcome at a regular RfA (compromise between +sysop forever and not +sysop forever), but I think Cryptic's point is valid. —Kusma (talk) 17:11, 19 November 2021 (UTC)[reply]
  17. This won't help generate more admins. The lack of individuals willing to run is the primary bottleneck, and this will make them go through the process twice. Now, unlikely many would fail the 2nd, but it fails to factor in the increased reticence to even start the process. The fact that it is technically optional would be irrelevant, as only those who would be slam-dunks anyway (and thus not so in the "difficult to encourage to run" camp) would not be pushed into doing it. Nosebagbear (talk) 08:46, 22 November 2021 (UTC)[reply]
  18. Not to be pessimistic, but I'm finding myself saying "Oh lord, not this again!" --Hammersoft (talk) 01:52, 27 November 2021 (UTC)[reply]
  19. Isn't the problem that we have too few candidates? Even fewer will be running if you make them go through RfA for all of two years. Sandstein 20:09, 29 November 2021 (UTC)[reply]
    @Sandstein: The problem identified in point 6 is "Because RfA carries with it lifetime tenure, granting any given editor sysop feels incredibly important". This proposal addresses that problem directly by lowering the stakes at RfA. The questions you should ask yourself in assessing whether this would work are, would you apply the same standard to someone running for a 1- or 2-year term as admin as you would to someone running for a permanent position? And would you scrutinize someone running for a permanent admin position who already had 1 or 2 years of experience in the same way that you scrutinize someone running with 0 years of experience? If your answers are "yes and yes" then you should oppose, but otherwise you should consider that this proposal could change the dynamic at RfA, making it a more attractive process for people who are not willing to go through the present version. (How it would look to the people who go through RfA as currently structured is practically irrelevant, since the number of them is tiny.) --JBL (talk) 03:26, 30 November 2021 (UTC)[reply]
  20. Try as I might, I just can't see this increasing the number of admins since, at least for a minority of !voters, it would likely become just another prerequisite. I appreciate JayBeeEll's argument that this minority would have little influence since most RfA candidates pass with 95%+ support, but it begs the question: why do most RfA candidates pass with 95%+ support? The answer, of course, is that most candidates won't touch RfA with a barge pole unless they're absolutely confident that they've dotted every "i", crossed every "t", and otherwise resolved every possible issue that might provoke opposition. Failure to run a temp-RfA will become just one more box that candidates will feel they need to check lest someone bring it up in their RfAs. (This is the same reason that substantial content creation has become a de-facto requirement even though there's never been a clear community consensus in support of insisting on it: while you absolutely can pass without it, a few vocal dissenters will make your RfA miserable nonetheless.) If candidates don't think they'll get 95%+ support, they won't run, full stop. As such, this "optional" process would become essentially mandatory since candidates just won't want to risk the increased skepticism that a first-time full RfA will provoke among some segments of the !voters. That requirement will, in Nosebagbear's words, generate "increased reticence to even start the process", making our already-bad dearth of candidates even worse. Extraordinary Writ (talk) 00:37, 30 November 2021 (UTC)[reply]
    @Extraordinary Writ: Since you have pinged me, I will ask of you the same question I have asked repeatedly of other voters (because it does not seem to be something oppose voters are addressing at all, unfortunately): would you apply the same standard to someone running for a 1- or 2-year term as admin as you would to someone running for a permanent position? And would you scrutinize someone running for a permanent admin position who already had 1 or 2 years of experience in the same way that you scrutinize someone running with 0 years of experience? For me, the answer to both questions is "no, obviously". I think that most voters will be like me in this regard. And if I'm right, then (this version of) the RfA process will become much less gruelling, and so it will become much less unpleasant to go through RfA, and that will create a virtuous circle that draws more people in. [If your attitude is "I would apply exactly the same standard to a candidate running for a 1-year term as administrator that I would apply to a candidate running for a lifetime position, and I would scrutinize a candidate with 1 year of admin experience in the identical way that I scrutinize a candidate who does not have any admin experience" then fine you should oppose this -- but I do hope/believe that most people would be more sensible than that.] --JBL (talk) 03:26, 30 November 2021 (UTC)[reply]
  21. Oppose. Making a person go through the RFA gauntlet twice does not seem to solve the original problem. In fact it may make it worse. I am also concerned that this could become like recall criteria, where every candidate is asked to do this, and the candidate is essentially penalized if they decline. –Novem Linguae (talk) 07:37, 30 November 2021 (UTC)[reply]
  22. Oppose The thought of getting someone to go through it twice if they want to be an admin strikes me as problematical.--Wehwalt (talk) 14:21, 30 November 2021 (UTC)[reply]
  23. Oppose People don't want to go through one RfA, asking them to go through two seem worse --Guerillero Parlez Moi 20:48, 7 December 2021 (UTC)[reply]
  24. The way to increase the number of admins isn't to make everyone RfA twice. – bradv🍁 15:16, 9 December 2021 (UTC)[reply]
    This is optional and opt-in. That said, the proposal's assumption is that allowing for an optional temporary term will mean both RfAs are less heated and stakes-heavy than a single permanent RfA. Assuming the proposal's assumption is true, and I think it is, then two RfAs with low stress is still less total stress than one RfA with high stress. ProcrastinatingReader (talk) 16:46, 9 December 2021 (UTC)[reply]
  25. Per Bradv and others.  — Amakuru (talk) 16:22, 9 December 2021 (UTC)[reply]
  26. "RFA is horrible, let's make it better by making people go through it repeatedly"..... No thanks. Beeblebrox (talk) 01:40, 10 December 2021 (UTC)[reply]

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 (talk·contribs) 19:06, 7 November 2021 (UTC)[reply]
    • @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)[reply]
      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 (talk·contribs) 20:12, 7 November 2021 (UTC)[reply]
      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)[reply]
      (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)[reply]
      That's a great point I hadn't thought of, so I've added my support. Giraffer (talk·contribs) 18:42, 10 November 2021 (UTC)[reply]
  • 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)[reply]
    Moved to a weak support, for a 1 year term only. Trainsandotherthings (talk) 20:00, 29 November 2021 (UTC)[reply]
    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)[reply]
    • 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}} talk 23:55, 7 November 2021 (UTC)[reply]
    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)[reply]
  • 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)[reply]
    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)[reply]
    Accurate on both counts. Retswerb (talk) 03:47, 30 November 2021 (UTC)[reply]
  • 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)[reply]
    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)[reply]
    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)[reply]
    "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)[reply]
    JBL, no one will ever really know until someone runs a search for stats. Wikipedia 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)[reply]
    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)[reply]
  • 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)[reply]
    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 Wikipedia 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)[reply]
  • The problem I see this actually solving is disinterested admins, the ones who pass RFA, are active as admins for a few months, maybe a year, then get bored and quit doing admin work. I have been and continue to be a supporter of removing admins who do not use the tools, but of course I realize that is not the actual intent of this proposal, and I do share the concern that this will become a de facto prerequisite for traditional permanent adminship. So I guess I'm on the fence. Beeblebrox (talk) 18:16, 8 November 2021 (UTC)[reply]
  • If this proposal gains consensus support, I think it would be better to name it something like "fixed-term adminship" rather than probationary. As it's optional, it's not a trial period before becoming a permanent administrator. Since it's up to the candidate to decide which route to take, the key difference is the length of term. isaacl (talk) 01:12, 12 November 2021 (UTC)[reply]
    Yes, I agree, "probationary" doesn't fit very well, and it would be good for someone to pick a better name should this come to pass. (It was more appropriate for 6D, and I didn't update it when I wrote the revised version.) --JBL (talk) 02:06, 12 November 2021 (UTC)[reply]
    Maybe "temporal" ? — xaosflux Talk 03:07, 12 November 2021 (UTC)[reply]
    Did you mean "temporary" (as opposed to related to time)? Personally I prefer fixed-term, which to me is more reminiscent of how volunteers sign up to take turns working on essential tasks. isaacl (talk) 05:49, 12 November 2021 (UTC)[reply]
    @Isaacl: I meant temporal, wikt:en:temporal#Adjective (usage 2.1). — xaosflux Talk 12:47, 12 November 2021 (UTC)[reply]
    OK; my only real-world experience with this adjective is where it meant related to time (e.g. temporal distortion) rather than related to a limited time. (Merriam-Webster's definition doesn't include limited time.) isaacl (talk) 16:21, 12 November 2021 (UTC)[reply]
    I like 'fixed-term adminship', but at the same time I don't think it really needs a name. An admin via this is just an admin, one that will have to go through reconfirmation but a full admin nevertheless, and should be willing to do any task they feel competent to do (whereas 'probationary admin' indicates otherwise). ProcrastinatingReader (talk) 10:04, 12 November 2021 (UTC)[reply]
    I'm not picky on this at all, think this would just be a term for the RfA option used, not for the resultant administrator themselves. — xaosflux Talk 12:47, 12 November 2021 (UTC)[reply]
    Yes, as Xaoxflux said, I only meant this term to describe the RfA option, and not the candidate or administrator. isaacl (talk) 16:21, 12 November 2021 (UTC)[reply]
  • Regarding every candidate being asked to specify recall criteria: it's been a long time since this question was in vogue, and as far as I recollect, it's been even longer since any candidacy was significantly affected by the response. (I don't know of any, but I've only paid attention to RfAs in years subsequent to their peak period.) Thus as far as precedence goes, I don't see this as a reason to believe that a significant number of RfA commenters will start requiring all candidates to first sign up for a finite-length administrative term. isaacl (talk) 07:59, 30 November 2021 (UTC)[reply]
  • Further note that no one during this RfC has said that they plan to make it a requirement for candidates to first complete a fixed term before being approved for an unlimited term. As the participants in this RfC are generally those most interested in the approval process for administrators, I feel it's unlikely that the views of other RfA commenters will diverge in numbers large enough to make a difference. isaacl (talk) 09:18, 30 November 2021 (UTC)[reply]

Issue 7: Admin permissions and unbundling

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

Closed: 7A Limited adminship

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
There is no consensus to implement this proposal. We have roughly the same amount of supports and opposes. The supports think that this is a good idea per nomination, but even some of them have doubts that it would work. The opposes think that the existence of the limited adminship can actually make the full RfA more difficult without obvious benefits; in addition, some opposers as a matter of principle oppose multiple-tier adminship. Whereas some areas which could profit from the attention of limited admins were mentioned, no way forward for this proposal, with any modifications, have been identified.--Ymblanter (talk) 09:48, 3 December 2021 (UTC)[reply]

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

Further details

If the request is successful, bureaucrats will grant sysop rights for the duration requested. Near the expiration of the grant, the same process may be used to renew the limited request or the normal RfA process may be used to request an indefinite grant.

Using tools for a purpose other than the requested task is tool misuse. Editors may raise complaints about tool misuse on the Administrators' Noticeboard to discuss whether the limited admin used their tools in excess of their agreed limitation. If there is a consensus that the tools were misused then a bureaucrat will desysop citing the community consensus. Limited administrators are also subject to existing Arbitration Committee procedures on desysopping.

Support 7A Limited adminship

  1. I don't know if this will genuinely help. It even has the potential of making it harder to generate non-limited admins. But I do think it has the possibility of success and certainly some potential use-cases. As such, it warrants a chance to run. Nosebagbear (talk) 16:33, 31 October 2021 (UTC)[reply]
  2. I think this could help; I'm sure non-limited admins will have enough trust and competence under their belts to still pass.  – John M Wolfson (talk • contribs) 16:38, 31 October 2021 (UTC)[reply]
  3. Like other user rights, we provide temporary grants to see if they can be trusted to use the tools. The temporary nature means that the user needs to use the rights and so we have users who can show that they can be effective admins. Many other projects have time limited admin rights, and although enwiki is different to these wikis I don't see why trialing this would be an issue. Furthermore, this means that if a particular editor is helpful in one area (let's say copyvio) but has no experience in deletion discussions, the editor doesn't need to demonstrate to the community that they are trusted enough to also be able to delete articles in deletion discussions. However, this does run the risk of making the current RfA harder (as people might oppose as they want to see a candidate go for the limited first). On the other hand, this might make running for a full RfA easier after a limited length adminship. Dreamy Jazz talk to me | my contributions 16:46, 31 October 2021 (UTC)[reply]
  4. Count me in. With a duration of 12 months, it practically becomes a mandatory recall after a year, for those who chose this path. I'd be willing to evaluate adminship performance and vote based on actual actions after a year. Less than a year, however, would be overly optimistic: People do need some time to make errors and learn from them without immediately facing a new election. ~ ToBeFree (talk) 17:09, 31 October 2021 (UTC)[reply]
  5. Sure, seems fine and fits in to the current structure without any large process or technical changes needed. That being said, I'm not sure how useful it will be (I don't expect a high number of candidates needing this). — xaosflux Talk 17:22, 31 October 2021 (UTC)[reply]
  6. Yes, works like a sort of internship or trainee program, candidate gains experience and trust and later can request permanent tools at RfA. Since RfA reforms were unable to address problems with standard requirements and level of scrutiny raises, we need different paths to get sysop flags. Carlosguitar (Yes Executor?) 17:56, 31 October 2021 (UTC)[reply]
  7. Support. I see this as a "catch-all unbundling" process, to cover the gaps that are not big enough for us to establish a mandate for a specific unbundling. That is, it's useful where a user has a genuine need, but the need may not be shared by hundreds of people. Once we see this succeeding in action, I'd likely support a longer term limit than 12 months, as well. I see others consider this as more of a "trial period admin", which is a perfectly fine reason to support the proposal as well. Most dissent is over this making RfA harder. Given that the community has literally just established a mandate that "No need for the tools" is a poor reason as we can find work for new admins, and that I so rarely see "no need for the tools" as a reason to oppose nowadays, I do not believe these concerns will be realised in practice, nor that we couldn't address it only if it actually turns out to be true (e.g. RfC for closing crats to discount "should have run for limited adminship" as a valid oppose). — Bilorv (talk) 19:54, 31 October 2021 (UTC)[reply]
  8. We routinely have unbundling proposals premised on the fact that many competent editors refuse to go through RfA just to get access to one or two tools (see my replied in the comments section). That is, in fact, an issue which achieved consensus in phase 1. We have editors who need tools, a broken process they refuse to use, and a reluctance to create new user groups to get them those tools. If the community refuses to create new permissions because those editors should just become admins, what options do we have left? This process grants access to editors interested in only a subset of the tools and because of that restricted nature avoids the most toxic elements of review at RfA that prevent these editors from running. As others have mentioned, there may be additional benefits for other use cases, but minimally we have a class of highly trusted editors who need tools and will not endure our existing hazing procedures. Other attempts to get them the tools they need failed, so this strikes me as the last best option. — Wug·a·po·des​ 20:44, 31 October 2021 (UTC)[reply]
  9. Other wikis do this without issue. --Rschen7754 02:43, 1 November 2021 (UTC)[reply]
    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)[reply]
  10.  ― Qwerfjkltalk 07:21, 1 November 2021 (UTC)[reply]
  11. Per Wugapodes. ProcrastinatingReader (talk) 09:32, 1 November 2021 (UTC)[reply]
  12. I certainly like this idea more than unbundling the admin tool set. Limited adminship is a thing on metawiki and to my knowledge it has worked well there. This may also finally prove to the community that doing a few niche things as an admin can still make you a very valued and productive admin. If a limited admin went a year and blocked hundreds of vandals without opposition, who cares if they are good at writing articles? That sort of change of mindset is what I'm hoping most will come out of RFA2021. — MusikAnimal talk 19:32, 1 November 2021 (UTC)[reply]
  13. Per MusikAnimal. KevinL (aka L235 · t · c) 23:25, 4 November 2021 (UTC)[reply]
  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)[reply]
  15. A better alternative than unbundling admin tools. I have doubts about whether this will work, but it's certainly worth a try. 🐶 EpicPupper (he/him | talk) 22:45, 7 November 2021 (UTC)[reply]
  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)[reply]
  17. I strongly support this. I have long felt that "partial admins" can do a lot of good work. It is why I became a rollbacker and later, when it was introduced, a template editor. Especially since many jobs are of a more technical nature, and do not require the high standards of other fields. I would have done certain admin jobs long ago (I am about 12 years here), if it were a possibility. Debresser (talk) 23:08, 8 November 2021 (UTC)[reply]
  18. Wugapodes said it better than I can. Schazjmd (talk) 18:20, 9 November 2021 (UTC)[reply]
  19. We badly need something like this to grant further users the right to edit the Main Page; too often no admins respond to requests even after 24 h. Jmchutchinson (talk) 18:35, 10 November 2021 (UTC)[reply]
  20. As theleekycauldron and Isabelle Belato mention, this would benefit users intending to specialize in niche areas requiring admins, which is incredibly important. See, for instance, this discussion concerning CCI, which really drives home the point regarding the bus factor. GABgab 02:37, 11 November 2021 (UTC)[reply]
  21. I like this a lot. I can think of plenty of editors I would trust for plenty of things, even though I might not be so thrilled about them having the entire toolset. SandyGeorgia (Talk) 21:22, 13 November 2021 (UTC)[reply]
  22. I can never quite figure out the whole, "If they want that tool, they should just run RfA" objection. I have interacted with multiple people who would be willing to, say, move a prep set to queue -- which in almost all cases receive days of scrutiny before actually appearing on the main page -- but have zero interest in any other admin tools, don't want to feel pressured to do other admin activities, and don't want to go through a full RfA. —valereee (talk) 16:53, 19 November 2021 (UTC)[reply]

Oppose 7A Limited adminship

  1. I'm afraid this will make it more difficult to gain full adminship. Furthermore, it will put additional bureaucracy in place (having to go through RfA twice if full adminship is required afterwards). These limited admins cannot help out at will at places with backlogs if that is not part of their purpose. If we have a large fractions of admins in this category, the resilience of the admin corps will further decrease. Femke (talk) 16:50, 31 October 2021 (UTC)[reply]
  2. I am fundamentally opposed to creating different "tiers" of admins. This is unneeded bureaucracy and creates second-class admins. The "limited admins" would still go through RfA anyways, so what is the benefit here? I don't foresee many cases where someone who could pass for a limited adminship would not also pass for a full adminship. Trainsandotherthings (talk) 16:56, 31 October 2021 (UTC)[reply]
  3. Per Femke. I can already envision the comments on full RfAs "Why wouldn't limited adminship be sufficient for that?" Soon enough, running first for limited adminship becomes a de facto requirement, and then candidates have to endure two RfAs rather than just one. If someone can't be fully trusted with the tools, they shouldn't have the tools; there shouldn't be some in-between state. {{u|Sdkb}} talk 17:34, 31 October 2021 (UTC)[reply]
  4. Oppose. Per Femke, Trainsandotherthings, and Sdkb. Kudpung กุดผึ้ง (talk) 20:07, 31 October 2021 (UTC)[reply]
  5. Oppose more or less per Femke. Unbundling is seductive, but counterproductive. Vaticidalprophet 21:51, 31 October 2021 (UTC)[reply]
  6. Per Femke and Sdkb, I fear that this would only worsen the dearth of admins. Extraordinary Writ (talk) 22:12, 31 October 2021 (UTC)[reply]
  7. Oppose, this would become a de facto requirement creating just another reason for arbitrary opposes. It will reduce the ability for new volunteers to actually help in a dynamic way(we don't know where the work will be in the future). This treats new admins as a lower tier and old timers as a sort of super admin. HighInBC Need help? Just ask. 23:03, 31 October 2021 (UTC)[reply]
  8. In practice, I think this would end up just being another hoop to jump through in order to become a full fledged admin. We need less hoops, not more. -- Tavix (talk) 00:32, 1 November 2021 (UTC)[reply]
  9. I'm afraid this will result in editors voting oppose during "full" RfAs and telling the candidate to seek a "limited" permission first before trying for the full thing. Isabelle 🔔 03:09, 1 November 2021 (UTC) Changing to support. Isabelle 🔔 00:34, 8 November 2021 (UTC)[reply]
    • Just to comment on this point, as many have raised it: the same concept exists on metawiki (for example) and isn’t a de facto requirement and it remains a minority of requests. While metawiki is not enwiki, the closest to evidence we have without implementing it is by looking at other wikis. ProcrastinatingReader (talk) 09:32, 1 November 2021 (UTC)[reply]
  10. Per above. Sounds nice in principle, but I foresee this leading to increased drama and becoming a barrier to "full" adminship -FASTILY 04:55, 1 November 2021 (UTC)[reply]
  11. I suspect this will make things worse. Candidates will be given a small subset of the admin toolkit and requests to give someone the current admin toolkit will be treated very suspiciously. Hut 8.5 09:46, 1 November 2021 (UTC)[reply]
  12. If I'm reading this right, limited adminiship would only last for 12 months. What happens after that? If we allow editors the chance to seek a specific admin tool or tools -- blocking, deletion, page protection, etc. -- fine. But I see no reason for having a time limit on it. -- Calidum 16:37, 1 November 2021 (UTC)[reply]
  13. Oppose. Agree fully with what was said by Trainsandotherthings, Femke, and Sdkb. Ganesha811 (talk) 19:22, 1 November 2021 (UTC)[reply]
  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)[reply]
    @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)[reply]
    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)[reply]
  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)[reply]
  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)[reply]
  17. WP:SLOP 🐔 Chicdat  Bawk to me! 10:56, 5 November 2021 (UTC)[reply]
  18. Something tells me that this will lead to even fewer full time administrators. Scorpions13256 (talk) 16:33, 5 November 2021 (UTC)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
    @力: 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)[reply]
    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)[reply]
  22. Oppose. We already have this: WP:PERM. JackFromWisconsin (talk | contribs) 15:33, 8 November 2021 (UTC)[reply]
    PERM cannot be used to assign temporary administrator rights, so I think you have misunderstood what this proposal is suggesting. Dreamy Jazz talk to me | my contributions 16:11, 8 November 2021 (UTC)[reply]
    @Dreamy Jazz I think they are talking about a perennial proposal -- Guerillero Parlez Moi 13:14, 9 November 2021 (UTC)[reply]
  23. I oppose a two-tiered adminship. Neutralitytalk 05:40, 9 November 2021 (UTC)[reply]
  24. In my experience, editors typically don't seek to become admins in order to perform a specific task in a specific amount of time. They just want to help out indefinitely with things like deletion, permissions, blocking vandals, etc. Putting a time limit on their ability to help out in these areas doesn't solve any problems. —⁠ScottyWong⁠— 06:08, 11 November 2021 (UTC)[reply]
    That's true of most admins, which is why the main RfA process should exist and remain intended as the primary route. This creates an additional, smaller route for those who don't want to do a myriad of tasks. ProcrastinatingReader (talk) 11:21, 11 November 2021 (UTC)[reply]
    Are you sure that such editors exist? If you want my support, you'd have to demonstrate that there is a significant set of editors who want to be admins for a limited time to perform a specific, time-limited task. —⁠ScottyWong⁠— 04:17, 12 November 2021 (UTC)[reply]
  25. Femkes, Trainsandotherthings' and Beeblebroxs have all said it better than I ever could so wont repeat them - Again like above I don't agree with going through RFA again once 12 months is up (because RFA is gruelling enough once!). In short it really should be a case of all or nothing. –Davey2010Talk 17:53, 11 November 2021 (UTC)[reply]
  26. Systems of limited adminship are quite useful for wikis like Meta, where the sysop toolkit contains rights other than the core rights (delete, block, protect, etc.), such as editing global abuse filters and the global spam, email and title blacklist. On enwiki, on the other hand, the admin toolkit is pretty much only the core due to unbundling in the past. Given this, I'm sceptical that limited adminship will be useful on enwiki. In case technical work needs to be done, we have enough admins to assist non-admins in that. JavaHurricane 10:14, 13 November 2021 (UTC)[reply]
  27. Not sure how workable this is. Who would patrol whether the limited admin only performed admin actions as specified? Some admin actions are fairly visible but, say, deletion often goes under the radar. If one wants to help out at DYK/ITN/mainpage errors, why the time limit? Would this really help at RfA, given that the main problem is trust, and we're still having to trust the limited admin with the complete toolset. Espresso Addict (talk) 05:27, 14 November 2021 (UTC)[reply]
    @Espresso Addict: I think one advantage of the time limit is as a compromise between the editors who want to see 'full admins' only vs those who want unbundled rights; it encourages the limited admin to seek renewal as a full admin rather than another limited admin term, with the successful tenure of limited adminship underlying their RfA. Regarding patrolling: it's not hard to check a limited admin is acting within scope; since admin log entries are in different logs, a 'DYK limited admin' should have an empty block, permissions change, etc log -- a bot could verify this if really necessary. ProcrastinatingReader (talk) 11:28, 15 November 2021 (UTC)[reply]
  28. Oppose - This process will create a two-tier system and a second class of admins which should not happen. People's preferences and interest in different areas of the project change over time. Moreover this will undoubtedly become a de-facto requirement for all future full adminship RfA's and it will force people to go through RfA twice. A better proposal suggested at 6E Initial probationary term (optional) looks much more better to try out on a trial basis because it is a time based adminship but is otherwise non-restrictive when it comes to using the admin tools as and when required. TheGeneralUser (talk) 09:32, 30 November 2021 (UTC)[reply]

Discussion 7A Limited adminship

  • Why do we care whether it limits requests for "full" adminship if all "full" adminship means is "admin for life"? Why do we care about tiers, ditto? —valereee (talk) 17:45, 31 October 2021 (UTC)[reply]
    • To split hairs, "full" isn't simply an indefinite grant. It's also an unrestricted grant. Limited administrators may only use their tools in specific areas for predefined tasks stated in their request and if they want to use the rest of the toolkit, they need an full RfA to evaluate that. It's not about creating tiers, but addressing a gap. As I mention in my comment below, many editors would like to help in particular areas but are not interested in a full RfA or in being an administrator at all. Proposals to unbundle tools so that we can accommodate those editors routinely fail. If the community will not unbundle permissions and editors needing tools refuse to go through a full RfA (for the reasons established in phase 1), this seems like the only possibility remaining. — Wug·a·po·des​ 20:10, 31 October 2021 (UTC)[reply]
  • Can we get a list of a few examples of "specific tasks" that could justify a limited RFA? User:力 (power~enwiki, π, ν) 17:49, 31 October 2021 (UTC)[reply]
    Move prep to queue at DYK. This simply requires someone who is experienced at DYK and is trusted to edit through protections at the level of the main page. It's an area often in short supply of admins. —valereee (talk) 19:51, 31 October 2021 (UTC)[reply]
    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)[reply]
    Editors interested in main page curation (see the failed Wikipedia:Main page editor proposal from 2020); deletion of copyright violations (see discussion at issue P in phase 1); editors doing antivandalism response (see failed Wikipedia:Vandal fighters proposal from 2015 and failed unbundling semi-protection proposal from 2018). These usually fail for some variation of "anyone who would use these should just be an admin" without regard for the fact that lots of people who would use these perms don't actually want to be an admin or go through a full RfA (explained in more depth at the main page editor RfC). — Wug·a·po·des​ 20:09, 31 October 2021 (UTC)[reply]
  • A crat could give the details of how this works, but I recently discovered that granting adminship for a time-limited duration is something the current software already supports. We already have several examples of granting temporary use of various tools for special projects. Don't arbcom election scrutinizers get temporary checkuser access? And WP:Event coordinators get some temporary admin-ish abilities. -- RoySmith (talk) 01:03, 1 November 2021 (UTC)[reply]
    @RoySmith: as far as mechanics: the "expiration" part would be handled by the software automatically (when granting the access, the expiration would be specified by the 'crat); the limits on usage would simply be policy based (e.g. If you asked for this access to just work on a project to delete old versions of PDF files, then started blocking people - you would be held accountable - likely blocked by other admins - pending access removal discussion). — xaosflux Talk 11:36, 1 November 2021 (UTC)[reply]
    Hell, I currently have temporary page mover rights. WP:PERM is allowed to give out temporary rights as a trial period. — Bilorv (talk) 11:50, 1 November 2021 (UTC)[reply]
  • @Rschen7754: "Other wikis do this without issue." Would be nice to hear of some examples. I did apply for Global Rename on Meta a while back; is that the sort of thing you were thinking of? Ritchie333 (talk) (cont) 14:48, 1 November 2021 (UTC)[reply]
    • @Ritchie333: the only project that comes to mind that uses only rules to restrict limited admins is meta-wiki. Here we have adminbots, which slightly touch this (they have access to all tools, but are limited by rules to only use certain tools in certain cases - of course we also only allow these to be run by full admins). Several other projects have advanced usergroups such as interface-editor (not to be confused with global interface editor), eliminator, and engineer which are limited administrator types that also have technical controls. — xaosflux Talk 15:23, 1 November 2021 (UTC)[reply]
    • There are some arbcoms (I think dewiki is one) that have non-admins, where adminship is granted for the duration of their term and removed thereafter. Even we do it with the ArbCom steward scrutineers - they only have it for a limited time and can't go around CUing editors at will, they can only use it for the scrutineering. Test administrators on Incubator [2] is another example - while technically they have near-full admin access, they can only use the tools on their test. --Rschen7754 18:14, 1 November 2021 (UTC)[reply]
  • In response to "If a limited admin went a year and blocked hundreds of vandals without opposition, who cares if they are good at writing articles?" Theoretically, that's not an issue, but if and only if they are 100% correct all the time. Then I'm interested in how they manage mistakes (do they apologise and make amends, or ignore it and dig their heels in) and that is what makes a difference. Ritchie333 (talk) (cont) 22:22, 1 November 2021 (UTC)[reply]
  • @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)[reply]
    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)[reply]
  • 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)[reply]
  • 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 Wikipedia. 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)[reply]
    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)[reply]
    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. That depends on how the apprentice role is structured. Applicants could be told that they would be expected to work on backlogs and other administrative tasks and that their efforts would inform a future RfA.--agr (talk) 17:28, 8 November 2021 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Closed: 7B Researcher userright

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
This motion fails to garner enough support to overcome the opposition. Primefac (talk) 09:29, 3 December 2021 (UTC)[reply]

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

Further details

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

Support 7B Researcher userright

  1. Support practically-automatic granting of this right to SPI clerks who have finished their training and are trusted by checkusers. ~ ToBeFree (talk) 17:02, 31 October 2021 (UTC)[reply]
  2. Support, as proposer.—S Marshall T/C 17:18, 31 October 2021 (UTC)[reply]
  3. The reasons an editor might want access to deleted content are often different from the rest of the toolkit. Also, the reasons to restrict access to deleted content are different from the rest of the toolkit. This permission won't be super-common, but that's a good thing -- it avoids the concerns that successfully obtaining the researcher userright will become an unofficial pre-requisite for RFA. User:力 (power~enwiki, π, ν) 17:43, 31 October 2021 (UTC)[reply]
  4. I have always seen viewing deleted content as a part of the toolkit which often is an outlier to other admin rights. By viewing deleted text you do not get any resulting admin like action which effects other users (except from maybe being able to share the deleted text, but this requires an extra step). Although in theory you could "undelete" the text by copying the wikitext into an edit window and then saving it, this would be something which IMO should lead to removal of the userright. For most really bad stuff (like privacy breaches) oversight is used. It allows users with a real need to see deleted content (like SPI clerks) to get access without having to become an admin (and all the extra work / stuff that comes with). I think that anyone with this right should have appropriate account security in place and should go through some sort of community discussion (as this is a requirement from the WMF I think). Dreamy Jazz talk to me | my contributions 18:40, 31 October 2021 (UTC)[reply]
  5. Support. Use cases include for SPI and anti-vandal fighting, as referenced above. For XfD, DRV and other deletion-related processes, it is necessary to participate in a discussion with full information; its usage in copyright-related areas like CCI should be obvious. Currently, G4 is a silly CSD criterion because a non-admin can't know whether an article is eligible or not, unless they happen to (a) have seen and (b) remember in near-perfect detail the content of a page that is now deleted. This would also expand democracy in the cases where we are discussing misconduct issues, like vandals whose vandalism is mostly on now-deleted pages. It would be particularly important in cases of admin misconduct relating to now-deleted pages, where it is currently only admins and any non-admin who saw and remembers the page content who can properly contribute to the discussion and form a consensus. (A decision about admin conduct made only by admins will have obvious systemic biases.)
    It would be useful to me on a content creation basis: I often want to view the content of deleted drafts or AfD'd or CSD'd articles when recreating the same topic or a related one. The first use case is in establishing that I have new references to present to improve upon the declined draft or AfD'd article—without this, I'm potentially wasting several hours of my time rewriting content that was already considered by another editor and decided to fail GNG. The second usage is that viewing old drafts or content that was since redirected often gives me leads to look for or references I can re-summarise in my own words. As such I can either go to WP:REFUND (generally by the point it's refunded it will no longer be of use to me, as I'm past my initial search for sources) or lose out on useful information, just because the page happened to be deleted, not redirected. — Bilorv (talk) 20:24, 31 October 2021 (UTC)[reply]
  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)[reply]
  7. Sure, for SPI and anti-vandal fighting. 🐶 EpicPupper (he/him | talk) 22:46, 7 November 2021 (UTC)[reply]
  8. There should be some mechanism for trusted users to viewdeleted without requiring full-blown admin. Feoffer (talk) 01:55, 8 November 2021 (UTC)[reply]
  9. Personally this would be useful to me for CCI clerking, so support. Iazyges Consermonor Opus meum 18:52, 8 November 2021 (UTC)[reply]
  10. On balance, mostly per the stuff at Wikipedia:Arbitration Committee/June 2008 announcements/Activation of view-deleted-pages. There are valid reasons to need access to see deleted content. The right shouldn't be called researcher, for the record. ProcrastinatingReader (talk) 19:38, 8 November 2021 (UTC)[reply]
  11. View deleted is useful when checking a candidate's edits at RFA, and to deal with some queries at the teahouse and elsewhere. ϢereSpielChequers 17:51, 11 November 2021 (UTC)[reply]
  12. Yes, same reasoning as Bilorv, Foeffer and ProcrastinatingReader. SandyGeorgia (Talk) 21:25, 13 November 2021 (UTC)[reply]
  13. Support - I'm open and supportive to un-bundling userrights on a case by case basis. It might even be better to create a related but brand new userright from scratch which would enable in viewing deleted pages and deleted content through a proper community wide RfC, but if the researcher userright is sufficient and would meet that need, then I think we can un-bundle it. TheGeneralUser (talk) 10:20, 30 November 2021 (UTC)[reply]

Oppose 7B Researcher userright

  1. I think this is a bit too much bureaucracy. The law of the instrument applies, and I feel that if I can't trust someone to block or protect, then I can't trust them to view deleted material, which has some actual legal implications.  – John M Wolfson (talk • contribs) 16:16, 31 October 2021 (UTC)[reply]
  2. Weak oppose because I don't think this is going to fix anything, I'm all for making another group of people with some tools to do some work - but this doesn't sound like the right tool bag to make a process for. — xaosflux Talk 17:19, 31 October 2021 (UTC)[reply]
  3. Strong oppose. It invites too many opportunities to be used for personal agenda. Kudpung กุดผึ้ง (talk) 20:10, 31 October 2021 (UTC)[reply]
  4. I agree with xaosflux. If the goal is to grant viewdeleted etc to certain editors, I would rather we craft a user group tailored to the particular use cases with all the necessary tools rather than co-opt a user group meant for something completely different. From a meta-perspective, this will also create problems for oversight by polluting the namespace. As it is, we can see who is researching our deleted contributions and easily keep tabs on the WMF research activities. If we start granting this for other purposes we make it harder to observe actual researchers and their activities by hiding them amongst editors doing completely different things. I would be very willing to create a new user group, but I'm opposed to scope creep for the researcher user group. — Wug·a·po·des​ 20:53, 31 October 2021 (UTC)[reply]
  5. Sorry but these are some of the most sensitive userrights in the admin bundle. Looking through deleted revisions of a userpage often yields sensitive information and is not logged. What is more these researcher admins will not really be solving the lack of admin problem, because they will not be doing anything productive. There is no way at all to vet if they are using the tools in a way that would support greater access in the future. HighInBC Need help? Just ask. 23:05, 31 October 2021 (UTC)[reply]
  6. On the surface this seems like a good thing and it is just going by the policies, but WP:REVDEL has been used in too many cases where oversight should have been used instead for me to be comfortable with allowing broader access to it. Chess (talk) (please use {{reply to|Chess}} on reply) 04:05, 1 November 2021 (UTC)[reply]
  7. No. Researcher should only ever be granted by WMF. I have no desire to expand the audience of deleted edits. Anarchyte (talk) 06:32, 1 November 2021 (UTC)[reply]
  8. Viewdelete is a dangerous thing to nonadmins. If you want viewdelete, don't ask the WMF for an obscure user right, run for adminship. 🐔 Chicdat  Bawk to me! 10:47, 1 November 2021 (UTC)[reply]
  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)[reply]
  10. I'm not buying that this actually solves any real problems. Beeblebrox (talk) 20:16, 1 November 2021 (UTC)[reply]
  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)[reply]
    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)[reply]
    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)[reply]
  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)[reply]
  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)[reply]
  14. This is a potentially dangerous userright because the action is not logged. Its an invisible action that could be silently abused without any scrutiny. Imagine bad Wikipedia content being harvested and then republished elsewhere. Jehochman Talk 08:24, 5 November 2021 (UTC)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
  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)[reply]
  16. There's a reason there are only three dedicated researchers on the English Wikipedia 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)[reply]
  17. I am not persuaded that this solves a real problem. Neutralitytalk 05:41, 9 November 2021 (UTC)[reply]
  18. I can't imagine any reason why any typical editor would need to do things like view deleted content, without the ability to also hide content, block users, etc. —⁠ScottyWong⁠— 06:10, 11 November 2021 (UTC)[reply]
  19. Genuinely didn't have a clue this userright even existed! - The very fact only 3 out of 42 million users[3] have this userright tells you all you need to know. –Davey2010Talk 18:03, 11 November 2021 (UTC)[reply]
  20. Per above. Doesn't actually solve a real problem. Also, if I were to trust someone with access to deleted revisions, I'd also support their RfA. -FASTILY 01:31, 14 November 2021 (UTC)[reply]
  21. Per Dennis Brown, HighInBC and others. I do sometimes trawl deleted material (eg to try to assess what proportion of expired drafts were viable) and there's some seriously problematic stuff in the heap that should not be widely accessible. Espresso Addict (talk) 05:42, 14 November 2021 (UTC)[reply]
  22. I don't see what this solves, and it comes with risks that I find unacceptable. Trainsandotherthings (talk) 20:03, 29 November 2021 (UTC)[reply]

Discussion 7B Researcher userright

  • I'd have to query to John as to how the law of the instrument applies here. Viewdelete doesn't offer any methodology to enact an outcome (where a different tool would usually be used) because it has to executive action inherent. Additionally, while I agree as to the "trust" issue, adminship necessitates both "trust" (which is across the board) and "competence" (which can differ in areas). Someone could meet the trust aspect, but not say sufficient competence you'd want them deleting, but more than enough to act safely with hidden edits. Nosebagbear (talk) 16:29, 31 October 2021 (UTC)[reply]
    • I'd say that being able to view deleted material without yourself being able to delete material would be a bit of a waste, and if I'm not mistaken only 3(!) users actually have the userright. While it wouldn't be as bad as the true "law of the instrument" due to its lack of ability to do anything, it would still be such a waste that I would still oppose.  – John M Wolfson (talk • contribs) 16:34, 31 October 2021 (UTC)[reply]
  • Need to have a further think about this. Dreamy Jazz talk to me | my contributions 16:41, 31 October 2021 (UTC)[reply]
  • I recall stumbling across Wikipedia:Arbitration Committee/June 2008 announcements/Activation of view-deleted-pages, presumably written by a 2008 ArbCom. I think the premise there remains true and this is a useful tool to unbundle, although probably not have it called "researcher". I'm not sure about giving it to XfD regulars; it's a valid use-case on the surface, but then it creates a distinction between a "noticeboard regular" and everyone else, namely by providing technical advantages to the former group to review cases the latter might not be able to. It would just solidify a cabal. I prefer the current system, where pages are generally temporarily undeleted for everyone to see. I wouldn't want to see that become less common just because more DRV regulars were able to see deleted text. ProcrastinatingReader (talk) 18:45, 31 October 2021 (UTC)[reply]
    • There's already such a cabal (administrators) in all areas where viewing a deleted page is relevant to a decision but the page cannot be undeleted. The request is about expanding membership of the cabal, which would hopefully make it less cabal-like. In cases where the page in question can be undeleted, we do need to see people asking for temporary undeletion and I hope such requests would not decrease, except where they are genuinely no longer needed by anyone participating in the discussion. — Bilorv (talk) 20:24, 31 October 2021 (UTC)[reply]
  • I'd support this idea in theory, but I'd be curious to first hear whether or not the WMF Office has any objections to this, legal or otherwise, since they currently control access to the group if I'm not mistaken (I believe only stewards and Jimbo have the ability to actually manage this group). Taking Out The Trash (talk) 19:02, 31 October 2021 (UTC)[reply]
    @Taking Out The Trash: they won't; they care more about the underlying permissions than the "group" - and we are already allowed to issue those permissions after a showing of community support (e.g. at RfA). There is already plenty of precedent for more powerful non-admin groups that include this access on other projects. (e.g. eliminator@fawiki and arbcom@fiwiki) — xaosflux Talk 19:21, 31 October 2021 (UTC)[reply]
    @Xaosflux:, I wouldn't call fa.Wiki (845,736 articles) and fi.Wiki (519,290 articles) 'plenty of precedent'. If they were a major language Wikis, such as e.g. German or French, maybe. Kudpung กุดผึ้ง (talk) 21:26, 8 November 2021 (UTC)[reply]
    @Kudpung: certainly not comparable in size - but that it is not unusual, the following projects have groups with (deletedtext) access given to groups other then admin/botadmin/checkuser/oversight: cswiki, fawiki, fiwiki, jawiki, nlwiki, plwiki, ptwiki, ruwiki, viwiki, viwikibooks (6 of which are in 1MM+ article projects). — xaosflux Talk 23:04, 8 November 2021 (UTC)[reply]
  • Not going to oppose this because I think there are a few niche use cases where it might be useful but I don't think it'll be much benefit either. For example non-admins who want to see deleted content at DRV can request temporary restoration (which is usually granted) or look at the article in some archive. Hut 8.5 19:20, 8 November 2021 (UTC)[reply]
  • This proposal is another classic example of one that has nothing whatsoever to do with RfA reform, i.e. encouraging more candidates and reducing the toxic nature of the process. There is no harm in suggesting unbundling or creating new user rights, but they are far from what I understood to be the original goal of Barkeep49's mission and should be reserved for another time and another place. Kudpung กุดผึ้ง (talk) 21:26, 8 November 2021 (UTC)[reply]
    I will have a lot more to say about the whole process, and where I think the process worked, where it didn't, and what I would have done differently if I had it to do over again, when we know what the results are. But I will say that we have 15 proposals which is not I think an overwhelming number of ideas. I agree that some ideas have ventured farther from RfA itself than others. However, a proposal like this happens because there was a rough community consensus that 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. Best, Barkeep49 (talk) 21:46, 8 November 2021 (UTC)[reply]
    @Barkeep49:, I don't deny that there will be some good to come out of your project and it needed to be done, but I have already left a more detailed explanation on the meta side of it on the talk page. Kudpung กุดผึ้ง (talk) 23:29, 8 November 2021 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Closed: 7C Unbundle blocking from the admin rights

SNOW closed as unsuccessful. Barkeep49 (talk) 16:18, 7 November 2021 (UTC)[reply]

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

Extended content

Support 7C Unbundle blocking from the admin rights

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

Oppose 7C Unbundle blocking from the admin rights

  1. Sorry, this proposal is way to vague to support as it is. — xaosflux Talk 17:17, 31 October 2021 (UTC)[reply]
    Once a bit more became available: While I'd be open to consider ways to extend permissions like 'block' to others, I'm very opposed to actually removing that permission from sysops - being able to stop active disruption is an important task that all admins should be able to do. — xaosflux Talk 10:45, 4 November 2021 (UTC)[reply]
  2. Blocking and unblocking should be held by the same groups. I do not support allowing any user group to block without the power to unblock as well. Accidental blocks do happen. Trainsandotherthings (talk) 17:21, 31 October 2021 (UTC)[reply]
    @Trainsandotherthings: There is no unblock right. Blocking and unblocking are both controlled by the "block" right, AFAIK. Nosferattus (talk) 18:00, 31 October 2021 (UTC)[reply]
    If so, and you are probably right, that would eliminate my original oppose reason. I do also oppose it on the basis that blocking and unblocking are fundamental parts of the admin toolkit that should not be unbundled. Trainsandotherthings (talk) 18:05, 31 October 2021 (UTC)[reply]
    Interestingly, MediaWiki lacks documentation about this. I have now created phab:T294710 asking for this to be fixed. ~ ToBeFree (talk) 18:24, 31 October 2021 (UTC)[reply]
  3. I could possibly support unbundling some subset of the blocking permission (along the lines of this), but the ability to block anyone at all should, if anything, be harder rather than easier. Extraordinary Writ (talk) 17:26, 31 October 2021 (UTC)[reply]
    Why do you assume it would be easier? I very much doubt that would be the case. Nosferattus (talk) 17:55, 31 October 2021 (UTC)[reply]
    See below; let's keep the discussion there ~ ToBeFree (talk) 18:06, 31 October 2021 (UTC)[reply]
  4. I oppose any more unbundling, almost on principle.  – John M Wolfson (talk • contribs) 17:27, 31 October 2021 (UTC)[reply]
  5. I strongly suspect this will lead to blocking being treated as a big deal. The block button really shouldn't be that contentious. Take a look at the people who are actually getting blocked: the vast majority are vandals, spammers or sockpuppets, and the rest are largely very new users who are doing something obviously disruptive. Hut 8.5 17:37, 31 October 2021 (UTC)[reply]
  6. Half-baked idea. Creating a cadre of admins that can't patrol AIV is not an improvement. There is a perennial suggestion to limit blocking of extended-confirmed users; though even there admins should have a break-glass ability to block compromised or stealth-vandalism accounts. User:力 (power~enwiki, π, ν) 17:57, 31 October 2021 (UTC)[reply]
  7. In it's current form, I don't support this. Dreamy Jazz talk to me | my contributions 18:24, 31 October 2021 (UTC)[reply]
  8. Oppose. Like John M Wolfson, I oppose on principle any further unbundling of what's left in the admin toolset. Otherwise what's the point in having admins? And most definitely the power to block. Such a user right is what all the hat collectors would be standing in line for. Kudpung กุดผึ้ง (talk) 20:16, 31 October 2021 (UTC)[reply]
  9. This is a non starter. The phrase half-baked has come up and I agree. Once again this idea creates lesser admins and old timer super admins. HighInBC Need help? Just ask. 23:07, 31 October 2021 (UTC)[reply]
  10. I would never support such an outrageous proposal; blocking has always been one of the three core admin tasks: Block, delete, protect. Giving it to others would wreck the encyclopedia. 🐔 Chicdat  Bawk to me! 10:44, 1 November 2021 (UTC)[reply]
  11. No way. If somebody vandalises today's featured article page with Nazi insignia or hardcore pornography (I've seen both), you don't want to wait - you hit the block button there and then so they can't easily retaliate. Ritchie333 (talk) (cont) 14:28, 1 November 2021 (UTC)[reply]
  12. I think #7A Limited adminship is the better proposal. To do counter-vandalism properly you need to be able to also protect and delete pages. — MusikAnimal talk 19:50, 1 November 2021 (UTC)[reply]
  13. Terrible idea. Admin tools are a set, an admin that can't block anyone might as well not be an admin at all. Beeblebrox (talk) 20:17, 1 November 2021 (UTC)[reply]
  14. Not to pile on, but blocking is a core tool that every admin needs, even if they do not use it much. And I wouldn't want an admin that only had the block tool, obviously, so there isn't use for debundling it. Dennis Brown - 2¢ 00:08, 2 November 2021 (UTC)[reply]
  15. As above. Blocking is probably the least unbundleable. ~ Amory (u • t • c) 14:29, 3 November 2021 (UTC)[reply]
  16. SpencerT•C 20:54, 3 November 2021 (UTC)[reply]
  17. Blocking is highly scrutinized and frequently reversed. No need to unbundle. Jehochman Talk 08:26, 5 November 2021 (UTC)[reply]
  18. Even if this came with the understanding that the group would only be granted to admins. Every admin task needs access to blocking. —Cryptic 08:36, 6 November 2021 (UTC)[reply]
  19. Block, protect, and delete are too related to each other to unbundle any of them. -- Tavix (talk) 17:03, 6 November 2021 (UTC)[reply]

Discussion 7C Unbundle blocking from the admin rights

  • How would someone apply for membership in the blocking usergroup? Wouldn't the result be easier access to the blocking usergroup than to the sysop usergroup? That doesn't match the reasoning, then. ~ ToBeFree (talk) 17:05, 31 October 2021 (UTC)[reply]
    The same way you apply for membership to other usergroups. Why do you assume it would be easier? I imagine it would be harder as the scrutiny previously used for admins would be transferred to the new blockers user group. Nosferattus (talk) 17:53, 31 October 2021 (UTC)[reply]
    Ah. I think your argument is based on the – I'd say incorrect! – assumption that more than half of RfA's scrutiny is caused by the blocking permission alone. Page deletion, history modification and even editing access to the main page are bundled. Additionally, if this really works like WP:PERM, all that's needed to receive the permission is one single administrator who trusts the user enough. That's much easier than passing RfA. ~ ToBeFree (talk) 18:03, 31 October 2021 (UTC)[reply]
  • Do we really want anyone blocking people who thinks, "I'd like to block people! Think I'll apply for that right!" When I ran RfA, I though blocking anyone would be a rare occasion. It's not something I do a lot of, but I do use that tool. —valereee (talk) 18:47, 31 October 2021 (UTC)[reply]
  • If the admin user group is unbundled, block/protect should be together in one group, and delete/viewdeleted in another. We wouldn't need to have an RfA for the first group. (If we wanted to do that.) Levivich 21:13, 31 October 2021 (UTC)[reply]
    @Levivich, sorry, I'm stupid today...we wouldn't need an RfA for block/protect? —valereee (talk) 21:19, 31 October 2021 (UTC)[reply]
    IIRC the WMF wants "community vetting" for the viewdeleted permission, but not for block or protect. So we could have a system where the "delete admins" give the block/protect perm out like it was Template Editor or Page Mover. Or where everyone gets block/protect after hitting some criteria like 10k edits and two years without sanction. I think that would be very interesting, and would lead to quicker resolution of chronic disruption between veteran editors. :-) Levivich 21:20, 31 October 2021 (UTC)[reply]
      ~ ToBeFree (talk) 22:27, 31 October 2021 (UTC)[reply]
    Giving out block automatically is scary to me. I see too many editors with 10k edits who still don't understand the speedy deletion process or WP:BITE and make a hash of things -- having them also be able to block anyone who didn't get their first attempt at a page perfect will scare off every possible new editor for sure.--Fabrictramp | talk to me 00:34, 3 November 2021 (UTC)[reply]
  • Shameless plug for Wikipedia:Requests for comment/Responder role. Enterprisey (talk!) 01:20, 4 November 2021 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Passed: 7D Remove autopatrolled from default toolkit

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
Tracked in Phabricator
Task T297058
This motion passes. Those opposed were concerned that a) this doesn't fix RfA, b) admins should be trusted with creating articles, and c) this would put more of a burden on the already-strained NPR process. The rebuttals for (a) and (b) were that it would remove some of the necessity of de-facto "requiring" that admins be prolific content creators, and that some desysops in the past could have potentially been prevented if autopatrol was not part of the equation. Those in support did not heavily comment on the affect at NPR, but mostly did agree that having a second set of eyes on any new page is a positive thing; admins who are confident and prolific can still grant themselves the perm. Primefac (talk) 09:38, 3 December 2021 (UTC)[reply]
(Post-close note: it was brought to my attention that there was a singular duplicate vote in this discussion; it did not significantly impact the close as it was not any sort of tipping-point comment, and the change was reverted purely to avoid any potential misunderstandings about the timeline of events. Primefac (talk) 15:54, 7 December 2021 (UTC))[reply]

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

Support (7D Remove autopatrolled from default toolkit)

  1. As proposer. Taking Out The Trash (talk) 18:56, 31 October 2021 (UTC)[reply]
    I feel like that removing autopatrolled from the toolkit by default would decrease the pressure/expectations of candidates having a large amount of content creation/content work/GA/FA/whatever under their belt. If admins did not become autopatrolled by default, it would open the door to having admin candidates that are exclusively or almost exclusively technical or countervandalism or some other non-content focus. Now before anyone says that having autopatrolled able to be self-assigned by admins doesn't actually alleviate the concerns, we don't currently expect candidates to demonstrate proficiency in managing edit filters even though they can assign EFM to themselves. This would be along similar lines. Moved from collapsed box as non-neutral explanation by proposer. Barkeep49 (talk) 19:00, 31 October 2021 (UTC)[reply]
  2. Support. I have seen definite cases of extremely sub-standard articles created by admins, particularly those who passed RfA long ago but have somehow not noticed that notability standards have increased since 2005 (and by "somehow not noticed" I mean "deliberately ignored every polite notification of this"). Passing RfA does not demonstrate competence at creating articles to a sufficiently high standard that we don't need a second pair of eyes on it, nor should it. We expect admins not to be fully proficient in all actions they can technically perform, but to read up on new areas before plunging in, and learn from constructive feedback they receive and consequences they observe. How can they do that in page creation without sufficient scrutiny in their actions? Autopatrolled is somewhat unique in that all it does is remove a vector of feedback you get, so we shouldn't be handing it out to someone with 3 page creations and 1 GA when the same person would not be granted it at WP:PERM. — Bilorv (talk) 20:42, 31 October 2021 (UTC)[reply]
  3. Letting admins self-assign autopatrolled instead of granting by default is, I think, a reasonable idea. I wasn't opposed for my article creations, but the relationship between my creations and autopatrolled was a point of discussion in my RfA. Like EFM, it's just not a tool that everyone needs, and if you do, you can give it to yourself. If not, let your contributions go through NPP. Personally, I might actually prefer that for myself since I don't create articles at a high volume. Regardless of the OP rational, I think it's just a good idea to let admins customize their toolkit a bit more and see very little downside. — Wug·a·po·des​ 20:59, 31 October 2021 (UTC)[reply]
  4. That's okay; I don't need it and wouldn't self-assign it. I was very relieved when my low amount of content creation didn't lead to many opposes. ~ ToBeFree (talk) 22:30, 31 October 2021 (UTC)[reply]
  5. I don't see why autopatrolled needs to stay as the default for admins, especially since many admins would not otherwise meet the autopatrolled criteria, and there have been issues with admins having autopatrolled in the past.Jackattack1597 (talk) 23:05, 31 October 2021 (UTC)[reply]
  6. I see no reason why this right should be auto-applied to admins. Administrative actions are carefully separated from content matters. If they are qualified for it then there is no reason they just can't get it the normal way. I don't see how this would help RfA, but it would probably help a little with article patrol.
    I don't believe it should be taken away from existing users without reason, though asking if they really need it is fine. HighInBC Need help? Just ask. 23:09, 31 October 2021 (UTC)[reply]
  7. Certainly an improvement; my only concern was that it was too trivial to justify the increased rule burden. Enough admins (or potential admins) appear interested in not having this permission, so this isn't an idle change. User:力 (power~enwiki, π, ν) 23:14, 31 October 2021 (UTC)[reply]
  8. Per above. -FASTILY 04:55, 1 November 2021 (UTC)[reply]
  9. This won't change anything about RfA, but I do like the idea of autopatrolled not being a part of the admin toolset. Anarchyte (talk) 06:57, 1 November 2021 (UTC)[reply]
  10. Very strong support. RfA is about administrative competence (sensibly) and doesn't really assure us that an editor can create articles that don't need a second pair of eyes. In general we have far too many autopatrolled accounts and far too low a standard for granting it, but that's definitely out of scope of an RfA RfC... – Joe (talk) 08:53, 1 November 2021 (UTC)[reply]
  11. I see no problem with this idea. Admins who frequently and appropriately create new articles can request autopatrolled (or even assign it to themselves) to avoid being a burden on NPP. Those who do so more infrequently probably could benefit from having a quick once-over on it when they do create one. Hopefully, this will reduce the "Oppose due to content creation" bit; that's not particularly relevant to being an admin and hopefully this change will make it clear that it is not. Seraphimblade Talk to me 10:10, 1 November 2021 (UTC)[reply]
  12. There have been a few discussions in the past year about autopatrolled (eg Carlos Suarez 46), and the ability to have autopatrolled separate from the admin toolset appeals to me a lot. 🐔 Chicdat  Bawk to me! 10:42, 1 November 2021 (UTC)[reply]
  13. Eh, I am not entirely convinced that this would have any effect. OTOH, it's always struck me as a little odd that autopatrol [which is a totally passive userright] is part of the default package. And I can't think of a reason why it would be bad if admins didn't have autopatrol. So, support. Jo-Jo Eumerus (talk) 11:23, 1 November 2021 (UTC)[reply]
  14. Don't see why not. You can still do plenty of article writing and convince the community of it at RfA without actually creating any new pages in mainspace. Ritchie333 (talk) (cont) 14:30, 1 November 2021 (UTC)[reply]
  15. Support. Also slightly reduces the adverse consequences in the inevitable circumstance when spammers become admins. MER-C 17:41, 1 November 2021 (UTC)[reply]
  16. Autopatrolled is chiefly about patrolling mainspace articles. Insufficient experience in content writing is a common excuse to oppose an otherwise great candidate at RfA. Thus, not having autopatrolled automatically in the sysop group may alleviate those concerns. Sure, you'll probably get conditional support !votes like "support if the candidate agrees not to make themselves autopatrolled", and similar social implications, but if the net result is adminship is less about content building than it is perceived by many today, it's a win to me. — MusikAnimal talk 19:58, 1 November 2021 (UTC)[reply]
  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)[reply]
    For the record, I don't see this as fixing the de facto content creation requirement for admins. I have always felt that folks who oppose/support a candidate for that reason do so because they want admins in general to have more thorough understanding of the content creation process. –MJL ‐Talk‐☖ 06:37, 12 November 2021 (UTC)[reply]
  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)[reply]
  19. Seems reasonable --Guerillero Parlez Moi 10:33, 2 November 2021 (UTC)[reply]
  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)[reply]
  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)[reply]
  22. Per above. ― Qwerfjkltalk 20:45, 4 November 2021 (UTC)[reply]
  23. Weak support. Dreamy Jazz talk to me | my contributions 13:24, 7 November 2021 (UTC)[reply]
  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 (talk • contribs) 17:28, 7 November 2021 (UTC)[reply]
  25. * Pppery * it has begun... 18:39, 7 November 2021 (UTC)[reply]
  26. Sure, why not? Jclemens (talk) 05:55, 8 November 2021 (UTC)[reply]
  27. Support. Long verdue. As someone who was heavily involved in patrolling new pages for many years and having had first-hand experience of admins abusing the autopatrolled right, I certainly believe it is time to remove this from the default admin toolset. Kudpung กุดผึ้ง (talk) 13:39, 8 November 2021 (UTC)[reply]
  28. Support and badly needed. Everybody needs a second set of eyes on their new article. Even page reviewers need to have someone else review their article. North8000 (talk) 22:19, 8 November 2021 (UTC)[reply]
  29. Levivich 14:48, 9 November 2021 (UTC)[reply]
  30. Per Jo-Jo Eumerus. Schazjmd (talk) 18:23, 9 November 2021 (UTC)[reply]
  31. I'm of the opinion that autopatrolled should be opt-in by default, even to the extent that perhaps it should be implemented by requiring autopatrolled users to manually mark their own creations as patrolled, for accountability and to enable them to seek a review in cases where they may be uncertain. This would be in-line with that, admins can self-grant this perm and in doing so they create a record which can be referred to if any issues arise. ASUKITE 18:00, 10 November 2021 (UTC)[reply]
  32. Not a huge thing, but it would be better if admins can choose whether they have it. — J947 ‡ message ⁓ edits 18:27, 10 November 2021 (UTC)[reply]
  33. Unlikely to have a major positive impact, but also harmless with no downside. --JBL (talk) 18:31, 10 November 2021 (UTC)[reply]
  34. I do think some demonstrated content creation competence is important, but this makes good sense to me. Cavalryman (talk) 23:05, 10 November 2021 (UTC).[reply]
  35. Don't see why not. Honestly I'd even support getting rid of the right altogether. There's more to article creation than writing; there's all sorts of wikification processes that are easy to forget, and are frequently better covered by a fresh pair of eyes. Though I'd likely assign it to myself at the moment, given high NPP queues and impossible AfC queues. Vanamonde (Talk) 17:35, 12 November 2021 (UTC)[reply]
  36. I mean, I don't see any reason why not. I'm doubtful it will have much impact, but I don't see any downside. Trainsandotherthings (talk) 17:37, 12 November 2021 (UTC)[reply]
  37. I agree it probably won't have a huge impact on RfA voting, but this just seems like a sensible change. Autopatrolled is a very different kind of right from the other admin tools. the wub "?!" 02:08, 17 November 2021 (UTC)[reply]
  38. No real downsides. —valereee (talk) 16:56, 19 November 2021 (UTC)[reply]
  39. Lowers the stakes at RfA. HouseBlastertalk 14:09, 22 November 2021 (UTC)[reply]
  40. I support this. People would be able to say "yes, I haven't created much content, and I won't give myself autopatrolled." Personally, I'd also prefer that people be banned from granting themselves autopatrolled anyway. YttriumShrew (talk) 07:07, 24 November 2021 (UTC)[reply]
  41. Support, as per Kudpung กุดผึ้ง above. --Whiteguru (talk) 07:41, 29 November 2021 (UTC)[reply]
  42. Full Support - Not every admin and potential admin candidate has the desire to create articles frequently and to have their creations marked as auto-patrolled. Removing this from the default admin toolkit will also lower the expectation that admins need to have a lot of high quality article and content creation because every person has different areas of interest which can change over time. Also, adminship is more about overall maintenance and administration of the project. Some admins might create articles occasionally and very rarely and would actually do not want their articles to be auto patrolled every time. Sure, an admin who is confident about his/her ability in creating good and high quality articles can self-assign auto-patrol to themselves just like EFM, but the rest of the admins can leave the patrolling of their creations to other editors. This change would be a very good and useful net positive. TheGeneralUser (talk) 10:43, 30 November 2021 (UTC)[reply]
  43. Support It would have stopped Wikipedia:Arbitration/Requests/Case/Neelix and Wikipedia:Arbitration/Requests/Case/Carlossuarez46, and anything that can stop Arbcom cases with no obvious downsides has to be a good thing. Ritchie333 (talk) (cont) 19:08, 30 November 2021 (UTC)[reply]

Oppose (7D Remove autopatrolled from default toolkit)

  1. No thanks, this minute tweak isn't going to solve the increased scrutiny for RFA candidates problem; I can't think of the last time someone got opposed for fear that they were incapable of creating a page that didn't meet the minimum acceptance criteria. — xaosflux Talk 19:04, 31 October 2021 (UTC)[reply]
    @Xaosflux: There seemed to be quite a few opposes related to "insufficient content work to be trustworthy with autopatrolled" at Wikipedia:Requests_for_adminship/1997kB. Granted, I wasn't active at that time, so there may be other context I'm missing. Taking Out The Trash (talk) 19:06, 31 October 2021 (UTC)[reply]
    @Taking Out The Trash: thanks for the note, regardless if I trust someone to assign patrol and autoparol to others, I trust them to use it appropriately themselves. That being said, I am in support of phab:T280890 (which would allow any autopatrolled page creator to unpatrol a page they create if they think it should have more scrutiny). — xaosflux Talk 19:10, 31 October 2021 (UTC)[reply]
    Assigning autopatrol seems very simple and uncontroversial if someone meets the requirements and has not gathered negative feedback from other editors. Being able to determine if an article is excellent is not the same skill as writing an excellent article. But, voting support at RfA is not saying "this person currently has the skills to work at Wikipedia:Requests for permissions/Autopatrolled", but "if this person chose to work there, I trust they would learn and prepare sufficiently by themselves to do so". As for opposition at RfA, one might expect that "oppose: no content creation" would be used and replied to a little bit differently if the most major content creation-related right is removed from the kit. — Bilorv (talk) 20:50, 31 October 2021 (UTC)[reply]
  2. Nope. If you don't have enough content work to be autopatrolled, you don't have enough to be a sysop, end of, full stop. This would be a nuisance for admin content creators such as myself, as well.  – John M Wolfson (talk • contribs) 19:08, 31 October 2021 (UTC) Too minor in any event to be of help, will only be a nuisance to admin content creators such as myself. – John M Wolfson (talk • contribs) 19:25, 31 October 2021 (UTC)[reply]
    To be fair, candidates pass RfA without autopatrolled all the time: it's not usually granted without at least 25 newly created articles, which is a far higher threshold than even the most ardent pro-content-creation !voter demands. Extraordinary Writ (talk) 19:19, 31 October 2021 (UTC)[reply]
    Fair enough, and I consider myself rather lenient on content creation so long as it's not "frighteningly negligible". Struck and replaced with a better oppose rationale. – John M Wolfson (talk • contribs) 19:25, 31 October 2021 (UTC)[reply]
  3. The autopatrolled right means that your creations don't need to be reviewed by NP patrollers, who are largely interested in filtering out articles which obviously need to be deleted and applying obvious maintenance tags (unreferenced, uncategorised etc). A candidate who genuinely can't manage that shouldn't be an admin. Nor do I see any argument that this will actually solve any issues with RfA. Are people actually more concerned about the autopatrolled right than block, delete or protect? This would also increase the workload of NP patrollers (a perpetually backlogged area), for no particular reason. Hut 8.5 09:42, 1 November 2021 (UTC)[reply]
  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)[reply]
  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)[reply]
    @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)[reply]
    @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)[reply]
  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)[reply]
  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)[reply]
  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 (he/him | talk) 22:39, 7 November 2021 (UTC)[reply]
  9. Oppose as irrelevant to solving any problems at RfA. ProcrastinatingReader (talk) 02:07, 8 November 2021 (UTC)[reply]
    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)[reply]
  10. Weak oppose, not relevant to RFA. Bigger problem is likely some non-admins having autopatrolled.Djm-leighpark (talk) 14:43, 8 November 2021 (UTC)[reply]
  11. Oppose procedurally as irrelevant to the more important question at hand, and substantially, since if an admin can just grant the right to themselves, all we're doing is adding a new hoop to jump for. I might be inclined to oppose if any editor who frequently argues oppose at RfA on the basis of low content creation would likely stop if we made this unbundling, but I am skeptical that that would happen. Has any such editor made such a declaration? --BDD (talk) 15:54, 10 November 2021 (UTC)[reply]
  12. If we can't trust an editor to create an article that doesn't need to be patrolled, then they shouldn't be an admin. Admins are expected to know and thoroughly understand the basic editing policies that govern the creation of new articles and content. —⁠ScottyWong⁠— 06:13, 11 November 2021 (UTC)[reply]
  13. Not relevant to RFA, also oppose per Hut. –Davey2010Talk 18:09, 11 November 2021 (UTC)[reply]
  14. An admin who can't be trusted with autopatrolled shouldn't be an admin.-- Pawnkingthree (talk) 17:38, 12 November 2021 (UTC)[reply]
  15. More or less for the same reasons as Trainsandotherthings's support. I don't see what problem this is going to fix. It just seems like creating a small amount of extra bureaucracy for no reason. —David Eppstein (talk) 08:38, 14 November 2021 (UTC)[reply]
  16. On further consideration, I'm going to oppose this one as well. If an editor can't be trusted to create adequate new articles they should not be an admin. As a committed Candidates Must Have Created Content commenter at RfA, simply unbundling autopatrolled would not be enough to shift my position (which is that this is an encyclopedia, so admins exist to support content creation, and must understand what that entails, including the several balancing acts necessary). Espresso Addict (talk) 00:16, 15 November 2021 (UTC)[reply]
  17. The notion that we can trust new admins to appropriately delete articles but not to create them is silly. Jonathunder (talk) 03:39, 15 November 2021 (UTC)[reply]
  18. Someone who can't write a decent article should not be an admin on an encyclopedia. 4nn1l2 (talk) 09:22, 29 November 2021 (UTC)[reply]
  19. In the early years of Wikipedia, some of the worst administrators have been people who got their mop early with the reason of "I fight vandalism a lot!" Then they roll into content disputes like a Wild West Sheriff, decree which side is "right", and shoot the other side as a bad guy vandal. Or are just generally not clueful. Any administrator who doesn't qualify for autopatrolled absolutely should not be an admin anyway - many of the tough calls admins make require content-creation background knowledge to distinguish situations like where one editor is politely breaking the spirit of Wikipedia rules & policies, and another is angrily breaking the letter of the rules to keep the intent. SnowFire (talk) 01:09, 30 November 2021 (UTC)[reply]
  20. Oppose. NPP backlog is currently around 10,000, and our current NPP backlog drive is barely making a dent. I see no reason to add a bunch of articles to the queue from admins, who are a very low risk group. In that sense, this is a solution looking for a problem... the problem of "admins contributing low quality articles", which I think is the exception and not the norm. –Novem Linguae (talk) 07:25, 30 November 2021 (UTC)[reply]
  21. Seems pointless to me.--Wehwalt (talk) 14:20, 30 November 2021 (UTC)[reply]

Discussion (7D Remove autopatrolled from default toolkit)

  • In response to John in the oppose section, my whole point is that sysops don't need content experience, frankly at all, in order to be an effective admin. Users who are exclusively dedicated to countervandalism efforts or other technical aspects would still make effective admins. Producing content doesn't actually involve the admin tools most of the time, and so whether or not someone can write an article to X standard isn't really indicative of their ability to use the (mostly technical-based) sysop tools properly. However, people expect sysop candidates to have content experience because the toolkit comes with autopatrolled. If it didn't this expectation wouldn't be necessary. Taking Out The Trash (talk) 19:35, 31 October 2021 (UTC)[reply]
    • I'm sorry, but I'm going to have to disagree with that point, as are many people. The fact that content creation is de facto required for adminship has nothing to do with autopatrolled, but is there because Wikipedia is an encyclopedia far before it's a technical/social clique w/ AN, ANI, ArbCom, etc.; all of that is built on our encyclopedic content. Indeed, as Amakuru said during the 1997kB RfA, candidates should have experience in the "coal face" boiler room before ever approaching the mop. People adamantly dislike restaurant owners who were not themselves chefs and don't take seriously club managers who never themselves played the sport; analogously, someone who is "running" Wikipedia without any experience with what Wikipedia actually does is generally not going to get very far. – John M Wolfson (talk • contribs) 19:47, 31 October 2021 (UTC)[reply]
      • I strongly agree with this comment, John M Wolfson, but not the argument you are using it to make. An autopatrolled level of content creation is not required for adminship, even though substantial content creation is. It seems you too don't require this in your votes, and have acknowledged that many RfAs pass with less than this level of ability. — Bilorv (talk) 20:54, 31 October 2021 (UTC)[reply]
  • This seems like it is nominally an improvement, but possibly not enough of an improvement to justify the rules creep. Are there any admins who would prefer not to have autopatrolled? Or editors who want an admin to not have autopatrolled? There's also the issue of whether "creating low-quality articles" should be considered "use of the admin tools" in finding cause to de-sysop. User:力 (power~enwiki, π, ν) 20:48, 31 October 2021 (UTC)[reply]
  • This idea could use a bit more research and refinement. I believe some other wikis have a similar setup, but I think those use pending changes. --Rschen7754 03:50, 1 November 2021 (UTC)[reply]
  • Keep in mind that autopatrol applies to all pages, and all pages are subject to new page review. It has some additional impact on new "articles", but that doesn't take away from new pages - and admins often create a lot of miscellaneous pages that shouldn't also need patrolling. — xaosflux Talk 11:31, 1 November 2021 (UTC)[reply]
    Ping to proposer: @Taking Out The Trash: - seems like this component was skipped in the review and this was presented as only being about "articles" when it actually applies to "pages". — xaosflux Talk 15:06, 1 November 2021 (UTC)[reply]
Not really sure what's being asked of me here. Taking Out The Trash (talk) 00:07, 2 November 2021 (UTC)[reply]
@Taking Out The Trash: it seems that the only thing presented about "autopatrol" is that it has to do with self-authoring new encyclopedia articles, however it actually has to do with the creation of all pages - everything from a new user talk welcome or warning, to many maintenance operations that an admin could run in to that deal with pages (including those in article space). — xaosflux Talk 00:11, 2 November 2021 (UTC)[reply]
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)[reply]
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 [4] to [5]. That this and this are in two separate logs kind of shows part of the problem.
Honestly, autopatrolled itself should be split to really only focus on the content creation part, so things like Wikipedia:New pages patrol/Redirect whitelist wouldn't be needed. –MJL ‐Talk‐☖ 17:37, 4 November 2021 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
    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)[reply]
    You'll also see that the vast majority of the 704 are inactive and that many of them should po0ssibly never have been granted NPR in the first place. Kudpung กุดผึ้ง (talk) 14:02, 8 November 2021 (UTC)[reply]
  • 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)[reply]
  • I strongly agree with John M Wolfson. Anyone who desires to police content should know how to create it. Having obtained 'autopatrolled' through scrutiny at PERM will put an end to the number of complaints at RfA 'Hasn't made any substantial creations' and hence will reduce some of the toxicity of the process. No one is really insisting on a raft of GA or a FA and the one serial opposer who did has now stopped it (or even retired). Kudpung กุดผึ้ง (talk) 14:02, 8 November 2021 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Closed: 7E New "Semi-protector" role

Closed as SNOW unsuccessful. The full responder role remains under development for future discussion. Barkeep49 (talk) 17:18, 14 November 2021 (UTC)[reply]

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 a new role, available to sufficiently experienced editors, that allows them to semi-protect pages for up to an appropriate duration, e.g., 72 hours.

Extended content

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

Discussion

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

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

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

  1. Oppose due to the implementation method, this design depends on these "group members" making a request to another admin, who would run a bot to just grant the requests. I'd prefer this be done software side, by splitting the protect permissions to be more granular with wgRestrictionLevels (e.g. permission protect-n can protect to restriction levels [array]), and maybe building the time controls in there too (though I'd be fine with that being just a policy); alternatively an extension that can handle some sort of short term protect/block could be a solution as well. — xaosflux Talk 00:48, 7 November 2021 (UTC)[reply]
  2. Definitely not. This would lead to many editors with this right protecting articles when blocking would be far more appropriate. This would cause a lot of collateral damage for IPs on these articles, and the disadvantages this proposal brings far outweigh the advantages. 🐔 Chicdat  Bawk to me! 12:18, 7 November 2021 (UTC)[reply]
  3. Blocking can be be more useful than protection in many cases. As such, giving some users the ability to semi-protect may lead to these editors semi-protecting because they can't block, where blocking is more useful and better for the article. For example, for an article which is in the current news there may be one static IP or new account who is vandalising which would be prevented from editing by semi-protection, but by protecting it stops many IPs and new editors from contributing to the article. As such I don't think this would really help. Dreamy Jazz talk to me | my contributions 13:28, 7 November 2021 (UTC)[reply]
  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)[reply]
  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)[reply]
  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)[reply]
  7. Oppose. Per Dreamy Jazz. Page protection and blocking go hand-in-hand, that's why we have AIV and RFPP. This is a feature of the admin tools that cannot be sensibly unbundled. Besides which, the proposal is totally orthogonal to improving RfA. Kudpung กุดผึ้ง (talk) 14:15, 8 November 2021 (UTC)[reply]
  8. Bilorv beat me to the hammer metaphor. It is often the case that a block will stop a content dispute or edit war more effectively than protection, i.e. when one specific user is clearly the problem. Protecting the page instead is not an acceptable solution. Beeblebrox (talk) 18:23, 8 November 2021 (UTC)[reply]
  9. Protection, deletion, blocking, and the reversal of those actions are the core parts of the admin toolset. They are not like rollback or account creation, which were largely ancillary to it and amenable to "unbundling". If someone is to have any access to those tools, they need to go through a full RfA. Anyone who can be trusted with any one of those tools can be trusted with them all, and anyone who cannot be trusted with all of them should not be trusted with any of them. Seraphimblade Talk to me 23:05, 9 November 2021 (UTC)[reply]
  10. I fear that this would cause protection to be overused, especially in cases where a block or rangeblock would be better. We have a noticeboard for requesting protection, so having more admins would help ensure these reports are handled in a timely manner. ASUKITE 18:26, 10 November 2021 (UTC)[reply]
  11. Protection is easy to apply incorrectly. I'd prefer to leave this only available to admins. The backlog at RFPP is usually manageable and doesn't get too long most of the time, so there isn't really a problem to solve here. —⁠ScottyWong⁠— 06:15, 11 November 2021 (UTC)[reply]
  12. per DreamyJazz. Blocks tend to do the trick and if it doesn't then we have protection ... –Davey2010Talk 18:13, 11 November 2021 (UTC)[reply]
  13. I am implacably opposed to any proposal to unbundle, in any way, even one of the three core rights (delete, protect, block) of the bit: one can be trusted with all three of them, or none at all. JavaHurricane 10:19, 13 November 2021 (UTC)[reply]
  14. Oppose per Jazz. --JackFromWisconsin (talk | contribs) 19:04, 13 November 2021 (UTC)[reply]
  15. Per above. If I were to trust someone with this right, I'd also support them at RfA -FASTILY 01:31, 14 November 2021 (UTC)[reply]

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)[reply]
  • 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)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

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.

Closed: 8A PROD-style adminship

SNOW closed as unsuccessful. Barkeep49 (talk) 16:20, 7 November 2021 (UTC)[reply]

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.

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

Support 8A PROD-style adminship

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

Oppose 8A PROD-style adminship

  1. Opposing on the basis of "1 oppose a month". Currently, that would be fine, but because any policy change to update the value would take time, the current ruleset doesn't cover what to do in the event where a multiple need arise at once. Possibly something like "if the 15-cap is met, then the oppose is "refunded" might work Nosebagbear (talk) 16:32, 31 October 2021 (UTC)[reply]
    I guess, if the 15 cap is met, an opposer has ~12-24 hours to "refund" an oppose for later use in the month. As said before, specific details would have to be sussed out if this gets consensus.  – John M Wolfson (talk • contribs) 16:37, 31 October 2021 (UTC)[reply]
  2. I am deeply skeptical of any proposal that would create multiple concurrent pathways to adminship. I worry that the effect may be that admins who pass based on this PROD-style system are treated differently than those who pass via the existing process. I also have concerns about the viability of this proposal on its own merits. The existing RfA system has plenty of problems, but I'm worried that this will not provide enough possibility of discussion. Trainsandotherthings (talk) 16:46, 31 October 2021 (UTC)[reply]
    I am deeply skeptical of any proposal that would create multiple concurrent pathways to adminship – This may be your opinion, but in phase 1 of this project we have established consensus that RfA should not be the only road to adminship. — Bilorv (talk) 23:36, 31 October 2021 (UTC)[reply]
    Read more closely. I oppose multiple concurrent pathways. I'm not opposed to a new process that replaces the existing RfA process. And I am allowed to voice my opinions on the matter regardless. Trainsandotherthings (talk) 23:52, 31 October 2021 (UTC)[reply]
  3. I strongly oppose this suggestion because I think it has several problems. First even the title is misleading - this is nothing like the prod process which is designed for uncontroversial maintenance, any single editor can stop a prod - even after the fact. Second, lack of a showing of some level opposition does not equate to a showing of actual community support necessary to get past the global expectations for access to deleted content. Third, barring bona fine objectors simply because they participate in other discussions is a bit much for me - and related to that the objectors can be eliminated by simply creating many of these in a short period (possibly in bad faith) - such that then we would need to have other discussions about voiding them. — xaosflux Talk 17:06, 31 October 2021 (UTC)[reply]
  4. This won't necessarily be harmful but I don't think it will do anything to resolve the issues with RfA. The only people who would put themselves up for PROD-style adminship are those who think they will pass easily with little opposition. Those people are exactly the people who will have the least reservations about using the existing RfA process. People who are intimidated by the existing RfA process won't use it and we won't end up with any more admins. I can also see the experience being even more negative for candidates as they will only get negative feedback. Hut 8.5 17:30, 31 October 2021 (UTC)[reply]
  5. This is a non-starter. A lack of opposition is not the same thing as community support. This will create a second class of admins that never got the support of the community, but rather just did not upset enough people along the way. HighInBC Need help? Just ask. 23:14, 31 October 2021 (UTC)[reply]
    A lack of opposition is not the same thing as community support – Except that this is exactly how RfA is at present, where there's guaranteed to be a large turnout and a majority of people who reflexively say "no big deal, not a jerk, has a clue" (if they are unconvinced by opposes), and the opposition or lack thereof is what actually determines the outcome. — Bilorv (talk) 23:36, 31 October 2021 (UTC)[reply]
    I believe that most take a careful look at the candidate and that your characterization is unfairly trivializing those participants. The reality is that unsuitable candidates are often opposed by those who support suitable candidates. If you look at historical RfAs you will see that, with few exceptions, the supporters and opposers are the same people. HighInBC Need help? Just ask. 23:54, 31 October 2021 (UTC)[reply]
    I personally do not, and simply support unless I see glaring issues. That said, I do agree that people often unfairly oppose. – John M Wolfson (talk • contribs) 23:55, 31 October 2021 (UTC)[reply]
  6. The "one oppose per month" is a complete non-starter with me, but it seems clear that won't actually be allowed to make a substantial impact. The bigger problem is that the flood of "supports" is the fun part of RFA (for both candidates and voters) and I'm not sure why to get rid of it. A "RFA without candidate participation" (like 4A but without the sortition aspect) seems like a better option to allow people to become admins with a lesser burden of participation. User:力 (power~enwiki, π, ν) 00:09, 1 November 2021 (UTC)[reply]
    The correct plural, per Italian, is adminabili, although adminabiles is good Latin. – John M Wolfson (talk • contribs) 00:17, 1 November 2021 (UTC)[reply]
    The lack of support 'flood' that you point out here is interesting. Seems like it has the chance to poison the well for candidates who get 15 opposes and then choose to pivot to a full RFA - the community will already have been primed with negatives and no positives. Retswerb (talk) 05:06, 6 November 2021 (UTC)[reply]
  7. This differs from PROD in two critical ways, and that makes the title indeed misleading, as well as the process likely not workable. The first is that PROD is designed to be lightweight—it is easy to propose a deletion under it, and just as easy to prevent or undo it. Even if the deletion already took place, a single objection results in an uncontested undeletion. Secondly, the "one oppose a month" criteria is subject to gaming—a candidate could just wait until a lot of their likely opposers have already used theirs, and then run. With PROD, conversely, an editor may object to and thereby stop as many PROD proposals as they believe warranted. So far as the process itself, the lack of even questions severely limits the community's ability to evaluate the candidate, as does the lack of discussion. Seraphimblade Talk to me 03:35, 1 November 2021 (UTC)[reply]
  8. I appreciate the sentiment, but... no. RFA is supposed to be a discussion. This moves further away from that instead of closer. Beeblebrox (talk) 20:19, 1 November 2021 (UTC)[reply]
  9. The Foundation has made it pretty clear that an RFA like we currently use is required to give someone access to deleted material. Dennis Brown - 2¢ 00:12, 2 November 2021 (UTC)[reply]
  10. Doesn't really seem to solve the issue, just provide another, slightly easier path for those already on a glide path. ~ Amory (u • t • c) 15:17, 2 November 2021 (UTC)[reply]
  11. Opposing this as I don't think solves the issue at hand. Dreamy Jazz talk to me | my contributions 13:31, 7 November 2021 (UTC)[reply]

Discussion 8A PROD-style adminship

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

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.

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_creepTalk 16:31, 31 October 2021 (UTC)[reply]
  2. This idea addresses two potential problems at once: A) By combining many RfAs into one big election, the entry barrier is lowered for each candidate. It doesn't hurt to join the election and to see what happens; one isn't the target of all the spotlights. B) By having a secret voting process after an initial round of comments, the bandwagon effect is reduced. While this will reduce the unanimity of successful RfAs (opposition does not require a reason anymore), it may cause good candidates to run for adminship who would otherwise avoid the toxicity of the public opposition. ~ ToBeFree (talk) 16:51, 31 October 2021 (UTC)[reply]
  3. I similarly think this idea addresses multiple issues, as pointed out by Tobias above, and I see no reasonable difficulties with implementation (after all, we already use the same process with ArbCom elections, and this if anything is simpler and likely to require less intervention from election commissioners than other methods). RandomCanadian (talk / contribs) 17:12, 31 October 2021 (UTC)[reply]
  4. I'm willing to support this at least on a trial period (maybe do it twice, then require a confirmation to continue) - keep in mind that I expect that there will be some significant technical challenges to getting it running for the first time. — xaosflux Talk 17:15, 31 October 2021 (UTC)[reply]
    I'd rather that Three days for discussion and questions... be 7, not all editors are here every 3 days - but this isn't a showstopper for me. — xaosflux Talk 17:45, 31 October 2021 (UTC)[reply]
  5. I think this is absolutely worth a try: at least in theory, it has the potential to reduce corrosiveness, scrutiny, and hesitancy to run. I agree with Xaosflux that some sort of trial period would be good since unanticipated consequences are always a possibility, but this seems to address many of the problems that plague RfA. Extraordinary Writ (talk) 17:23, 31 October 2021 (UTC)[reply]
  6. Worth a try, but would also like a trial period. Femke (talk) 17:25, 31 October 2021 (UTC). I've been convinced by the oppose votes that three days is too short and would like to add to the choir of 'Five to seven days of discussion' for appropriate scrutiny. Femke (talk) 08:16, 10 November 2021 (UTC)[reply]
  7. Also think it's worth a try, it might reduce the pressure involved in the process. Hut 8.5 17:46, 31 October 2021 (UTC)[reply]
  8. Yes, worth to try. It may also reduce level of scrutiny and create a better atmosphere at RfA. Carlosguitar (Yes Executor?) 18:21, 31 October 2021 (UTC)[reply]
  9. Worth a try. By bundling everyone together it reduces the amount of spotlight that an editor will feel going through an RfA. This is already partly achieved by nominators grouping their candidates together in small groups. Also by providing a system where editors can only simply vote for or against anonymously this means that there is likely to be less permanent to see negative scrutiny for a candidate who ends up failing. This is because the discussion and question stage lasts for less time, and generally only a few people will mention this issue in a comment unlike many voters who use it as a rationale to oppose. Dreamy Jazz talk to me | my contributions 18:30, 31 October 2021 (UTC)[reply]
    Worth trying as an additional route (rather than replacement of current RfA). —valereee (talk) 18:49, 31 October 2021 (UTC) Removing number, as I seem to have managed to !vote twice. —valereee (talk) 13:35, 2 December 2021 (UTC)[reply]
    Support trial per xaosflux — Wug·a·po·des​ 21:00, 31 October 2021 (UTC)[reply]
    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)[reply]
  10. Support. This is the only real way to decrease perceived scrutiny for the candidate without decreasing actual scrutiny to a level where the RfA is not rigorous enough. Questions can still be asked but the candidate is not on the hook to respond to all drama that arises on a discussion solely about them and lasting a week. Additionally, ArbCom is roughly speaking a much higher position of power than adminship, so if the suffrage conditions and success percentage are no more lenient than for ArbCom (and as proposed they aren't) then no-one can object to admin elections unless they also object to how ArbCom elections are currently done. I suspect the value that will need to be changed is a reduction in the support percentage required to pass, but this is something to discuss again when we have some concrete outcomes from a trial. (I don't see a need to codify how many "trial runs" we do before re-discussion, as such a thing is contingent over whether the elections are successful or not.) — Bilorv (talk) 21:11, 31 October 2021 (UTC)[reply]
  11. 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. WormTT(talk) 21:50, 31 October 2021 (UTC)[reply]
  12. This seems like a good idea as an alternative route to adminship, but the support percentage may need to be adjusted after a couple of runs of the system.Jackattack1597 (talk) 23:11, 31 October 2021 (UTC)[reply]
  13. To an extent I agree with Cryptic below, but I think our current system is collapsing so badly that we need to do something that really changes it, and this is, in my view, the only sufficiently radical proposal on the table.—S Marshall T/C 00:05, 1 November 2021 (UTC)[reply]
  14. I think this has potential. A longer question period and lower pass percentage would probably be better, but this is probably the right alternative to the traditional method. Aircorn (talk) 02:30, 1 November 2021 (UTC)[reply]
  15. I like this idea. I agree with all above me who requested for a longer period of discussions. Isabelle 🔔 03:20, 1 November 2021 (UTC)[reply]
  16. Support with a week or more for the discussion; the other details can be debated later. I carefully considered the opposes. The toothpaste is already out of the tube on it being a consensus-driven activity. RfA isn't (any longer) a good use-case for a consensus-based discussion. The outcome is binary; there can be no compromises. There's no way for a solution to anything to gradually evolve; there's only accusations and defenses. Bilorv put it well: decrease perceived scrutiny without decreasing actual scrutiny. As for other concerns: I imagine candidates already think RfA is quite imposing enough; for suffrage requirements, the voter rolls are public; for gaming, the same concerns apply to ACE; and for difficulty of implementation, I'm sure something can be figured out and I would hate to see a good idea die just because implementing it is tough. Enterprisey (talk!) 07:21, 1 November 2021 (UTC)[reply]
  17. This is a very smart idea that has the potential to square the circle around the desire to spare candidates public humiliation and the necessity of open discussion. If it's successful, I could see it replacing RfA entirely, but it's sensible to start it in parallel as a sort of trial. I agree that three days is too short, especially if the community has to assess multiple candidates. But that can be tweaked as we go. – Joe (talk) 09:01, 1 November 2021 (UTC)[reply]
  18. With significant caveats about thresholds. Vaticidalprophet 12:59, 1 November 2021 (UTC)[reply]
    Nice idea. Hopefully substantially less animus. ProcrastinatingReader (talk) 14:34, 1 November 2021 (UTC)[reply]
    Risker's comment in the discussion section gives me pause. ProcrastinatingReader (talk) 14:09, 5 November 2021 (UTC)[reply]
    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)[reply]
  19. Yes, let's give it a go Ritchie333 (talk) (cont) 14:38, 1 November 2021 (UTC)[reply]
    I support giving this a try, though there are technical issues that will need to be resolved. Trainsandotherthings (talk) 14:44, 1 November 2021 (UTC)[reply]
    In my opinion, the concerns raised by Risker and Wugapodes in the oppose section are damning. Considering this proposal isn't possible technically, I can no longer in good conscience support it. I also share concerns of the opposers about lack of discussion. Trainsandotherthings (talk) 00:09, 11 November 2021 (UTC)[reply]
  20. Support as trial only - I would prefer to have two or three elections before the next RFC but would also support a mandate for only one election. There are legitimate details that must be worked out, but the idea is good and we will only find out by trying. Regarding the concerns: if the WMF can't support us using SecurePoll even once, the community must simply write our own balloting tool. The voter rolls will be public, so I don't see any particular concerns about socking beyond what we have at RFA today; presumably some local checkusers could abstain from voting and scrutineer if necessary. If it is harder for candidates to pass a secret ballot than a public one, we will either adjust the standards or candidates will be motivated to use a public vote. And while there won't be bolded votes in the initial discussions, editors should be able to be clear about where they stand; there is no need for voter guides. User:力 (power~enwiki, π, ν) 16:55, 1 November 2021 (UTC)[reply]
  21. 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)[reply]
  22. Worth trying. MER-C 19:24, 1 November 2021 (UTC)[reply]
  23. 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)[reply]
  24. 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)[reply]
  25. It's worth a shot at least. -- Calidum 16:53, 2 November 2021 (UTC)[reply]
  26. We should try this. —Kusma (talk) 10:34, 3 November 2021 (UTC)[reply]
  27. 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)[reply]
  28. RFA currently has too much drama in it and people are scared to use it. As others have said, RFA is already a poll anyways so using a secret ballot here is the obvious answer. RFA needs a replacement or at least some kind of major change, this has been a problem for FAR too long. If this continues it will harm the long-term health of the wiki. Swordman97 talk to me 04:16, 4 November 2021 (UTC)[reply]
  29. I don't think technical concerns should be an issue. ― Qwerfjkltalk 20:47, 4 November 2021 (UTC)[reply]
  30. Support: This seems to be a clean solution. —¿philoserf? (talk) 00:38, 5 November 2021 (UTC)[reply]
  31. I'd be willing to give this a chance. -- Tavix (talk) 20:08, 5 November 2021 (UTC)[reply]
  32. 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)[reply]
  33. 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)[reply]
  34. 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)[reply]
  35. * Pppery * it has begun... 18:39, 7 November 2021 (UTC)[reply]
  36. 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 (talk·contribs) 19:03, 7 November 2021 (UTC)[reply]
  37. 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)[reply]
  38. 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)[reply]
  39. Sure, on a trial basis. Let's see how it goes. 🐶 EpicPupper (he/him | talk) 22:41, 7 November 2021 (UTC)[reply]
  40. No more need for pile-ons; simply vote your conscience. Jclemens (talk) 05:45, 8 November 2021 (UTC)[reply]
  41. I'm concerned that voting will increase the level of opposition, but that can be adjusted over time. We have to do something, and this seems to be the only truly major reform left on the table. {{u|Sdkb}} talk 16:25, 8 November 2021 (UTC)[reply]
  42. Worth a try, it could attract qualified candidates who are turned off by the atmosphere of RfA. Toohool (talk) 17:06, 8 November 2021 (UTC)[reply]
  43. Worth a try. Risker's comment on technical issues merely indicate that SecurePoll may not be a viable solution as of now. This does not prevent us from establishing that we want to use it – which will likely result in those issues being addressed by the WMF due to the demonstrated need. – SD0001 (talk) 17:16, 8 November 2021 (UTC)[reply]
  44. It's the process we use for arbcom elections and they seem to run quite well. Andrew🐉(talk) 18:58, 8 November 2021 (UTC)[reply]
  45. Worth a trial for a couple of elections. If it doesn't go well, we'll have learnt that and look at different ideas for changing RfA – with little harm done. If it does go well, then hallelujah. — J947 ‡ message ⁓ edits 00:00, 9 November 2021 (UTC)[reply]
  46. Worth trying. I do hope it doesn't add a further wrinkle to RfA in the form of "Why aren't you waiting for the next election?" questions. I hope we can just meet candidates where they are without fussing over such things. --BDD (talk) 15:58, 10 November 2021 (UTC)[reply]
  47. This might well help, well worth giving it a go. Chiswick Chap (talk) 16:20, 10 November 2021 (UTC)[reply]
  48. Good idea. Same community vetting, there's a chance for discussion, and three days is plenty. If SecurePoll is good enough for our board of trustees, it should be good enough for adminship. ASUKITE 18:45, 10 November 2021 (UTC)[reply]
  49. Good proposal with community vetting.Pharaoh of the Wizards (talk) 21:10, 10 November 2021 (UTC)[reply]
  50. per ToBeFree - I really like this idea to be honest. –Davey2010Talk 18:15, 11 November 2021 (UTC)[reply]
  51. Definitely worth a trial. FWIW, this process might see a significant increase in voters as well which would indicate that more people are interested in participating yet reluctant because of the current process.--John Cline (talk) 09:09, 13 November 2021 (UTC)[reply]
  52. Reduces drama, stress, and spectacle while maintaining safeguards for a trusted position (a similar process is used for the arbitration committee)  Mysterymanblue  09:58, 13 November 2021 (UTC)[reply]
  53. Worth a trial at least //Lollipoplollipoplollipop::talk 10:38, 13 November 2021 (UTC)[reply]
  54. Worth a try HelpfulPi (talk) 21:23, 14 November 2021 (UTC)[reply]
  55. Support: I like the concept, and upon further parsing of the discussion, I found the opposes to be unconvincing. We have yearly steward elections at Meta, an occasion requiring extreme scrutiny due to the toolkit being granted out (sysop, int admin, CU and OS access across all Wikimedia projects), with less post-appointment scrutiny than that which admins at enwiki get from the community here. So far we have not elected any bad steward, and as a result I don't think that sockmasters can game the system like what happened recently. Only in one case was a sockmaster able to influence the election results, and the sockmaster was promptly globally banned by the community when this came to light, and the candidate in question had already retired anyways. Hence, I do not think that the voting system gives less scrutiny to candidates. My only scruple is that, as Risker points out, there are serious problems with SecurePoll, and I share the scepticism of others that the WMF is unlikely to fix the issues. Additionally, I think that the voters at RfA should be publicly accountable for their votes. As a result, I feel that it would be better if public voting was used, as is used for Steward elections and for the old ArbCom elections before SecurePoll came up. JavaHurricane 17:43, 15 November 2021 (UTC)[reply]
    So far we have not elected any bad steward, I won't name names but I can think of several. --Rschen7754 19:03, 15 November 2021 (UTC)[reply]
    Welp; my statement is of course qualified by the fact that I know next to nothing about the elections of the old days. I do think that the current batch is pretty good. JavaHurricane 05:02, 16 November 2021 (UTC)[reply]
  56. Given the lack of major changes to the main RfA process it looks like we'll end up with, I think this alternative process is worth a try. Obviously there's challenges with SecurePoll, and this might need some development work, but I don't think it should be ruled out on that basis. the wub "?!" 02:10, 17 November 2021 (UTC)[reply]
  57. Support - I have considered the arguments against. Group elections such as this are the least drastic way to minimize the corrosive atmosphere of RFA. Robert McClenon (talk) 04:50, 18 November 2021 (UTC)[reply]
  58. I'm leery of the secret ballot aspect because it allows people to oppose without rationale, but I know that much of what makes RfA so toxic is the oppose rationales and subsequent discussion. I guess that leaves me at "let's give it a try if we figure out a way to make it technically feasible"? —valereee (talk) 17:22, 19 November 2021 (UTC)[reply]
  59. Solid idea, making adminship less of a gauntlet in a way that doesn't undermine the process is a step in the right direction. W42 16:05, 26 November 2021 (UTC)[reply]
  60. Same rationale as I just wrote (in 6C above). - Dank (push to talk) 03:00, 29 November 2021 (UTC)[reply]
  61. Support. Simplifies the process. This opens a door to competent editors who are turned off by the atmosphere of RfA. --Whiteguru (talk) 07:45, 29 November 2021 (UTC)[reply]
  62. Support. Has the potential to shorten the RFA gauntlet from 7 days to 3, and also to take the spotlight off since other folks are running simultaneously. I think this would be a meaningful way to address concerns about the RFA process being too strenuous and difficult. It could also reduce the amount of drama, since oppose votes would be hidden. –Novem Linguae (talk) 07:43, 30 November 2021 (UTC)[reply]
  63. Support Less bitterness and stress, as argued by others. A current election is conducted in such a manner. 19:53, 30 November 2021 (UTC) — Preceding unsigned comment added by TrangaBellam (talk • contribs) 19:53, 30 November 2021 (UTC)[reply]
  64. Support I think this approach is worth trying. --Danaman5 (talk) 01:34, 1 December 2021 (UTC)[reply]
  65. Support. I initially thought that three days would be insufficient, perhaps a week would be better. But, then I thought that would probably just degenerate into an alterative RfA which we are looking not to replicate. I see —valereee's point of being leery of a secret ballot but I see so many silly opposes that are not shy about publicly expressing them, I do not think that number will inflate. Ifnord (talk) 02:24, 1 December 2021 (UTC)[reply]
  66. Support It gives a realistic chance to compare the candidates, and will discourage the current focus on the minor errors of any one candidate. DGG ( talk ) 10:30, 2 December 2021 (UTC)[reply]
  67. Support - After a thorough re-review, I think this will be a good idea but I would definitely like to a see trial run for it first. TheGeneralUser (talk) 20:33, 2 December 2021 (UTC)[reply]
  68. This is the only proposal that addresses the "Level of scrutiny" and "Corrosive RfA atmosphere" issues. Allowing people to vote peacefully, separate from the discussion, is a major improvement. Dates will be published ahead of time, and there is still enough room for discussion for those interested in persuading others or reading the opinions of others. Adumbrativus (talk) 01:40, 3 December 2021 (UTC)[reply]
  69. Support. I've read the arguments against, and they have some really strong points. Unfortunately, this seems to be the only option that has a real chance of solving our problems. Sure, there is some chance it might create new ones. I think the discussion time is too short. ArbCom elections, which we're vaguely modeling this after, have a much longer review period. Similarly, there may be technical issues with using SecurePoll, and we may need to switch to something else (even, in the worst case, public voting with a "no responding to votes" policy). This really isn't a perfect solution. That said, some change is needed. There's been fairly wide agreement on that point for years. And yet, year after year, nothing substantive happens. Many of our best minds have worked on the problem, and no agreement has materialized. I think we've got to try this, despite the risks. If we never even try potential solutions, we'll never find one that actually works. I hope that the community will be willing to give this a try and that they will be willing to make adjustments as needed, to give this experiment the best possible chance of working. Tamwin (talk) 10:05, 7 December 2021 (UTC)[reply]
  70. I think a trial run would be worth a shot. Run it twice and then have an RFC to determine if there's consensus to continue. There are a lot of valid concerns among the opposers below, but until we have the data it's completely hypothetical.--Aervanath (talk) 19:57, 8 December 2021 (UTC)[reply]
  71. I think this is worth a try. I had concerns about potential abuse, but Ritchie333's comment below has helped alleviate those concerns to some extent. Aoi (青い) (talk) 22:30, 8 December 2021 (UTC)[reply]
  72. Give it a go. 4nn1l2 (talk) 10:10, 10 December 2021 (UTC)[reply]

Oppose 8B Admin elections

  1. I think I brought up something like this at phase 1, but overall way too much bureaucracy for my tastes. An ArbCom election is this whole annual shindig, and while I'm proud to serve as a reserve election commissioner this year I think introducing that level of bureaucracy and pomp into something that's supposed to be quite commonplace like RfA would have the opposite effect and make it more intimidating and formalized. I much prefer the "in-and out", "bada-bing-bada-boom" aspect of the RfA status quo.  – John M Wolfson (talk • contribs) 16:21, 31 October 2021 (UTC)[reply]
  2. There was a large drop in average support when arbcom elections moved from open to closed voting. (I want to say it was something around 15 or 20 points, but I'm too lazy to go look.) I'll grant that there's people who refuse to run an RFA because of the atmosphere who'd likely pass in the 90% range. I can think of two offhand. But I'd lay odds that there are far more that would pass a traditional RFA, get universal support in the public discussion period where people are accountable for what they say, and not even break 50% in the safely-anonymous voting. Being able to name and shame people who oppose for poor reasons is a feature, not a bug. —Cryptic 20:49, 31 October 2021 (UTC)[reply]
    Regarding Being able to name and shame people who oppose for poor reasons is a feature, not a bug. Issues 1 and 2 above are clear that the community believes it is a bug. There is a balance to be found, where issues can be raised, but not with shame. WormTT(talk) 08:04, 1 November 2021 (UTC)[reply]
    If the community truly thinks that opposes like the first (struck-through) one here should have been treated with less contempt, then there really isn't any hope. —Cryptic 10:12, 1 November 2021 (UTC)[reply]
  3. Wikipedia was build on the concept of WP:CONSENSUS, and we rather pointedly avoid voting on things. The suffrage requirements are very easily gamed. Drive by opposes for reasons normally not acceptable by the community will increase as they will go unchallenged. People need to give their reasons for support or opposition and they certainly should not be able to support or oppose anonymously. Frankly I don't think arbcom should be doing that way either.
    With the recent issue of a sockmaster almost becoming an admin I am very concerned that short of every participant getting a CU(something the checkusers have said they cannot do) that it would not be hard to push an RfA over the limit through sock puppetry. Arbcom election standards state This process includes using the checkuser tool to view voter IP addresses. This process requires checking every user who voted and takes a couple of weeks. We can't be checkusering every voter at RfA and we certainly can't be doing a couple of weeks work for each RfA. This has not been thought through.
    This is no replacement for our current human vetting of participants. HighInBC Need help? Just ask. 23:16, 31 October 2021 (UTC)[reply]
    Almost 2000 votes were cast in the 2020 ArbCom election, compared to 150–300 at modern RfA, so there is no reason why scrutinising would take 2 weeks. Your impression might be that we can't be checkusering every voter at RfA, but mine is that checkusers essentially informally scrutinise every voter at RfA at present, with suspicious voters regularly struck after a mysterious checkuser block. (This is not to say we're all being CU'd, as the CU tool itself is primarily useful to augment behavioural evidence.) — Bilorv (talk) 00:37, 1 November 2021 (UTC)[reply]
  4. I never liked going to secret ballots for ArbCom, and certainly don't like it here. We've always been built on a consensus model, not a balloting one. If you have something to say about a given proposal, say it publicly and state your reasoning behind it. Seraphimblade Talk to me 03:40, 1 November 2021 (UTC)[reply]
  5. Would have considered supporting proposal without the addition of secret ballots. Next we will have to decide on whether we allow guides for the elections. --Rschen7754 03:48, 1 November 2021 (UTC)[reply]
  6. Elections are easily gamed. If a long-term abuser can almost make it to adminship, why wouldn't the next attempt involve a team of sleepers preparing for the vote? There are many contentious topics where teams of people would be motivated to try that. Also, three days is not sufficient time for problems to be unearthed. Per WP:NOTFISHING and a lack of magic pixie dust, we cannot rely on checkusers to unearth sleepers who passively wait for the vote. Voters should engage with issues raised on the RFA page. It's ok for a vote of arbitrators since no one arb has the power to act alone, and there is a grueling Q&A and discussion period. Johnuniq (talk) 03:53, 1 November 2021 (UTC)[reply]
  7. I'm concerned about any change from an admin run to an admin race, especially a race that runs on a schedule. Just like the arbcom process, nobody can stop a user from creating !voter guides for such a race. Worse, timed admin elections may have the unintended consequence of giving off-wiki actors and others who are WP:NOTHERE clear and targeted opportunities to coordinate, disrupt and possibly manipulate !voting information. These sorts of issues render the admin process more politicized. Despite our frequent disagreements, so far wikipedians have been able to avoid overt partisanship in formal processes. If it is broken, the RFA process is at least now a screening/approval process (like choosing a doctor or accountant), not a contest (like choosing a representative). Making adminship any sort of competition makes us vulnerable to organized opposition from inside and especially outside the pedia. Lowering our typical measure of consensus is a bad thing. Politics and voting is a pandora's box we should never open. BusterD (talk) 04:01, 1 November 2021 (UTC)[reply]
  8. Per above. Not a fan of the private voting aspect, could be trivially gamed (especially by a competent sockmaster), and formalizes RfA as a vote, which imo runs counter to WP:CONSENSUS. -FASTILY 05:05, 1 November 2021 (UTC)[reply]
    @Fastily: in the SecurePoll method, the list of voters is public, with timestamps. As such, what is public is no different to during RfA except the votes themselves. As such, I'm confused as to why this system could be "trivially gamed" but current RfA cannot (or can it be?). — Bilorv (talk) 12:02, 1 November 2021 (UTC)[reply]
    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)[reply]
  9. Aside from several of the previously mentioned points, the reality is that the SecurePoll infrastructure is already near capacity, has almost zero technical support, and will significantly impede other projects from using SecurePoll for more important things like their local Arbcom elections. SecurePoll is limited to one instance at a time throughout the Wikimedia-world; it is not possible for there to be two or more simultaneous elections using it. (I note that the recent MCDC election had a significant impact on the Arab Wikipedia arbcom election, both delaying the arbcom election, and requiring the MCDC election to be "dumped" much earlier than initially planned, in order for the arbcom election to be set up.) I get that we on English Wikipedia don't really consider the impact on other projects when we come up with ideas. But this one would create a fair amount of animosity. Risker (talk) 05:41, 1 November 2021 (UTC)[reply]
    @Risker: I fully agree that this is a concern, however, the reason is that it is all managed from one place, a private wiki. It does not seem excessive to request an expansion Of the system from the WMF. I'll ask them about it directly. WormTT(talk) 07:16, 1 November 2021 (UTC)[reply]
    Sorry quick pedantic note (because what are we as Wikipedians if not all kinds of pedenants?) but MCDC impacted Farsi Wikipedia not Arabic Wikipedia. It is hardly unusual for these two languages and ethnicities to be confused which is one reason I try to get it right and to point it out when I see it. That said SecurePoll scarcity is an issue as I noted below when it was suggested it be even more frequent. Best, Barkeep49 (talk) 15:29, 1 November 2021 (UTC)[reply]
    Conversely, a large project like us using SecurePoll more often might spur the WMF into allocating resources to improve it. – Joe (talk) 15:58, 1 November 2021 (UTC)[reply]
    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)[reply]
  10. Too many unknown unknowns, in addition to the known knowns already identified. Leaky caldron (talk) 08:09, 1 November 2021 (UTC)[reply]
  11. I just hate secret ballots. Influencing others' !votes is part of RfA, and an important part at that. 🐔 Chicdat  Bawk to me! 10:39, 1 November 2021 (UTC)[reply]
  12. No, per what Risker said - there are technical limitations to SecurePoll that would significantly problematic if we used it in this manner. Also, what do people do if they find a significant problem with a candidate after the three days but can't publicize it with an "Oppose: [Significant issue]" rationale? Jo-Jo Eumerus (talk) 11:25, 1 November 2021 (UTC)[reply]
    Either you canvass or you write a guide. Both of which open up more cans of worms. --Rschen7754 18:19, 1 November 2021 (UTC)[reply]
  13. My concern is with the fact that it's only every six months. That just makes it feel more bureaucratic, and means people who want to become admins have to plan their life around the admin elections, rather than planning their RfA for a time they can handle. InvalidOStalk 12:59, 1 November 2021 (UTC)[reply]
    The proposal suggests that the normal RfA process will remain an option. ProcrastinatingReader (talk) 14:37, 1 November 2021 (UTC)[reply]
    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)[reply]
  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)[reply]
  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)[reply]
  16. The stewards are willing to review our elections once a year. I don't see them or the CUs doing it once every 3 months --Guerillero Parlez Moi 10:37, 2 November 2021 (UTC)[reply]
  17. I don't think secret voting would be an improvement to the RfA process. LEPRICAVARK (talk) 06:42, 3 November 2021 (UTC)[reply]
  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)[reply]
    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)[reply]
    I have thought more about this proposal; and I am striking my oppose for now. I am leaning support now, though I need some more time before I can take a call again. JavaHurricane 10:38, 13 November 2021 (UTC)[reply]
  19. I strongly oppose this, mainly because it is at serious risk of abuse by a sockmaster. YttriumShrew (talk) 07:55, 6 November 2021 (UTC)[reply]
  20. 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)[reply]
    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)[reply]
  21. 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)[reply]
  22. 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)[reply]
  23. 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)[reply]
    Politics is the set of activities that are associated with making decisions in groups, or other forms of power relations between individuals, such as the distribution of resources or status. --JBL (talk) 11:26, 8 November 2021 (UTC)[reply]
    @JayBeeEll: I don't quite understand what you're getting at here. Are you trying to define politics? 🐔 Chicdat  Bawk to me! 11:31, 8 November 2021 (UTC)[reply]
    Yes. (I've quoted the definition provided in the first sentence of our article Politics.) The reason I'm doing that is that the !vote I'm responding to begins with a flatly false statement: adminship is a political position (unambiguously so), and the questions we're discussing here concern the structure of the political process surrounding it. --JBL (talk) 14:05, 8 November 2021 (UTC)[reply]
    That is just such nonsense. Politicians make policy but administrators have no ability whatsoever to make policy decisions. We have no ability to "distribute resources or status". It is true that administrators have some limited powers, but not every position with some kind of power is considered political. The police have powers, but recruiting police officers is not normally considered political. Even the car park attendant at the municipal car park has power in a small way, but that's not political either. Administrators are more in the way of civil servants if you want a governmental analogy. SpinningSpark 18:12, 9 November 2021 (UTC)[reply]
    The selection of administrators is, literally, the distribution of status. The rest of your post is no less embarrassing. --JBL (talk) 20:16, 9 November 2021 (UTC)[reply]
  24. I think the current RfA process and this proposal are flawed. However, prepping up every six months for an election is a lot to ask for. Furthermore, secret ballots are no good substitutes for plausible rationales justifying their votes, especially when the results are within discretionary range. Moreover, even a sockpuppet, like the one whom Johnuniq brought up, would still be either elected an admin, especially by secret ballots, or blocked by ArbCom, depending on outcomes. Speaking of discretionary range, I see that the range is not proposed here. I would be against any proposal that omits the range, like this one. George Ho (talk) 00:02, 9 November 2021 (UTC)[reply]
  25. Mainly as a result of Johnuniq's and George Ho's reasoning. I dislike the idea of secret ballots in general, and the proposal that only 3 days be given for RfA candidates to respond to the concerns of other users seems like a net negative, even now. What if a user who isn't online during those 3 days decides to raise an issue... where would they then go to raise their concerns? And where would other users be able to read those concerns before voting? I'm aware the general atmosphere at RfA is toxic, which is why I rarely post there, but some level of discussion during the voting stage does need to take place. It's happening at this very page as we speak, and is a productive means of moving things along (i.e., people voting one way but changing their minds based on what other users write). Homeostasis07 (talk/contributions) 00:19, 9 November 2021 (UTC)[reply]
    I've seen this "what if someone who isn't online during those 3 days decides to raise an issue" before, and I do think it's easy to fix. Candidates would sign up by a date, and then we have a week between signup and starting the process. This would mean that a) everyone is aware of the start date, b) everyone is aware of the candidates. You can draft your discussion point in that week, and post it at any point during the three days. I don't buy that the discussion is too short which will lead to people not noticing it, as the wider process is much longer - just not focussed on the individual. WormTT(talk) 09:03, 10 November 2021 (UTC)[reply]
  26. At least in this form. Scrutiny by the community is a vital part of RfA, reducing the potential for the tools to be abused. It would be unfeasible for the community to review 10+ editors, all with thousands of edits in only three days. Even increasing this period to seven days would still require substantially more scrutinising in a short period compared to the drip feed of the current system. SmartSE (talk) 17:45, 9 November 2021 (UTC)[reply]
  27. Not because of the risk of an LTA sneaking through, but because - as Jo-Jo Eumerus and others point out - open discussion (including of emerging concerns) is an important and necessary part of RFA. GABgab 18:16, 9 November 2021 (UTC)[reply]
  28. I've thought about this more since striking my support above, and I find the opposition far more persuasive than the support. That is, I struck my support due to technological concerns, but I now oppose due to more fundamental concerns about the system. The best example to lead off with is this very comment: not only did discussion lead to me changing my opinion, it took me ten days to think through all the opinions and evidence before deciding what side I ultimately wanted to come down on. The proposal gives us three days and then severely limits our ability to continue discussion all but ensuring that no one has time to reflect on and reconsider their positions. If this proposal were to use similar rules as proposed, I feel like I would have made a worse decision, and that alone is enough to make me suspicious of its commitment to discussion; in what other venue do we have three days for discussion? It could be extended, of course, but that's not the only concern and its not the only proposed remedy or compromise.
    If we take seriously all the proposed, ad hoc solutions to legitimate concerns raised in opposition, we get compromise proposals that are largely incoherent; I oppose largely because I no longer know what will happen if I support. We have concerns that the debate period is too short and suggestions from supporters that it be lengthened to compromise, but if we're going to have a week long debate anyway, why not just combine the two steps like we already do? The goal is to reduce the animosity and corrosive atmosphere, but no matter how long the debate period is that will still be a concern just that we wouldn't have sections that start with bolded words; hardly an improvement. Reduced scrutiny is not necessarily a good thing and that goal is undermined by the public debate (and compromise suggestions to extend it). Even in phase 1, where I saw consensus that level of scrutiny was a problem, the main solution suggested was to place limits on what could be discussed not cutting off discussion arbitrarily. Then there are concerns about borderline cases, bad faith votes, and the opportunity to rebut lies. One editor suggested that we add the ability for rationales when voting which would require large changes to secure poll just to duplicate our existing system. There are concerns about the threshold and voting criteria that would result in major changes to admin promotions with minimal discussion or solutions. There are concerns that we risk promoting unprepared or bad faith administrators due to the reduced scrutiny (partly based on a sockpuppet who almost became an admin a few weeks ago), and those are largely brushed aside. That the administrator permission is hard to remove is frequently brought up as a reason to not support, a reason why RfA is toxic, and a reason why we routinely have de-sysop proposals to try and fix that. That the administrator permission is hard to remove is a compelling reason to not arbitrarily reduce scrutiny.
    Editors raise concerns about the technical limitations of SecurePoll and impact on other wikis. One solution is to not use SecurePoll which entirely defeats the purpose of a secret ballot. Others hope that by intentionally breaking the infrastructure used by hundreds of wikis, the WMF will devote resources to fix it which I find ludicrous. Russian Wikinews tried this with DynamicPageList in July and the WMF just disabled their use of the extension; they didn't spend time fixing something that was broken intentionally. ACERFC2020 had consensus to do something that local developers said wasn't realistically possible, and it never happened because it wasn't realistically possible in the first place. Risker points out below that when we tried using SecurePoll for checkuser and oversight permissions, it turned out to be a catastrophic failure. The main response to these technical concerns is to either ignore them or trust the WMF (who we famously don't trust) will have developers fix things we intentionally broke instead of just stopping us from intentionally breaking things. Those rationales are not believable in light of historical reality.
    In general, the reason to support has been "why not", but the opposition has made multiple compelling arguments as to why not. For those various reasons, I can no support just giving it a shot and hoping for the best, and I find those rationales incredibly unconvincing. What we should be asking is "why", and I don't see a compelling argument. Leaving aside the philosophical arguments about whether we should make this a vote or a discussion, this idea seems broken from the start and likely to only get more broken as the various band-aid fixes are pasted on over months and years until we reach a DYK-like behemoth that is more hotfixes than actual process. I'm willing to consider wholesale replacement of RfA, but this proposal--if we can even get the SecurePoll issues worked out to do it--seems like a quagmire. Just because we should do something doesn't mean we should do anything. — Wug·a·po·des​ 23:52, 10 November 2021 (UTC)[reply]
    @Wugapodes, I'm not sure it's accurate to characterize the typical support as "why not?". I'd say it's closer to "worth trying to see if it helps". Sorry for the late response, I ended up here again because a kindly colleague let me know I'd managed to !vote twice, which pulled me right back into the rabbithole. :D —valereee (talk) 21:39, 2 December 2021 (UTC)[reply]
    @Valereee: I don't see a meaningful difference between the two. "Let's give it a try" makes sense when the change is minimal and unlikely to have serious downsides, that is, it makes sense when there's no reason not to try it. But editors have raised a number of serious concerns from practical to historical to philosophical, most of which have been uncritically brushed off in favor of blindly trying something new. No one has said what success would look like if we did "try" this, so functionally we're just implementing a major change and hoping that none of the myriad ways its failed in the past or could fail in the future happen. I gave multiple examples of times decisions with that rationale have failed, and no one has given me any reason to believe this time will be different. — Wug·a·po·des​ 00:06, 3 December 2021 (UTC)[reply]
    @Wugapodes (and feel free to just say, "I've given my opinion, done here" if that's what you're feeling), but is it really a major change? RfA as always done is still in play. To me this is trialling something different to see if it also works, and maybe works better for some candidates. I feel like the worst outcome is that we could maybe sysop a few people who wouldn't have been sysopped by RfA. We have probably hundreds of sysops who wouldn't be sysopped in a 2021 RfA, and we deal with that. —valereee (talk) 00:34, 3 December 2021 (UTC)[reply]
  29. I support everything about this proposal except the part where admins can only be elected twice a year. There's no reason to make someone wait 6 months when they're ready to run now. —⁠ScottyWong⁠— 06:16, 11 November 2021 (UTC)[reply]
    This is in conjunction with the current process, so there is no need for anyone to wait if they are willing to go via the traditional route instead. Aircorn (talk) 23:01, 12 November 2021 (UTC)[reply]
  30. Per HighInBC. The risk of abuse is too high, and it runs contrary to the principles of consensus and transparency that make Wikipedia great. Colin M (talk) 06:36, 11 November 2021 (UTC)[reply]
  31. Many factors, including reduction of scrutiny, inability to respond to late-discovered issues, reduction in consensus-forming discussion, risk of abuse. The fact it's close to technically impossible is also a major problem. Espresso Addict (talk) 06:26, 14 November 2021 (UTC)[reply]
  32. This is a bad idea. Whilst the whole RfA process needs updating to reflect how big Wikipedia has become and the consequent demands on admins, having popular elections to elect admins isn't the answer. As we have seen all too often in real life, elections, no matter how democratic they are, don't always result in suitable candidates being elected. IMO the simple solution to getting more admins is to split the role into several, each having different levels of power/authority and reforming the RfA process so that the amount of scrutiny is dependent on the level of power/authority.--Obi2canibe (talk) 19:15, 14 November 2021 (UTC)[reply]
    Obi2canibe, please provide a specific example for your proposed "simple solution". Which privileges would you separate? What kind of "power/authority" are you talking about? ~ ToBeFree (talk) 09:53, 29 November 2021 (UTC)[reply]
  33. Oppose I would support having elections but the secret ballot would not be a good idea as it reduces response to issues discovered after elections started as well as a reduction in the formation of consensus during the election Lunacats (talk) 19:11, 15 November 2021 (UTC)[reply]
  34. I prefer supports and opposes to be out in the open where their rationales can be used to reach an informed consensus. Also, like SmartSE, I am concerned that too many candidates will apply at once, leading to reduced scrutiny. Tim Smith (talk) 02:23, 24 November 2021 (UTC)[reply]
  35. Per Cryptic and Risker. This will possibly make RfA worse. ProcrastinatingReader (talk) 00:58, 29 November 2021 (UTC)[reply]
  36. The problem is RfA. The solution is not sidestepping it, but improving it. Tol (talk | contribs) @ 15:44, 29 November 2021 (UTC)[reply]
  37. Per Johnuniq. Change is not necessarily for the better.--Wehwalt (talk) 14:16, 30 November 2021 (UTC)[reply]
    @TheGeneralUser: Thank you for laying out your concerns - assuming we SecurePoll is viable and used: functionally the same information about "who voted" would be available as in the current RfA system; namely a list of every voter by their username and the time they voted; "how" they voted would be a secret - but should a voter be deemed ineligible under public review their vote can be discarded without disclosing how they voted; this is the same system that is used for ArbCom elections, board representation, and other certain elections. Can you explain why you think it would be very difficult if not impossible to verify if somebody has voted more than once - especially in contrast to the WP:RFA system? I've got no concerns with you objecting in general, or with raising the other points of your objection - but am interested to see what additional insight you have for this specific problem you raised. Thank you, — xaosflux Talk 14:02, 2 December 2021 (UTC)[reply]
    @Xaosflux: Thank you for your note, after a thorough re-review I changed my mind and have decided to support it for a trial run first. My main concern with regard to the issue which you have mentioned was that since an RfA is an open community process, it is fully transparent and we can easily see who has !voted and what they have said. Although the secure poll election system is used for Arbcom elections, board elections, etc. it is much easier for someone to get away with voting however they want and we (the community in general) normally doesn't know if someone has voted in bad faith (like using sockpuppet sleeper account), that was my main concern. But like I said, I'm open and willing to give this proposal a trial chance and will see how it works. Thanks. TheGeneralUser (talk) 20:33, 2 December 2021 (UTC)[reply]
  38. I've been mulling this over for a few days, and I just don't see how this will help us make better decisions, even if the technical challenges can be overcome. Three days for discussion simply isn't enough, and the lack of bolded votes will make things more difficult to follow. We have had RfAs in the past where issues were brought up toward the latter half of the process – if that happens with that process, where should the issues be raised? The RfA process has always been about determining consensus, and this proposal is an effort to instead turn it into a popularity contest, with as little information given to the voter as possible. That's not a formula for improvement. – bradv🍁 15:11, 9 December 2021 (UTC)[reply]
  39. I agree with the premise that RFA needs to have the drama taken out of it and make it a process that candidates can approach without trepidation, but this really isn't the way to do that. Wikipedia works on the principle that votes for or against a proposition are accompanied by reasoning as to why. With a secret ballot you end up with a situation where someone might pass or fail but you really have no idea why. For example if all the comments in the "discussion" phase are positive but they they fail, what is the candidate supposed to do about that? Or conversely if a lot of negative comments emerge, of the sort which would typically end a normal RFA, but the candidate then passes the ballot, how will we know why? I like the idea of having the discussion phase before the !voting, so a better approach than the one proposed here would be to have the discussion phase first, perhaps even for a whole week (to allow all concerns to emerge), with informal chit-chat the order of the day and constructive comments with an easy route for the RFA to be postponed if the candidate sees that there are objections forming, and then after that proceed to the same public !voting process we currently have.  — Amakuru (talk) 16:18, 9 December 2021 (UTC)[reply]

Discussion 8B Admin elections

  • This is an interesting idea, but I'm not sold on the 6 month interval. I'd prefer every other month, or even once a month, though I could also get behind once per quarter. Trainsandotherthings (talk) 16:48, 31 October 2021 (UTC)[reply]
    I am neutral on the overall concept but getting access to SecurePoll, at least based on how it is setup now, is resource intensive and requires active WMF support. Twice yearly is probably a reasonable limit to how often we could expect that. Best, Barkeep49 (talk) 16:51, 31 October 2021 (UTC)[reply]
    I'm not sure if we'd have enough candidates for this approach. ~ ToBeFree (talk) 16:52, 31 October 2021 (UTC)[reply]
    Perhaps instead have it be every 6 months, or as needed? For example, if there are ten candidates after 3 months, it would make sense to schedule an election then rather than waiting another 3 months. It's unlikely that would happen, but we should be prepared for the possibility. Trainsandotherthings (talk) 17:16, 31 October 2021 (UTC)[reply]
    Having a well-known, regular time of adminship voting may increase the amount of voters and candidates. I think we shouldn't give up this positive aspect of the proposal. Also, another logistical concern: How would you know that there are already 10 candidates if nominations are twice per year? ~ ToBeFree (talk) 17:26, 31 October 2021 (UTC)[reply]
    I concur about having a well-known, regular time of adminship. My concern is that if it is too infrequent, it may instead reduce the number of applicants. What if outside circumstances at the time of an election dissuade candidates from running at that time (for an extreme example, the fallout from our most recent RfA). Trainsandotherthings (talk) 17:35, 31 October 2021 (UTC)[reply]
    If it works, we can certainly decrease the interval between runs - but I think there is a lot of technical challenges that would need to be overcome first. WormTT(talk) 08:07, 1 November 2021 (UTC)[reply]
    That's good enough to move me into the support column. Trainsandotherthings (talk) 14:46, 1 November 2021 (UTC)[reply]
    I have struck my support vote at this time. Trainsandotherthings (talk) 00:12, 11 November 2021 (UTC)[reply]
  • To be clear, my reading of this is that it will be a new, additional, process to adminship - and that the current RfA process will continue for anyone that wants to go that route. — xaosflux Talk 17:31, 31 October 2021 (UTC)[reply]
    I could support this if it is in addition to the normal RfA process, not a replacement of it. Trainsandotherthings (talk) 17:36, 31 October 2021 (UTC)[reply]
    Per Wikipedia:Requests for adminship/2021 review/Proposals/Admin elections, it is indeed "an alternative route to adminship". However, I hope (and guess) most candidates will try it. ~ ToBeFree (talk) 17:36, 31 October 2021 (UTC)[reply]
    I have now clarified this in the proposal text. It seems relatively clear that Worm That Turned meant this ([6]). ~ ToBeFree (talk) 17:40, 31 October 2021 (UTC)[reply]
    Thank you, just making sure nothing changed since the prior discussion. I'm not sure if "most" will try it, as you have to wait for the event - but that's not a "problem" for me. — xaosflux Talk 17:42, 31 October 2021 (UTC)[reply]
  • I think the idea has merit but that we run the risk of either making this too bureaucratic and too much of a hassle for voters. I would support something along the lines of quarterly elections (although we really would need a better word), similar to the Steward elections on Meta. Maybe something like a 5-day question & discussion period, and then a 5 day voting period. Using SecurePoll quarterly (or even bianually) could be difficult, so possibly a simple onwiki support/oppose/neutral, with a prohibition on discussion during voting would work. Giraffer (talk·contribs) 18:22, 31 October 2021 (UTC)[reply]
    The anonymity of SecurePoll does seem to be an advantage that can't be replicated this way. Advantage for the voters: Free voting without risk of offending anyone. Advantage for the candidate: A simple number as a result, not a list of specific people that seem to dislike them. ~ ToBeFree (talk) 18:48, 31 October 2021 (UTC)[reply]
  • As a lot of the votes are explicitly "support as a trial", can we agree on language to add to the proposal on how many of these elections to hold before a mandatory follow-up RFC? Presumably it would be 1-3 elections before the next RFC. User:力 (power~enwiki, π, ν) 18:35, 31 October 2021 (UTC)[reply]
    Three sounds sensible, as this would cover a 1 year period and should give good data. Though, I think it quite plausible that the community would reject this after one major failure. WormTT(talk) 08:10, 1 November 2021 (UTC)[reply]
    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)[reply]
  • I think this has merit, but I'm concerned about thresholds. Observationally, anonymous polling seems to draw far less support than open. The 70% threshold we apply to RfA is unlikely to be applicable to a hidden-ballot admin election, considering how even the most popular candidates in hidden-ballot ArbCom elections draw far more opposition than we see in equivalent RfAs. Vaticidalprophet 21:54, 31 October 2021 (UTC)[reply]
    • @Vaticidalprophet: I would urge you to support. No-one will be made to go through this process, and those who do in the first instances will surely understand that it is an experimental process and that a failure to be elected could simply be a failure in the process. A threshold can never be successfully worked out a priori: we didn't arrive at 65–75% at RfA that way, nor was that percentage appropriate for RfA when it began. To work out the threshold, we need this proposal to pass, and to see what happens in practice. — Bilorv (talk) 23:45, 31 October 2021 (UTC)[reply]
  • With the minimum participation standard shifted to an anonymous vote, there's a high chance of most voters ignoring most or all of the discussion. There are pros and cons to this, of course. We should however not harbour any illusions about the significant consequences of changing to a voting system. isaacl (talk) 22:07, 31 October 2021 (UTC)[reply]
  • We cannot user arbcom suffrage standards as they involve a multiple week process of checkusering every participant. Doing this for each RfA would a) be a huge workload for our CUs, and b) probably go against the foundation's CU policy. Without this step the process is very much open to gaming as it would be trivial to make sleeper accounts that meet the remaining suffrage requirements. I don't believe this has been considered with the current proposal.
    Did anyone ask the checkusers if they are willing and able to do this?HighInBC Need help? Just ask. 00:01, 1 November 2021 (UTC)[reply]
    The list of voters will be public, with timestamps of every vote, just like it is today. Only their votes become secret. You can already "make sleeper accounts" and use them for RfA voting. For some reason, we're currently not concerned enough to change this, for example by introducing RfA voting requirements or checkusering every RfA voter. ~ ToBeFree (talk) 00:32, 1 November 2021 (UTC)[reply]
    The proposal as written says to use arbcom suffrage standards, as written the proposal has this problem to address. If there was a different proposal then I would assess it based on its own merits. HighInBC Need help? Just ask. 00:35, 1 November 2021 (UTC)[reply]
    HighInBC, are you saying that because the proposed requirements are higher than today, the proposal will be more open to sockpuppetry issues? ~ ToBeFree (talk) 00:38, 1 November 2021 (UTC)[reply]
    No I would have used those words if I meant that, I am saying that the proposal as written has problems because it saying it would use standards that require a few weeks of work for each RfA and a radical change to our checkuser policy. HighInBC Need help? Just ask. 03:16, 1 November 2021 (UTC)[reply]
    Is this a dictionary/word issue? To me, "Voter suffrage would initially match Arbcom elections" means that voters have to be "registered over 1 month before election, 150 edits by election, 10 edits in the year running up to election, not sitewide blocked during the election, not vanished, and not a bot", which is the wording used at the details page of the proposal. None of this requires a change to our checkuser policy. Regarding SecurePoll voting, the additional work is purely technical (setting up SecurePoll), not scrutiny-related. As the current voter criterion at RfA is "registered over 1 second, 0 edits by election" and the voter list is public (with timestamps) during SecurePoll elections, the concern seems to be illogical. ~ ToBeFree (talk) 03:48, 1 November 2021 (UTC)[reply]
    HighInBC, we are limited to 75 words on the proposals, so I used the word "suffrage" to refer to the requirements to vote, and matched to Arbcom elections because they are already something that the community accepts. However, I do fully expect that a full Rfc on the election would take place before the first election so everything could be clarified. WormTT(talk) 08:17, 1 November 2021 (UTC)[reply]
  • One thing to consider with elections on a set calendar date is you may be disenfranchising a group of people for whom that time of year is always inconvenient. It might be a major religious holiday, or exams week at universities, or peak tropical storm season, or whatever. Letting people run at a time of their own choosing avoids that problem. -- RoySmith (talk) 00:28, 1 November 2021 (UTC)[reply]
    The date doesn't need to be the same from year to year. We can deliberately choose to move the scheduled period around to mitigate calendar issues. (I am conveniently ignoring technical issues; as described in Risker's comment, there are challenges in implementation.) isaacl (talk) 05:48, 1 November 2021 (UTC)[reply]
    The intention of multiple dates was to allay that problem, though we could absolutely move the dates each year as isaacl suggest. Alternatively, the standard RfA process would be available. WormTT(talk) 08:20, 1 November 2021 (UTC)[reply]
  • I think the references to Wikipedia:Requests for adminship/Eostrix are a red herring. Even if Eostrix had passed his RfA because Arbcom took another four days to make a solid and firm decision, he would have been desysopped anyway. Ritchie333 (talk) (cont) 14:43, 1 November 2021 (UTC)[reply]
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)[reply]
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)[reply]
Oh, certainly, except there are a lot of Wikipedians who wouldn't touch Google with a barge pole. WormTT(talk) 09:47, 2 November 2021 (UTC)[reply]
@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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
    The most obvious problem with that idea is that, as far as I know, we don't currently have the technical ability to do it. So, even if it were voted in, it owuldn't make any immediate difference unless and until the software or whatever was developed. Beeblebrox (talk) 18:29, 8 November 2021 (UTC)[reply]
    @Beeblebrox There is already a technical issue with SecurePoll; as mentioned above, technical issues should not be a reason to oppose this, and if there is a demonstrated need for this then something can be done. ― Qwerfjkltalk 20:35, 10 November 2021 (UTC)[reply]
    I also opposed the secure poll option for that very reason. This process is supposed to be coming up with actual solutions that we can implement forthwith, not brainstorming hypothetical scenarios we might be able to do someday. Also, note that I said "the most obvious problem". Even if we could do this, it seems clunky and just odd. Beeblebrox (talk) 20:41, 10 November 2021 (UTC)[reply]

It appears that Chinese Wikipedia is interested in using SecurePoll for similar purposes, though they have different considerations (notably, the recent office actions). --Rschen7754 03:17, 11 November 2021 (UTC) [reply]

Tracked in Phabricator
Task T295518

8B.alt Trial Admin election

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

Support (8B.alt Trial Admin election)

  1. As proposer. Many of the supporters above are suggesting a trial, and much of the opposition is reasonable regarding how well such a system will work and the unknowns that will be encountered. As such, recommend a single election based on layout in 8B, and then going forward we can have an RfC to answer questions raised as part of the trial. WormTT(talk) 16:19, 2 November 2021 (UTC)[reply]
  2. Per my !vote above. Extraordinary Writ (talk) 16:48, 2 November 2021 (UTC)[reply]
  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)[reply]
  4. Per my comments above. 🐶 EpicPupper (he/him | talk) 22:43, 7 November 2021 (UTC)[reply]
  5. Support - Support for a trial run as per my comments at 8B Admin elections. TheGeneralUser (talk) 20:35, 2 December 2021 (UTC)[reply]
  6. Support per my !vote on 8B above.--Aervanath (talk) 20:02, 8 December 2021 (UTC)[reply]
  7. Per above, if a trial helps some of the opposition to 8B feel more comfortable with a single trial, then rediscussing. —valereee (talk) 16:45, 9 December 2021 (UTC)[reply]

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)[reply]
  2. Per above. Also not clear what happens to successful and to unsuccessful candidates after the trial. --Rschen7754 18:03, 2 November 2021 (UTC)[reply]
    @Rschen7754 per 8B, successful candidates would become admins, unsuccessful would not. WormTT(talk) 18:47, 2 November 2021 (UTC)[reply]
    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)[reply]
  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)[reply]
  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)[reply]
    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)[reply]
    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)[reply]
  5. RfA is a discussion, not a vote. SecurePoll is not for adminship. 🐔 Chicdat  Bawk to me! 10:53, 3 November 2021 (UTC)[reply]
  6. RfA needs more discussion not less. HighInBC Need help? Just ask. 23:31, 4 November 2021 (UTC)[reply]
  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)[reply]

Discussion (8B.alt Trial Admin election)

General discussion

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

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Requests_for_adminship/2021_review/Proposals&oldid=1059594671"