Wikipedia:Requests for adminship/2021 review/Brainstorming

__NEWSECTIONLINK__

Purpose and format
The purpose of this page is to brainstorm solutions based on the issues identified during Phase 1 of this RfA review. It is intended to last 1 to 2 weeks depending on how the discussion develops.

On this page editors should feel free to create a new section to discuss an idea they have or even to just discuss an issue from Phase 1 more generally.

During Phase 2 the following format will be used when presenting ideas:

==A few word summary description of the solution being proposed== ''A 1-3 sentence description of the solution being proposed. For larger changes where new policy language may be required editors are encouraged to link to a subpage with wording and further details''
 * Issue(s) addressed: The number(s) of the issue(s) this solution is addressing

This example is based on a proposal from the 2015 RfA.

==Advertise RfAs with a watchlist notice== Another option is to post a notice announcing current RfAs on MediaWiki:Watchlist-details, which will display the notice on all watchlists.
 * Issue(s) addressed: #1

The goal is that no further RfCs/phases will be needed to implement any idea which gains consensus during phase 2. That is why this brainstorming period exists - to allow editors a chance to get feedback on their ideas and/or have time to fully develop their ideas before the 30 day discussion begins. Some details may, of course, be worked out during the 30 day discussion (i.e. during the 2015 review the multiple proposals for the exact percentage the discretionary range would start at were discussed/considered).

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

The following issues had a rough consensus of support from editors: 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 adverse 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 issues which had consensus against them when brainstorming 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

Idea: Administrator appointment board
Rather than using direct voting, the community would vote for members of an appointment board. This board would then cast the ultimate vote after a period for discussion.
 * Issue(s) addressed: 1, 2, 8

Discussion (Administrator appointment board)
Putting this here not because I support it but rather to kickstart discussion/serve as an example because it's something from my collection of RfA reform ideas that I'd seen proposed/discussed at times. Before this could be proposed some big details would have to be worked out including: I anticipate this is one where a subpage would be necessary for it to be proposed during phase 2. Best, Barkeep49 (talk) 20:51, 8 October 2021 (UTC)
 * Would there be different terms for elected/RfA vs appointed administrators?
 * Would some percentage of seats (50%?) need to go to non-administrators?
 * How do we define non-administrators? People who've never had sysop? People not eligible for at will reinstatement at BN?
 * What percentage would be necessary to pass (simple majority? 2/3? 3/4?)
 * An important read is the discussion rejecting the proposed Administrative Standards Commission, which was (I think) the most recent incarnation of this concept. The main points raised in opposition were that the proposal 1) was overly bureaucratic, 2) created a cabal, and 3) lacked true accountability. As such, a proposal would need to be very simple (e.g. no separate elections; make it a subcommittee of ArbCom) and very accountable (e.g. if thirty users email the committee objecting to a given sysop candidate, the process is void and the user must run at RfA) if it were to have any chance at success. The problem, of course, is that the more accountable it becomes, the more it begins to resemble RfA. But in my view, there's no way that the community is going to outsource its control over admins wholesale: it's going to insist on retaining at least a veto power and possibly a lot more. Extraordinary Writ (talk) 03:55, 9 October 2021 (UTC)
 * I want to add to this comment with an observation from the issues RfC: while there was consensus that we should explore alternate roads to adminship, a serious concern was creating a division within the admin corps. The issue of cabalism is not only in the committee itself but who gets sysop'd by the committee. Drafters should take care to consider why a cabal is perceived and try to mitigate how a new committee would change the legitimacy of institutionalized cultural capital across the sysop user group. Understanding the 2014 RfC that Extraordinary Write brings up and how it relates to contemporary views is, I think, incredibly important in creating a viable proposal along these lines. — Wug·a·po·des​ 20:24, 15 October 2021 (UTC)
 * As part of brainstorming, (i) delegate this to ArbCom (no separate committee needed or make it an ArbCom subcommittee); (ii) let them first appoint admins for a year and them reappoint forever. It might be some community discussion before the life reappointment, but it obviously only makes sense if it does not become a new RfA.--Ymblanter (talk) 08:49, 9 October 2021 (UTC)
 * I think an RfA for those having served a year is in order, the year having served as a probationary period. This also sidesteps the issue of whether we would/should have multiple hierarchical "tranches" of the admin corps because in the long run all admins would still have gone through the process. – John M Wolfson (talk • contribs) 10:43, 9 October 2021 (UTC)
 * People would take this route exactly to avoid RfA. I do not think if we add RfA as a requirement anybody would be interested.--Ymblanter (talk) 11:48, 9 October 2021 (UTC)
 * People would take the route to avoid the problems of RfA; having experience under their belts would shut most opposition up and reduce the corrosiveness of the atmosphere. – John M Wolfson (talk • contribs) 12:07, 9 October 2021 (UTC)
 * I doubt this. If I resign now and go for another RfA (which, for the record, I have done once on the Russian Wikipedia more than 10 years ago) I will most probably pass, but I am sure it is not going to be a pleasant walk, certainly way more unpleasant than my original RfA back in 2013.
 * We already have an "administrator appointment board" – it's known as the WP:Bureaucrats. I think you're getting at giving them more discretionary powers, which is something I'd probably support. Of course, some will oppose this idea, claiming "supervote". – wbm1058 (talk) 00:33, 10 October 2021 (UTC)
 * I'd suggest one of the options we put forward is to ask again about the Admin Standards Commission. It's a prepackaged, fully developed idea. The objections to it in 2014 would be much less substantial now; we know that RfA is broken, and we know it's unfixable, and none of the other solutions to the RFA problem that people proposed during that 2014 discussion have gone anywhere at all. We should also develop other alternatives so the community has choices.Arbcom is not the right body to make people admins. The Arbs have quite enough to do already and they weren't elected for that.—S Marshall T/C 01:21, 10 October 2021 (UTC)
 * With so few candidates for ACE in recent times, it's not particularly difficult to reach a pass threshold where there are just enough candidates to fill the seats. Hence this does not make arbitrators any more trustworthy than other users or admins. Such a process by an Arbcom sub-cabal would not be transparent and there is no guarantee that the committee members would do their due diligence (they have stated often enough that their tasks are not of an investigative nature). Thus any outcome from that small committee (or any other) would be based on personal likes and dislikes of the individual committee members.


 * The proposal for an Administrative Standards Commission was declined by 79/43 (around 2:1 against), and the participation was not really suggestive of a quorum for a discussion of such relative importance. Even WP:BARC, a proposed community desysoping process, but not entirely dissimilar to the kind of process proposed here, found much more participation.


 * Despite its unfortunate and totally unacceptable high level of toxicity RfA actually does its job quite well nowadays. In-depth scrutiny io candidates is necessary. Most passes since the 2015 reforms are achieved by an overwhelming consensus. Failed RfA have become a rarity and AFAICS, this is probably due to projects such as WP:ORCP, some comprehensive guidance, and blatant warning templates on the transclusion pages. Those that that do fail probably should have done. In earlier times there were more close run RfA. One knife-edge RfA that comes to mind was decided on a supervote closure by a single brand-new Bureaucrat, but that was a decade or so ago. An alternative system such as an Administrator Appointment Board is not the best solution. Kudpung กุดผึ้ง (talk) 02:15, 10 October 2021 (UTC)


 * Worth a try. This is likely what we'll end up with sooner or later if the community can't fix RfA, which looks a lot less likely than when this was last proposed in 2014. If nothing else when the number of active admins declines to the point that it becomes a serious problem then an alternative route to adminship would likely be established. ArbCom is a similar community elected body which has a similar function of ruling on issues which the community can't resolve, and it's not generally considered to be a cabal. I don't think quotas would be a good idea, the board should have the most qualified people on it and it wouldn't look good if a candidate with less support ended up on it just because they don't have a sysop flag. There ought to be some kind of role for community consultation in the process, maybe something similar to the community consultation for checkuser and oversight appointments.  Hut 8.5  13:15, 10 October 2021 (UTC)
 * Am I the only person looking at this suggestion in horror? When I try to explain the role "Bureaucrat" to someone, the most important part of the explanation is that they don't have sovereign power and strictly implement the community consensus. When I try to explain the concept of Wikipedia administration to someone, the most important part of the explanation is that administrators are elected by the community (and currently sadly unable to be de-elected by the community), don't have sovereign power and enforce policies that the community has decided upon in a consensus-based discussion. Granting the ability to appoint administrators against community consensus, who can then only be de-sysopped by ArbCom in case of severe or persistent misconduct, to a small group of super-administrators seems like a bad idea. I'm especially afraid that those required to take this route due to a lack of community trust will make up a majority of the appointed administrators. ~ ToBeFree (talk) 19:40, 10 October 2021 (UTC)
 * I think that's a mischaracterisation of the proposal. There's no suggestion that this board would appoint administrators against community consensus -- this is a request for the community to authorise a board to appoint sysops, so any appointment would by definition be in accordance with community consensus.  The proposed board (at least in the ASC format) would have the power to desysop.  It would coach, train, mentor, and where necessary sanction, sysops with a view to making their behaviour and decisions more consistent, in happy contrast to the current cavalcade of capricious and random sysop decisions.  You're right to say that owing to the toxicity of RfA, and the community's inability to reform RfA, it is likely that most candidates would prefer to apply via this route.  Surely what's horrific is the current RfA process.—S Marshall T/C 16:35, 11 October 2021 (UTC)


 * I like the idea, but I would like some thought going into the following questions.
 * How big should the board be? What should be the quora for a decision?
 * What community input would be allowed on a selection? How would transparency be managed?
 * For example, would the board make clear who it was considering - if so, would community comments be accepted - and then, how does this solve problems?
 * Would the board be elected? How often would it change?
 * I'm tempted to say I'd like near unanimity of a quora for subsection of the community to make such a decision. I also don't like the idea of this being related to Arbcom, I'd like that committee to do less, not more. WormTT(talk) 08:23, 12 October 2021 (UTC)
 * I think we should offer the community several choices on these things. Design #1 would be the ASC as described by RGloucester et. al.  For design #2 I might suggest:
 * Annually, the community should elect seven people to a RfA Panel. The quorum for the Panel would be five.
 * Everyone on the Panel would need the view deleted revisions permission to do their job, so unless any other proposals gain consensus here, they'd all have to be sysops.
 * The Panel would propose a person to the community. There would be a review period of seven days, during which the community would be invited to make comments to the Panel in strict confidence (i.e. via some private method).
 * At the end of the period, the Panel would vote. Two or more votes against would mean the person had failed.
 * The Panel would then make a public announcement, saying either: (1) After review, the Panel has agreed to grant sysop permissions to %editor; or (2) After review, the Panel has decided that %editor is not yet ready for the tools.
 * In case of failure the Panel would offer detailed feedback to the failing editor, by way of email.
 * The purpose of this design would be to maintain the community's role in decision-making about sysop permissions while removing the Hell Week: public dissection of the candidate's character and conduct would no longer be part of the process.—S Marshall T/C 10:20, 12 October 2021 (UTC)


 * DoNotLike - this intermediate step would create admins-like-existing-admins rather than spread the net wider. If someone runs wild with 'admin powers' they can be blocked and edits reverted. We should be making adminship easier, not more difficult. --AlisonW (talk) 15:53, 12 October 2021 (UTC)
 * An idea, I hope, that can be put down to a brainstorm rather than an exercise in brainstorming. It's just terrible. The idea of any sort of board or committee to select front-line functionaries who will operate within the community introduces centralised control on a grand scale. The potential for abuse far exceeds the purported problems it is seeking to address. Leaky caldron (talk) 07:07, 14 October 2021 (UTC)
 * I am all for brainstorming, and I don't think this is nearly such a terrible idea as Leaky caldron does, but I do think that the community as a whole will have similar fundamental issues with this idea, and I'm not sure how they can start to be addressed. As such, it may well be worth focussing on other ideas. WormTT(talk) 08:22, 14 October 2021 (UTC)
 * None of the other ideas offer the kind of step change it would take to solve the RfA problem. They amount to rearranging the deckchairs on the Titanic.—S Marshall T/C 14:08, 14 October 2021 (UTC)
 * I share the concerns of other editors that this would be the opposite of empowering the community. I am strongly opposed to having two concurrent processes for adminship. If this were adopted, I would want the existing RfA process to be discontinued, lest we end up with two "tiers" of admins. I'm pretty skeptical of this idea, as it feels undemocratic to me. Candidates should not have to be appointed by a board. With that said, I do think the idea should be considered in an advisory role. Think of how the American Bar Association rates judicial nominees in the United States as "well qualified", "qualified", or "not qualified" . Something similar for the adminship process might be helpful, as long as it doesn't replace the voice of the community as a whole. Having a board which considers if they believe RfA candidates are qualified would be a way to advise voters. Trainsandotherthings (talk) 18:44, 20 October 2021 (UTC)

Topic discussion: RfA should not be the only road to adminship
Noting that I reached out to Legal during the time that Phase 1 was being closed to see if they would be willing to provide a statement. I was told yesterday that they had an internal discussion about it and they're not ruling out alternative paths to RfA. I am hoping now that there is a rough consensus behind the idea someone from the legal team will make a more public statement. Best, Barkeep49 (talk) 20:51, 8 October 2021 (UTC)
 * , it's time for the flagship communities to assert more independence from the WMF. At the moment, the process of choosing admins may (or may not) be anchored in some Foundation policy, but I fail to see what 'legal' relevance this has. Notwithstanding, WMF policies can be changed by local consensus, and have been. Kudpung กุดผึ้ง (talk) 02:31, 10 October 2021 (UTC)
 * @Kudpung personally I share some concerns about the community's decreasing ability to self-governance and a personal opinion that has been caused in part by foundation moves to increase control. This feeling impacted how I voted during the recent board elections as the board can be an ally in this regard. That said, Legal got introduced to this process because of this 2014 statement. Hope that explains what relevance they have. Best, Barkeep49 (talk) 02:36, 10 October 2021 (UTC)
 * I rember the discussion well and I'll never understand what motivated Robert to propose it. I knew personally and we collaborated on some cross-wiki issues. He was one of the very few friends I had in the WMF in the old days, and with Maggie who also took a paid job and joined his team. But they were not lawyers or legal counsel. What he 'did' say was that the selection of admins must be done through community consultation like RfA, which if taken today would mean that any of the other suggestions in this current suite of discussions would also be ruled out. What he did not say was what those 'legal reasons' were.  Kudpung กุดผึ้ง (talk) 03:57, 10 October 2021 (UTC)
 * They did say what those 'legal reasons' were, although they were hardly legal. I remember finding the diff in another similar discussion at WT:RFA, IIRC it was some ~2009 comment from WMF Legal claiming that Congress would step in and create new legislation, if too many more people were given access to deleted content. It's a highly dubious claim, given that they can't even combat the issues posed by Facebook etc despite extensive discussions, and there's no wind blowing in that direction either, but that was Legal's position. ProcrastinatingReader (talk) 09:56, 10 October 2021 (UTC)
 * FYI, our exact RfA process isn't the only route that is already acceptable "upstream", locally our ArbCom election process is blessed; externally most any RfA system from any other project is OK, as is the stewards election system. There is a lot of room for adjustments that still allow for an afirmative showing of community support.  And nothing stops us having multiple, for example we could have RfA and also have VotesForAdminship.  Theoretically we could probably get away with an elected panel of admin appointers, as the WMF challenge is really about accessing deleted stuff and we already have this in place with being able to elect arbcom who can then appoint oversighters. —  xaosflux  Talk 10:16, 10 October 2021 (UTC)
 * @Xaosflux I have no horse in this race. My goal, to keep with this metaphor, is just to ensure the race is run fairly and to completion. I note this because there was a concern during Phase 1 that the 2014 statement would rule out larger changes. You are correct that strict elections would be allowed by the foundation. There was concern about whether an admin appointment board (itself elected) or delegation to crats or arbs would be allowed; during Phase 1 there was some mooting around the specifics of how delegating to the crats would work. Whether this would be seen as OK by Legal is what I was hoping to clarify. Best, Barkeep49 (talk) 15:55, 10 October 2021 (UTC)
 * So as far as to crats or arbs would be allowed I'd say "no, but". It would be no as-is, because the community that appointed these people didn't do it with that capability as part of the review of those positions.  The "but" is that we should be able to have a community vote to expand this capability if we wanted to. We're going to be hard pressed to get legal to engage on this - but  if we really wanted to go this route I think we could get it through, but out internal process would require some new hurdles to be built - but they could be different kinds of hurdles -- my guess is that bootstrapping that won't get consensus - but if it does I'd be happy to help with the minutiae. —  xaosflux  Talk 17:57, 10 October 2021 (UTC)
 * We're actually not going to be hard pressed to get legal to engage on this at least to the extent of a statement and I'm guessing if a proposal went too far afield a statement about that. Best, Barkeep49 (talk) 14:21, 11 October 2021 (UTC)
 * I think you're referring to this diff? (For whatever reason I seem to have become one of the keepers of the knowledge of where that one diff is located.) FWIW, my understanding—and I've had discussions with WMF people that make me pretty sure I'm right, although, for good reason, they'll never explicitly confirm this—is that the  and   issue centers around scenarios like the following: John Doe requests we remove a libelous statement on his article; we revdel it; and then John Doe takes a look at our deletion policy, sees that thousands of people can still see the content and that all they need do for access is ask nicely / be around long enough / etc., and decides to sue the WMF because they're still publishing the content. Same situation with copyvio. With Congressional action being the most extreme possible outcome if a scandal were to erupt around that.  --  Tamzin  [ cetacean needed ] (she/they) 16:31, 10 October 2021 (UTC)
 * Thanks for clarifying. I guess the Congressional action part was the memorable one for me, perhaps because it comes across as rather conceited.
 * DMCA requires that access to the content be "disabled" (whatever that means - there's probably case law clarifying this). There's nothing in DMCA that requires directly elected admins (indeed, most organisations don't democratically elect the staff members who can view DMCA'd content). It's also worth noting that just getting the desysop/sysop rate to net 0 would require a more ambitious RfA reform than is likely here, so there isn't going to be a ballooning in # of editors who can see copyrighted text. So I'd personally find it surprising if the WMF rejected a modest proposal for a new path to adminship, and if they did reject it I think they should back their view by citing some relevant case law. ProcrastinatingReader (talk) 17:43, 10 October 2021 (UTC)
 * So if we use oversight more aggressively, we can hand out mops freely? —Kusma (talk) 17:45, 10 October 2021 (UTC)

Statement from legal
gave me permission to post the following email he had sent me.

Barkeep49 (talk) 00:47, 14 October 2021 (UTC)

Idea: Formal moderation of RfA
RfA discussion would be significantly less corrosive if we installed moderators with formalized duties, rights, and responsibilities.
 * Issue(s) addressed: 2

Discussion (Formal moderation of RfA)
This was moved to the talk page during Phase 1 as a solution rather than an issue. Pinging its proposer for further comment/development. Best, Barkeep49 (talk) 14:01, 9 October 2021 (UTC)
 * I think in practice that this is already somewhat in place to a certain extent, but I don’t see a huge problem with this. I’d be interested to see John’s comment/development. —TheSandDoctor (mobile) (talk) 02:01, 10 October 2021 (UTC)


 * Possible solutions for Formal Moderation were offered way back in 2011 and then discussed in depth. The idea was generally rejected at the time, but the study project itself was finally abandoned due to trolling. If the current format of RfA were to be retained, moderation/clerking will be a necessity. For some reason, RfA has always been Wikipedia's single playground for abuse with impunity (and not only by trolls - in fact they are the least problematic of voters) and it's time to put a stop itKudpung กุดผึ้ง (talk) 02:49, 10 October 2021 (UTC)


 * Wouldn't it be easier to let bureaucrats handle this, rather than come up with some new group? -- Calidum  04:25, 10 October 2021 (UTC)
 * The claim - more from the community than from the Bureaucrats themselves - is that it's not the job description the 'Crats signed up for. See WP:BARC. Kudpung กุดผึ้ง (talk) 06:32, 10 October 2021 (UTC)


 * I'd support this in proper form, although I wouldn't suggest using the 2011 structure too closely, as it had some aspects that were rightly viewed as negatives. As part of it, I would want it to be fairly clear what they should and should not act on - with the former in particular highlighting what they might be doing now that is not currently done. Nosebagbear (talk) 11:30, 10 October 2021 (UTC)
 * I think this is a good time and place to discuss the kinds of things we would want a moderator to do, and the things we would not want them to do.--John Cline (talk) 07:13, 11 October 2021 (UTC)
 * Wikipedia has generally been pretty terrible at enforcing conduct standards in discussions between experienced editors. Unless these moderators had a lot of community backing I suspect it would be hard to find people willing to do the job.  Hut 8.5  13:29, 10 October 2021 (UTC)
 * It is probably easier to design a new process that doesn't need formal moderation than to introduce new behavioural norms to an existing process. —Kusma (talk) 17:51, 15 October 2021 (UTC)
 * I agree with you on that. In fact, if it came down to one or the other, I'd rather see a new or alternate path to adminship. In all honesty, resources like time and effort would likely profit more spent there, opposed to here.--John Cline (talk) 21:03, 15 October 2021 (UTC)
 * I would like the so called "badgering of oppose !voters" left entirely to the moderator's discretion. It always bothers me to see supporters piling on to ridicule an opposing rational which they disagree with, especially when the !vote itself has practically no effect on the overall outcome.--John Cline (talk) 07:13, 11 October 2021 (UTC)
 * With talk of imposing a word limit on every participate, which is a change I support, if it goes in effect, it intuitively seems that enforcing compliance should fall on the moderator as well.--John Cline (talk) 07:13, 11 October 2021 (UTC)
 * I think a word limit might be a good idea, with the caveat that an additional number of characters be allotted to respond to direct replies to a user. Trainsandotherthings (talk) 18:57, 20 October 2021 (UTC)
 * I think this should be handled with extreme care. Quite simply, I believe this one proposal has the ability to torpedo every other one, as it will effectively be status quo that people can support as a change. Or, in other words, if we allow this to be voted on, people can point to a "change being made", even though nothing will be different - there is already informal moderation on RfA pages, and without a very strong criteria on what is appropriate and what is not (something that I haven't seen yet), yet the general opinion remains that the atmosphere is unpleasant. So please, if we are moving forward with formal moderation, be specific about what would be moderated and why it would be different. <b style="text-shadow:0 -1px #DDD,1px 0 #DDD,0 1px #DDD,-1px 0 #DDD; color:#000;">Worm</b>TT(<b style="color:#060;">talk</b>) 13:11, 11 October 2021 (UTC)
 * I agree with all of your concerns. If there's a general consensus that formal moderation is desirable, the harder part, and the most important, will be developing the specific criteria associated with that role. While ideas here, and perhaps throughout phase 2 (should this idea advance) will be very helpful, I believe it is unlikely that this discussion (and perhaps phase two's) will result in that specific criteria. If the general consensus is strong enough, it will give the prudent reason for embarking on the harder part of establishing specifics. In the absence of such a strong general consensus (that this should be done) it is my opinion that it's a fool's errand to endeavor for specific criteria and a detailed charter at this time. --John Cline (talk) 21:18, 12 October 2021 (UTC)
 * Just a reminder that for Phase 2 specific proposals will be necessary so to the extent that it might need feedback/iterations now is the time to do it. A proposal about formal moderation is likely going to be hard to iterate/offer too many options for during Phase 2. Best, Barkeep49 (talk) 21:33, 12 October 2021 (UTC)
 * The 2011 Clerks research clearly identified what could/should be addressed and suggested some tasks for clerks The issue of clerking (which has now come to be called 'moderation') is a project that revolves around two specific themes: 1. what should be moderated, and 2. who should do the moderating. The discussions which ensued failed due mainly to side tracking and editors going off and stating their own simultaneous RfC.


 * IMO, due to the importance of addressing the toxicity of RfA as highlighted in Phase 1, clerking/moderation is going to be one of the major points in any programme for reform. Any RfC proposal statements(s) should bear this in mind and it might be an idea to collaborate with some users, such as just for example  who was a major contributor to the 2011 research, and who are skilled at carefully drafting neutrally worded RfC proposals which are nevertheless aimed at achieving the goal of the RfC, and   could be invited to expand on his comment above and help craft the statement. It's not going to be easy because the pool of RfA punters will not like the idea of its favourite playground being properly policed. Kudpung กุดผึ้ง (talk) 22:35, 12 October 2021 (UTC)
 * I've stayed away from all of this. On this particular proposal however, what is needed is simply for existing moderation arrangements to be actually implemented with greater consistency. It's simple enough to see with half an eye when extended discussions - usually down in the Oppose zone where someone takes exception to a controversial / trolling / perverse / daft oppose !vote - gets heated and pointless pile-on ensues. "Take it to the Talk Page" was the agreement and it should be done far more frequently by anyone in good standing but if really necessary a passing Admin. or 'Crat. Formal rules will cause more issues than they will solve and is wholly unnecessary. Leaky caldron (talk) 08:13, 13 October 2021 (UTC)


 * Take a glance at my RfA and what pops out at you? A couple of editor signatures defaced it with their graffiti-like signatures. I count "GregJackP" signing about 18 times and "Cassianto" signing about 17 times. We have a quota on questions asked. Why not a quota on number of posts to the discussion? wbm1058 (talk) 20:24, 14 October 2021 (UTC)
 * , Since partial blocks are now a thing, we can now simply block any bludgeoning editor (whether for or against the candidate) from the RfA for the remainder of the duration. The tricky bit is making sure there is a reasonable consensus for this when the blocked editor complains about "censorship" (even though, by definition, a partial block allows them to edit everywhere else). <b style="color:#7F007F">Ritchie333</b> <sup style="color:#7F007F">(talk) <sup style="color:#7F007F">(cont)  17:17, 15 October 2021 (UTC)
 * A partial block that is logged forever is a rather blunt method for the moderation of a discussion. —Kusma (talk) 17:41, 15 October 2021 (UTC)
 * We've tried the softly-softly approach, and it doesn't work; people still don't like the atmosphere at RfA, so we need to try something stronger. Don't want to get blocked? Don't badger at RfAs! Problem solved. <b style="color:#7F007F">Ritchie333</b> <sup style="color:#7F007F">(talk) <sup style="color:#7F007F">(cont)  11:18, 16 October 2021 (UTC)


 * I think formal moderation is a good idea, though the exact details would have to be worked out. Certainly, formal moderators handling responses to dubious oppose votes would be better than all the support voters ganging up on oppose voters. I'd like to see moderators decide what questions should be thrown out. We would also have to establish who the moderators would be, how they would be chosen, and if they would be required to abstain from voting on RfAs they moderate. Trainsandotherthings (talk) 18:57, 20 October 2021 (UTC)

Idea: If non admins do well in the Arbcom elections, make them admins
At the end of the Arbcom election, any non admin candidates who have >=65% support for adminship become admins. RFA itself remains as the other of two routes for adminship.
 * Issue(s) addressed: 3, 4, 8

Discussion (If non admins do well in the Arbcom elections, make them admins)
This was moved to the talk page during Phase 1 as a solution rather than an issue. Pinging its proposer for further comment/development. Best, Barkeep49 (talk) 14:01, 9 October 2021 (UTC)
 * Before commenting on this, I wonder even how likely of a route this is. How many A) non-admin candidates for ArbCom are there, usually (I assume: few and far between)? and B) how many of these get significant support (I assume: even fewer) (related: C - has any non-admin ever been granted adminship (one gets CU ex officio, so I assume adminship too) as a result of being elected to ArbCom?). I know, adminship isn't formally a requirement (5-minute_guide_to_ArbCom_elections); but there is obviously a huge gap between what is formally minimally required and what is practically required. RandomCanadian (talk / contribs) 00:42, 10 October 2021 (UTC)
 * In addition to Random Canadian's concerns, wouldn't this incentive people to run for ArbCom hoping to get adminship instead? &#123;{u&#124; Sdkb  }&#125;  talk 00:48, 10 October 2021 (UTC)
 * Yeah, also an issue. However, that also brings up the possibility, which would also fix issues no. 1 and 2, of doing "admin elections" in the same way we do ArbCom elections (i.e. a simple support/oppose neutral; ideally with more than a single candidate (i.e. combining with by ) RandomCanadian (talk / contribs)  01:11, 10 October 2021 (UTC)


 * ACE are often as toxic as RfA and subject to as much nonsense and trolling even if the voting itself is a secret poll. you can get your answers by reviewing a few previous ACE. There are occasionally one or two non-admin candidates for Arbcom who would make excellent committee members and I would support them (and have done). They sometimes get high scores but fall short of obtaining a seat simply because most voters consider adminship to be a prerequisite for Arbcomship. I don't think this '[would] incentive people to run for ArbCom hoping to get adminship instead', because what with all the candidate guides, unlimited questions, and discussions about the candidates, the process can be just as humiliating and discouraging for candidates who wouldn't want to submit themselves to RfA for the same reasons. To summarise therefore, any non-admin who gains a seat would probably qualify for automatic adminship. Kudpung กุดผึ้ง (talk) 03:07, 10 October 2021 (UTC)
 * Has any non-admin ever received more than 65%? If the answer is no (as I believe it is), this proposal would be of little practical value. (I also share some of the concerns expressed above, and I note that the community quite decisively rejected giving even successful candidates the mop.) Extraordinary Writ (talk) 03:17, 10 October 2021 (UTC)
 * I agree that this proposal would probably have very little practical value), but I don't know how to make sense of that RfC, since ArbCom members are ex-officio (and remain thereafter) Checkusers (arguably a position which requires even more community trust than simple admins); so it seems... inconsistent? or maybe it was a purely theoretical question and shouldn't be taken too seriously, since no non-admin has been appointed to ArbCom. RandomCanadian (talk / contribs) 03:25, 10 October 2021 (UTC)
 * Going back to 2009 no one (admin or not) has gotten 65% and not been elected. The highest non-admin percentage in that timeframe was 59.93%. Best, Barkeep49 (talk) 03:28, 10 October 2021 (UTC)
 * , there were two unsuccessful 65%+ candidates (DGG and Drmies) in WP:ACE2018, no? But putting that aside, it's clear that there would be vanishingly few cases (if any) where this provision would be invoked. I also note that the highest performing non-admin candidate has failed RfA twice, so it seems that the community may have its reasons for not affording moderately successful ArbCom candidates the mop. Extraordinary Writ (talk) 03:46, 10 October 2021 (UTC)
 * The relevant candidate guide has both as admins as of the time it was last updated... RandomCanadian (talk / contribs) 03:50, 10 October 2021 (UTC)
 * I realize that. I was responding to Barkeep's comment that "no one (admin or not) has gotten 65% and not been elected". Extraordinary Writ (talk) 03:52, 10 October 2021 (UTC)
 * You're correct about 65%+ EW. Best, Barkeep49 (talk) 03:58, 10 October 2021 (UTC)
 * This isn't likely to make a significant difference. If a non-admin does well in an ArbCom election then they aren't likely to have problems which would cause their RfA to fail (because their ArbCom election would fail for the same reasons) and they probably don't mind putting themselves through the process (because ArbCom is a lot worse). Meaning that a non-admin who does well in an ArbCom election probably just isn't interested in adminship. There are in any case very few such cases and the few examples are often ex-admins who resigned.  Hut 8.5  09:46, 10 October 2021 (UTC)
 * I've mentioned before that I don't like this, due to conflating two different processes. People who are voting in ACE should be considering whether the candidate would be appropriate on the Arbitration Committee. Candidates who want to stand should not have to risk being elected (and I'm serious about that - I can imagine non-admins running with an intent to become admin and accidentally doing better than other candidates). I fully support using a similar system, just not conflating the two. <b style="text-shadow:0 -1px #DDD,1px 0 #DDD,0 1px #DDD,-1px 0 #DDD; color:#000;">Worm</b>TT(<b style="color:#060;">talk</b>) 13:38, 11 October 2021 (UTC)

Topic discussion: Non-core admin-only tools remaining
Since unbundling was brought up, are there any tools other than blocking, deleting, and protecting that are still only for admins? I'm wondering whether anything substantial can be unbundled without touching those three. – John M Wolfson (talk • contribs) 14:40, 9 October 2021 (UTC)


 * Long ago we got consensus for some limited ability to delete your own work in your own userspace. something like U1 when the system could check that only your account had edited a page. But to be worthwhile it would need to be a system change, a delete button that disappeared from pages that others had edited. So good luck convincing the devs on that one. It would however reduce U1/G7 deletions, and much more importantly, empower all editors. There are some potential uses of view deleted, such as a combination of that and setting/unsetting the autopatroller, reviewer and rollback flags. But given the WMF reticence at handing out view deleted, I doubt that one would fly. Probably our best option is to have revision suppression as a tool availabe for active vandalfighters and copyvio detectors. Actually deleting pages is always going to be contentious, but revision suppression is rarely contentious.  Ϣere Spiel  Chequers  16:01, 9 October 2021 (UTC)
 * All of that still counts as "deletion" in my book. Even revdel without view deleted would lead to problems per the law of the instrument and bloat the deleted revision log IMO. – John M Wolfson (talk • contribs) 19:47, 9 October 2021 (UTC)
 * I can imagine that there would start being a lot more contentious revdels if the right was handed out more liberally (specifically under WP:CFRD, WP:CFRD, and WP:CFRD). &#8211;<span style="font-family:CG Times, times"> MJL &thinsp;‐Talk‐☖ 22:28, 9 October 2021 (UTC)
 * Something like this might be easier to do using an adminbot activated via a web interface. It could even have an API to allow for a gadget that creates a portlet link to trigger the bot. – <span style="font-weight:normal;background:linear-gradient(90deg,#e40303,#ff8c00,#ffed00,#008026,#004dff,#750787);color:transparent;background-clip:text;-webkit-background-clip:text;">Rummskartoffel 13:29, 20 October 2021 (UTC)
 * Obviously, non-admin closing of discussions which require deletion (and/or possibly undeletion) as a result--Ymblanter (talk) 16:15, 9 October 2021 (UTC)
 * True, and such closes are strongly discouraged, but they do still technically occur and don't require any special tools that can be reasonably unbundled. – John M Wolfson (talk • contribs) 19:47, 9 October 2021 (UTC)
 * On the Russian Wikipedia, there is a closer flag. A closer is not an admin, but they may perform nacs and delete articles if the result is delete. They may not delete articles under any other circumstances, I believe.--Ymblanter (talk) 21:37, 9 October 2021 (UTC)
 * The right to edit fully protected pages is still restricted to admins, but I believe proposals to unbundle that have failed. ( Would be useful for users working on main page content)Jackattack1597 (talk) 00:23, 10 October 2021 (UTC)


 * There is, in regards to the specific aspect of fighting vandals, this draft proposal (never formally proposed). Although that comes back to the question: if we trust X to do (Y-admin-task), why not trust them for Z too? Or less cynically and more pragmatically: is there any tool that, beyond technical/policy limitations that could be imposed (such as preventing those with a hypothetical "vandalfighter" role from blocking anything but non-ACs), would really be effective without the others (i.e. if you need to block vandals, you might occasionally find it is more effective to protect the page; and of course sometimes some vandalism requires page deletion or revdel: somebody who only has access to part of these tools can only do half the job ...) RandomCanadian (talk / contribs) 00:59, 10 October 2021 (UTC)


 * Dispute resolution in general is tilted towards admins. Even setting aside WP:NAC being discouraged, disputes in general get resolved by admins using tools more often than not. I've had a few situations where I've seen long-running content disputes that I just went ahead and intervened in by starting an RfC as an uninvolved editor. This has resolved the dispute more often than the standard admin tactic of "protecting to facilitate discussion" which can result in waiting 1/3/6 months before edit warring again. I believe the community in general would benefit if we mentally unbundled the ability to resolve conflicts from one's status as an admin and we made a greater effort to encourage the use of non-administrative methods to resolve conflicts in general. Chess (talk) (please use&#32; on reply) 00:59, 10 October 2021 (UTC)
 * Agree that there's lots of situations where admin tools are not really effective (or, conversely, required) if they are used without recourse to other methods (for example, I asked for move-protection of this after seeing a discussion on the talk page of somebody in my watchlist - the expected discussion/requested move/or even basic discussion has failed to materialise). Also agree that NACs shouldn't have any stigma against them, if done in an appropriate manner by somebody who knows what they are doing - although of course there's the problem that deletion discussions obviously require deletion tools to be closed effectively... RandomCanadian (talk / contribs) 01:08, 10 October 2021 (UTC)


 * This is basically another perennial 'unbundling' exercise. I am firmly convinced that here are no compelling arguments for further unbundling, even if not all admins use all the features in the tool box. In fact, contrary to unbundling I can think of plenty of areas where some tasks should be handed back to admin discretion. Kudpung กุดผึ้ง (talk) 03:12, 10 October 2021 (UTC)
 * You're probably self-consciously in the minority if you think there are "plenty of areas where some tasks should be handed back to admins"; but would you at least mind clarifying what kind of areas you're thinking of? RandomCanadian (talk / contribs) 03:31, 10 October 2021 (UTC)
 * I did not hint as to whether I were in the minority in the majority - anyone here is permitted personal thoughts without harsh criticism. I will not clarify here (yet) but if you have been around long enough you might wish to delve into some 'adminy' areas that have a high rate of failure or discord when attempted by non-admins and draw your own conclusions. Kudpung กุดผึ้ง (talk) 04:29, 10 October 2021 (UTC)

Let me pick on for a moment here to maybe better explain myself. They had an obvious need for the tools because RFD was frequently backlogged, and it was obvious Rosguill knows a lot about redirects (and had the backing of the other RFD admins). That was the primary purpose of their RFA besides helping with WP:NPP. Of course, almost two years later, Rosguill can now be found helping out at WP:AN/I or commenting at AE cases in addition to their regular work at RFD and NPP. If the same process that granted Rosguill the ability to help out in their primary areas of interest didn't also allow for them to comment at AE as an admin or issue partial blocks from AN/I reports, then I doubt we would ever see Rosguill in those areas. The same goes for practically every admin that hasn't answered Q1 with anything other than the dramaboards. That's just my opinion though. &#8211;<span style="font-family:CG Times, times"> MJL &thinsp;‐Talk‐☖ 20:00, 10 October 2021 (UTC)
 * Yes, you could unbundle a "view deleted revisions" permission. Would be able to see but not restore content that's been deleted -- appropriate for people active at DRV, for example. Needs coding and so would take WMF time away from their current power-grabbing exercise.—<b style="font-family: Verdana; color: Maroon;">S Marshall</b> T/C 08:02, 10 October 2021 (UTC)
 * that (and by nature undelete) are basically the only things that WMF cares we have a robust vetting process for candidate about. — xaosflux  Talk 10:23, 10 October 2021 (UTC)
 * Yeah, there would still need to be a RFA-like process. I think the community would apply lower standards to a VDR-only permission than a full sysop though.—<b style="font-family: Verdana; color: Maroon;">S Marshall</b> T/C 11:30, 10 October 2021 (UTC)
 * I don't think any involved coding would be needed for that. The underlying perms are already separate from other admin perms. A dev would just have to create a new group with  and , maybe also  . (We already have a user group, researcher, that has those three plus  , although researcher is granted by the WMF only.)  --  Tamzin  [ cetacean needed ] (she/they) 21:49, 10 October 2021 (UTC)
 * I don't think there are any significant user rights remaining to be unbundled apart from block/protect/delete, stuff closely related to one of those (e.g. revdel, viewdelete), and the ability to hand out some user rights. The rest either have been unbundled or are sufficiently minor that they won't make much difference. There might be some scope to allow experienced non-admins to close more discussions which are usually closed by admins, e.g. at AfD.  Hut 8.5  09:36, 10 October 2021 (UTC)
 * I do think unbundling via social restrictions (rather than technical) should be considered. When you vote at RfA, your only option is to vote someone in to be a full admin and use the tools in entirety, which can cause problems. The option to give +sysop and only allow the usage of tools for specific purposes (whichever are requested) offers far more options for editors who may be unsuitable for full adminship but still have a valid use for some of the tools, and there are no concerns with them exercising that part. I think a significant blocker at RfA tends to be dealing with conduct issues, particularly those involving blocking for non-vandalism reasons, so being able to abstract that away (for those who don't want to do that) might help. ProcrastinatingReader (talk) 10:05, 10 October 2021 (UTC)
 * Absolutely.--Ymblanter (talk) 10:10, 10 October 2021 (UTC)
 * I'm mostly in support of making an unbundled group - but only if it will serve a purpose and would be sufficiently populated. Problem is, I'm not hearing screams for "if only we could do x!".  Edit protect gets brought up from time to time, but there is generally not much backlog at Category:Wikipedia_fully-protected_edit_requests - where someone who just wants to help with edit requests is needed (as opposed to the perpetually backlogged Category:Wikipedia requested edits which almost any editor could already be helping at). —  xaosflux  Talk 10:46, 10 October 2021 (UTC)
 * I do not claim to have a project-wide overview, but for example inability to edit this fully protected page is the reason why at WP:CFD only administrators can close the vast majority of the discussions. Accidentally, WP:CFD is perennially backlogged, but I do not know whether it would become less backlogged once nac's are allowed, or just nobody cares about categories.--Ymblanter (talk) 10:51, 10 October 2021 (UTC)
 * The problem that makes RfA's difficult is not one of technical bundling but one of cultural bundling. There are many, many admins that you rarely see but go about doing the grunt work of adminship: processing CSD's, granting permissions, modifying MediaWiki and other technical stuff, etc. There are admins that are prominent in the controversial and highly visible areas of adminship: ANI, AE, RFPP, EW, etc. (Of course, there are also those that do both.) Anyone wanting to be an admin of the former type needs access to the same technical group permissions as those in the latter. This includes deleting articles and viewing deleted material, which I understand are the abilities the WMF insists on only allowing access to through a community process. Every RfA, however, is overshadowed by the idea that every admin wants to be one of the highly-visible ones. Even RfA's that provide a Question 1 response that make their desire to not do that type of highly-visible work are difficult. (and I apologize for the use of you as an example) is one such admin. At the time of his first RfA he had a great record of technical contributions and it was clear that the admin bit would help but his nomination failed because he didn't have "enough" article contributions. In other words, despite a clear record that the bundled tools would be a benefit to the project, the cultural bundling of gnomish adminship and big stompy adminship kept him from helping in those areas for a year and a half. So while there are probably some some permissions listed here that could be peeled off (does anyone really care about creating or modifying short URL's?) that would not change the fundamental issue. The cultural issue that every RfA is for big stompy adminship is not going to be addressed by permission changes.  Eggishorn  (talk) (contrib) 15:42, 10 October 2021 (UTC)
 * they don't care about "delete" - the only things they really care about are: viewing deleted (and by extension undeletion), the ability to make admins or 'higher', and the already-split interface editing. — xaosflux  Talk 18:00, 10 October 2021 (UTC)
 * Noted and updated the statement. I don't think it changes the substance but thank you for the correction. Eggishorn  (talk) (contrib) 18:16, 10 October 2021 (UTC)
 * That might be true for the WMF, but I think that those that would object to unbundling would not do so out of the same reasons as the WMF... RandomCanadian (talk / contribs) 18:39, 10 October 2021 (UTC)
 * While I get the reason why people want to see a cultural unbundling of the admin tools, I don't think people realize that if there was two tracks for potential admins to go down (one for handling controversial areas like AN/I and one for everyone else), then we would practically never get new admins for the former. The only way it works right now is that we have candidates do a song and dance about how they are really interested in doing [insert X non-controversial admin activity here] only to later get involved with helping out in the controversial areas (for the obvious reason that those areas frequently need help).
 * This might also be why some people are reluctant to run (at least, although not interested in RfA at the moment, it's my case: more details not needed here), especially if they have previously been involved in controversial areas (where involvement is likely to get you on unfriendly terms with at least some amount of persons): most use of admin tools is not particularly controversial (blocking and protecting are certainly uncontroversial the vast majority of the time; and even deletion, save for the occasional close run AfD/whatever-fD, isn't either), and I guess there are many people who could be trusted to do this correctly who currently aren't admins. And of course, this is also caused by a cultural aspect of some people viewing admins as having some form of superior status (as evidenced by the stigma around WP:NACs - which, unless it involves something which needs to be deleted or some other currently admin-only action, can probably be done competently by any uninvolved experienced editor, even when it is controversial); which goes back to the necessity for having people deal with the actually controversial aspect, ... RandomCanadian (talk / contribs) 00:02, 11 October 2021 (UTC)


 * Now that non-admins can delete-by-proxy (by moving something to draft-space with no real rationale, even after a PROD has been rejected) the list of things non-admins can't do is getting smaller and smaller. I don't think the answer is to make that list even smaller again by handing some non-admins half a mop based on their area of personal interest. I'm interested in AFD. I participate there fairly regularly (when I'm active). I non-admin-close things all the time, but only ever non-controversial technical things. But handing me a mop would be a terrible idea. I know the ins-and-outs of AFD. I've seen most of the arguments before, and made most of them myself. An experienced and articulate editor can probably game the system effectively to produce whatever outcome they want at least 75% of the time. We don't need more AFD closers. What we need are uninvolved admins willing to do the hard work of AFD which (believe it or not) isn't the closing; it's the log fixes, the comment refactoring, the topic-bans, the blocks, the closure of disruptive and pointy nominations, prevention of zero-WP:BEFORE nominations, and obvious examples of said system-gaming. It makes me super-leery when I see the same admins simultaneously nominating things for deletion, contributing to AFDs, and closing AFDs. They are consistently the ones most likely to super!vote something closed when they should have simply contributed (as they have shown they are willing to do). I'm also super-leery about appointing AFD regulars to adminship generally; 1. because of the propensity to see it as "promotion" to a position of power in an arena they frequent, and 2. because the nature of AFD itself is so antithetical to the purpose of this project. There are so many ways to exclude content from this "encyclopedia that anyone can edit"; those who revel in the argumentative nature of AFD to achieve that aim are usually amongst the most aggressive of deletionists because all other efforts to stymie contributions have been exhausted.  St ★ lwart 1 1 1 01:24, 11 October 2021 (UTC)
 * There have been a lot of very insightful comments posted in this section, and I, for one, really appreciate the thoughtful considerations that are collectively evident throughout. In general, I am a proponent of unbundling tools where a non-admin can be empowered to do more in building Wikipedia, and protecting what's already been built. For the most part, this discussion has well articulated that the remaining tools in the admin set are not easily unbundled and that their effective use generally requires having access to the collective set opposed to an individual piece here, and another piece there. What hasn't been said as thoroughly well, is: are there areas where help is needed (specifically help that requires tool use) to the extent that it would be worthwhile to find a workable solution? If so, what areas are in the most need? If not, then there's really nothing to solve. Thank you for considering this comment.--John Cline (talk) 10:42, 11 October 2021 (UTC)
 * The only unbundling I would be in support of would be allowing template editors to grant the template editor role and new page reviewers being able to grant the new page reviewer role (though I'm less enthused by this one), and perhaps the introduction of a role capable of granting rollback and PCR that would require a similar process as edit filter role requests. All other admin permissions listed at Administrators require similar levels of trust, and I would feel uncomfortable granting only some. Anarchyte  ( talk ) 12:14, 11 October 2021 (UTC)
 * I don't think there is ever much backlog at WP:PERM/TE, however as far as patrollers go - not sure about using them to create more patrollers - however letting patrollers assign (and maybe revoke) autopatrol could be useful, WP:PERM/A does get backlogged. If you want to go further with these, it can just be split to a discussion at WT:PERM that is well advertised and doesn't need to wait for this process. —  xaosflux  Talk 13:58, 11 October 2021 (UTC)
 * How would people feel about splitting the role in two? Effectively content management admins / user management admins. Current admins can have both user-rights, future admins can ask for one or both. User management would be focused on the block button, Content on the delete button. I can't say it's my favourite idea - but if we're looking at unbundling, it's a way we could go. <b style="text-shadow:0 -1px #DDD,1px 0 #DDD,0 1px #DDD,-1px 0 #DDD; color:#000;">Worm</b>TT(<b style="color:#060;">talk</b>) 13:50, 11 October 2021 (UTC)
 * , I can see that falling apart very quickly. This incident, for example requires both blocking and revision deletion. I believe that there are many such incidents which would require a content management admin to co-ordinate with user-management admins. Even routine vandal fighting and POV-pushing would require a constant stream of "can you do this" requests from one group to the other and vice-versa. Eggishorn  (talk) (contrib) 14:11, 11 October 2021 (UTC)
 * Absolutely, so can I. As I say, not my favourite solution, but it is a workable starting point for a solution. Given the brainstorming nature of the discussion, I thought it was worth putting out there.
 * That said, it could be argued that co-ordination works well in those circumstances. Say, vandal-fighting, 99% can be done with the user-management hat on, moreso if we include page protection in both roles. Similarly for POV pushing. Effectively, I'm thinking that the User management admins would look after areas such as WP:AN / ANI / ANEW, while content management admins would look after places like XfD etc.
 * With separate roles, we'd have different types of concerns for each, questions could be more tailored etc. What's more, you'd be able to demonstrate skills with one before applying for the other. ... It COULD work. <b style="text-shadow:0 -1px #DDD,1px 0 #DDD,0 1px #DDD,-1px 0 #DDD; color:#000;">Worm</b>TT(<b style="color:#060;">talk</b>) 16:09, 11 October 2021 (UTC)
 * Alright, if we proceed from that basis, maybe there is something here. From the point of view of breaking the cultural bundling I discuss above, maybe the need for constant communication is a feature and not a bug. It would require that the primary communication channel for such coordination would be something more effective than the noticeboards. IRC and Discord already have been established as channels so it could work. I'm honestly not sure if that's just something that developed or if there has been formal community approval of off-wiki adminness. Given that ArbCom conducts a large proportion of its business off-wiki, even that wouldn't necessarily be a hurdle. Eggishorn  (talk) (contrib) 16:29, 11 October 2021 (UTC)
 * Of course, Arbcom facilitates its discussions through a mailing list and I'm not sure that would be any better than a noticeboard. Communication would be a key aspect of any split though, and should be considered were any proposal to come out of it. <b style="text-shadow:0 -1px #DDD,1px 0 #DDD,0 1px #DDD,-1px 0 #DDD; color:#000;">Worm</b>TT(<b style="color:#060;">talk</b>) 14:56, 12 October 2021 (UTC)

PAGE ]]) 02:58, 21 October 2021 (UTC)
 * The more you unbundle abilities/functions the fewer people-who-would-be-worthy will see becoming an actual 'admin' will put themselves forward, or let themselves be put forward. If the desire is to increase the number of admins then re-bundling might even be appropriate. --AlisonW (talk) 15:58, 12 October 2021 (UTC)
 * Ding ding ding! Exactly. The winning answer in this section. The creation of "page movers" has been an absolute disaster which has cratered the participation level of "real" admins at WP:Requested moves. If you want to increase the number of administrators, you could start by unbundling the ability to block extended-confirmed editors from the admin toolset, and only allow ArbCom members or those they appoint to block long-term editors. – wbm1058 (talk) 20:43, 14 October 2021 (UTC)
 * As I noted at the previous discussion, some of us proposed unbundling the ability to edit the main page. There's many non-admins involved in curating content that we feature there, and it seems like the lowest-hanging fruit as far as unbundling is concerned. The proposal was rejected by a pretty large margin: some of the objections were technical, and some were IMHO utterly unreasonable, but most argued that we can't trust editors with main page content without an RFA. I personally disagree, but I don't think it's an unreasonable position to take, and if that's the community's attitude I don't see us getting much mileage out of this particular idea. Vanamonde (Talk) 17:50, 12 October 2021 (UTC)
 * There are several other things that only admins can do, such as moving any of the thousands of pages that require administrator rights to move them (efforts to allow pagemovers to move them have failed), editing fully protected pages, performing a histmerge, suppressing revisions, assigning permissions, etc. --Ahecht ([[User talk:Ahecht|<span style="color:#FFF;background:#04A;display:inline-block;padding:1px;vertical-align:-.3em;font:bold 50%/1 sans-serif;text-align:center">TALK

Idea: Tranches Cohorts of candidates
The level of scrutiny is high in part because RfA's are exceptional events. When RfA's were commonplace, the level of scrutiny was much lower. Presenting tranches of 5-10 candidates would provide candidates mutual support and reduce over-examination of individual candidates. This would address Point #4 by allowing candidates who do not wish to run the current gauntlet to do so in an environment where they are part of a supportive group and also one which there will not be a laser focus on their entire history. Spreading scrutiny in this way would address Point #2 and also lessen the corrosive nature and impossible standards of Points #1 and #3. Eggishorn (talk) (contrib) 00:57, 10 October 2021 (UTC) Header edited per 's cogent arguments below. Eggishorn (talk) (contrib) 19:24, 13 October 2021 (UTC)

Discussion (Tranches of candidates)
The chief problem I see with this idea is finding the people willing to be part of that first tranche. Once it gets established as a method, it may be successful but who will want to be the guinea pigs? Ensuring the proper level of mutual support would also take some work. Maybe a candidate/mentor Zoom or Discord or Slack? That might fall afoul of off-wiki canvassing issues, though. Eggishorn (talk) (contrib) 00:57, 10 October 2021 (UTC)


 * @Eggishorn we ran a tranche (or what I labeled a flight) of editors in September 2020 and another 5 or 6 (I forget the exact number now) explored running but did not, with one of those running and passing later. I found the editors through regular postings to WT:RFA as well as talking it up in other places when RfA would come up. Best, Barkeep49 (talk) 01:10, 10 October 2021 (UTC)
 * , it looks like 3 out of five of that "flight" passed, and passed easily. The number of questions asked of the candidates was lower than normal, as well. The three full-length (i.e., successful) RfA's averaged 11 questions whereas an overlapping trio of nominations from May of last year averaged 14 questions and even more recently, who had not one "Oppose", faced 17. Limited sample sizes and everything as caveats, but it suggests that there is some merit.  Eggishorn  (talk) (contrib) 01:29, 10 October 2021 (UTC)
 * I agree that there were less questions at those RfAs so on that level it was a success. But the reason I haven't organized a second flight is because of the other 2 who didn't pass. Neither has continued editing despite being good editors and 1 of them I am pretty sure wouldn't have run without the flight. I suspect the other would have run anyway and I ended up opposing them for admin but still very much wish we had them as an editor. If tranches encourage people to run who wouldn't otherwise it's only a good thing if those are people who would pass but are otherwise reluctant to run. If it draws out people who are reluctant to run and those editors are right to be reluctant it's not actually a net positive especially if they are otherwise valuable members of the community. One tranche is too small of a sample size to draw any firm conclusions but the risk of net harm is why I didn't organize more of them. Best, Barkeep49 (talk) 01:39, 10 October 2021 (UTC)
 * <span id="202110100302_Extraordinary_Writ"> Interesting idea. It would be good to get some statistics on what happens when multiple candidates run at once: I know that in the most recent incident, one passed unanimously while the other went up in flames. Extraordinary Writ (talk) 03:02, 10 October 2021 (UTC)


 * When RfA's were commonplace, the level of scrutiny was much lower. Was it ? Tranches are probably a good idea - 'safety in numbers'. Candidates would feel less intimidated if they were not running alone, and indeed there have been times when several RfA running simultaneously were the norm rather than the exception. Regular tranches, say quarterly at fixed dates and requiring a minimum of two candidates, might, just might, help towards building a corps of more serious regular voters rather than the drive-by people who happen to see a watchlist notice, and socks and trolls. Kudpung กุดผึ้ง (talk) 04:34, 10 October 2021 (UTC)
 * This would be interesting to get some statistics on. &#8213; Qwerfjkl  talk  07:41, 10 October 2021 (UTC)
 * What statistics might those be @Qwerfjkl? Best, Barkeep49 (talk) 15:51, 10 October 2021 (UTC)
 * Those that Writ Keeper referred to. &#8213; Qwerfjkl  talk  16:03, 10 October 2021 (UTC)
 * I have to do other things at this time but I might try to put something together later tonight. In the meantime, you can take a look at the RfA's in 2007 (when there were 408 successful candidates) or those in 2008 (when there were 202). That number of candidates meant that there were always multiple RfA's at the same time. Eggishorn  (talk) (contrib) 16:52, 10 October 2021 (UTC)

If fixed RfA dates are introduced, then perhaps there would be willingness to extend the length a bit, given that the spotlight may be reduced on each individual candidate and the decrease in periods of ongoing RfAs, thus accommodating the proposals to break up the process into separate phases. (On a side note, I don't think tranche is an apt name, since this typically is used to refer to a division of the whole.) isaacl (talk) 22:05, 10 October 2021 (UTC)

I think this has a lot of merit. It does raise some questions that we'd need to address around how tranches are formed. For example the rule might be that the minimum tranche size has to be (say) five, so any nominee would have to wait until there were four other nominations before theirs could proceed; or we could make RfA something that's only open during (say) one month per year, so all the nominations would have to take place during that time, thus encouraging multiple RfAs to be open at the same time - but again nominees would be waiting for the right time for their nomination to proceed. Neither of these are awful scenarios and I'm sure there'll be other ideas, but it's worth considering the drawbacks of each idea as well as the merits. <b style="color:#98F">W</b><b style="color:#97E">a</b><b style="color:#86D">g</b><b style="color:#75C">ge</b><b style="color:#83C">r</b><b  style="color:#728">s</b><small  style="color:#080">TALK  15:58, 11 October 2021 (UTC)

I have collected data on RfAs since 2016 which was chosen as reflecting RfAs since the last major changes. I labeled RfAs as either being simultaneous (defined as running for at least 4 out 7 days with another RfA or the rough equivalent for withdrawn candidates) or not simultaneous. I ignored any clear NOTNOW/SNOW candidates and I also am ignoring the 1 reconfirmation RfA. That data set had 128 RfAs, with 68 simultaneous and 60 not. 76.6% of those who ran simultaneously with someone else passed, while 69.1% of those who ran solo passed. Looking at just successful RfAs (to control for the length of the RfA) simultaneous candidates had on average 16 questions and 195.6 participants while non-simultaneous candidates had on average 19.1 questions and 212.9 participants. Best, Barkeep49 (talk) 20:25, 12 October 2021 (UTC)
 * I think this is a good idea that should be pursued further. I'd like to hear input from people who have gone through RfA in the past few years as to if they think it would have improved their experience. Trainsandotherthings (talk) 17:03, 24 October 2021 (UTC)
 * I agree this should be pursued further. To Waggers' question, I'd have a mild preference for setting a number rather than setting a date. Ensuring the number of candidates will always be equal will put editors on a more level playing field and ensure that we always have the optimum number of candidates (whatever that ends up being) rather than too many (which burdens !voters and could cause scrutiny lapses) or too few (which burdens candidates). I agree that 5 sounds like a reasonable number; we could adjust it up or down over time as we discover how well it works. One potential drawback of the system is that it might force someone to run at a time less convenient for them. To alleviate that, perhaps the system could work such that once a flight is filled, the editors in it talk with each other and choose a week sometime in the next month to run. &#123;{u&#124; Sdkb  }&#125;  talk 06:39, 25 October 2021 (UTC)
 * This strikes me as a solid idea. Opening up regular "RfA seasons", say four times annually, and putting up batches of candidates during that period, would lower the stakes for the candidates involved and provide a regular schedule and incentive to find new worthy candidates. I'd be in favor of some version of this proposal. Ganesha811 (talk) 16:16, 25 October 2021 (UTC)

Idea: Trifurcate discussion, Q&A, (!)voting
A few editors brought this up previously and I though it was a good point and that is to separate Q&A, discussion and !voting. I suppose there are multiple ways this could occur, but I imagine a 3-3-3 approach: editors have three days to submit questions, at the end of which no more questions are accepted; the candidate has three days to respond to the submitted questions; 72 hours later, (!)voting commences and lasts for a quick three days. Make this true voting in which editors are limited to registering support, oppose or neutral without comment. Throughout the entire process, discussion occurs on the Talk page, versus the (!)voting space.<Br/>By time-limiting Q&A and effectively prohibiting follow-ups we limit the back-and-forth that seems to be the onus of the "deeply unpleasant" atmosphere. By moving discussion out of view of (!)voting, we preserve the opportunity for discourse but, perhaps, limit the number of drive-by comments by requiring an extra step to access it. I'm not set on this specific formula but I think any approach that modifies processes rather than creates new systems (e.g. limits on subject of discussion, creating panels of moderators, etc.) will be more likely to see implementation and better preserve the spirit of our current approach. Chetsford (talk) 01:37, 10 October 2021 (UTC)
 * Issue addressed: 1
 * Are you suggesting that the 2 question limit is retained? &#8213; Qwerfjkl  talk  07:44, 10 October 2021 (UTC)
 * A couple of issues arise to me: one is that "3 days" is not an anomalous amount of time for people to be off-site. This means I can see lots of cases where people would know about an RfA and want to (!)vote in it, but simply not be around at the critical time. To a lesser degree, this issue also applies to the first stage. Late-game questions can end up be critical where something arises later on, and so the usual problems arise there. As a more general note, I do think you're correct that modification rather than replacement is more likely to pass. Nosebagbear (talk) 10:59, 10 October 2021 (UTC)
 * Agree 100% that this is problematic on several levels but, especially, time limiting Q&A or !voting to just a few days. Chetsford (talk) 15:25, 10 October 2021 (UTC)
 * As in Idea: Tranches of candidates, it could be predetermined when discussion will start. &#8213; Qwerfjkl  talk  15:47, 10 October 2021 (UTC)
 * Yes, I'd keep the two question limit, however, by requiring all questions be submitted during X period and then all questions answered during Y period, you eliminate the possibility of chain gang follow-up in which a single action by the candidate is endlessly probed. Chetsford (talk) 15:25, 10 October 2021 (UTC)
 * - in that vein, the issue with that would be that sometimes follow-up questions are necessary. Either because the original question doesn't sufficiently answer the issue, or because it raises completely new issues Nosebagbear (talk) 15:06, 12 October 2021 (UTC)
 * I agree there's definitely a trade-off that will occur. Chetsford (talk) 00:46, 13 October 2021 (UTC)
 * I'm suggesting something similar below, but with a different split. My problem with a 3/3/3 split is that it seems to push for the worst of all worlds. Some people do not find questions particularly useful, others pay less attention to the discussion. I think you will find one of these two phases will end up being redundant or individuals trying to push to act in the other way. Finally, the 3 days of voting, as Nosebagbear points out, is insufficient to ensure we don't disenfrancise users. Start on say, a Saturday and you will get the voting on a weekend, where people may be paying less (or more) attention, or have less availability.
 * I do however, agree with the idea of splitting discussion and voting into different pages. <b style="text-shadow:0 -1px #DDD,1px 0 #DDD,0 1px #DDD,-1px 0 #DDD; color:#000;">Worm</b>TT(<b style="color:#060;">talk</b>) 15:04, 12 October 2021 (UTC)

Idea: Administrator probationary period
Make the first 180 days of administrator tenure a probationary period. During this period, the administrator will be subject to a compulsory recall process using a to-be-determined formula. If the administrator is not recalled within 180 days, the probation is lifted and the current status quo with respect to recall processes (it's voluntary) resumes. As I read it, the recurring issue that's been identified by mandatory recall opponents is the potential for gaming of the system in which admins operating in contentious areas build-up a laundry list of enemies and then get railroaded into a bad faith desysop. While this largely seems to be a hypothetical issue, in cases where it does manifest I'm sure it would rarely or never be faced by very new admins; those within the first six months of their appointment. Chetsford (talk) 01:48, 10 October 2021 (UTC)
 * Issue addressed: 6
 * Makes sense to me and would lower stakes mentioned somewhat. —TheSandDoctor (mobile) (talk) 02:07, 10 October 2021 (UTC)
 * The problem, of course, is that it's easy to game: just do uncontroversial things for 180 days (deleting obvious spam, blocking obvious vandals, etc.) and then move on to controversial things (arbitration enforcement, ANI, difficult deletions, etc.) once the sword of Damocles has been lifted. It's an interesting idea, but that question would need an answer. Extraordinary Writ (talk) 02:59, 10 October 2021 (UTC)
 * That's an excellent point. I would respond by clarifying that the issue this is addressing is one of perception (depressurize "a risk adverse and high stakes atmosphere") versus one of practice (stop bad actors from becoming admins). The idea is merely intended to decrease the pressure of the atmosphere by creating an emergency exit to soothe the nerves of !voters fixated on the infinite unknown. It is not intended to actually ferret-out determined bad actors, and has very little utility in doing so for the reason you correctly identify. It's like the Queen's reserve powers; they never actually get used but it makes some people feel good that they're there. Chetsford (talk) 04:01, 10 October 2021 (UTC); edited 04:18, 10 October 2021 (UTC)
 * That's an excellent answer. My next question would be: how do you keep the recall system itself from being gamed? For instance, the widely used sample process allows six editors to force a reconfirmation RfA. We've had recent successful RfAs with 88, 92, and 116 opposes: what would stop a handful of disgruntled editors from finding some pretext to initiate a recall? I can think of a few answers (including the interesting prospect of only allowing the candidate's supporters to initiate a recall), but I'd be eager to hear your thoughts. Extraordinary Writ (talk) 05:15, 10 October 2021 (UTC)
 * Good question. I would say that, if the terms of the probationary recall were equal to the terms of the initial RfA, it would be difficult to game. In other words, if RfA passes at 70% support, recall would also require 70% support (oppose !votes permitted). That's a high threshold to game and the recall, in other words, simply becomes a chance for the community to have a "do over" if an admin doesn't seem to be working out in the first X period of time. I think the recall could be initiated by a petition signed by 10 extended confirmed editors. Chetsford (talk) 15:00, 10 October 2021 (UTC)


 * Probationary periods have been discussed before. However, what metrics, if any, does one apply? For example to a new admin who simply does not use the tools for the first 3 months. Kudpung กุดผึ้ง (talk) 04:58, 10 October 2021 (UTC)
 * I think this could work but possibly not in terms of probationary time but in terms of probationary admin actions: say 1000 (obvious gaming such as deleting and undeleting pages in own userspace without a good reason not counted).--Ymblanter (talk) 07:23, 10 October 2021 (UTC)
 * May be adding to this. I work in the university environment, and we have lifetime appointments (well, until the mandatory retirement), but the first part is a tenure track - when the appointment is formally not permanent, but a tenure review in 5 years make it - or does not make it - permanent. There are two important features of the system which we can reflect on and possibly incorporate in the proposal: (1) the person(s) taking the decision during the tenure review is not necessarily the same person taking the hiring decision. In our case, for example, it might be some review after the end of the "tenure track" but not in a form of full-scale RfA which would make it less stressful; (ii) one could also consider mentorship, or even mandatory mentorship - of course if an evil party wants to become admin to block Jimbo Wales this is not going to help, but for many candidates just below the RfA passing threshold is it usually one aspect which sinks the RfA, and the mentorship can help them to realize how to get around this aspect.--Ymblanter (talk) 07:33, 10 October 2021 (UTC)
 * Your comment about tenure got me thinking. Instead of a recall initiated by editor action, maybe there's just an automatic, mandatory, one-time "retention election" after X number of admin actions to conclude the probationary period. That would be similar to Mailer_diablo's WP:AMR proposal but be a one-time thing that was triggered semi-automatically after X# of actions. Chetsford (talk) 15:13, 10 October 2021 (UTC)
 * That's a good idea, I prefer this option (X# of admin actions) versus a time-based metric. Chetsford (talk) 15:00, 10 October 2021 (UTC)


 * While I'm a little nervous about use of purely perception-based mechanisms, for the purpose of this discussion, I'd suggest a mix of time/admin actions, in a similar vein to protection levels. 180 days/500 admin actions I believe is reasonable (1000 is actually quite a lot, and depending on your area, could take a very long time to get to). As to "how to stop recall-gaming" question. That's a tough question. The "no opposes allowed" issue is tough, and "supports only" would rule out the vast majority and necessitate canvassing, which is not good. Nosebagbear (talk) 12:43, 10 October 2021 (UTC)
 * I like this idea. While I do think that "bad-faith desysopings" are more a moral panic than a genuine issue (if it's truly bad-faith ANI can sort it out, and admins are simply community volunteers, not combat veterans), this does avoid this issue while also lowering the stakes. However, would inactivity with the tools be grounds for "failing" the period? – John M Wolfson (talk • contribs) 14:18, 10 October 2021 (UTC)
 * I think this would be sensible. The details can be hashed out, but the aim is that someone can be given adminship on a probationary basis and then upgrade to full. This means that people are less likely to oppose candidates on the grounds that it's too high a risk/too difficult to recall them, and the probationary admin can demonstrate their abilities. Stifle (talk) 20:11, 10 October 2021 (UTC)
 * Probationary periods attempt to solve the problem of a lack of a community recall procedure, but they merely delay the problem. We already have a probationary period called "non-adminship", and those doing well in it are elected to become administrators. We can add another probationary period called "probationary adminship", and those under probation will be extremely careful not to upset people until they have finished the probation period. This makes the probation meaningless. What we need is exactly the opposite: A period of non-recallability, say a year, after every successful RfA, followed by an infinite period of recallability. This allows new administrators to gain experience and learn by doing, making occasional beginner mistakes, before being subject to a re-election. That's how the German Wikipedia community does it, and it works. That's also what I'm voluntarily providing at User:ToBeFree/recall because it's a good process. ~ ToBeFree (talk) 20:17, 10 October 2021 (UTC)
 * "We can add another probationary period called "probationary adminship", and those under probation will be extremely careful not to upset people until they have finished the probation period." I agree, there's no argument against this possibility. That said, the issue this is trying to solve isn't bad actors sneaking in, it's the perception bad actors could sneak in; the perception is what contributes to issue #6 "a high stakes atmosphere". The probation is intended to act as a salve to the catastrophic thinking that leads some !voters to apply insurmountable standards. So this is only a measure to depressurize a "high stakes atmosphere", it is probably not very useful as a solution to the separate issue of bad actors sneaking in. Chetsford (talk) 21:35, 10 October 2021 (UTC)


 * To my mind, every admin is _always_ on a form of probation, given that we are all subject to review of our actions by others for every edit and admin action we carry out, whether having served 20 days or 20 years. For all the above reasons I don't see this as being specifically beneficial to the aims. --AlisonW (talk) 16:05, 12 October 2021 (UTC)


 * Probation should be a kind of "support" vote, rather than subjecting every admin to the probation process—if an admin is unquestionably qualified according to the vote, the probation period shouldn't be necessary. As an example, maybe if you pass an RfA, and a majority of the "support" votes want the candidate to be on a probationary period, then it'll apply. Otherwise, they'll be outright admins like before. theleekycauldron (talk • contribs) (they/them) 02:17, 26 October 2021 (UTC)

Idea: Temporary adminship
Create a secondary method, users can now candidate to have 2-years lifetime sysop flag. This new process does not accepted poorly reasoning oppose voters, such as "no need for tools", or high-standard requirement, such as 20.000+ edits, 2 FA, 2 GA, etc. After 2-years with flag user can, either, run again temporary adminship or get permanent flag at WP:RfA. Carlosguitar (Yes Executor?) 03:54, 10 October 2021 (UTC)
 * Issues addressed: #6 and #8
 * Issues it may address: #3 and #5

Discussion (Temporary adminship)

 * Temporary time with tools can later discussed if community prefer 180 days, 1, 2 or 3 years. Same goes to poorly rationale oppose voters. Carlosguitar (Yes Executor?) 03:54, 10 October 2021 (UTC)


 * Temporary adminship would probably not appeal to most editors. As far as I could make out, once obtained adminship is a jealously kept privilege/medal of distinction as proven by those totally inactive admins who just return to do their one edit to avoid being desysopped for lack of activity. An award of temporary adminship should not be a reason to lower the bar. Kudpung กุดผึ้ง (talk) 06:41, 10 October 2021 (UTC)
 * Who would prevent these oppose voters?. Would there be moderators, as in Idea: Formal moderation of RfA? &#8213; Qwerfjkl  talk  07:51, 10 October 2021 (UTC)
 * I don't have strong opinion on this, initially I was thinking about bureaucrats-only, but we can advance the discussion later if we should get some sort of moderation or clerking. This phase we should get enough consensus to have temporary adminship or not, later discuss details about time, poor oppose voters and who moderate. Carlosguitar (Yes Executor?) 09:55, 10 October 2021 (UTC)
 * I'm generally in support of doing something like Meta:Administrators - it is time limited (1mo to 1year as requested) but is only for a stated set of specific reasons. Think it is a good enough catch-all for any one who wants to just help with some specific thing for a while.  This isn't really appropriate if the thing is the social powers of admins such as dealing with arbcom remedy enforcement. —  xaosflux  Talk 10:49, 10 October 2021 (UTC)
 * 2 years is a significant length of time, and it would be odd to disallow a (!)vote that would otherwise be permitted normally for what is very similar to the same. I'd object to this method - it would be better to try and prohibit certain types of non-reason from all RfAs Nosebagbear (talk) 11:02, 10 October 2021 (UTC)
 * We can leave to candidate to select between 180 days, 1, 2 or 3 years mandate, the 2-years was only a example, what do you think? This way also works as a sort of intership or trainee program, which user gets more experience and confidence, maybe later can run to get permanent tools at WP:RfA. I don't think we will able to get consensus for removing high-standards requirements in current RfA process, some people think that working in main articles and getting 2 FA and 2 GA is quite important to understand how Wikipedia works and be an administrator, therefore we need a new process that is disallowed such high requirements. Carlosguitar (Yes Executor?) 18:43, 10 October 2021 (UTC)
 * , I'm not sure why you'd leave it to the candidate - my objection is that early time is both the most active and subject to more mistakes. As such, the assessment of whether someone is both trustable and competent inherently needs to be front-loaded. The issue isn't what they do in years 2-4 of being an admin, it's what they'd do in months 0-6/12/24 Nosebagbear (talk) 11:14, 12 October 2021 (UTC)
 * , It is more flexible way to the candidate experience the tools at same time create less pressure in the manner that temp admin will work, so a user can request 6 months first time, on second time can request again 6 months, and maybe a third mandate with 6 months or 1 year. Many good users doesn't feel confident enough to request permanent tools because RfA turned into a hard place (issue #1), therefore the more flexible and friend we make a new Request for Temporary Adminship process, less bad atmosphere we will have. About less time with tools, it is because some people may argue that a admin is gaming system by requesting only 3 months flag and making no substantial, no controversial and obvious work, so 2-years is not few nor too much time IMO. But I am not against 3-months up to 3-years of temporary flag. Carlosguitar (Yes Executor?) 18:57, 12 October 2021 (UTC)
 * Is there evidence of a significant number of candidates who would be qualified for RfA, but choose not to run but would do so if they could apply for a shorter time-frame? Nosebagbear (talk) 19:07, 12 October 2021 (UTC)
 * I think the idea behind is to create a new friend process (issue #8), where candidate feel more comfortable to request the tools, since we didn't get consensus to reform RfA. I not sure about evidences, because temporary adminship was not a thing discussed much, so most of time that a user think about getting tools it may think solely about the hard process that RfA is. Carlosguitar (Yes Executor?) 19:58, 12 October 2021 (UTC)
 * If we attempt to enforce a "support" consensus by forbidding some types of votes we subjectively consider to be "badly reasoned", a) people will be less interested in providing a (alternative-less/forced) "support" vote, and b) those opposing a candidate for whichever reason will find a way to voice it in a policy-compliant way. If we forbid people from writing "I oppose the candidate because they have never written a Featured Article", then people will write "I oppose the candidate due to a lack of content experience". The reasoning is the same, but we're suddenly forcing people to keep their actual criteria secret, perhaps even to lie, just to make their vote count. This is not desirable. ~ ToBeFree (talk) 20:33, 10 October 2021 (UTC)
 * I'd like to see some stats, but I wouldn't be surprised if the quantity of admin actions decreases after two years of tenure. It would need to be lower because if my instincts are correct, this would be like granting adminship for the high-intensity duration and then taking it away when they naturally move on. Wouldn't change much, and if I trust someone for two years I trust them indefinitely. Anarchyte  ( talk ) 12:17, 11 October 2021 (UTC)

Idea: Hand out adminship to stewards
Stewards, having been through a rigorous community vetting process, should be able to bypass RFA and request permanent adminship at WP:BN. MER-C 08:53, 10 October 2021 (UTC)
 * Issues addressed: 8.

Discussion (Adminship for stewards)

 * At the very least, I would require that they speak English with some degree of fluency.--Ymblanter (talk) 09:59, 10 October 2021 (UTC)
 * And some degree of involvement with the project, which is difficult to quantify, but may be a number of non-automated edits.--Ymblanter (talk) 10:02, 10 October 2021 (UTC)
 * These kinds of proposals (along with others like "If non admins do well in the Arbcom elections, make them admins") do not deal with the crux of the issue, only apply to minority candidates, and would not really solve the issue identified in proposition A in the issues RfC. Even if they passed, their effects would be marginal, and even having them up for voting distracts from more substantial proposals (which may well be harder to achieve consensus on, but more discussion on those parts may well lead to something workable). I don't think any of these should make it to voting for this reason. I'd say there are also other issues here (consider that even meta doesn't give automatic adminship to stewards), but that's mostly an aside. ProcrastinatingReader (talk) 10:08, 10 October 2021 (UTC)
 * Agree with this. Furthermore suggestions of new routes to adminship don't help much if they are far harder than passing RfA.  Hut 8.5  13:49, 10 October 2021 (UTC)


 * Per the above, I would reject this idea, since it is not a realistic way to solve the issues here. RandomCanadian (talk / contribs) 14:38, 10 October 2021 (UTC)
 * Stewards already shouldn't do much in their home wiki, so combined with their rather small number I don't think this would help. – John M Wolfson (talk • contribs) 14:58, 10 October 2021 (UTC)
 * While it might not solve the issues at RfA, it does solve the issue that we are running out of admins. These candidates have already been vetted by the community in order to become stewarts, so a speedy process to promote them will save the community time that it can focus on writing an encyclopedia. I agree that there should be additional criteria for stewarts to meet, including a certain number of edits and demonstrate that they have read the required policies and guidelines. Z1720 (talk) 15:03, 10 October 2021 (UTC)
 * Stewards are not implicitly qualified for local adminship in large, self-governed wikis. They intentionally do not mess with our local matters, and I'd say we don't want them to. ~ ToBeFree (talk) 20:05, 10 October 2021 (UTC)
 * Neither sensible nor useful. Stifle (talk) 20:11, 10 October 2021 (UTC)
 * I fail to see how it will solve our acute shortage in new admins. Stewards already have enough to do on their home wikis, as well as at Meta; and they have enough troubles with LTAs, spammers, xwiki vandals and spambots, not to mention other things. We need not burden them with a right they are not very likely to use. Briefly, not very useful.  Java Hurricane  14:14, 11 October 2021 (UTC)
 * Actively harmful. User:力 (power~enwiki, π,  ν ) 23:15, 11 October 2021 (UTC)
 * Stewards are designed to be a catch all for wikis that do not have their own processes. They've got more than enough to do without worrying about our project. What's more, our project has a lot of nuances which I would expect an admin to understand, and I would not expect a steward to automatically understand. Finally, I don't want to be encouraging users to become stewards with a view to become admins on en.wp - that seems like a poor route. <b style="text-shadow:0 -1px #DDD,1px 0 #DDD,0 1px #DDD,-1px 0 #DDD; color:#000;">Worm</b>TT(<b style="color:#060;">talk</b>) 10:26, 12 October 2021 (UTC)
 * Former steward here, and I agree... when I was a steward I stepped away from adminish things on en:wp. Becoming steward was an onerous process, even then. So I don't think this helps much even if it was something stewards would want. ++Lar: t/c 14:23, 12 October 2021 (UTC)

Idea: Admin-ability to block an admin from using their tools
If admins had the technical ability to block another admin from using their tools, much concern about "life time tenure" and difficulties with removing the tools could be allayed. Also, by forcing a leave of absence from tool use, ostensibly during periods of admin burnout and lapses of reason, many Arbcom desysops may not happen at all. Past efforts have shown it nearly impossible to achieve a community process to remove the admin bit, but this is something that I think we can do.--John Cline (talk) 12:16, 10 October 2021 (UTC)
 * Issue(s) addressed: 6.

Discussion (Admin-ability to block an admin from using their tools)

 * I think this would be a good opportunity for admins to police their own corps while alleviating much apprehension regarding the many admin things that are entirely too hard to correct. --John Cline (talk) 12:16, 10 October 2021 (UTC)
 * I don't think this would ever be used, or (more importantly in this context) fix any problems at RfA. ProcrastinatingReader (talk) 12:26, 10 October 2021 (UTC)
 * If there's any truth in the notion that if it was easier to desysop a "rogue" admin !voters at RfA would be less apprehensive about supporting new admins, I would think this could have a similar calming affect. If it's a non-starter, nothing's been lost for the thought. Best regards.--John Cline (talk) 13:00, 10 October 2021 (UTC)
 * My thinking on this proposal is that technical ability to do something doesn't (and shouldn't) mean something will actually be done, similar to the reason why admins are basically never unilaterally blocked (except if completely uncontroversial, like a compromised account). In practice, any kind of "admin tool-use block" would always be preceded by discussions at AN, at which point this concept is not distinct to normal site blocks/bans, emergency steward action, or ArbCom cases (as appropriate). I also doubt it would ever be an appropriate action, because bad judgement usually doesn't happen in succession to the point where a preventative tool-use block would be appropriate. That kind of rogueness doesn't happen on enwiki anyway, and I don't think it's what RfA voters are concerned about. I think they're more concerned about persistent bad judgement that never quite rises to the level of ArbCom, or only appears at ArbCom after causing a lot of long-term frustration. This proposal wouldn't fix that. ProcrastinatingReader (talk) 15:09, 10 October 2021 (UTC)
 * That being said, there is the related idea that the community should be able to implement bans on admin use of tools. It's an interesting concept, and I don't see why it shouldn't already be possible (the community can already ban editors from any kind of definable activity at AN), but I'm also not sure that would really reduce the high-stakes atmosphere at RfA. Perhaps if there was evidence of such a system working well, but since it's often difficult to get consensus for bans of non-admin established editors at ANI, I'm sceptical. ProcrastinatingReader (talk) 15:13, 10 October 2021 (UTC)
 * Thank you ProcrastinatingReader. As normally is the case, your comments are rather astute. You have a keen ability to bring out areas of consideration that may have, otherwise, not been considered. I'm glad that you've shared your insight here. Best regards.--John Cline (talk) 01:12, 13 October 2021 (UTC)
 * Except any evidentiary levels to warrant such a use would need to approach that of an ARBCOM desysop anyway, and not something you'd want lone admins doing. I don't know if it would help the RfA aspect anyway, but even if it did, this would seem a "cure worse than the disease" issue Nosebagbear (talk) 13:28, 10 October 2021 (UTC)
 * Also don't think this is going to help, in situations where using this right is appropriate the admin should be desysopped instead. If you want to make it easier to desysop people then propose another community desysop process, if there isn't consensus for that then there definitely isn't consensus to leave the decision up to one person.  Hut 8.5  14:03, 10 October 2021 (UTC)
 * If the prerequisites for applying such a restriction of tool use followed the same limitations we now observe, " preventive, not punitive", I don't think it would automatically imply that using the technical restriction meant they should have been desysoped instead. You are probably correct in saying this is not a feature to be left to the discretion of a single admin. In fact, reflecting on things stated so far, I agree. Z1720 has counterproposed a few things below that I believe are worthy of consideration. Best regards.--John Cline (talk) 19:37, 10 October 2021 (UTC)
 * I would feel uncomfortable for Admins to do this, but I'm supportive of Bureaucrats using this tool more often, with the understanding that if a Bureaucrat does this the blocked admin can appeal to ARBCOM, and a case is automatically opened to examine the conduct (so arbs cannot decline an admin blocking case). I would couple this idea with encouraging the community to recruit and promote more Bureaucrats. Z1720 (talk) 14:56, 10 October 2021 (UTC)
 * I appreciate your comments, thank you for sharing them. My hope was that ideas, like yours, would emerge. You've made some good points and I would definitely support whatever came of them. I suppose if I had to summarize the idea in this section, I would just say that our past inabilities to establish a procedure for removing an admins tool-set might be surmountable if instead our procedure only results in a technical suspension of their functionality. Thank you again.--John Cline (talk) 19:37, 10 October 2021 (UTC)
 * This exists; it's called a "block". It also encompasses editing; perhaps a partial block would technically work. It's just practically never used because the resulting controversy ("oh my god, an administrator has blocked an administrator") is extremely undesirable for all parties, and because we expect administrators to be able to change their behavior without being technically forced to do so. All concerns about wheel warring, asking the protecting administrator before undoing their protection, asking the blocking administrator before unblocking, and all the desire for careful collaboration between administrators is contrary to this proposal. ~ ToBeFree (talk) 19:58, 10 October 2021 (UTC)
 * You're right, and I suspect it would be seldom used. It's a matter of having a manner of community recourse, or not. Not having community recourse is largely responsible for why things have devolved unto the current state. And why it could be a continuing trend.--John Cline (talk) 20:36, 10 October 2021 (UTC)
 * I'm not sure this would achieve anything, but I'm open to being convinced. Stifle (talk) 20:12, 10 October 2021 (UTC)
 * I appreciate your objectivity Stifle. Whether the end sees you in support or opposition, the fact that you didn't oppose out of hand means quite a lot to me, and speaks considerably well of you (in my opinion). Best regards.--John Cline (talk) 01:12, 13 October 2021 (UTC)
 * The underlying concept - blocking admins from their toolkit - has already discussed and rejected. See Arbitration/Requests/Case/RHaworth/Proposed decision as well the section that follows. If an admin has to be blocked from using their mop, even if for a cooldown, in all practicality and probability they are not fit to be admin: the community expects admins to not use their tools when they are incapable of responsibly using them, say for emotional reasons, till they regain their proper sense. An admin who abuses the toolkit so grossly will probably be taken to ArbCom soon enough for long-term issues, and the Fred Bauder ArbCom case was a good example of that.  Java  Hurricane  15:27, 11 October 2021 (UTC)
 * I'm not sure this fits under this project, but I will say that I don't think it's a good idea as written. "Blocking from using tools" would be carry stigma and I cannot see a case where desysop would not be the right decision - which makes me think, if we do go down this route, perhaps it would be better to create a "temporary desysop" mechanism, in periods of 24 hours to 1 week, which would be automatically restored at the end, and could link in with an Arbcom case. There may be some use cases for that, but as I say, not necessarily for this project. <b style="text-shadow:0 -1px #DDD,1px 0 #DDD,0 1px #DDD,-1px 0 #DDD; color:#000;">Worm</b>TT(<b style="color:#060;">talk</b>) 10:22, 12 October 2021 (UTC)

Idea: Remove !voting at RfA, replace with a discussion and crats determining consensus
Instead of editors !voting on a candidate, a discussion will take place. Editors can express their opinions with a bolded "Support" or "Concerns", then give their thoughts about the candidate. After a pre-determined time, bureaucrats will determine the consensus of the discussion. The running tally of !votes and percentage of support will be removed.


 * Issues(s) addressed: 1, 5.

Discussion: Remove !voting at RfA, replace with a discussion and bureaucrats determining consensus

 * I believe one aspect of the corrosive environment is the voting at RfA and the interest in the support/oppose tally of a candidate. "Oppose" declarations have been used less often in other processes, such as WP:FAC, because of the negative association with this declaration. In this idea, "Oppose" is replaced with "Concerns". Editors joining the discussion are encouraged to explain why they support or have concerns about the candidate. Declarations will not be split into support and oppose sections, as the goal is to facilitate a discussion instead of a vote. When the RfA closes, bureaucrats will determine the consensus of the RFA discussion and can discount concerns such as, "No need for the tools." Z1720 (talk) 15:26, 10 October 2021 (UTC)
 * While I'd personally like this idea, I note that issue B ('make it more like a discussion') did not gain consensus; there was consensus for the status quo in terms of discussion vs vote, with a slight preference for 'make it more like a vote'. So I think this idea is out of scope. ProcrastinatingReader (talk) 15:30, 10 October 2021 (UTC)
 * (I was going to make a separate section; but Z beat me to it): (I'll note that this is similar to ; and to 's comment in )):
 * Since this has been brought up by multiple, and is also a problem that can actually be noticed at RfAs (from the now-frequent sillyness about being "open to recall"; to absolutely ridiculous stuff like Requests for adminship/Blablubbs where some people [ultimately, without consequence] opposed someone for endorsing WP:NONAZIS...); there probably should be something done about this. WP:NOTAVOTE is already a fact of life for every other discussion on Wikipedia (and RfAs, unlike ACE, are not pure votes, so unless we go that way, this will remain a discussion and not a mere vote), and it probably should be enforced, at least in some way, at RfA: at the very least, bureaucrats should be free to strike-through any comment which lacks supporting reasoning or which is blatantly out-of-line. RandomCanadian (talk / contribs) 15:32, 10 October 2021 (UTC)
 * I also agree with Z's broader suggestion, although it is much harder to judge consensus when there is a significant amount of participation (and it isn't snowing to one side), such as one could expect at RfA. RandomCanadian (talk / contribs) 15:32, 10 October 2021 (UTC)
 * An alternative would be giving everyone a word limit (except the candidate, and the questions section, which has its own limits); and a relatively short one (not more than a few hundred words). That way the discussion side can remain, but people don't get to make much ado about nothing; and obviously with less words one needs to concentrate on important issues and not focus on tiny details. RandomCanadian (talk / contribs) 15:37, 10 October 2021 (UTC)


 * Notwithstanding the facilitator note at the top, I hope editors will still consider some other ideas in this proposal, such as replacing "Oppose" with "Concerns", the word count, and removing the running tally of support/oppose percentages. Z1720 (talk) 15:56, 10 October 2021 (UTC)
 * Yes all those ideas could certainly be proposed. For Phase 2 specific proposals will be necessary so the details around a word count (how many words, would it only apply to the voting section or elsewhere, etc etc) would need to be worked out which is why I specifically mentioned it and not the idea of re-titling the Oppose section or removing the running tally. Best, Barkeep49 (talk) 16:01, 10 October 2021 (UTC)
 * Formalising: I'll add two specific proposals here, with the idea being that wording can be improved, and if any proposal is deemed to be extremely unlikely to pass, so that we can figure this out sooner rather than later:

Proposal: Word limits at RfA/RfA participants behaviour
This seems to have attracted some tentative support, so I'll make a suggested wording (details, as per above) [to replace the final point on the edit notice]: 500 words is the same limit as at WP:AE and at ArbCom case requests, so seems a logical statement. Keeping the initial !vote shorter is an innovation, and might not be strictly necessary if people are aware of the 500 word limit (as they will then naturally tend to keep their comments shorter), but having this formally will more explicitly encourage the brevity and "concentrating on important issues and not tiny details" which I mention in my previous comment. RandomCanadian (talk / contribs) 17:51, 10 October 2021 (UTC)
 * Participants in an RfA are expected to remain polite and courteous when discussing a candidate. Participants are also expected to allow for reasonable discussion and not to impose themselves on the discussion. As such:
 * Individual participants may not ask more than two questions of an RfA candidate. They may, however, ask appropriately relevant follow-up questions for reasons of good faith; for example: to improve understanding or mitigate the effects of a misunderstanding. [note: unchanged]
 * Individual participants (whether in expressing their support or concerns) are limited to 200 words for their initial statement; and are limited to 500 words overall (whether as follow-up to their statement or to comments by others). This limit does not include any questions under point 1 (although these are reasonably expected to remain short); and does not apply to the candidate. Bureaucrats are allowed to enforce this restriction as they seem fit. [this last sentence not strictly necessary, but for clarity's sake]
 * Arbitration enforcement requests have a word limit, but there is no limit on subsequent discussion. Arbitration case requests aren't nominally intended to be discussions—participants are supposed to be offering evidence to help decide if the case should be accepted or not. A word limit can only be managed if each commenter has their own section, and if the format is changed from a conversation to essentially individual statements. Instead of responding directly to someone else's arguments, you would rework your statement to accommodate your counterarguments. This could be helpful in making the process more efficient, but it would be a significant change in the mode of operation and require participants to rewrite their statements as needed, which generally they find more onerous than conversational replies, as well as re-read other people's statements, which takes more time. isaacl (talk) 22:29, 10 October 2021 (UTC)
 * ...participants are supposed to be offering evidence to help decide if the case RFA should be accepted or not. ;-) IznoPublic (talk) 11:16, 20 October 2021 (UTC)
 * I was describing why a word limit for arbitration case requests is manageable, as they aren't discussions and each commenter has their own section. isaacl (talk) 15:45, 20 October 2021 (UTC)

I mentioned this elsewhere, but I believe this is a good idea with the caveat that editors are allotted additional words to answer direct replies to their comments. Rather than a 500 word limit overall, perhaps a word limit per reply would be better? Trainsandotherthings (talk) 17:11, 24 October 2021 (UTC)


 * My suggestion is that oppose voters can only "Oppose per Q3" or one of a few specific canned objections (WP:NOTNOW), in other words there is no option to give a detailed response in the oppose voting. If you have concerns that other editors should heed, phrase them in the form of a question so the candidate can respond. User:力 (power~enwiki,  π,  ν ) 17:18, 24 October 2021 (UTC)

Proposal: Re-titling the Oppose section
Per above: this to encourage a more collegial attitude (you are expressing your concerns with someone's suitability for the admin role, not opposing them personally) and also to encourage people to actually spell out valid 'concerns'. RandomCanadian (talk / contribs) 17:51, 10 October 2021 (UTC)
 * The "Oppose" section shall be retitled "Concerns"
 * I would like to see all three sections eliminated entirely, in favor of a straight discussion. Most discussions receive commenters in their order of arrival, like we are discussing things now. While it would make things harder on crats when evaluating consensus, I think it would improve the discussion overall.--John Cline (talk) 19:59, 10 October 2021 (UTC)


 * A very reasonable idea and the absolute minimum of change that should happen as a result of the 2021 RfA reform. ~ ToBeFree (talk) 21:43, 10 October 2021 (UTC)

I don't think there are participants who remain unaware of the need to describe their concerns (as there are many people willing to remind them). I also think that those who are prone to expressing themselves in ways that give the impression that they are opposing someone personally aren't going to be swayed by the section title.

From a semantic point of view, if RfA continues to have a straw poll format, then "Oppose" is more appropriate. If it moves to a "determine consensus of pros vs cons" format (for example, as I proposed in 2015), then "Concerns" may be apt. I don't believe there is sufficient community support for this change, though. isaacl (talk) 22:45, 10 October 2021 (UTC)

Idea: Wikiproject:Ask Them to Run
A Wikiproject will be established for editors to suggest potential RFA candidates, and to invite candidates to run.


 * Issues(s) addressed: 4

Discussion: Wikiproject:Ask Them to Run

 * A Wikiproject will be established for editors to suggest potential RfA candidates. Editors cannot suggest themselves, as that is what WP:ORCP is for. When a potential candidate is posted, editors will be encouraged to assess their candidacy and indicate "Support" or "Archive". "Archive" means that the editor would not support their candidacy at that time; when one archive is recorded, the suggestion is archived immediately. No discussion or explanations for an editor's recommendation will be allowed, in order to avoid the corrosive atmosphere present at RfA and to avoid discussing issues without the involved parties present. If there is significant support for a candidate without an "Archive" comment, the project will send an invitation to the potential candidate with a link to the suggestion, so the candidate can see the support they already have for a run. I imagine that this project would run similar to WP:EotW, where the potential candidate is not notified: this allows the potential candidate to be "surprised" for how much support they already have while hopefully not discouraging editors from running if their potential candidacy is archived. This project should not be seen as a prerequisite to running for RfA, rather as a recruitment tool. Z1720 (talk) 17:33, 10 October 2021 (UTC)
 * Informally, this exists as a small group of editors who actually invite users to start an RfA when they notice good candidates. Organizing this activity in a WikiProject, and hopefully gaining more participants, would indeed be nice. ~ ToBeFree (talk) 19:53, 10 October 2021 (UTC)
 * This project should not replace the informal search that other editors conduct. Instead, I hope this project will show reluctant candidates that there is already support for their run. Z1720 (talk) 02:42, 11 October 2021 (UTC)
 * That would be excellent. I tried to get several nominations in my year before becoming a sysop, but they all fell through. I really like this idea. – John M Wolfson (talk • contribs) 21:32, 10 October 2021 (UTC)
 * Note WikiProject Admin Nominators was created in 2013, and foundered as it didn't figure out a good mode of operation. If there are editors interested in reviving it, that would be great—please go ahead and best of luck! isaacl (talk) 22:52, 10 October 2021 (UTC)
 * This project might last a short time, but if it gets some great quality candidates to run then I think it would be worth it. Z1720 (talk) 01:58, 11 October 2021 (UTC)
 * I agree that finding more candidates is worthwhile. There's nothing holding anyone back—I strongly encourage anyone interested in starting some initiatives to go for it now! isaacl (talk) 20:26, 12 October 2021
 * Long long ago, there was a mentorship process. I participated as a mentor, and I think we got a few good admins out of that process. (which now I cannot find) This seems similar, perhaps better. It doesn't address the causticness of the RfA process itself, but it's not a bad idea. ++Lar: t/c 20:34, 11 October 2021 (UTC)
 * Do you mean Admin coaching? I think that was discontinued about a decade ago. – John M Wolfson (talk • contribs) 22:10, 11 October 2021 (UTC)
 * Yes, that's it. Thanks for finding it. I don't know if any of my coachees are still admins or not. ++Lar: t/c 14:15, 12 October 2021 (UTC)

Idea: Two-phase evaluation/criteria process
Separate the two questions of "What kind of candidate is this person?" and "Should that kind of candidate be made an admin?" into distinct phases.

In the first phase, voters would evaluate the candidate, and attempt to establish an outline of the candidate's characteristics, qualities and qualifications, experience and expertise. The RfA page would be divided into sections, each dealing with a general aspect to evaluate. The page would start with a handful of "conventional" starting sections, and voters would be permitted to add new ones. Within each section, voters would ask questions, discuss the candidate, and try to work toward conclusions, "findings of fact", about the general qualities of the candidate. (Any questions to candidates must be placed into a specific section.) Participants would express their support for or opposition to proposed conclusions. Similar to current RfAs, the decision-making on this part would more closely resemble a vote than normal consensus processes (with some leeway for the closing bureaucrat's judgement). At the end of the first phase, a bureaucrat compiles/collates/synthesizes the conclusions into a profile, several paragraphs in length. At this point, active participation by the candidate in the process ends.

The second phase is for determining whether or not a person with this profile should be made an administrator, determined by !vote with normal bureaucrat closing ranges. Any discussions would be about criteria, not re-arguing the attributes of the candidate. No one who participated in the first phase would be permitted to participate in the second phase.

Potential benefits:
 * No questions or comments without clear aims. Each must be within an aspect-evaluating section.
 * Judgement of a characteristic is less harsh than of the entire editor. If you hear that the community thinks you're good at A, B, and C, excellent and D, but pretty bad at very_important_thing E, that might take the sting out of things a bit. Also, if a single user puts that forward, it'll seem much less like an attack. And the "important" second phase will seem like it's not really about you at all.
 * Separate phases with non-overlapping participants may help lower the temperature, may draw in different kinds of participants.
 * Harder for a single point to become the focus of the RfA. At worst, it's part of a single section within the first phase, and a mark on the summary. Discussion is less focused on potential disqualifications.

Cons:
 * Way more pseudo-bureaucracy. Two phases, votes on every point, arguments and rules and so on would drain a lot of the voters' and candidates' time, and considerably increase bureaucrat workload.
 * Less fine-grained info for those actually making the decision; voters work from a summary prepared by others. Those more-informed from the first phase, meanwhile, are removed. Reductionist to the extreme: things have all sorts of exceptions, and trying to reduce things about a person to a summary is lossy.
 * Even more putting-under-a-microscope. Need to evaluate every major thing about a candidate, not just clearly relevant ones.

Issue(s) addressed: 1, 3, 5, potentially aggravates 2 (increased overall scrutiny, but possibly in a less unpleasant manner). Related issues include rejected issues B and C.

(I'm trying for "outside the box", here. Possibly at the expense of practicality, but I'll leave that judgement to others. Hopefully it inspires insightful discussion regardless.) --Yair rand (talk) 18:08, 10 October 2021 (UTC)


 * I do appreciate the brainstorming, but I think this is more trouble than it's worth. – John M Wolfson (talk • contribs) 21:47, 10 October 2021 (UTC)

I'm having déjà vu with my somewhat similar proposal in 2015. As I stated then, I think focusing on candidate characteristics will help consolidate discussion and de-personalize it, thus reducing acrimony and redundancy. I disagree that every major thing about a candidate needs to be examined; it's still up to the participants to decide on what relevant aspects to examine. I think once a good standard has been established, a lot of the phase 2 discussion is reusable, thus reducing its overhead cost. For better or worse, though, I don't think there is enough community support to make this shift. isaacl (talk) 23:05, 10 October 2021 (UTC)

Idea: Sortition as a means to get candidates
Randomly select a bunch of candidates who meet certain criteria randomly (except for those who opt-out). Assign each of them an advocate based on some select pool of users who volunteer for it. RFA then goes on like normal without or without the candidate present with the advocate playing the role of nominator.
 * Issue(s) addressed: #4.
 * Issues(s) it may address: #1, #2, #5, #8.

Discussion (Sortition)

 * Just throwing it out there. If you want to get more candidates to run, maybe change it from an opt-in system to an opt-out one. Commenters will have to proceed explicitly knowing the candidate did not ask to be nominated for adminship which could make them less hostile. Though, I can't help find the idea rather silly, I'm also weirdly fond of it? &#8211;<span style="font-family:CG Times, times"> MJL &thinsp;‐Talk‐☖ 20:18, 10 October 2021 (UTC)
 * This method could solve the level of scrutiny problem as multiple candidates could be selected at once, and candidates could just ignore the process if they felt like it. Though it technically is still an RFA, it provides an alternative to the current traditional route (which I imagine will still be there). &#8211;<span style="font-family:CG Times, times"> MJL &thinsp;‐Talk‐☖ 20:32, 10 October 2021 (UTC)
 * I absolutely love this. It should be easy to develop some kind-of algorithmic test pulling in certain criteria (i.e. X# of edits, less than X# blocks, % match on XFD !votes, etc.) to generate lists of candidates. Chetsford (talk) 21:24, 10 October 2021 (UTC)
 * Hmm. "Forced exposition to hostility for a week", I'll say as an Advocatus Diaboli. ~ ToBeFree (talk) 21:41, 10 October 2021 (UTC)
 * Yes; only if you really want the bit and are just having hesitancy in getting it jump started. – John M Wolfson (talk • contribs) 21:45, 10 October 2021 (UTC)
 * I'm also up for this; this will give a push to people who really do want to be admins but are prone to cold feet; unless this gets the biggest consensus ever against it, it should be voted on at Phase 2. – John M Wolfson (talk • contribs) 21:43, 10 October 2021 (UTC)
 * This is the underlying idea that Anna Frodesiak had for the Optional RfA candidate poll. She asked people to generate lists of potential candidates through any means they thought reasonable, and then issued invitations to all of them to hold a poll. I'm not sure an request for administrative privileges where an advocate is the primary driving force behind the request is a good idea. If we're going to solicit editors to do something with zero preparation, I think asking if they would start a poll is a better idea. isaacl (talk) 23:15, 10 October 2021 (UTC)
 * I'm of the opinion that that forum is an excellent but underused resource. The idea that a potential candidate could use feedback from many experienced editors is sound; more scrutiny, from people who have no reason to be hostile, should help candidates address concerns before they have to face the entire community. That ORCP isn't doing much suggests, to me, that candidates are just using less public alternatives. Vanamonde (Talk) 19:15, 12 October 2021 (UTC)
 * I think it's a bad idea to discuss the faults of a candidate without their consent. However, I would be in favour of a process of naming candidates, then offering the bit to candidates whom did not receive an objection. In my hypothetical process, any discussion of the candidate's faults would not occur and opposers would not explain their opposition. Z1720 (talk) 01:52, 11 October 2021 (UTC)
 * @Z1720: Ideally, opposes would be less descriptive with their !votes out of respect for the candidate. The onus should really be on the supporters to say why they would like to see this user become an admin. Centering the discussion on a potential admins positive qualities would certainly help a lot to remove the toxicity of RFA.
 * Regardless, it is an opt-out system. If an editor really does not want to be discussed at all (either positively or negatively), then they can already remove their name from consideration. &#8211;<span style="font-family:CG Times, times"> MJL &thinsp;‐Talk‐☖ 15:14, 11 October 2021 (UTC)
 * I have tried, a number of times, to assign numerical values to individuals, to generate a potential "adminship index", which could be used to find potential candidates. One of the better ones (though flawed) was Scottywong's adminship score (I'm not sure if that is still available) - I do wonder if we could automate something, a bot that looks for candidates, drops a note on their page, they can respond with "Interested, not yet, not ever" options. Interested would go into this pool, not yet and the bot could leave you alone for a year, not ever is an opt out. Of course, it all comes down to the fact that adminship isn't numerical - there are multiple routes in (different skillsets looked at), and the values that knock people out (such as communication skills) are non-numerical. <b style="text-shadow:0 -1px #DDD,1px 0 #DDD,0 1px #DDD,-1px 0 #DDD; color:#000;">Worm</b>TT(<b style="color:#060;">talk</b>) 07:47, 12 October 2021 (UTC)
 * Any attempt to assign a numerical value to someone's potential for adminship will inevitably be flawed, because something like "adminship potential" is inherently a very subjective and complex concept. The adminship score tool that I created a long time ago only attempted to assign a score to a user based on the objective, easily measurable aspects of their contributions. Like, how long have they been an editor, what's their edit count, how many AfDs have they participated in, how many RfAs have they voted in, how many times have they been blocked, etc. I don't remember the exact algorithm, and I have no idea if the tool is still available (multiple people took over my tools when toolserver went away, and they are in various states of disrepair and availability). But, in any case, any bot that you program will obviously only be able to assess these kinds of measurable things, and will never be able to understand things like "is this user an asshole" or "has this user pissed a lot of people off, even though they never got blocked for it" or "is this user a serial wikilawyer who tries to use WP policies in misguided ways". It can certainly help you to quickly narrow down a large field of users to a smaller set of people that have a higher likelihood of succeeding at RfA, but it will never be a perfect indicator (or anywhere even close to perfect).
 * If you're hoping to convince someone to create a bot or a tool that performs this function, my advice would be to find some agreement on exactly what numerical/measurable aspects of a user's contributions are important to determine their adminship potential, and assign weights to each aspect. (By the way, you'll never find agreement on this, as everyone has different opinions on it.) In other words, design a full scoring system based on the measurable aspects of someone's contributions. That's the hard part. If you can put that together, then convincing someone to implement a bot or a tool based on those rules should be relatively easy. But, just telling someone to "make me a bot that finds good admin candidates" is a much harder sell. <span style="font:bold 15px 'Bradley Hand','Bradley Hand ITC';color:#044;text-shadow:0 0 4px #033,0 0 10px #077;"> —&#8288;Scotty Wong &#8288;— 16:26, 12 October 2021 (UTC)
 * Actually, I found some discussion around the scoring algorithm that I used in the tool about 9 years ago. If you're interested to do a deep dive, it's all still at User talk:Scottywong/Admin scoring workshop. <span style="font:bold 15px 'Bradley Hand','Bradley Hand ITC';color:#044;text-shadow:0 0 4px #033,0 0 10px #077;"> —&#8288;Scotty Wong &#8288;— 16:38, 12 October 2021 (UTC)
 * Any 'scoring' algorithm that counts numbers of edits is, imho, doomed to fail as easily gamed. Which is the 'better' editor: one who makes 20 edits to an article's grammar, each of 10 characters (whether marked 'minor edit' or not), or one who makes a single edit of 250 characters which improves the content? --AlisonW (talk) 16:49, 12 October 2021 (UTC)
 * Who is more likely to succeed at RfA? An editor with 50 edits, or an editor with 50,000 edits? Edit count plays a role. If you're evaluating a candidate at RfA who you're unfamiliar with, one of the things you'd probably check is how long they've been here and how much they've done. Edit count is one way to check that. You obviously can't make a decision to support a candidate based solely on edit count, but it's a relevant data point. An automated tool would save you the trouble of looking that up yourself. Any statistic can be gamed. No one is saying that if an automated tool finds a user with a high score, then they automatically become admins. There would still be a need for human intervention to inspect the nature of the candidate's edits to ensure that they haven't gamed the system, among other things. The automated tool or bot would simply narrow down the field of millions of editors to a smaller number of editors that are more likely to succeed at RfA. <span style="font:bold 15px 'Bradley Hand','Bradley Hand ITC';color:#044;text-shadow:0 0 4px #033,0 0 10px #077;"> —&#8288;Scotty Wong &#8288;— 20:00, 12 October 2021 (UTC)
 * I wonder if there isn't a machine learning problem here that could make someone's doctoral thesis... IznoPublic (talk) 11:23, 20 October 2021 (UTC)


 * This would absolutely have to be an opt-in process, but with that change it might work. There are plenty of editors who either actively don't want the burdens of the tools, or know any discussion would be hostile and counter-productive; it's not reasonable to ask them all to opt out. User:力 (power~enwiki,  π,  ν ) 16:41, 18 October 2021 (UTC)
 * There is a policy WP:VOLUNTARY which states that "Wikipedia is a volunteer community and does not require Wikipedians to give any more time and effort than they wish. Focus on improving the encyclopedia itself, rather than demanding more from other Wikipedians." The practical implementation of this idea might put undue pressure on some editors who simply prefer to volunteer their time in their way, rather than feeling pressured to do more than they wish having been "identified" by some bizarre AI process. Leaky caldron (talk) 12:26, 20 October 2021 (UTC)

Idea: PROD-style adminship
Any user may nominate another user for adminship by starting a page styled Wikipedia:Proposed adminship/Username and transcluding it to WP:RFA. The nominator(s) may make a statement, and the candidate may answer the three standard questions. Aside from that, there are to be no comments, no questions, and no support votes. If X number of users (10? 20? 30?) object within seven days by writing "Object. ~ " (and nothing else!) on the transcluded page, the process is nullified. (The candidate may run a standard RfA if desired.) Otherwise, the candidate shall be made an admin, with all the rights and privileges of other admins. Candidates who have previously used this process unsuccessfully may not try again, and those who have previously run RfA are ineligible. Extraordinary Writ (talk) 22:55, 10 October 2021 (UTC)
 * Issues addressed: #1, #8.
 * Issues it may address: #2, #4.

Discussion (PROD-style adminship)

 * We've long used the system known as WP:PROD for certain uncontroversial deletions, the idea being that we can dispense with some of our formal processes in cases where no objections are anticipated. This idea adapts that system to the adminship context. Even the least controversial RfAs can be incredibly nerve-racking: I was recently struck by this comment, in which a candidate who recently passed RfA with 98% support noted that she nonetheless considered withdrawing because of how "emotionally draining" the process was for her. My proposal above provides an alternate system for uncontroversial candidates like her (and the majority of recent RfA candidates), allowing them to be approved without the vitriol, corrosiveness, and stress that characterize RfA. If the candidacy turns out to be controversial, that will become apparent in a much less painful way than normal, and the candidate will have some idea of what to expect if they later decide to run a standard RfA. (Note: this was vaguely inspired by this discussion and related proposals, although I replaced several parts of it, including the rather boneheaded idea of allowing a single user to object.) Extraordinary Writ (talk) 22:55, 10 October 2021 (UTC)
 * I would need to marinate on this a bit but I think, given a low-enough objection number (i.e. 10 editors), and assuming we maintained a good method of notification (e.g. watchlist notice), this would be something I'd support. I might like to see some low-threshold objective criteria applied to who may nominate and who may be nominated, though, to limit the potential of floods of dead-on-arrival candidates (perhaps limiting this to extended confirmed editors). Chetsford (talk) 23:27, 10 October 2021 (UTC)
 * I agree with that. Since WP:RFA is extended-confirmed protected, the transclusion requirement effectively imposes that as a minimum. Extraordinary Writ (talk) 23:55, 10 October 2021 (UTC)
 * I'd be okay with this, except that objectors need to be allowed to elaborate on their objections, so that others may be aware of possible problems the objector has found; indeed, it is often the case that an RfA starts out as uncontroversial and doesn't fail until a single oppose brings up previously-unknown issues that others learn about and thereby change their minds. As for the number, assuming a modern-day minimum participation of ~150 !votes for all but the quickly-SNOWED RfAs and assuming 90% is the "controversial" cutoff, I'd say 15 objects would be sufficient to trigger the normal process. – John M Wolfson (talk • contribs) 23:42, 10 October 2021 (UTC)
 * Agree with the above (re comments). Chetsford (talk) 23:52, 10 October 2021 (UTC)
 * The point about elaboration is a fair one. The problem, of course, is that objections trigger responses, and responses trigger replies, and replies trigger questions for the candidate, and soon we're back to the corrosiveness of RfA. Perhaps an option would be to allow threaded discussion only on the talk page (like es-wiki does for their RfAs) or some other designated forum. Extraordinary Writ (talk) 23:55, 10 October 2021 (UTC)
 * That's a good point I didn't think of; allowing comments risks this turning into RfA Lite. I like your idea for limiting discussion to a secondary space like Talk (or maybe just reverting to the original idea of no discussion). Chetsford (talk) 00:43, 11 October 2021 (UTC)
 * Maybe just edit summaries? – John M Wolfson (talk • contribs) 00:51, 11 October 2021 (UTC)
 * What about a word limit for every objection, and diffs must be supplied (50 words max to keep them short?) Or a restriction that responses can only be given by the candidate and crats, and any further follow-up must happen on the talk page? Z1720 (talk) 01:56, 11 October 2021 (UTC)
 * Lots of good ideas here. I read that the Spanish Wikipedia limits comments to only 15 words, with any additional questions, discussion, or elaboration banished to the talk page. I think my original idea of "no questions, no comments, no support votes" is unlikely to gain traction, judging from the comments below, so allowing some form of talk-page discussion will probably be necessary. I'd probably oppose mandating that "diffs must be supplied": just like at PROD, users should be allowed to object for any reason or no reason. Extraordinary Writ (talk) 17:40, 11 October 2021 (UTC)


 * I like this idea of a PROD-style RfA, and I like the criteria that is emerging in discussion here. Just to be clear, am I correct in understanding that no form of self nomination would be allowed? If so, I'd like to suggest that any verifiable form of canvasing others for the purpose of requesting that they nominate or otherwise publish the PROD-style RfA on their behalf should be an automatic disqualifying factor. --John Cline (talk) 09:40, 11 October 2021 (UTC)
 * I agree that self-noms should probably not be permitted. It would probably be difficult to outlaw canvassing formally (since it could quite easily be done through email or some other off-wiki means), but an overly ambitious candidate could quite easily be opposed on that basis alone. Extraordinary Writ (talk) 17:40, 11 October 2021 (UTC)
 * I'm leaning oppose. There would need to be a highly visible list, otherwise you'll end up with people being granted adminship without anyone noticing. Would need talk page notices and a similar "currently open RFA/RFB" table. Anarchyte  ( talk ) 12:20, 11 October 2021 (UTC)
 * I would support treating these the same way we treat standard RfAs: watchlist notices, T:CENT, the same "currently open RFA/RFB" table, etc. This is certainly not intended to become a route to RfA under cover of darkness. Extraordinary Writ (talk) 17:40, 11 October 2021 (UTC)
 * Not substantially different from the current process IMO; you have to give the opposers the ability to explain themselves; you have to give !voters the opportunity to ask questions; and these two things will make the process devolve back into the current RfA system due to things like controversial opposes and questions, and long, toxic discussions over it. I do not see how a PROD-style adminship solves the toxicity problem at RfA.  Java Hurricane  15:40, 11 October 2021 (UTC)
 * I think this could work, with the strict priviso that it isn't for self-nominations - so each admin must have at least some explicit support from someone in the community! <b style="color:#98F">W</b><b style="color:#97E">a</b><b style="color:#86D">g</b><b style="color:#75C">ge</b><b style="color:#83C">r</b><b  style="color:#728">s</b><small  style="color:#080">TALK  16:06, 11 October 2021 (UTC)
 * I'm uncomfortable with this idea, and it's simply because we cannot gauge the level of support (i.e. the numerical value, not the percentage) - I'm concerned this is unlikely to pass community muster as a proposal, and even if it did that we would have individuals who would object to every Prod Adminship on principle, making the process useless. Even if we can get the process off the ground, one controversial decision from one individual who has passed through this method will lead to the same (users who object on principle) - I don't oppose the idea, it's out of the box and not bad, but I'm struggling to see how it will move forward. <b style="text-shadow:0 -1px #DDD,1px 0 #DDD,0 1px #DDD,-1px 0 #DDD; color:#000;">Worm</b>TT(<b style="color:#060;">talk</b>) 07:39, 12 October 2021 (UTC)
 * ...we would have individuals who would object to every Prod Adminship on principle, making the process useless This deserves emphasis. The proposal is not a bad idea but we already have editors that object in all, or nearly all, RfA's on transparently pretextural grounds. Let's say that this goes to a RfC and passes. The opposes would know that all they'd have to do is type 11 characters and every PROD RFA fails and they'sve gotten their way despite consensus against them. There's no downside to them. In theory, this is exactly what's needed. In practice, it would be far too easy to game. Eggishorn  (talk) (contrib) 12:31, 14 October 2021 (UTC)
 * I have yet to see these all-RfA opposers since the beginning of 2020. The vast majority of successful RfAs since then have been near enough to unanimous as to make PROD gaming infeasible. – John M Wolfson (talk • contribs) 13:49, 14 October 2021 (UTC)

PAGE ]]) 03:14, 21 October 2021 (UTC)
 * I just looked back at the process involved when I became an admin (in 2004!) A user subpage (username/rfa) was created by someone (whom I didn't know) with a brief two-line statement of why they'd nominated me. I accepted the nomination and others then added themselves with a sig under support, oppose, or comment. At 25-0 about a week later someone made the relevant status changes. imho such a procedure worked well. --AlisonW (talk) 16:56, 12 October 2021 (UTC)
 * I don't think this would help. Very few RfAs are unanimous and even ones which pass overwhelmingly often have at least a few opposes. If a candidate thinks their RfA is likely to be uncontroversial and attract little opposition then they are less likely to mind the existing RfA process. However if the candidate thinks their RfA might attract significant opposition then they won't be keen on trying this process, not least because it won't matter how much support they get.  Hut 8.5  12:03, 14 October 2021 (UTC)
 * I wonder if this is something that could be done at ORCP instead (or trialed there?). --IznoPublic (talk) 12:23, 20 October 2021 (UTC)
 * It doesn't really fit Anna's original intent of the candidate poll (have a quick score with a short comment, in order to encourage more candidates to run), or the current trend to provide more detailed, constructive feedback. Turning it into "don't say anything if you support" would be a radical departure. isaacl (talk) 15:50, 20 October 2021 (UTC)
 * While I love this idea in theory, I am worried that this would just give free-reign to the types of people that oppose for reasons such as "we don't need more admins" to sink every single PROD nomination, which could discourage otherwise promising candidates from doing a full RfA. --Ahecht ([[User talk:Ahecht|<span style="color:#FFF;background:#04A;display:inline-block;padding:1px;vertical-align:-.3em;font:bold 50%/1 sans-serif;text-align:center">TALK
 * I understand the motivation behind this proposal, but I do not believe this is the right way to go. RfAs should not be able to be torpedoed by a small number of users, if a clear majority of participants support them. As I have said previously, I am opposed to creating multiple types of RfA processes at once, as I am concerned this will lead to different "tiers" of admins, or at least the community perception of such. Trainsandotherthings (talk) 17:14, 24 October 2021 (UTC)

Specific proposal for phase 2 (PROD-style adminship)
Here's what I'm thinking based on the feedback so far:
 * PROD adminships run for 7 full days, much like a "regular" RfA; also like "regular" RfAs, they are listed on everyone's watchlist, on WP:CENT, and placed on the table of active RfXs, perhaps with a note of the "PROD-style" process.
 * No one who has previously run at RfA may be nominated, nor may anyone nominate himself (herself, etc.).
 * In order to curb the WRRFAOs (Wikipedian Resident RfA Opposers), users are limited (across all accounts) to one oppose every month (this does not apply to "regular" RfAs), enforceable by the crats; this number is derived from a putative ~10-20 PROD RfAs a year, a putative ~10-20 WRRFAOs (whom I haven't seen since at least 2019, to be quite frank) in the whole community, dividing that 10 giving a "baseline" of 1-2 opposes and a few trolls every then and now to make sure that "undue" failures don't generally happen.
 * Opposers may only write Object/Oppose, or Strong Object/Oppose and their signature (or just their signature) in the appropriate section. They are to explain their reasoning/rationale in the edit summary, and are required to be concise per the character maximum of that summary; if their reasoning can go into more detail, such detail is appropriate only once the candidate becomes controversial enough to trigger the normal process. "Per" !votes are allowed.
 * Once the candidate has obtained 15 objections, he (she, etc.) may choose to either discontinue the process or go into the "regular" RfA route, with the full 7-day clock being reset upon such decision; as I stated above, the 15 number is derived from every single successful RfA having at least ~150 supports since 2015 and 90%+ being "uncontroversial".

Unless anyone has any comments on the specific numbers, etc., I plan on proposing this during Phase 2, although Extraordinary Writ may do so in my stead. – John M Wolfson (talk • contribs) 23:23, 15 October 2021 (UTC)
 * John M Wolfson If as I suspect, the number of alleged WRRFAO's (and without proof it seems a rather wild and unreasonable estimate to me) I see little practical benefit in this. Also, without the proof, how do you intend identify so-called WRRFAO's who, in any case, could be entirely good faith editors? This desire to compel and / or marginalise editors for their stated opinions is really, REALLY concerning. To reinforce my point, you have created this acronym without presenting one scintilla of evidence to support your narrative. Leaky caldron (talk) 16:57, 20 October 2021 (UTC)
 * It is extremely ironic that you have said this, given that I agree with you in my skepticism of the idea and am only addressing the concerns of Worm et al. who say that there are enough people who "oppose every RfA on principle" to sink this idea; the acronym, I believe, is from WP:RFAADVICE. Also, I think it's very implausible for someone to oppose two consecutive RfAs "in good faith" without someone else sharing concerns, so this isn't the biggest issue IMO. – John M Wolfson (talk • contribs) 18:00, 20 October 2021 (UTC)
 * This proposal probably won't (and IMO shouldn't) pass as-is. Because one editor can know something actually bad about the candidate, and be unable to present the evidence, since no comments are allowed. Editors will be voting entirely based on personal interactions. This process relies on the idea that every bad potential admin has made their unsuitability clear to enough editors such that, for any given PROD-adminship request, there will be 15 editors active in the 7 day period to oppose it. That assumption is probably not true. I'd like to keep an open mind when voting for phase 2 proposals, because I recognise if everyone only votes for their preferred solution then none will obtain consensus, but this idea (as written) is one I would probably oppose. ProcrastinatingReader (talk) 18:27, 20 October 2021 (UTC)
 * Opposers have the ability to explain themselves in the edit summaries, and several RfAs are initially uncontroversial until someone finds an issue and disseminates it causing more to oppose in turn; as such, only one truly-good oppose is enough to sink an RfA that should fail. – John M Wolfson (talk • contribs) 18:33, 20 October 2021 (UTC)
 * To let people explain their oppose in an edit summary, while disallowing it on the discussion page, seems kinda like a loophole. I'd have expected that's not allowed, and if it is I don't know why comments aren't allowed on the page. ProcrastinatingReader (talk) 18:39, 20 October 2021 (UTC)
 * Disallowing comments on the discussion page is not my idea, but I presume it's to lower the intimidation factor for the candidate. I included allowing comments in the edit summary because disallowing them altogether would be bad as you have said. – John M Wolfson (talk • contribs) 19:01, 20 October 2021 (UTC)
 * Fair enough. My other major concern is in labelling out a seemingly undesirable group of users ("WRRFAOs"). I don't think that should make it into formal policy. I'd drop the bullet altogether tbh, as I can't really think of anyone who opposes like that even in current RfA. But even if the provision is kept, that language should be dropped. ProcrastinatingReader (talk) 19:10, 20 October 2021 (UTC)
 * Whoever's idea this is needs to turn up and explain this stuff. Some of this is abusive. The categorisation of editors in a negative manner, with or without evidence, is derogatory verging on a breach of WP:POLEMIC and limiting comments to an edit summary is just perverse. Leaky caldron (talk) 19:39, 20 October 2021 (UTC)
 * I disagree with a process where comments are made in the edit summary but not within the edit. Edit summaries should not be used as a side channel for the main message of the edit. If the information is important enough to include, it should be in the edit itself, to make it easier to find and read. isaacl (talk) 21:01, 20 October 2021 (UTC)
 * I appreciate the lively and thoughtful discussion about this idea of mine. Many of the comments above raise very reasonable points, and I'm not sure they can be adequately resolved in a way that would obtain consensus. As such, I don't plan to propose any iteration of this concept in phase 2, and while John is of course free to do so, I doubt that it would ultimately be a successful endeavor. Extraordinary Writ (talk) 19:58, 20 October 2021 (UTC)


 * With the huge increase in participation since the Dec 2015 reform which allowed extensive advertising of each RfA, the 'pool' of RfA voters has been diluted and has become even more transient and volatile. Two serial opposers and at least one regular poser of 'nonsense' questions who come to mind have since either desisted or even completely retired, knowing that their votes served only for disruption and had no impact on the end result. As explained above, a group of WRRFAO (Wikipedian Resident RfA Opposers) therefore becomes even less identifiable - if indeed it exists at all - than the user traits revealed in the extensive research at RFA Voter Profiles. and the charts and analyses it produced.


 * I cannot find any strong evidence that "undue" failures have actually happened; RfA ususually does its job however plain-sailing or downright nasty the process may have been for some candidates. There have been one or two borderline fails but conversely, there have certainly been very close calls which have passed on a crat chat or on a super-vote by a single closing 'crat. The Dec 2015 reforms did not address the toxicity of RfA, nor did they increase the volition to run. Ironically in fact, it might even seem to a casual onlooker that the opposite has happened. Substituting the current process with another one that might invite obnoxious comments is not a solution, and using edit summaries for a purpose for which they were not intended, even less so. Even the much cited secret polls such as ACE have their playground sections for allowing unpleasant people to vent their spleen.


 * As previously mentioned on this brainstorming page, a successful RfC generally includes some facts and stats in its preamble - significant claims need significant sources. The lack of willing candidates is clearly due to the toxic environment of the process and not really to any other cause.  I do not understand the resistance to doing some data mining for more modern information; RfA are nowadays few and far between but there is a big enough sample size of 160 RfA since Jan 2016 to be able to draw some conclusions. Kudpung กุดผึ้ง (talk) 03:08, 21 October 2021 (UTC)

Idea: Less time between RfA reviews
RfA reviews should take place more often. Bureaucrats are encouraged to organise this type of review every few years.


 * Issues addressed: #1

Discussion: Less time between RfA reviews

 * This process began because of the dwindling number of nominations at RfA, and the last review took place in 2015. During Phase 1, there was clear opposition to the statement that "There is no issue" at RfA. Instead of waiting until there is a problem, the RfA process should go through a regular review every few years. Bureaucrats are encouraged to organise this type of review, with the assistance of interested and experienced editors if they so wish. I think two years is a good time period, but perhaps others have a different suggestion. This process will not prevent editors from proposing changes to the RfA process between reviews. Z1720 (talk) 02:19, 11 October 2021 (UTC)
 * I don't think this directly addresses issue #1. In any case, anyone can organize an RfC discussion such as this one when they feel the time is right (and in the past they were indeed set up by non-admins, non-arbitrators, and non-bureaucrats). It takes social capital to gain agreement on change and thus I don't think it is feasible to set a schedule. isaacl (talk) 03:28, 11 October 2021 (UTC)
 * Concurring with, this is more of a meta discussion than a suggestion on what is attempting to be achieved with this brainstorming. But you're right - a review 2 years or so after the December 2015 reforms were rolled out would not have gone amiss to examine what had worked and what hadn't. There have however been plenty of serious RfA reviews over the years even before the first of the big ones exactly ten years ago.  You only started regularly editing a year ago so you might not be aware of what has been done over the years. This will quickly bring you up to speed, especially if you read the listed articles in The Signpost from 2005 through 2019 which summarise the history quite well. Kudpung กุดผึ้ง (talk) 11:07, 11 October 2021 (UTC)
 * I struggled with which issue to place this under; I felt like this was the best one because I hope that this review will solve some of the corrosive environment problems at RfA, and regular reviews will continue to assess and propose solutions to ensure it doesn't happen again. Last year, I read through some of the Talk:RfA archives, previous RfA reform essays, and the 2015 conclusions last year, and I'm interested in looking at these other documents in WP:RFA reform. My limited impression is that there has been lots of discussion, but the last time any serious change happened at Rfa that required community consensus was after the 2015 review. I don't want to wait until there is a serious problem before people discuss solutions. I also think that this review and previous reviews were successful is because it was organised by well-respected members of Wikipedia: if I set up this review it would probably go nowhere fast due to my lack of experience. This proposal empowers 'crats to organise a review every few years with the help of interested editors. Z1720 (talk) 14:43, 11 October 2021 (UTC)
 * Any editor is empowered to organize a request for comments on the topic, and I disagree that bureaucrats should be mandated to do so on a fixed schedule. There hasn't been a shortage of discussion on the matter in the interim. The right combination of someone willing and able to shepherd discussion plus a receptiveness of the community to engage productively has to arise for an RfC to be helpful. I can agree, though, that once this review process is completed it may be useful to tentatively schedule a followup to evaluate the effect of any changes that were made (or, if none were made, to investigate other ideas). isaacl (talk) 15:29, 11 October 2021 (UTC)
 * We do this for ACE, and actually, if we're looking at setting up some alternative system, especially one that might be regular, it would not harm us to put in a retrospection and improvement step to the cycle. There are quite a few ways we could do this, but an annual RfC on RfA may work, split into incremental and wholesale improvements. Just to highlight ongoing issues. ... Of course, it might also just be a waste of pixels. I'm less keen on 'crats organising these, unless they have a known structure and it's just management and closing of the RfC. <b style="text-shadow:0 -1px #DDD,1px 0 #DDD,0 1px #DDD,-1px 0 #DDD; color:#000;">Worm</b>TT(<b style="color:#060;">talk</b>) 07:25, 12 October 2021 (UTC)
 * I think once every half-decade or so is fine. If it ain't broke (which RfA wasn't prior to the dwindling), don't fix it. – John M Wolfson (talk • contribs) 16:46, 11 October 2021 (UTC)
 * I think a process every year would be a bit much, but every 2 years in, say, September, would work fine for me Nosebagbear (talk) 17:20, 13 October 2021 (UTC)
 * I think codifying a specific maximum amount of time between reviews would be good. Perhaps the language could be along the lines of "RfA review takes place every 5 years, or sooner if community consensus is that RfA review is prudent ahead of schedule." Trainsandotherthings (talk) 17:17, 24 October 2021 (UTC)

Idea: An underused ready-resource
I'd like to discuss an underused resource that is available, and has been effectively used in the past. I hope to discuss ways to improve it, and gain some collaborative assistance to that end. --John Cline (talk) 04:12, 11 October 2021 (UTC)
 * Issue(s) addressed: 4.

Discussion (An underused ready-resource)
PAGE ]]) 03:55, 21 October 2021 (UTC)
 * It involves substituting {{subst:GetMop}} on the user talk page of a prospective admin candidate. The RfA styled message and box links to an essay titled: Administrators without tools. The essay's prose alludes to the type of editor that we thought was an admin already, and were surprised when we found they were not. Together, the template and essay thank the recipient for what they do, and encourages them to commence an RfA of their own. Aside encouraging others to begin using this resource, I'd like to also ask each of you to adopt these pages, and help to improve them. Surely we can take what is good now, and transform it into a much better tool. --John Cline (talk) 04:12, 11 October 2021 (UTC)
 * That's nice . I don't know why I didn't know about it before I retired. I did spend a lot of time searching for possible admin candidates and it reminds me very much of this which I am sure you will be able to relate to. And here's another just two months later. Of course there were still some spoilsports hell bent on causing drama on both of them. Kudpung กุดผึ้ง (talk) 11:32, 11 October 2021 (UTC)
 * I too think this is a great idea. One improvement I might suggest is the creation of an associated category that may help producing admin candidates. What's more, as you say, this is already available (and has been apparently since 2011), so I think what it really needs is more publicity! Mentioning it at WT:RFA would be a good start. <b style="text-shadow:0 -1px #DDD,1px 0 #DDD,0 1px #DDD,-1px 0 #DDD; color:#000;">Worm</b>TT(<b style="color:#060;">talk</b>) 07:19, 12 October 2021 (UTC)
 * Thank you WTT. I've added a link to Category:Wikipedia administrator hopefuls to the essay. The are nearly 1,500 Wikipedians in this category who have expressed a positive interest in becoming an administrator. That certainly counts as an improvement in my opinion. Thanks again.--John Cline (talk) 09:12, 12 October 2021 (UTC)
 * I think that a different category might be a good idea here and applied directly to the template. Perhaps the most obvious - Category:Administrators without tools <b style="text-shadow:0 -1px #DDD,1px 0 #DDD,0 1px #DDD,-1px 0 #DDD; color:#000;">Worm</b>TT(<b style="color:#060;">talk</b>) 10:11, 12 October 2021 (UTC)
 * I'll work on that. Thank you.--John Cline (talk) 18:35, 12 October 2021 (UTC)
 * When we still have advice up in places like User:Ritchie333/RfA, User:Chris_troutman/My_RfA_criteria, Special:Diff/805561497, etc. saying that you should never advertise that you want to be an administrator, I'm not sure how useful Category:Wikipedia administrator hopefuls would be. --Ahecht ([[User talk:Ahecht|<span style="color:#FFF;background:#04A;display:inline-block;padding:1px;vertical-align:-.3em;font:bold 50%/1 sans-serif;text-align:center">TALK
 * In the past, when this template has been used, its effectiveness has been significantly improved when others have endorsed the original message with their own encouragement. In effort to further improve this resource, I have posted a bot request to have a bot notify interested users whenever the template is used so they can consider endorsing its use. The notifications will be sent to users listed on  Administrators without tools/Endorsers. I hope that some of you will sign that page, and appreciate all who do.--John Cline (talk) 03:16, 14 October 2021 (UTC)
 * In a heartbeat, great idea. <b style="text-shadow:0 -1px #DDD,1px 0 #DDD,0 1px #DDD,-1px 0 #DDD; color:#000;">Worm</b>TT(<b style="color:#060;">talk</b>) 06:57, 14 October 2021 (UTC)
 * Can I add myself here?  Java Hurricane  15:19, 14 October 2021 (UTC)
 * You certainly can, and I hope that you will.--John Cline (talk) 16:17, 14 October 2021 (UTC)
 * To update, the discussion inquiring about this has gone well. A bot operator has agreed to take up the tasking and all of the preliminary work is done. It now has a, so it probably won't be long before everything is up and running. It's opt-in only, so you have to sign the list to receive these notifications. I'm doubling down to ask others, again, to sign up for this. Thank you.--John Cline (talk) 05:25, 17 October 2021 (UTC)
 * Another, improvement (I hope) that I'm working on now, involves loading the template with a variety of different messages, taylored for use in different situations. I've already modified the template's coding, and tested that it works. Everything involving the use of GetMop works exactly as it has, but now you can switch to any of the other output messages by adding an extension. I have an example loaded if you wanted to test how it works, but it's still in development because the message isn't quite ready. It's using the |ask extension because it will be for situations where instead of telling a prospect that you think they should run, you To rest it, or use it when it's ready, you would publish {{subst:GetMop|ask}}, and everything else follows the same pattern except with a different template message. Other switchs I'm thinking about include |new, for a newish editor who demonstrates good future potential; |prep, for a good prospect who could do a few things to increase their chance of success; |hard, for someone that would clearly have some difficulty that you would support if they were willing to try; and |wish, for someone who has said they weren't interested, or didn't have time that you wsnted to respectfully tell that you wish things were different. The secondary purpose of this template is to send kind encouragement and thanks for the good work a user is doing and these different situations open more opportunities for that, and they plant seeds for future prospective candidates. There's practically no limit to the amount of switched output that can be accommodated so if anyone has an idea, it can certainly be considered. And once again, anyone can help to get the ball down field. For example: help writing the prose for all of the switched output is currently in high demand. Anyway, that's an idea that's happening now, I hope others feel that it's an improvement, and headed in the right direction. Thank you.--John Cline (talk) 09:51, 15 October 2021 (UTC)

Idea: Two Part RfA - Discussion / Anonymous Vote
Could we split an RfA in two? Have the first X (perhaps 3-5) days as a simple discussion (moderated, to ensure it doesn't get nasty) with no voting allowed. Concerns could be raised and discussed. Questions could be asked. At the end of the period, the candidate is given the option to carry on to the next phase, the discussion phase would be hatted (perhaps even protected) and an anonymous vote phase begins, which would last Y (perhaps 7) days.

Issues addressed: 1, 2, 8

Discussion (Idea: Two Part RfA - Discussion / Anonymous Vote)
As I see it, this could have the following benefits I don't know if there is a simple vote system on meta, it may be that one would need to be created to meet our needs, as securepoll is probably a little excessive. <b style="text-shadow:0 -1px #DDD,1px 0 #DDD,0 1px #DDD,-1px 0 #DDD; color:#000;">Worm</b>TT(<b style="color:#060;">talk</b>) 08:03, 12 October 2021 (UTC)
 * Candidates don't have to watch their RfA beyond the discussion, and are allowed to actively participate in that phase. Reduces the stress of slowly watching your RfA tank, or worrying that it might.
 * Concerns of badgering are gone as you would expect the candidate to discuss in the discussion phase.
 * Keeps the level of scrutiny for those who want it, but does not subject the candidate to the scrutiny in the same manner.
 * I would love to see this, or something like it (have campaigned for this for years). A slightly worse, but technically simpler option would be a discussion followed by open section-based voting with strictly enforced no-comment policy (i.e. "Happy to support" is not acceptable, and neither is "See my comments in the discussion"). —Kusma (talk) 11:53, 12 October 2021 (UTC)
 * Then you can see how others are voting, which defeats point 1 of what Worm wrote. I do like Worm's idea as written, assuming the WMF were willing to code up an extension for it. ProcrastinatingReader (talk) 13:54, 12 October 2021 (UTC)
 * I'd love to see two-phase elections, like what is done at Steward elections; but for some reason I also recollect reading opposition to 2-phase RfAs as being overly long. Can't remember where anymore. I'd wholeheartedly support your plan, that said.  Java Hurricane  14:13, 12 October 2021 (UTC)
 * There's a balance - overly long vs overly short. I seem to recall that some individuals were unhappy with less than seven days, due to editing patterns and whether or not people could edit at a weekend - so I thought the voting should be at least seven days. In addition, with anonymous voting, the length is less important, as part of the problem with "too long" is that you are consistently looking at the RfA to see what has been said on each vote, and re-counting and calculating, and seeing what effect comments have etc. Anon voting takes all that away. It's an axnious wait (certainly, I can tell you that from ACE), but it's not "in your face" stressful. <b style="text-shadow:0 -1px #DDD,1px 0 #DDD,0 1px #DDD,-1px 0 #DDD; color:#000;">Worm</b>TT(<b style="color:#060;">talk</b>) 14:30, 12 October 2021 (UTC)
 * Multiple phases have been objected to previously due to increasing length being required to accommodate those who only participate once a week. I think though that this change can complement the proposal to have scheduled RfA dates (for example, quarterly). If a greater number of parallel requests indeed results in less intense scrutiny for each candidate, then I feel extending the overall period for the request should be manageable. isaacl (talk) 15:03, 12 October 2021 (UTC)
 * a version of SecurePoll would likely still be needed, perhaps without the encryption system overhead. The challenge of secret ballot is that a scrutineering process is likely needed to enforce voter eligibility requirements (such as each 'person' may only vote once, regardless of how many accounts they have access to). —  xaosflux  Talk 14:38, 12 October 2021 (UTC)
 * But perhaps it could be part of a tranched, scheduled, votes-for-adminship parallel process? (Which who knows could become the primary process) - anyone that wants to be an admin signs up on-wiki by some deadline, gets questions by some deadline, confirms if they want to move to the vote by a deadline, then we run a BULK vote ACE style with (Support / Oppose / SKIP THIS PERSON "Neutral") options - and we can spit out an entire list of those who win by a strict percentage. Maybe quarterly (?).  The benefit of bulk is that the same scrutineering can be done for everyone at once.  If we did go to something like that, maybe we only keep RfA for a new "temporary adminship" process for someone that needs access quicker or for a specific purpose, and limit those to like 4 month terms unless approved in the "new vote" system.  Just brainstorming here!! —  xaosflux  Talk 15:36, 12 October 2021 (UTC)
 * I'm definitely getting the idea a combination of brainstormed ideas might be the final solution! <b style="text-shadow:0 -1px #DDD,1px 0 #DDD,0 1px #DDD,-1px 0 #DDD; color:#000;">Worm</b>TT(<b style="color:#060;">talk</b>) 15:39, 12 October 2021 (UTC)
 * We could also combine this with my suggestion to always +sysop the top 5/10/20/? candidates each round if they receive more than the minimum percentage required for ArbCom election, to ensure a minimum promotion rate. —Kusma (talk) 15:46, 12 October 2021 (UTC)
 * Instead of a fixed number of top candidates in the tranche, can I suggest that it would be some percentage of the number of candidates included, as long as they reach some minimum percentage of approval? We wouldn't want to set it a 10 candidates, have 14 apply, and then grant the bit to some-one that got 45% approval because they were tenth. Eggishorn  (talk) (contrib) 15:51, 12 October 2021 (UTC)
 * I wouldn't see these people as competing with eachother (as it is fine for everyone to "win" the election), everyone passing the minimum threshold (whatever it should be) would pass - don't think I'd like the idea of continuing to lower the threshold just because some specific tranche had some candidates with lower support %'s. — xaosflux  Talk 16:01, 12 October 2021 (UTC)
 * Well, we need admins. Just like we need arbs. For arbcom, the threat of a tranche of terrible candidates being appointed helps to make people stand for election. I think we may need something that forces the community to approve more admins. —Kusma (talk) 16:08, 12 October 2021 (UTC)
 * I don't think there would be the same sense of urgency. There are readily available processes to review poor decisions made by administrators, where arbitrators are (in practice) the last resort to interpret community views. isaacl (talk) 20:08, 12 October 2021 (UTC)
 * Good thought on having a one-phase, ad hoc request process for fixed terms, and a (say) quarterly two-phase process for unlimited terms. This would enable editors to sign up to fill a temporary need without committing for the long-term, thus perhaps tapping into the pool of editors who are now drifting away after a couple of years. On a side note, How about using the term "cohort" instead of "tranche"? These aren't really divisions of the whole admin pool. but new waves of admins being added regularly. isaacl (talk) 20:17, 12 October 2021 (UTC)
 * I like cohort in this aspect better. — xaosflux  Talk 20:51, 12 October 2021 (UTC)
 * Cohort does seem better. Implementing the Meta limited adminship concept also is excellent; I've always liked the idea.  Java Hurricane  01:37, 13 October 2021 (UTC)
 * I don't want to seem overly critical, but I can't help but wonder whether this will have the intended effect. The opposition to any RFA, whether justified or otherwise, tends to be far more vocal than the support. Allowing the opposition to analyze a candidate's record, without also giving them a mounting tally of support !votes to draw confidence from, seems a little counter-productive to me. Vanamonde (Talk) 18:51, 12 October 2021 (UTC)
 * Addendum: I do think there's some benefit to separating the questions and general discussion section from the !votes. I also think more direct moderation of these venues is a good thing (and in the last couple of years we have seen the effects of that). I'm not convinced they need to be separated in time from the !voting, but perhaps even separate pages (like with the ARBCOM election) would help? Vanamonde (Talk) 19:05, 12 October 2021 (UTC)
 * Perhaps - but the idea is that without a marked "opposition" (and I believe we should be pushing for active moderation of support and oppose comments in this) it becomes more of a discussion. Each individual is free to make up their minds - and the visibility of sides should be less obvious. Don't forget, you will have nominators, and answers to questions, so there will be positives there. Equally, the "opposition" could well find themselves less vociferous if they don't have to argue against the weight of 100+ voters, but instead are just raising potential concerns. <b style="text-shadow:0 -1px #DDD,1px 0 #DDD,0 1px #DDD,-1px 0 #DDD; color:#000;">Worm</b>TT(<b style="color:#060;">talk</b>) 13:03, 13 October 2021 (UTC)
 * I think that's reasonable, and there is perhaps a set of candidates for whom this may be beneficial. On reflection I agree that for good-faith opposition, this may even be a superior model, because folks can discuss their concerns in detail, potentially with the candidate. However, when editors refer to a hostile environment at RFA, I think a good many are referring to opposition that isn't interested in discussion, and occasionally opposition that isn't acting in good faith. If your proposal had been the only system available in 2016, I would not have run; and I suspect most candidates who have worked on contentious topics would not run either. My RFA was tolerable because for every !voter raising "concerns", there were four expressing support, and in many cases stating explicitly that (most of) the opposition had no basis for their comments. This problem wasn't ameliorated by making it a discussion; see Tony's section and mine at CUOS2018, for instance. Vanamonde (Talk) 15:20, 13 October 2021 (UTC)
 * I support this idea. I'm not certain I'm 100% keen on a moderated discussion per se, as I think our normal WP:CIVIL expectations are all the moderation required, but I very much like the idea of separating !voting (or even making it true voting) from discussion. Chetsford (talk) 00:49, 13 October 2021 (UTC)
 * I still feel uneasy about drawing the RfA out longer than it already is, even if objectively it's only by a little bit. I prefer RfAs to be "one-and-done" each, without the agony of two different phases. – John M Wolfson (talk • contribs) 00:50, 13 October 2021 (UTC)
 * It's a little paradoxical, but this method is equally longer and shorter. It takes longer from the start to receiving the bit, but the attention that must be spent on it is less, as it only remains for phase 1. <b style="text-shadow:0 -1px #DDD,1px 0 #DDD,0 1px #DDD,-1px 0 #DDD; color:#000;">Worm</b>TT(<b style="color:#060;">talk</b>) 12:47, 13 October 2021 (UTC)
 * I'm open to this idea, but I have to wonder if it will get support past the brainstorming phase. I guess that could be said about a lot of these ideas, but I'm especially nervous about any proposal that seeks to change how RFA is currently structured. My limited experience tells me there will be resistance to anything beyond an alternative process. &#8211;<span style="font-family:CG Times, times"> MJL &thinsp;‐Talk‐☖ 06:02, 13 October 2021 (UTC)
 * There's nothing saying this could not be an alternative process, or at least an alternative route through the same process. An individual could chose Route 1 or Route 2. <b style="text-shadow:0 -1px #DDD,1px 0 #DDD,0 1px #DDD,-1px 0 #DDD; color:#000;">Worm</b>TT(<b style="color:#060;">talk</b>) 12:48, 13 October 2021 (UTC)
 * The only issue I have with providing options is if, over time and in practice, one option is more stigmatised over the other. e.g. discussing is generally considered a good thing, but it's become a norm that replying to comments in your own RfA is a bad thing and itself could invite more opposes. ProcrastinatingReader (talk) 15:46, 13 October 2021 (UTC)
 * It's OK if over time one option becomes preferred; we can then phase out the less preferred option. It may be easier to introduce a new process in parallel. isaacl (talk) 19:56, 13 October 2021 (UTC)
 * My limited experience tells me there will be resistance to anything. —Kusma (talk) 13:40, 13 October 2021 (UTC)
 * I'm also open to this idea, and would suggest it be included as an option in phase 2. Dreamy <i style="color:#d00">Jazz</i> talk to me &#124; my contributions 15:06, 19 October 2021 (UTC)
 * I've not thought too deeply about it but so far I like the idea. My only concern is that an open discussion page may lead to potentially nonconstructive back-and-forth between potential opposers and the candidate, provided the candidate can respond (contrary to our current de facto standard of discouraging comments from the candidates on oppose votes, but I presume a discussion phase would change that). Giraffer (talk·contribs) 22:48, 20 October 2021 (UTC)
 * This has merit, in fact IIRC something similar was discussed years ago. Discussion and Q&A before !votes might help to reduce one persistently annoying aspect of the current system where, as soon as someone's name turns up, there are upwards of 40 immediate !votes supporting the candidate without a question asked or seemingly any research done. Leaky caldron (talk) 07:31, 21 October 2021 (UTC)

Idea: Limited adminship
Allow editors to ask for  technical permissions for defined tasks only. Similar, in concept, to meta:Meta:Limited admin.


 * Issues addressed: 2, 3, 7

Discussion (Idea: Limited adminship)

 * As above: I do think unbundling via social restrictions (rather than technical) should be considered. When you vote at RfA, your only option is to vote someone in to be a full admin and use the tools in entirety, which can cause excess concerns. The option to give +sysop and only allow the usage of tools for specific purposes (whichever are requested) offers far more options for editors who may be unsuitable for full adminship but still have a valid use for some of the tools, and there are no concerns with them exercising that part. I think a significant blocker at RfA tends to be dealing with conduct issues, particularly those involving blocking for non-vandalism reasons, so being able to abstract that away (for those who don't want to do that) might help. There are lots of less contentious admin tasks people can (and are trusted to) do. ProcrastinatingReader (talk) 15:47, 13 October 2021 (UTC)
 * I'm skeptical of this idea; as shown in the above discussion, all that's left in the mop exclusively are the "core three", broadly construed. And I don't see a scenario on enwiki where I could trust someone with the tools but only some of the time. – John M Wolfson (talk • contribs) 16:29, 13 October 2021 (UTC) Alright, I guess it could work.  – John M Wolfson (talk • contribs) 18:59, 13 October 2021 (UTC)
 * @John M Wolfson: The way I imagine this would work is that if you are.. let's say, and you got a backlog at WP:CCI (because you always do). You have a few folks that help you out, but only a handful are admins. Instead of putting a volunteer up for limited adminship for the purposes of helping out at CCI only until X case gets cleared. That's where I imagine limited adminship would come into play. &#8211;<span style="font-family:CG Times, times"> MJL &thinsp;‐Talk‐☖ 17:53, 13 October 2021 (UTC)
 * That one sounds a bit broad, since what does helping out there even mean (so others can tell if you are within your limits easily). I'd envision it as more of a User:X is coordinating a program with something and will make frequent updates to the the MediaWiki:Spam-blacklist for the next 3 months; or User:X will be coordinating a large campaign of events and will be constantly updating Geonotice/list.json for the next 6 months. —  xaosflux  Talk 18:04, 13 October 2021 (UTC)
 * The idea was to allow requesting permissions for a specific area or task rather than an entire toolkit to use for any purpose. There's naturally less concern about whether an editor has the judgement necessary to handle complex AE issues if all they want to do is edit sysop-protected modules or update DYK queues. Each of these requires rather different character traits and skills, and it's feasible the community might trust someone to do one of these but not another (even with voluntary commitments to only work in certain areas). ProcrastinatingReader (talk) 10:41, 15 October 2021 (UTC)
 * A metawiki example is Requests for limited adminship/GeneralNotability then Requests for adminship/GeneralNotability. Since the latter was 76% (the cut-off is 75%), and the former 100%, potentially a full request in the first instance might've failed. A limited admin option could safely result in more admins than would pass the full adminship process. ProcrastinatingReader (talk) 10:48, 15 October 2021 (UTC)
 * If someone wants to edit a few protected pages, besides interface pages, then dropping their protection to template-protected and granting the editor TE rights is already a viable option. (I say this as a TE.) I can’t think of any current technical means how a non-admin could be allowed to edit a couple of interface pages only without the assistance of an admin-bot, but hopefully that need is rarer. User:GKFXtalk 08:37, 17 October 2021 (UTC)
 * We kind of have had admins promising to do only specific things in their RfAs. Requests for adminship/lustiger seth is perhaps the most extreme example. Currently this is technically voluntary; if you want to formalise it, we'll need an enforcement mechanism for admins breaking their limitations. —Kusma (talk) 16:43, 14 October 2021 (UTC)
 * An enforcement mechanism is exactly what Admin-ability to block an admin from using their tools is all about. --John Cline (talk) 17:49, 14 October 2021 (UTC)
 * That seems like a temp desysop, better left to crats. But the difficult bit is to find consensus for a process for these temp desysops. —Kusma (talk) 18:41, 14 October 2021 (UTC)
 * I think we could just leave desysopping with ArbCom and have the policy say something like "using tools for other purposes will result in a summary desysop", and I imagine ArbCom could handle rare incidents by motion. But I don't think such a process would ever really come into play. For comparison, I don't think violations happen on meta, and non-admins with EFM have a technical means to block/protect but obviously don't use it as such either. I think scope violations are unlikely. ProcrastinatingReader (talk) 10:41, 15 October 2021 (UTC)


 * Unless I've missed something, this suggestion sounds like unbundling under another name. There seems to be (without any RfC on the matter) a general consensus that adminship has already been unbundled as much as it can and that anyone asking for any of the tools should be sufficiently  mature, experienced,  and trustworthy to be in possession them all - whether they use them or not.  Kudpung กุดผึ้ง (talk) 10:48, 15 October 2021 (UTC)
 * I think this could work. It differs from unbundling in that:
 * All of the administrator conduct policies would apply to the user (thus making this less of a grab-and-go type scenario like rollback or PCR).
 * Candidates are evaluated as administrators in the areas they wish to work in, not just unilaterally denied or approved for a permission by one administrator.
 * The candidate is still technically an administrator, and giving them access to the tools they're supposed to use also means trusting them not to use tools they aren't permitted to.
 * Brainstorming further:
 * We've had similar "act only within your remit" perms before – we had read-only EFM before we had EFH.
 * It's been tested and it works on a big project (Meta).
 * It makes applying for (full) adminship less stressful, because you already have experience with the tools and maintain a higher level of trust going into the RfA.
 * It allows for people with a limited skill set to be able to work efficiently in their areas even if they may have issues elsewhere - a limited admin candidate intent on working with technical moves won't fail based on the merits (or lack thereof) of their CSD tagging. Giraffer (talk·contribs) 22:26, 20 October 2021 (UTC)

Buy administrators' coffee
It's usually the last thing corporations want to do when they have an employee or volunteer shortage, but when push comes to shove, they reluctantly increase their wages – or reimburse their volunteers' expenses. Give any administrator in good standing an annual, quarterly, or monthly "coffee stipend" simply for the asking. The total amount paid will keep under the limits that trigger mandatory reporting to taxing authorities. The community will apply for a Wikimedia Foundation grant to fund this. – wbm1058 (talk) 12:26, 15 October 2021 (UTC)
 * Issue(s) addressed: #4

Discussion (Buy administrators' coffee)

 * Obviously an early, or late, April Fool candidate. Leaky caldron (talk) 12:39, 15 October 2021 (UTC)
 * I really don't want to see money linked to a Wikipedia tool - so, as written, nope, not a chance. However, it would, without a doubt increase adminship requests. I'm tempted to suggest that if we do look for funding something, how about a genuine "I'm a wikipedia admin and all I got was this crappy t-shirt" t-shirt or other swag? <b style="text-shadow:0 -1px #DDD,1px 0 #DDD,0 1px #DDD,-1px 0 #DDD; color:#000;">Worm</b>TT(<b style="color:#060;">talk</b>) 13:01, 15 October 2021 (UTC)
 * A t-shirt would be nice.. &#8211;<span style="font-family:CG Times, times"> MJL &thinsp;‐Talk‐☖ 06:21, 16 October 2021 (UTC)
 * Oh God no maybe if we accepted advertising this would work, but as it stands this would compromise the "purity" of the Wikimedia mission and the volunteer nature of the job (which, as I've said earlier with the boogeyman of "bad-faith desysops", is a far cry from frontline nurses or combat veterans and requires no compensation), and would attract the wrong people. – John M Wolfson (talk • contribs) 14:04, 15 October 2021 (UTC)
 * T-shirt plz. And a Wikipedia branded mop? No regular coffee money (volunteer position and all). —Kusma (talk) 14:17, 15 October 2021 (UTC)
 * This would definitely attract more candidates, but not the type of people we want. Meta already has Merchandise Giveaways, but asides from that, we should not be giving real-world rewards to editors or admins. Jackattack1597 (talk) 21:55, 15 October 2021 (UTC)
 * Would send entirely the wrong message about adminship.  Hut 8.5  09:38, 16 October 2021 (UTC)
 * Nope nope nope. Having certain admin tasks be done by paid staff is an idea that may have its time (remember how some former ARBCOM tasks are now done by WMF paid staff), but this isn't that time.  And "so little it doesn't generate tax requirements" isn't going to motivate anyone we want other than poor college students -- and we would be better off motivating them through an improved WikiEd program. User:力 (power~enwiki,  π,  ν ) 16:37, 18 October 2021 (UTC)
 * Joining the list of those fundamentally opposed to this idea. Trainsandotherthings (talk) 20:20, 20 October 2021 (UTC)
 * Opposed. I prefer tea, thank you. Risker (talk) 16:15, 21 October 2021 (UTC)
 * Absolutely not. Naleksuh (talk) 22:28, 22 October 2021 (UTC)
 * I'll make my own damn coffee, thank you very much. Wikipedia is supposed to be a volunteer project. I don't get paid for it, and I do not want to get paid for it. Once you introduce money, bad things inevitably happen. Let's keep that box closed (well, as closed as we can anyway), preferably with nails, iron bars, and some very strong epoxy. Seraphimblade Talk to me 09:48, 24 October 2021 (UTC)

Bundled options for scheduled RfAs / two-part RfAs
I think there are some synergies between the concepts of scheduled RfAs and two-part RfAs such that it may be useful to propose different bundles of these options and ask editors to support all of those they feel is a net positive over the status quo. Here are some of the various possible combinations (for argument's sake, I'll pick quarterly for the scheduled RfAs). For simplicity, I'll assume that introducing a parallel two-phase process or a parallel scheduled RfA will be more likely to gain consensus support, so all of these options offer a choice of procedures to admin candidates.


 * 1. ad hoc single-phase + scheduled single-phase RfA options:
 * 1-1. ad hoc single-phase RfA for unlimited term + quarterly single-phase RfA for unlimited term
 * 1-2. ad hoc single-phase RfA for fixed term + quarterly single-phase RfA for unlimited term
 * 2. ad hoc single-phase + scheduled two-phase RfA options:
 * 2-1. ad hoc single-phase RfA for unlimited term + quarterly two-phase RfA for unlimited term
 * 2-2. ad hoc single-phase RfA for fixed term + quarterly two-phase RfA for unlimited term

Personally I think someone supporting 2-1 would be likely to support one or more of 1-1, 1-2, and 2-2. Thus I suggest at most proposing 1-1, 1-2, and 2-2. I feel it may be possible to drop 1-1, as I believe there is a good argument with scheduled RfAs to treat ad hoc RfAs as interim grants of admin privileges.

In summary: I think by bundling some options together, it may be easier to reach consensus support. I don't think we should present all the possible bundles, and so we should try to avoid proposing ones whose support will likely get picked up by other choices. What does everyone think about what proposals should be put forth? isaacl (talk) 22:21, 15 October 2021 (UTC)
 * , I agree with the idea but I think the suggested options bundle too many things together:splitting RfA discussion, cohorts, and term limits. Term limits especially are a fundamental alteration while the other two suggested changes are not. In RfC's I have been involved with, there is a distinct trend for more options to result in less consensus, as well. I hope that helps. Eggishorn  (talk) (contrib) 22:12, 16 October 2021 (UTC)
 * Yes, that's the idea behind reducing the options to a smaller number: just have one choice of three new options, rather than having people make separate binary choices that may be contingent on each other's outcome (for example, someone might only support two-phase RfAs if there is also consensus support for scheduled RfAs). But sure, taking term limits out will simplify matters further. Thus the options could be as follows:
 * ad hoc single-phase (status quo)
 * ad hoc two-phase RfA
 * ad hoc single-phase RfA + quarterly two-phase RfA
 * Any suggestions on reducing the options further are welcome. isaacl (talk) 00:48, 17 October 2021 (UTC)

Draft proposal: Un-unbundling, or limited requests for adminship as an alternative path to granting of high-trust user groups

 * General outline
 * The page mover or template editor user groups will no longer be granted by administrator discretion.
 * As an alternative to existing procedures, editors seeking high-trust user groups may make a Limited Request for Adminship. High trust user groups are:
 * Page mover
 * Template editor
 * Edit filter manager
 * Edit filter helper
 * (other suggestions?)
 * The format of a limited RfA will be identical to a full RfA with the following exceptions:
 * Two new standard questions: (a) What user group is being requested and (b) for how long, including indefinitely
 * Editors may !vote in one of three sections:
 * Support limited request
 * Support full adminship
 * Oppose request
 * The procedures for a limited RfA will be similar to those of a full RfA:
 * The request will remain open for 7 days
 * The request will be advertised by a watch list notice
 * Requests may be closed by a bureaucrat
 * There is no numerical threshold for consensus to grant non-sysop user groups. After considering the opposition, a bureaucrat or administrator may grant those user groups if they find consensus supports it. In unambiguous cases, any administrator may grant page mover or template editor following a successful request.
 * If support full adminship !votes comprise over 75% of all !votes, a bureaucrat may grant the sysop group if there is consensus
 * In this scheme, support for the limited request is considered opposition to granting the full sysop bit.
 * Support for full sysop grant is considered support for the limited request.
 * Opposition to the limited request is sufficient to oppose the full request
 * In determining consensus for a full sysop grant, bureaucrats should consider the degree of opposition
 * If 75% support full adminship but 25% oppose even granting page mover, there is insufficient trust to grant +sysop without a full RfA
 * Conversely, if 75% support full adminship and 25% support granting template editor only, there is likely sufficient trust to grant +sysop based on the discussion
 * In ambiguous cases, bureaucrats should prefer to not grant sysop and instead defer to a full RfA
 * Crat chats to evaluate ambiguous cases are allowed but discouraged


 * Why this?
 * Page movers and template editors are two of the most powerful user groups granted by admin discretion
 * Both groups allow editors to modify edit notices and create pages otherwise restricted by the title blacklist, otherwise restricted to sysops
 * Page movers are granted limited ability to delete pages in certain cases, mostly single-edit redirects, otherwise restricted to sysops
 * Template editors are given the ability to edit through high-level protection and may change page content models, otherwise restricted to sysops
 * Centralizing and advertising requests for these permissions highlights potential candidates to nominators and the community (see 4)
 * More time to review the candidate reduces the likelihood that a bombshell drops at a later RfA (see 1, 2 and issue T)
 * Provides lightweight editing review focused on clearly defined criteria that provides feedback similar to ORCP (see 2, 3 and issue N)
 * Lowers the stakes of sysop discussions (see 6)
 * Request is not "all or nothing", promising but unready candidates can still get useful tools on top of helpful feedback (see 1 and 2)
 * Potential for drafting without involuntary review (see 8)
 * The candidate asks for feedback knowing we might thrust adminship on them
 * We can thrust adminship on people we think should be admins
 * Low overhead: it largely relies on processes and tools we already have
 * Extensible: if it works well we can consider creating new groups such as main page editor or copyvio deleter which go through the same process

Discussion (un-unbundling)

 * It's perhaps a crazy idea, but I think it touches on a lot of the ideas people have had while still relying on the structures we have in place. I posted the roughest possible draft, and I encourage everyone to edit this proposal as a way of building consensus on the process and perceived merits. — Wug·a·po·des​ 23:18, 15 October 2021 (UTC)
 * Anyway, as for ideas I had but would like feedback on: I'm open to changing the threshold for +sysop but personally think 75% strikes a good balance; I considered making the oppose section admin only to have some kind of PERM/AE consensus-of-admins type deal to prevent bad faith opposition to a request for page mover but if it's not needed at RfA I don't expect it to be a problem here; I considered adding the edit filter user groups but they're not really at admin discretion and I think the EFN is actually a better place for discussions but maybe they'd fit well here. — Wug·a·po·des​ 23:34, 15 October 2021 (UTC)
 * We're going to give people permissions they didn't ask for?—<b style="font-family: Verdana; color: Maroon;">S Marshall</b> T/C 09:05, 16 October 2021 (UTC)
 * We're having this discussion because RfA isn't working well, using RfA to grant more user rights sounds like the last thing we should do. This could easily lead to fewer people getting these user rights because they don't want to go through the process. These user rights are sensitive but there isn't any evidence presented that they are being granted inappropriately.  Hut 8.5  09:46, 16 October 2021 (UTC)
 * I think I see kinda where you're coming from here, and I like the idea to the extent that it might get us more admins. But it might also get us less page movers and template editors. Around the time I requested TE (like ~2 months editing?) I remember submitting template-protected edit requests was getting a bit frustrating. An admin at PERM was willing to grant TE, but I don't know whether a WP:RFA discussion (even if 'limited' form) would have. Equally importantly, I don't know whether I'd have wanted to open such a discussion. So basically I have two categories of concern: (1) the level of unease a requesting editor would have (would it give the impression of RfA now, where few try and the pass rate is high, or more like PERM which is the opposite?) and (2) the level of scrutiny from editors (how generous would the community be in granting such requests?) ProcrastinatingReader (talk) 16:00, 16 October 2021 (UTC)
 * Please don't break these mostly-working-other-things; for the most part WP:PERM is rather low drama (with probably the most being new editors arguing they should have autopatrol). Generally if we deny someone with a good faith request at the more advanced types (PERM/T, PERM/PM, PERM/FM, PERM/MMS) it is with guidance on what to do next and an invitation to reapply after doing it (which is usually along the get-more-expierence-in-x category). Recently, when someone is borderline the trend has been to grant a limited trial (always in time, sometimes in scope during the time) and ask them to come back towards the end of the expiration. I think because the scope is much broader, unsuccessful RfA's tend to leave candidates with more of a "nope, this isn't for you" than a "here's what to work on next" result - and I would hate for that to end up getting pushed to someone that just wanted to help out with something like moving files. —  xaosflux  Talk 17:45, 16 October 2021 (UTC)
 * Agreed. I can't understand why making more people go through RfA when the consensus that RfA is "broken" and they don't actually want to request adminship fixes RfA. I've advocated above that increasing numbers of RfA's might help, but this doesn't seem like the way to do it. Eggishorn  (talk) (contrib) 19:44, 16 October 2021 (UTC)


 * Per some above comments, I've revised the draft to propose a parallel process rather than a replacement for the existing PERM process. Since it's no longer a replacement for processes, I have also included EFM and EFH since I could imagine the people interested in those user groups might be interested in trying out this alternate process as well. I've also modified the closer instructions to allow an administrator to grant rights that are within their discretion to grant. I think making it an optional path to these permissions addresses concerns around visibility and imposition. As an optional process, it is a path that would ideally be used by editors who (1) can use one of the listed user groups, (2) are interested in the other tools bundled with the sysop toolset, but (3) who are not yet confident enough for a full RfA. So editors who don't have any interest in the sysop tools or who don't want a highly visible request won't have it imposed upon them.To say more about the wider goal: I hope the proposal can close the wide gap between making a request at PERM and a request at RfA. It's not a wholesale replacement for the RfA process, but an intermediate step meant to provide a social function we currently lack. In my mind there are two use cases (1) newer editors who are competent and promising but not yet widely known, and (2) veteran editors who are widely trusted but wary of running an RfA.In the first case, an LRfA serves as an event similar to a beautillion or debut where the candidate is introduced to the community in a formal and structured way. The possibility of gaining sysop is there if the candidate is spectacular, but the point is networking. The community gets to learn about new and promising admin candidates, and the candidate gets useful feedback for a future RfA alongside some user group they wanted. In the second case, the goal is to demonstrate to the veteran editor that they do have community support similar to a political draft. This would be especially useful for the edit filter groups and some of the proposed user groups like main page editor where the primary use case is highly trusted editors who for some reason don't run an RfA. Ostensibly they would request the user group they want, and the community would be able to demonstrate their support for a future RfA run.Now, the usefulness of this requires nudging participants to provide constructive feedback and view their participation in requests for non-sysop permissions as valuable, but I don't see those as major problems. Yes, RfA is imperfect, but the reasons are specifically tied to the structure and permission being discussed. By changing the permission under discussion and reframing the discussion around that we have the ability to nudge participants into behaving differently and providing different kinds of feedback. It's not simply a copy and paste of RfA, so I don't find arguments that "RfA is broken so this will be broken too" very persuasive. Instead, it would be helpful to get feedback on what particular aspects would or would not bring about the kinds of feedback and behavior we want. Making it optional, for example, was very helpful as it helped refine the process to the groups it would be most useful for by making it opt-in. — Wug·a·po·des​ 01:09, 18 October 2021 (UTC)
 * Can we talk about the possibility of unbundling the ability to view deleted content? As somebody who spends most of my time on the IRC helpdesk, the ability to view deleted content would be the most useful admin power. It would allow me to see if some content being created is a recreation of something that was deleted. It would allow me to see a broader pattern of abuse where an editor's other contributions were no longer in existence. The ability to view deleted content is not without legal implications, so almost certainly could not be granted trivially. It is a non-destructive power, and it's hard to argue that it could be abused as easily as the other admin powers (e.g. deleting, blocking, protecting). --Salimfadhley (talk) 11:09, 23 October 2021 (UTC)
 * You say yourself that it could not be granted trivially, which I think the WMF would interpret to require an RfA or RfA-style process. – John M Wolfson (talk • contribs) 11:51, 23 October 2021 (UTC)
 * What problem is this solving? Are these permissions routinely being given out inappropriately, requiring using up more volunteer time to more closely scrutinize who they are granted to? I'm not aware of that being the case, but am open to being convinced otherwise. Absent that, though, this seems rather a solution in search of a problem. Seraphimblade Talk to me 20:54, 23 October 2021 (UTC)

Draft proposal: Optional "generic question" for last 24 hours of RfA
Perhaps there should be a "generic question" in the form:
 * n. Is there a question you wished was asked during the RfA? If so, answer it.

This would only be answered sometime during the last 24 hours of the RfA.

Issue(s) addressed: 2, to a lesser extent 1. – John M Wolfson (talk • contribs) 15:42, 16 October 2021 (UTC)

Discussion (Optional "generic question" for last 24 hours of RfA)
There is a norm that candidates not directly interact with the discussion of their RfAs. This is not particularly a bad thing, and does create a purdah that solemnifies the process, but it can lead to issues where a candidate wishes to counter a point arising in the RfA that none of the participants have addressed. This would be limited to the last 24 hours of the processes for a couple of reasons; pre-RfA issues should already be addressed in the nom statements and the answers to the first 3 questions, a "limit" to the last 24 hours gives participants enough time to possibly ask the question desired, and any RfA that sinks between its transclusion and the last 24 hours is unlikely to be salvaged by such a question/answer in any event.

This isn't my idea, but was brought up during phase 1. It also works well as a "gradual" change that might be more likely to be adopted during phase 2 in contrast to the completely different processes proposed here. The only problem I have with this proposal is that it might over time not be truly optional, as a norm might develop that a candidate come up with a question and answer it. Although my RfA was probably not typical, I found nothing wrong with it and couldn't think of an issue that I would want to address. In fact, if I tried and came up with a bad one, it would likely affect my RfA adversely and cause me to garner opposition. – John M Wolfson (talk • contribs) 15:42, 16 October 2021 (UTC)
 * Personally, I don't see this as a pressing concern. I don't think constructive engagement is viewed negatively. I believe argumentative behaviour that shows a lack of receptiveness to feedback is what may concern editors. This would remain the case if the comments are made in direct response to a comment, in a separate section in the Discussion section (which is an available option with the current format), or a new "say what you like here" section. isaacl (talk) 20:54, 16 October 2021 (UTC)
 * I would prefer a cultural norm where nominators can ask "softball" questions in response to concerns in the votes. User:力 (power~enwiki, π,  ν ) 16:34, 18 October 2021 (UTC)
 * I'm also fine with that; I'll be sure to do that for any noms I might do. – John M Wolfson (talk • contribs) 16:52, 18 October 2021 (UTC)

Idea: Support only RfA
A candidate may choose to run a "Support only" RfA. For this type of RfA there will be no Oppose or Neutral section. To be successful a candidate must have a minimum of 150 supports and the closing crat must deem there to be consensus in the discussion. This method will be piloted for 5 RfAs before it must have re-authorization from the community.
 * Issue(s) addressed: 1

Discussion (Support only RfA)
I don't know how I feel about this idea myself, but in thinking the relatively uncontencious elections we have for the ArbCom Election Committee this is how we do it. Even our CUOS appointment process, after an unbelievably bitter year in 2018, now is relatively peaceful. In re-reading the comments from Phase 1 I noted that many people felt that the need to make a forceful oppose and then the feeling for people to need to forcefully counter that forceful opposition was part of what made RfA so unpleasant. This is an attempt to bring a process that works elsewhere (albeit with substantial differences) to RfA for a trial. Best, Barkeep49 (talk) 00:56, 18 October 2021 (UTC)
 * Under this system, how will an editor be able to express concerns about a nomination's behaviour or conduct? Z1720 (talk) 01:08, 18 October 2021 (UTC)
 * Presumably in the comments section or the talk page. — Wug·a·po·des​ 01:13, 18 October 2021 (UTC)
 * @Z1720 the idea is that there would be nominating statements, questions, supports, and discussion. So concerns, or even substantive supports, could all go in that discussion section. Perhaps that would even need to be written in that supports would be signature only. Again this is really just a re-action to my re-reading Phase 1. I do think the mechanism of a defined trial would be useful for many of the larger changes to consider. Best, Barkeep49 (talk) 01:21, 18 October 2021 (UTC)
 * There have been some very close to 150 supports that have failed, so not sure about this. 140 support - unsuccessful, 143 support - unsuccessful. — xaosflux  Talk 01:33, 18 October 2021 (UTC)
 * I don't think using any data from before the last RfA reform is worthwhile. A major impact off that process was to really expand the number of participants. Since 2015, the average successful RfA has seen 204 participants. 75% of that is 153. I changed to 150 because it's a round number. There have been 3 RfAs which were unsuccessful which had 150 supports. Obviously this is a bit imperfect as some withdrawn candidates might not have withdrawn in this system but it retains the ability of crats to do something the community has expressed confidence in crats doing - determining consensus. Best, Barkeep49 (talk) 01:44, 18 October 2021 (UTC)
 * Had Fram 2 run for the full seven days, it would have almost certainly exceeded 150 supports despite a clear consensus against. And, of course, Floq 2 went to a crat chat despite a whopping 325 supports. While those are certainly extraordinary cases, the system only works if it can accommodate them. I'm also not certain about how permitting discussion would work: there'd be little to prevent would-be oppose !voters from simply commenting in another section (thus returning us to RfA). Extraordinary Writ (talk) 02:44, 18 October 2021 (UTC)
 * I agree with the above that either a) comments are not allowed, which means that opposers can't voice their view at all, which precludes the somewhat-common case of RfAs being initially uncontroversial and then failing when a single oppose !vote brings up hitherto-unknown issues and causes supporters to change their minds, or b) comments are allowed, in which this would either make things even muddier in terms of deciding what "consensus" is, or devolve back into RfA. – John M Wolfson (talk • contribs) 13:34, 18 October 2021 (UTC)
 * This does solve the problems but at the expense of making RfA almost useless. It no longer guarantees that a candidate has the confidence of the community, because candidates who don't have even majority support could still pass. It also no longer means the candidate is qualified, because it's now much more difficult or impossible to post evidence that the candidate isn't qualified.  Hut 8.5  16:43, 18 October 2021 (UTC)
 * A nice idea in theory, but just because a candidate can get 150 supports does not mean that they have majority or supermajority support overall. The level of community participation in RfA could very well change in the future and invalidate this proposal anyhow. Trainsandotherthings (talk) 17:22, 24 October 2021 (UTC)

Idea: Remove RfAs from Watchlists
Active RfAs will no longer be advertised on editor's watchlists.
 * Issue(s) addressed: 2

Discussion (Remove RfAs from Watchlists)
I don't know how I feel about this idea myself, but it is responsive to the idea that the level of scrutiny is too high without going to bigger changes such as anonymous voting. Best, Barkeep49 (talk) 00:56, 18 October 2021 (UTC)
 * Not sure if I agree with this idea. Candidates are discouraged from advertising RfAs, which means the watchlist notice is one of the only ways editors find out about new nominations. I fear that the RfA process will become dominated by a core group of regulars if the notice is removed, increasing accusations of a "cabal" that decides who gets to be an admin, or that editors have to suck up to a few editors in order to gain adminship. Z1720 (talk) 01:05, 18 October 2021 (UTC)
 * Well besides editors watch listing RfA itself if they wish to be informed it would presumably stay as part of CENT. I considered throwing out the idea that an RfA launch would be noticed at AN as a high profile venue that is used for announcements but decided that made things more complicated than a strict brainstorming of the core idea of reversing this. Best, Barkeep49 (talk) 01:23, 18 October 2021 (UTC)
 * It would be interesting if there were some survey-produced statistics on how editors find RfAs – whether from the watchlist notice, CENT, watchlisting WP:RFA, etc. If I had to guess, I would say the least productive participants are the "regulars" who watchlist WP:RFA. The ones who come via watchlist notice are probably the relatively harmless "support, no issues" !voters. Extraordinary Writ (talk) 02:48, 18 October 2021 (UTC)
 * There is already the barrier of "knowing that watchlists exist" before editors see those notifications. Separately, I currently don't watchlist WP:RFA (to avoid seeing morasses on the talk page) and would miss RFAs without the notice. User:力 (power~enwiki,  π,  ν ) 02:51, 18 October 2021 (UTC)


 * I think the benefit of the watchlist notice is that it mitigates the risk that the self-selecting group who watchlist RfA might become unrepresentative of the community.—<b style="font-family: Verdana; color: Maroon;">S Marshall</b> T/C 10:00, 18 October 2021 (UTC)
 * Absolutely not. A massive retrograde step. The more I read into many of these proposals seems to be a desire to exclude, prohibit and limit contributors by the ordinary editor in favour of a clique or other unelected or unqualified group (like Stewards!?) Leaky caldron (talk) 11:15, 18 October 2021 (UTC)
 * Well, yeah, they absolutely are. The problem is that we're not getting a sufficient number of candidates because RfA is such a ghastly experience for the candidate.  It's the toxic behaviour of the editors participating in RfA who make it ghastly, so, most of the proposed solutions are trying to limit that toxicity.  If you can think of any way to do that without somehow screening out ordinary editors or putting boundaries on their behaviour, then we need to hear it.  It needs to be a major, transformative change to the process.  We've known this is a problem for about a dozen years and tinkering around the edges has consistently failed.—<b style="font-family: Verdana; color: Maroon;">S Marshall</b> T/C 11:35, 18 October 2021 (UTC)
 * I've yet to see one piece of provable, measurable evidence that there are not sufficient new Admins to cover the tasks required to offset natural wastage. This perennial argument seems to be based on gut fell or a desire to return to the halcyon days of 10+ years ago when all you needed was a handful of edits and the nod and a wink from a few mates. Leaky caldron (talk) 11:46, 18 October 2021 (UTC)
 * @Leaky, with respect, the idea that we don't have a problem was soundly rejected during Phase 1. Best, Barkeep49 (talk) 12:24, 18 October 2021 (UTC)


 * I generally find RfAs from watchlists; I don't regularly follow CENT or WP:RFA. I think less advertisement wouldn't help (as RfA problems existed before the 2015 watchlist change), and may hurt representativeness. ProcrastinatingReader (talk) 11:26, 18 October 2021 (UTC)
 * This is the second-worst idea on this list (second only to the stipend proposal); excluding people will not help and, while I don't think "democracy" is as sacred in general as many do, this is still fundamentally a community process so needs to be as democratic as reasonably possible. Not to mention, this reflects an issue that was actively rejected in phase 1. – John M Wolfson (talk • contribs) 13:23, 18 October 2021 (UTC)
 * I generally only see new RfAs through my watchlist. Dreamy <i style="color:#d00">Jazz</i> talk to me &#124; my contributions 13:56, 19 October 2021 (UTC)
 * Strong oppose. We should be trying to get the community more involved in RfA, not less. Trainsandotherthings (talk) 17:23, 24 October 2021 (UTC)

Idea: Weighting of consensus
When weighing the consensus for a candidate, greater weight should be given to issues with-in the last 12 months, with little weight given to issues older than 24 months unless it is part of a pattern that includes at least one example with-in the last 24 months.
 * Issue(s) addressed: 2

Discussion (Weighting of consensus)
I'm not sure this is practical, as between discussion and voting Phase 1 identified a preference towards more voting, but many remarked that the prospect of people scrutinizing years of edits is a major turn-off. This proposal would put explicit safeguards in place. The logic behind this idea was found to have no consensus due to low participation in Phase 1. Best, Barkeep49 (talk) 00:56, 18 October 2021 (UTC)
 * I see this as only really being of importance should the issue take the discussion to crat chat. My sense from phase 1 is that unless there's consensus for crats to indent !votes taht don't comply with some guidelines, community views on these rationales won't really be useful unless it's in the discretionary zone. Put another way, if something happened 35 months ago that the community thinks was really bad and gets the percentage to like 52%, crats shouldn't promote on the basis of "but it's more than 24 months ago" since there's clearly a consensus to except this instance. I don't think it's a bad idea to tell crats "here's what the community thinks is unreasonable to help you evaluate consensus in a crat chat" but anything more than that I think will be hard to build consensus for. — Wug·a·po·des​ 01:19, 18 October 2021 (UTC)


 * Is "issues" supposed to mean that this is weighting that only applies to the opposition? Would any support not showing something recent be expected to be weighed down? —  xaosflux  Talk 01:35, 18 October 2021 (UTC)
 * Unlike the discussion we're having below this is explicitly about opposition and not support as that's what people in Phase 1 identified as an issue. Best, Barkeep49 (talk) 01:48, 18 October 2021 (UTC)
 * I think having some sort of list of rationales which are not considered appropriate would help, and the age of the issues would be a good example. Bureaucrats would be more confident in ignoring or downweighting comments if there is an explicit consensus that the rationale wasn't acceptable. There are definitely cases where something older than 24 months should be taken into consideration though, e.g. if the candidate was indeffed 25 months ago and unblocked 12 months ago then you should be able to cite the block when opposing.  Hut 8.5  16:54, 18 October 2021 (UTC)

Idea: Lower passing percentage
The text of RfA will be changed so it reads: Consensus at RfA is not determined by surpassing a numerical threshold, but by the strength of rationales presented. In practice, most RfAs above 75% 2/3 support pass. In December 2015 the community determined that In general, RfAs that finish between 65 and 75% 50%+1 to 2/3 support are subject to the discretion of bureaucrats (so, therefore, almost all RfAs below 50% will fail). However, it must be noted that a request for adminship is first and foremost, a consensus-building process.
 * Issue(s) addressed: 3

Discussion (Lower passing percentage)
This idea was suggested during Phase 1 as a way to address this issue. The exact % change could obviously be different. Best, Barkeep49 (talk) 00:56, 18 October 2021 (UTC) PAGE ]]) 03:59, 21 October 2021 (UTC)
 * I think lowering the lower bound is more likely than lowering both lower and upper bounds. I think the main opposition will be along the lines of "if more than 33% of your colleagues don't trust you, it's going to be hard to be an admin". — Wug·a·po·des​ 01:23, 18 October 2021 (UTC)
 * I think the discretionary range is already about as low as it can go. Even bringing it down to 60% failed by a wide margin in WP:RFA2015, and while consensus can change I still doubt such a proposal would meet with much enthusiasm. Extraordinary Writ (talk) 02:53, 18 October 2021 (UTC)
 * Agreed with all, I don't think this is a productive change. If an RfA fails, it usually tanks and it makes no difference whether it's 70% or 50% support. In any event, if you can't even make the current discretionary bound you don't deserve the mop IMO. – John M Wolfson (talk • contribs) 13:18, 18 October 2021 (UTC)
 * I'm not sure I'm necessarily keen on this idea. Looking at the last two years worth of non-selected candidates, there are two who would have passed at a lower percentage that I would like to have seen sysoped but, by and far, I'm pretty satisfied with the outcomes. That said, if the purpose of the percentage change would be to lower the intimidation factor of RfA, I think we could just as easily achieve that objective by pointing out the huge number of admins who are regularly passing with more support than Kim Jong-un got in the last North Korean parliamentary election. I mean, our last three candidates all got five or fewer opposes; I passed with something like 99.2% support and, to be perfectly frank, I'm cognizant of my own limitations and that was higher than should have been likely. If anything, I think the fact 98% just tried to sysop a sockpuppet may indicate our thresholds are too low. Chetsford (talk) 16:50, 20 October 2021 (UTC)
 * Do you really mean 50%+1, or do you mean >50%? A vote of 51 to 50 would fail the former but pass the latter. --Ahecht ([[User talk:Ahecht|<span style="color:#FFF;background:#04A;display:inline-block;padding:1px;vertical-align:-.3em;font:bold 50%/1 sans-serif;text-align:center">TALK
 * The case for the current pass percentage was well made during a full RFC. This proposal directly lowers standards. Large numbers of valid concerns would effectively be disregarded without any commensurate increase in the support !vote justifications - just the usual mono-syllabic, token gesture !votes. It's like turning on the tap to meet (perceived and not statistically proven) "demand". I don't think the community at large would support this. Leaky caldron (talk) 07:19, 21 October 2021 (UTC)
 * I think this idea has merit. The question, of course, is how far do we lower the percentage? I don't know that I have a good answer to that, beyond it should be above 50%. In my opinion, I don't think the community would support lowering the percentage, but you never know until you propose it. Trainsandotherthings (talk) 17:27, 24 October 2021 (UTC)

Idea: Evaluation of trust
The purpose of RfA will be to answer the question "Does the community trust this person with the administrator's toolkit?" !votes which fail to address this issue will be discounted when determining consensus.
 * Issue(s) addressed: 3

Discussion (Evaluation of trust)
There was some consensus during Phase 1 that the question "Does the community trust this person with the administrator's toolkit?" should be what RfA is about. This was my attempt to codify that. Best, Barkeep49 (talk) 00:56, 18 October 2021 (UTC)
 * If this was implemented, I would like to see wording above the "Oppose" section of every RfA that explicitly states this rule. This will remind editors of this rule and prevents a pile-on of aggressive editors demanding explanations from unsuspecting or new RfA contributors. Z1720 (talk) 01:15, 18 October 2021 (UTC)
 * So would !votes that "support" the candidate, but don't declare that it is for this reason be discounted? — xaosflux  Talk 01:27, 18 October 2021 (UTC)
 * @Xaosflux this is a brainstorming exercise. What do you think would be most helpful? Do you think there's a better way of codifying this statement which seemed to have a fair degree of support in Phase 1? Best, Barkeep49 (talk) 01:34, 18 October 2021 (UTC)
 * so what should happen to !votes like: "Support Hard working wikipedian." "Support hoo-hooo" "Support. Not a jerk, has a clue". These are support examples from the currently running RfA right now, how do you think such statements should be weighted? —  xaosflux  Talk 01:38, 18 October 2021 (UTC)
 * @Xaosflux yes I quite understand the issue you're suggesting even without the examples. So maybe this proposal isn't quite it. Let's find something that works better. Do you think there's a better way of codifying this statement which seemed to have a fair degree of support in Phase 1? Best, Barkeep49 (talk) 01:45, 18 October 2021 (UTC)
 * so I'm all on board with reminders what the primary purpose of the RfA discussion is, the challenge I see in this idea is the !votes which fail to address this issue will be discounted part - which seems to be an instruction to the closing bureaucrat, but is a bit vague - suggesting that every single statement needs to be evaluated to this standard and then a subjective "discounting" needs to be applied. In practice, I know that I already apply weighting when closing - however the RfA discussion can often be more nuanced.  Is the discounting supposed to be boolean, or variable? —  xaosflux  Talk 10:02, 18 October 2021 (UTC)
 * Again, this is meant to be an iterative process. I posted all the ideas yesterday as a spur for discussion rather than because I believe in any of them. So I am glad we're discussing but I don't necessarily have a concrete proposal here to sell. That said I would imagine this would be variable. What are your thoughts? Best, Barkeep49 (talk) 12:28, 18 October 2021 (UTC)
 * Barring any explicit new guidance for 'crats, I'd continue to give weights as I described in Requests_for_bureaucratship/Xaosflux. — xaosflux  Talk 14:16, 18 October 2021 (UTC)
 * This would just devolve back into the status quo IMO. Even for stuff not directly related to administrative tools, such as the infamous content stuff, a dedicated enough opposer can just say that a lack of content work (or any desired parameter) indicates a lack of enough experience to handle content issues (or other desired issues) with the mop, and that they therefore don't trust the candidate with the toolkit; this especially applies with such relevant but nebulous parameters as "character" or "judgment". – John M Wolfson (talk • contribs) 16:49, 18 October 2021 (UTC)
 * No. There are plenty more things to think about than trust like experience, use case, editor activity, and plenty more. The idea that is it about just trust and nothing else is something I can't believe I'm even reading. I see no reason to discount legitimate concerns. Naleksuh (talk) 01:09, 24 October 2021 (UTC)

Idea: Remove Question 1
Because "No need for the tools" is considered a poor reason to oppose someone, we will no longer ask candidates "What administrative work do you intend to take part in?"
 * Issue(s) addressed: 5

Discussion (Remove Question 1)
Arguably the consensus of issue 5 should be sufficient on its own for a change - that is crats should discount such opposes. However, this question as referenced in Phase 1 as contributing to the problem. It's possible that a revised wording of this question could be more productive but I will leave that for others to brainstorm. Best, Barkeep49 (talk) 00:56, 18 October 2021 (UTC) PAGE ]]) 14:53, 20 October 2021 (UTC)
 * On the one hand, I can see how "No need for the tools" is a poor reason to oppose. On the other hand, RfA is similar to a job application, and candidates have to show that they can do some aspect of the job. The admin toolset is so vast that this question helps questioners narrow down a candidate's expertise to ask questions about those areas. Without this, candidates will get questions about admin tasks that they know nothing about, making the RfA process more difficult. Perhaps change the wording to, "What administrative work do you intend to take part in at the beginning of your administrative career, and what expertise do you bring to this task?" Or something similar. Z1720 (talk) 01:22, 18 October 2021 (UTC)
 * Mostly agree. I think a more useful wording would be Why are you interested in becoming an administrator? which shifts the frame to motivation and goals without focusing on what venues or buttons they plan to work with. — Wug·a·po·des​ 01:25, 18 October 2021 (UTC)
 * Yes that change probably better captures the discussion around issue 5 than just removing the question altogether. Best, Barkeep49 (talk) 01:53, 18 October 2021 (UTC)
 * I would certainly support a change along those lines: although I'm skeptical that it would have much of a practical effect, it's worth trying. Extraordinary Writ (talk) 02:57, 18 October 2021 (UTC)
 * I also support Wugapodes's wording change. – John M Wolfson (talk • contribs) 13:16, 18 October 2021 (UTC)
 * +1 to the Wugapodes re-phrasing. -1 to getting rid of this entirely; that just means voters will guess at what admin work would likely be done and denies the candidate a chance to pro-actively answer. User:力 (power~enwiki,  π,  ν ) 16:33, 18 October 2021 (UTC)
 * Q1 can help focus additional questions to areas relevant to where the prospective admin thinks they want to admin. Without it, I imagine other questions may be of poorer quality or relevance. e.g. currently asking a verbose/obscure RFPP/AIV question to an editor who says they only want to do Main Page work would be silly, and (imo) a mediocre answer (or no answer) would be less of a concern. Without Q1, the editor has no suitable place to say they want to be a Main Page admin, so all Qs are on the table. ProcrastinatingReader (talk) 11:33, 18 October 2021 (UTC)
 * I'm open to rewording it but it is a useful question. Essentially all RfA candidates have at least one admin area in mind, and a candidate who says they have no intention of using any of the admin tools likely wouldn't get very far. The answer does also show the candidate has good judgement. If someone says they're going to work at RFPP but they've never requested that a page be protected then that's a problem.  Hut 8.5  16:40, 18 October 2021 (UTC)
 * It IS important for !voters to know which areas of Adminship the candidate intends to work in. You might have an admin candidate who is an expert on copyright infringement and that side of things, but lacks knowledge or interest in participating at AfD. Similarly, you might have someone who focuses heavily on AfD and CSD, but has no interest in vandal fighting or AiV. Without question 1, we're back to expecting admins to be perfect experts on literally every aspect of Wikipedia. --Ahecht ([[User talk:Ahecht|<span style="color:#FFF;background:#04A;display:inline-block;padding:1px;vertical-align:-.3em;font:bold 50%/1 sans-serif;text-align:center">TALK

We have to consider why need for the tools has become a de facto requirement. I doubt that Question 1 is the reason. I have added a new idea below – 'Document that "need for the tools" is not a requirement'. Nurg (talk) 01:38, 19 October 2021 (UTC)

I think it would be a good change to reword Q1 as suggested by Wugapodes. There's room enough in the revised wording for the candidate to mention areas they intend to administrat at first. If they don't, their intentions will be a good optional question to ask early in the RfA.--John Cline (talk) 07:24, 21 October 2021 (UTC)
 * I understand why it makes sense to remove it, but I feel like someone will inevitably ask the question anyway, so what's the point? -- Calidum  16:19, 21 October 2021 (UTC)
 * So we currently have up to 200 editors evaluating a candidate. In future we cannot have a simple starting point of why they want to be an Admin? Leaky caldron (talk) 16:59, 21 October 2021 (UTC)
 * I'm confused . Are you lamenting the loss of Q1 in its current form, or saying that we shouldn't have such a simple starting point as asking why they want to be an admin? I ask because the revised version of Q1 will tentatively be: Why are you interested in becoming an administrator?, and you say we can not have such a simple starting point? It seems like a perfectly good starting point to me. Best regards.--John Cline (talk) 04:29, 22 October 2021 (UTC)
 * My response is to the proposition that Q1 be "removed". There are a variety of responses to this, including the replacement wording mentioned as well as a response, immediately above mine, suggesting it makes sense to simply remove it. As you say, there is no certainty that Why are you interested in becoming an administrator? is the de facto wording to replace Q1, it is at this stage merely a suggestion. FWIW, I want to know what areas a candidate is interested in because it gives those with expertise something to work on in assessing the candidate's suitability. Leaky caldron (talk) 07:17, 22 October 2021 (UTC)
 * Thank you for your reply, I understand and agree. Perhaps the best approach would be to merge the new with the old, for example: Why are you interested in becoming an administrator and if you become one, what administrative work do you intend to take part in? I will say, FWIW, I never liked Q1, as written, because it forces pomposity by making you presuppose adminship by stating intentions. I've always felt, at minimum, it should be changed to say: If your RfA is successful, what administrative work do you intend to take part in? Thanks again, for your reply. Best regards.--John Cline (talk) 12:40, 23 October 2021 (UTC)
 * I do think that having an idea of how the applicant will use the tools for the first 6 months or so is useful when !voting and posing questions, however this is often answered in the nomination statement and I'm sure someone will ask the question themselves if there is any doubt. I support the rephrasing suggested by above. We all know that admins don't always stick to what they say they "intend to take part in" as they become more familiar with the tools.  Anarchyte  ( talk ) 14:18, 22 October 2021 (UTC)

Idea: Bot-intermediated limited adminship
Certain semi-trusted users would have access to an (off-wiki) tool that can use the admin tools in specific contexts. For example, "block an IP editor for 31 hours, with the requirement that user has been warned by at least two other editors in the past 24 hours". User:力 (power~enwiki, π,  ν ) 01:11, 18 October 2021 (UTC)
 * Issues addressed: 7, 8

Discussion (Bot-intermediated limited adminship)

 * It's unreasonable to expect arbitrarily complex logic to be built into MediaWiki; a community-managed tool is more likely to be responsive to community desires. User:力 (power~enwiki, π,  ν ) 01:11, 18 October 2021 (UTC)
 * May I interest you in Requests for comment/Responder role? Enterprisey (talk!) 02:24, 18 October 2021 (UTC)
 * For certain admin actions, this tool might also require that multiple users want to perform that action. For example, if one such user told the tool to G1 an article, it might only place db-g1, but if two others also pressed that button, it would go through with deletion. – <span style="font-weight:normal;background:linear-gradient(90deg,#e40303,#ff8c00,#ffed00,#008026,#004dff,#750787);color:transparent;background-clip:text;-webkit-background-clip:text;">Rummskartoffel 13:42, 20 October 2021 (UTC)
 * I think this idea has good potential, especially in situations where the limited admin summons the bot from a project page where administrative log actions routinely occur, like UAA, AIV, RFP, RFPP, and XFD. I'd even be fine if the limited admin was limited to project page areas all together; there would certainly be plenty of scrutiny for their loged actions that way.--John Cline (talk) 07:47, 21 October 2021 (UTC)
 * Potentially a good idea, but I'm skeptical we can get bots to handle this properly and account for edge cases. The community would likely be skeptical of allowing non-admins to block users, a skepticism I share personally. Trainsandotherthings (talk) 17:31, 24 October 2021 (UTC)

Idea: Add admin training with sponsorship
Adding to exisiting processes, anyone meeting experience-specific criteria can approach any admin (from a list of willing mentors) and request coaching and sponsorship, curriculum, duration and levels of complexity to be decided and agreed. Existing admin mentors might be limited to a decided number of sponsees. Sponsors likely/expected to nominate successful sponsees. Creates collegial chains/webs of relationships of trust between sponsors/sponsees which are enduring and traceable.


 * Issues addressed: 2-8

Discussion (Admin sponsorship)
We might formalize an informal process of admin coaching, establishing chains of sponsor/sponsee relationships. Because long existing admins often have a specialty (main page, processes, coi, copyvio) admin candidates might seek sponsors in their arena of interest (which could be generic). Sponsees might have grand-sponsor relationships as well, helping the sponsor make good training choices. When sponsor/sponsee relationship matures, sponsee is nominated and confirmed through existing RFA process. BusterD (talk) 16:41, 18 October 2021 (UTC)
 * Admin coaching was done in the past, about a decade ago, but was discontinued as it was felt to "teach to the test"; i.e., training people for, not adminship itself. That said, I'm open to this idea. – John M Wolfson (talk • contribs) 16:55, 18 October 2021 (UTC)
 * FTR, I was "coached" by two high-vis admins, but the process didn't go anywhere specific. When I "coached" User:CorporateM as an openly paid contributor (under the eyes of WikiProject Cooperation), I made list of things I wanted us to accomplish together and I made demands of the mentee. We might develop a shared list which candidates are expected to master under supervision. I see some potential issues with factionalism and tribalism, but this is a brainstorming phase, so as long as the suggestion is serious, I think such ideas warrant consideration. BusterD (talk) 17:17, 18 October 2021 (UTC)
 * I spent a whole year between seriously considering the mop and obtaining it; of course, I know that's potatoes compared to how long you waited. I contacted SoWhy, Worm, and Lourdes in that order for nomination, but those ultimately fell through and I dropped the consideration until by chance I encountered Barkeep's "cohort" program and volunteered (with the help of co-nom Stephen and Ritchie barging in at the last minute); even that took about a month of preparation. It would have been nice to have a coach in that regards to have more follow-through, so I do think this is a worthy idea. I am aware my case is atypical, and in that year I did transition from doing NPP stuff to more Main Page stuff (not to mention that my current account was less than 1.5 years old in late 2019 so an RfA would have been borderline regardless), but it's still nice to think about how candidates can be helped from the cracks. – John M Wolfson (talk • contribs) 17:32, 18 October 2021 (UTC)
 * The English Wikiversity has a similar process which requires new sysops to be mentored by an existing sysop for at least 4 weeks. — Wug·a·po·des​ 18:50, 18 October 2021 (UTC)
 * So basically, instead of just nominating someone, I adopt them as my padawan and we try to work together for a few months, and then I nominate them? Might work in some corners of the 'pedia, might not in some others, depending on how near-synchronous master and padawan need to edit for this to make sense. —Kusma (talk) 19:03, 18 October 2021 (UTC)
 * I would assert User:Kusma's description is much like how the old ad-hoc admin coaching system was operated. Not to sound contentious, but the changes I'm suggesting here are 1) a set curriculum, and 2) a continuous, maintained semi-permanent relationship-with/deference-to the acknowledged Jedi master (and responsibility of the mentee to maintain approval of the mentor). Just like in twelve step sponsorship, it's possible (and inevitable) to change sponsors as situations change, but somewhat difficult to game the system (which is my highest concern in any new program). I envision some sort of a time commitment (and routine secretarial/clerkish tasks padawans do for "masters"). Further, I do agree "teaching to the test" should be delayed until the very last module. The first module might be "what sort of admin candidate will the community endorse?". BusterD (talk) 19:52, 18 October 2021 (UTC)
 * Building on what I've said above, in some circumstances perhaps the mentee acts as a sort of personal law clerk for the mentor in formal processes (gathers diffs, pens drafts, provides options). It's possible Arbs need personal clerks/mentees. I don't have that experience upon which to draw. BusterD (talk) 20:24, 18 October 2021 (UTC)
 * In most of my admin work, I have no need for a clerk. I could imagine coaching someone while I do speedy deletions (if we're both using the same chat/instant messaging system), but I wonder how many parts of your curriculum I'd even be qualified to teach. —Kusma (talk) 20:42, 18 October 2021 (UTC)
 * Deepening training and experiences among admins sounds like a benefit, not a negative. Let's take the example of RfPP: there's zero reason a responsible editor couldn't be trained to look at a case and recommend an outcome, then defend that recommendation under questioning. Do that for 30 minutes twice a day for two weeks with somebody smart and (in scratch space) they will make acceptable recommendations 95% of the time (my prediction). Busy work? Maybe. Acceptable under pillars, policy and guideline? Totally. I can see ways several processes could be trained in this manner. If the mentee was well-trusted, it could maximize an admin's time enormously. BusterD (talk) 20:56, 18 October 2021 (UTC)

I think a revived WikiProject Admin Nominators could take on a role of helping potential candidates attain the knowledge and experience required to effectively perform administrative actions. isaacl (talk) 21:17, 18 October 2021 (UTC)
 * Possibly. That we tried something/anything long, long ago is no reason to discount the idea of trying again, given the import of what we're discussing. BusterD (talk) 22:00, 18 October 2021 (UTC)
 * Yes, I've said multiple times that we should indeed try it again. Volunteers are welcome to just do it! isaacl (talk) 22:39, 18 October 2021 (UTC)

I think this is good idea. Have you started drafting the formalities yet? Post a like here if you have, or when you do, and I'll try to help you with some of that.--John Cline (talk) 08:22, 21 October 2021 (UTC)
 * I'd be happy for any drafting help. BusterD (talk) 17:22, 21 October 2021 (UTC)

Idea: Create formal admin school
Establish a school for admins that anyone can join, so long as they meet certain minimums.


 * Issues addressed: 2-8

Discussion (Admin school)
Much like massage therapy school, the first phase of training is designed to teach basics and to screen undesirables. After school is well established, this becomes an academy and is run by graduates. With exceptions, all admins must get passing grades in all subjects (mastery-based learning model) before graduation. No specific timeline. We still run open RfA procedures as now. Non-graduates still welcome to run. BusterD (talk) 16:53, 18 October 2021 (UTC)
 * Perhaps, but I'm suspicious of something too formal. See also my comments on sponsorship about past attempts at this. – John M Wolfson (talk • contribs) 16:57, 18 October 2021 (UTC)
 * How is this different from the old admin coaching? We all know how that project ended.  Java Hurricane  18:27, 18 October 2021 (UTC)
 * The above comment by User:JavaHurricane might be better placed in the section above. In this idea thread I'm suggesting formal training, approved by the community, which operates in real time sessions (possibly with several candidates at the same moment). I'm suggesting the community adopts certain lesson plans and modules of lesson plans which demonstrate a knowledge of pillar, policy and guideline through working on live space to a given standard. Nothing resembling the unstructured admin coaching I experienced. I'm suggesting a group of rotating school leaders who initiate the process and then the process taken over by recent graduates whom the community has chosen to promote. WikiProject Military history/Academy is similar to what I'm suggesting, but with evaluation and practicum completed before any RfA. We don't have to go full Harry Potter, but collegiality starts with colleagues. BusterD (talk) 19:34, 18 October 2021 (UTC)
 * Even if it is to be a formal system approved by the community, I still am thinking this is like the coaching system in several key regards: most importantly, it still seems to be about passing RfA rather than becoming a good sysop. And in any case, admin coaching in most forms is already redundant: WP:CVUA helps with getting counter vandalism skills (and spam and UPOL) knowledge to levels comparable to that of a sysop, and the goal of WP:NPPS is to get a graduate the NPP right, which requires knowledge of the NPP policies (e.g. deletion, notability, copyvio) comparable to that of a sysop. RfPP experience can be gained through experience, and CVUA helps with that as well. The only areas where existing structures aren't quite as helpful are AN3, dispute resolution, unblock requests, SPI and XfD other than MfD and AfD. SPI already has the clerk mentoring system; and for all the mentioned systems, experience can be gained through being active in those areas. The main reasons for opposes at RfA lately have been regarding maturity and content creation, and I doubt any coaching system, formal or otherwise, can teach graduates these qualities.  Java  Hurricane  03:58, 19 October 2021 (UTC)
 * I thank User:JavaHurricane for making my point for me. They have demonstrated there are already disparate opportunities for training/mentorship/experience across almost all the necessary disciplines and pointed out how irregular and disconnected such essential pedagogical fields have become. On the other hand, demonstrating and modelling in the arenas of maturity and content creation (sport, art, music, literature, science, law) are the precise purposes of coaching/mentorship. BusterD (talk) 17:33, 19 October 2021 (UTC)
 * The idea of more training/self-evaluation processes has been suggested many times over the years. No one has proceeded further to-date though, which is understandable given the amount of effort required and the uncertain return on investment. If anyone wants to start working on it, that would be great—just do it! isaacl (talk) 21:13, 18 October 2021 (UTC)
 * Because the academy is written under CC license, there's no reason we couldn't just start with/improve some of those completed courses and work our way outward. I'm certain WPMilHist members would be over the moon if all potential admins treated the academy as a project-wide training resource. Lots of very accomplished folks have contributed there. BusterD (talk) 22:07, 18 October 2021 (UTC)
 * Great—anyone interested is welcome to get started! isaacl (talk) 22:43, 18 October 2021 (UTC)


 * What an excellent summary by of everything that has been discussed about admin coaching/training over the years. The main point being that one is here primarily to build an encyclopedia, not to police it. Anyone who joins Wikipedia with the express intention of becoming an admin someday has joined for all the wrong reasons. Kudpung กุดผึ้ง (talk) 05:35, 19 October 2021 (UTC)
 * Well said. Leaky caldron (talk) 07:16, 19 October 2021 (UTC)
 * "The main point being that one is here primarily to build an encyclopedia, not to police it. Anyone who joins Wikipedia with the express intention of becoming an admin someday has joined for all the wrong reasons." I couldn't agree more; and I doubt I'll ever be able to voice my thoughts so well.  Java Hurricane  09:46, 19 October 2021 (UTC)

In what way does establishing and teaching an approved curriculum for admin candidates 1) become "about passing RfA rather than becoming a good sysop", 2) imply the candidate is here to "police" not build pagespace, and 3) create a "cadre of specially trained, hand picked graduates", "Animal Farm stuff"? There is nothing in my suggestion which naturally leads to such hyperbole. Has anybody even read Academy? It primarily concerns best practices for content creation and reviewing, written by our most productive content area wikiproject. I'm baffled by this set of straw man assertions. BusterD (talk) 17:04, 19 October 2021 (UTC)
 * The notion of a cadre of specially trained, hand picked graduates is chilling. This is Animal Farm stuff. Leaky caldron (talk) 07:16, 19 October 2021 (UTC)
 * Which specific parts of my "hyperbole" do you specifically refute? Leaky caldron (talk) 17:39, 19 October 2021 (UTC)
 * I think that the main opposition is not to the concept itself, but rather to a problem with the education system in general, which places a greater stress on theoretical rather than practical knowledge, i.e. preparing you for the test rather than life. I'm certainly more amenable to a coaching system that is based on the practical aspects – CVUA and NPPS already have done well with this – while my concerns about the content creation part have been solved now by a thorough read of the Academy (and I unreservedly apologise for not doing so before commenting earlier). I do still have some doubts about teaching maturity, that said, though I suppose an initial screening process should help allowing only users with more than sufficient maturity for holding the mop into the system.  Java Hurricane  17:42, 19 October 2021 (UTC)
 * Doubts are reasonable. That is why we have so much clash in these discussions. This is a "monumental good thing" to quote Devo. If I primarily used a hammer, I'd see the world as a set of nails. I'm formally trained as an educator, so I see the world as teachable, and am used to thinking in this mode, and using these methods. Pedagogically I am a follower of Dewey, who championed real life experience over book learnin'. I am happy to entertain doubts and admit the failings of my own (sometimes overly optimistic) world view. BusterD (talk) 18:15, 19 October 2021 (UTC)
 * Do you still believe this? "A Wikipedia administrator is a person who has demonstrated a certain amount of trust based on their actions in real time and their transparency in page history time." It's from your User Page. Leaky caldron (talk) 18:35, 19 October 2021 (UTC)
 * I do. The quote is on my /Analogies subpage and comes from my questioning of User:Gwen Gale during her first run for admin (which I opposed). BusterD (talk) 18:50, 19 October 2021 (UTC)
 * Part of the reason why I suggest just doing it is because I don't think it's effective to argue about the proposal in theory. If someone creates appropriate resources, keeps them up to date, and others find them useful, that's great! If the initiative falls short, it'll be a pity, but we can still gain some benefits and some experience to consider next steps. isaacl (talk) 20:46, 19 October 2021 (UTC)


 * There is a vast difference between teaching people how to build the encyclopedia corpus and coaching power hungry/prestige seeking users how to police it. Kudpung กุดผึ้ง (talk) 04:58, 21 October 2021 (UTC)
 * Which is precisely why I have my doubts about how the process can teach candidates the maturity required to use the mop.  Java Hurricane  05:44, 21 October 2021 (UTC)
 * I like the "sponsorship"idea better. Some of these specific training opportunities can be incorporated into that, and probably should be. This idea competes with sponsorship, in my opinion, and in such a competition, I choose sponsorship.--John Cline (talk) 08:41, 21 October 2021 (UTC)

Idea: Document that "need for the tools" is not a requirement
Spell out on relevant pages that "need for the tools" is not a requirement (or some other statement along those lines).


 * Issue addressed: #5

Discussion (Document that "need for the tools" is not a requirement)
The key requirement for adminship is trust. "Need for the tools" is a relatively weak reason (relative to trust, that is), but where an candidate has an obvious need for the tools, it is a good secondary reason for granting them. I think a leap is made from "need for the tools" being a good secondary reason to grant them to "no need for the tools" being a reason to oppose it. But this leap is not logical. I think the answer is to spell out, on relevant pages, that "need for the tools" is not a requirement (or some other statement along those lines). I'm not sure exactly which pages – obvious possibilities are Requests for adminship and Administrators. Nurg (talk) 01:34, 19 October 2021 (UTC)
 * Although people are wrong to oppose for "not needing the tools", candidates should ultimately have an actual need for the tools, even if it's slight; just "wanting the tools" is inadequate and can demonstrate a fundamental misunderstanding of adminship. Explicitly saying that a candidate doesn't actually have to have a need for the tools, without any further nuance, is a sure way to invite hatcollecting and other MMORPGing. Having no backstage experience or intended mop use – even if it's ultimately a far cry from what the candidate actually does once the mop is granted – is just as bad in my book as having little to no content creation. And yes, when in combination with other factors such as lack of trust or poor judgment, "no need for the tools" is a perfectly valid reason to oppose. – John M Wolfson (talk • contribs) 02:41, 19 October 2021 (UTC)


 * Concurring with : A need is a need (for some individuals), even if it's for something to brag about in the schoolyard, or in the case of others, on their personal blog or CV. Kudpung กุดผึ้ง (talk) 05:43, 19 October 2021 (UTC)


 * I think the whole concept of "no need for the tools" is a misnomer. RfA candidates almost always have some intention to use the tools for something. A candidate who made it clear they had no intention whatsoever of using any of the admin toolkit, ever, would likely be considered a hat collector and fail as a result. The term is often used to dismiss opposes on the grounds that the candidate has little experience of admin-type work, but I think those are legitimate. It's reasonable to expect people who want to become admins to show that they can do the kinds of things that are involved in adminship.  Hut 8.5  11:50, 19 October 2021 (UTC)

PAGE ]]) 15:19, 20 October 2021 (UTC)
 * I agree that "need for the tools" is problematic because no one needs the tools. There are already other admins that could handle just about any task. That said, candidates should be able to answer how they'd use the tools. --Ahecht ([[User talk:Ahecht|<span style="color:#FFF;background:#04A;display:inline-block;padding:1px;vertical-align:-.3em;font:bold 50%/1 sans-serif;text-align:center">TALK
 * Well, there aren't really any hard requirements other than being extended confirmed. I think "requirement" is misleading, and so is "need" for tools, but I don't think pretending a use case for the sysop tools is optional is a good idea. If a candidate doesn't have a use for the tools, then the main reason they are requesting sysop is likely for a trophy. Naleksuh (talk) 21:18, 21 October 2021 (UTC)


 * If anyone failed to understand my sardonic cmt above, a user who has done little or no adminny things such as NPP, AIV, AfD, etc, can hardly claim a need for the tools as  concurs: '...for a trophy', or for posturing off-Wiki. Kudpung กุดผึ้ง (talk) 02:43, 22 October 2021 (UTC)

Idea: Applying any of the proposals above to a person's second RfA but not their first one
This is a meta-proposal that I don't expect anyone to like ... until and unless it turns out that the proposals that are most popular with people in favor of RfA reform can't pass in the current environment. At the point where it's "Plan B" or nothing, this might be preferable to nothing. Let's discuss.
 * Issue(s) addressed: whatever issues are addressed by some proposal above that this one is being paired with.

Discussion (Applying any of the proposals above to a person's second RfA but not their first one)

 * To clarify: I'm not saying that the rules for a person's first RfA can't or shouldn't change ... some of the proposals above will probably pass without too much trouble, and that's great. But some of the best proposals (best in the eyes of most pro-reform voters) may not be able to pass, especially after a recent troubling RfA (you probably know which one I'm talking about). I get that no one is going to be enthusiastic about this meta-proposal today, because the voting hasn't started yet. But in the sad event that the mood has indeed soured, it would be nice to get some feedback on this ahead of time. Some of the proposals above would have the effect of stopping some voters from saying what they want to say ... that's kind of the point ... and I don't want us to overlook the fact that some voters would be okay with giving up the right to repeat their points in a 2nd and 3rd RfA for a particular candidate (heck, some of them would be happier not having that burden) as long as you give them one shot to say whatever they would normally say during a 1st RfA. I also don't want us to overlook that many potential RfA candidates have no problem with a week of community scrutiny; the problem is that a failed RfA can easily turn into something that feels like years of hazing and having to watch everything they do and say, because of what might happen at a 2nd RfA ... and even if they say they'll never run again, that doesn't necessarily fix the problem. If any of the above proposals that have the effect of mitigating scrutiny were put in place for a 2nd RfA, there's a chance that could help in a meaningful way (again, assuming that the original proposal, meant to apply to all RfAs, fails to pass). - Dank (push to talk) 21:17, 21 October 2021 (UTC)
 * As to how exactly this would work ... that's impossible to answer without discussing some particular proposal above that we want to pair this one with, and it would be too complicated to get into all of the what-ifs right now. I'm thinking that, in the course of the RfC, it might become clear that there are one or two proposals that the RfA-reformers are really enthusiastic about, but that can't quite make it over the hump. After voting picks up and things get clearer, it might become easier to discuss specifics. - Dank (push to talk) 21:27, 21 October 2021 (UTC)
 * This is all a bit too complicated in my eyes, same with the multi-stage RfA ideas. RfA doesn't need a whole lot of reform; it's not itself that bad, it's mainly the perception of it being a viper's nest that discourages otherwise-suitable candidates from running. Cultural changes and shifts would be far, far more effective and less costly than anything technical or procedural. Applying different rules between the same candidate's different RfAs runs into time problems; it can unduly incentivize a user into re-running at RfA far too early since the scrutiny in the second RfA would be (probably, if the reformers have done their job right) lowered, yet there are also certain candidates like BusterD whose runs were almost a decade apart, and should therefore both be treated as a "first" RfA IMO. As for the Eostrix affair, I highly doubt anyone cares so much about it as to significantly change any opinions on reform or RfA in general over it; anyone who lost actual genuine sleep over it is far too invested in Wikipedia for their own, and the project's, good, and anyone using it in the context of discussion is just using it as an excuse to further any pre-existing agenda, for or against reform. – John M Wolfson (talk • contribs) 21:54, 21 October 2021 (UTC)

Idea: An informal forum of some kind where people who are interested in being admins can discuss the possibility with admins
One problem with RFA is that it is very public. Editors might not want to become candidates for fear of being denied, and the loss of credibility that might come with being ruled unworthy. But what if there was a more private way to have one's chances assessed before an official nomination?

This could be run along similar lines to IRC help, in that it's not recorded and for advisory purposes only. Information shared through IRC help is generally not used in any other way, except in the case where vandalism is detected.

A user can turn up and mention that they would like to be an administrator. The person who is offering help could do a quick review of the candidate's experience and motives for wanting to be an administrator.

Advice could be offered, e.g. whether a RFA is plausible given an editors previous experience and contributions. This could be a less embarrassing and invasive way to begin one's journey towards adminhood. If a candidate is deemed to be not yet ready for administrator's duties they could be given advice and have expectations set. It could also be used to encourage or discourage candidates from making an RFA application based on some non-public advice.

Issues addressed: 1, 4

Salimfadhley (talk) 16:39, 23 October 2021 (UTC)

Discussion (An informal forum of some kind where people who are interested in being admins can discuss the possibility with admins)

 * This already exists in the form of ORCP, which has quite constructive feedback. – John M Wolfson (talk • contribs) 17:05, 23 October 2021 (UTC)
 * Well, I think this idea is looking for something less public than ORCP. I would say it already exists in the form of emailing one of the more frequent nominators (e.g. Barkeep, Ritchie, etc.): I understand they're generally willing to give the sort of advice that this proposal is talking about, privately. Extraordinary Writ (talk) 17:29, 23 October 2021 (UTC)
 * Indeed, with a little tweaking, WT: Request an RfA nomination could do this <b style="text-shadow:0 -1px #DDD,1px 0 #DDD,0 1px #DDD,-1px 0 #DDD; color:#000;">Worm</b>TT(<b style="color:#060;">talk</b>) 07:56, 24 October 2021 (UTC)
 * I was unaware of all this. Perhaps this information could be added to the RFA page? --Salimfadhley (talk) 12:12, 24 October 2021 (UTC)
 * It's mentioned and linked under the "Nomination standards" sub-heading. I suppose what would be more helpful is removing links to processes that simply don't work, both to avoid misleading potential candidates and also to avoid distracting from useful information. For example, the suggestion of "Category:Wikipedia administrator hopefuls" should probably be removed, as should the link to ORCP which we know doesn't work because a) most successful candidates don't use it; b) most people who do use it don't go on to pass RfA. ProcrastinatingReader (talk) 12:16, 24 October 2021 (UTC)
 * Regarding the optional candidate poll, if you're including those who never go on to request administrative privileges, then (b) is true, but that is also part of how it was designed to work: it keeps editors who aren't suitable by anyone's criteria from wasting their time at RfA. (And I imagine the same would be true for an informal forum: it would attract attention from casual editors, most of whom would not further pursue a request for adminship.) As for (a), it was never intended for most candidates to first undertake an optional poll. The poll was created by Anna to encourage those who were uncertain of their suitability to pass RfA, and it's natural that many administrators were sufficiently confident in their self-evaluation so that they felt no need to have an optional poll first. isaacl (talk) 15:35, 24 October 2021 (UTC)
 * WP:ORCP is certainly a broken process, so I think this might be worth trying. &#123;{u&#124; Sdkb  }&#125;  talk 07:02, 25 October 2021 (UTC)
 * That's a very strong claim, . Would you care to elucidate what you believe the problems to be? According to your user page: This user knows that Facts Matter. Kudpung กุดผึ้ง (talk) 00:53, 30 October 2021 (UTC)
 * I've seen many editors state that they were advised not to go through ORCP because it would harm their chances at RfA. I forget where I saw that but I could try to find it if you're interested. &#123;{u&#124; Sdkb  }&#125;  talk 00:57, 30 October 2021 (UTC)
 * I'd be interested in hearing details from "many editors" on this subject. If going through ORCP is an intimidating process for some candidates, it says something about 1) the process, 2) "many editors" themselves, 3) those giving advice. In my experience, I entered the poll at face value, knowing the quality and vast experience of the few editors who frequent that process (compared to the variety at RFC). In my case I didn't feel any reason to refrain; someone who does might not feel themselves ready for the run without strong encouragement. My case may not be representative of the set of potential admin candidates, but the warm reception given by editors I admire melted any reluctance I harbored. BusterD (talk) 18:26, 30 October 2021 (UTC)
 * See and  for a view on the lack of benefits for the optional RfA candidate poll. The participants have shifted in the last couple of years, though, and there is a greater focus on interactive discussion. isaacl (talk) 02:34, 31 October 2021 (UTC)

Idea: Create an impartial board to evaluate RfA candidates' qualifications
I mentioned this in discussion earlier, but I want to bring up this idea specifically and see what others think. My idea is that we create a board which evaluates the qualifications of RfA candidates, and gives them a rating. This is based on how the American Bar Association rates the qualifications of judicial branch nominees in the United States. The ABA evaluates each nominee, and issues a rating: either "well qualified", "qualified", or "not qualified". We could do something similar, where some experienced admins and community members evaluate each candidate's credentials, and present their findings to the community. This would not be binding, but would serve as a way to have an impartial outside evaluation of candidates which could help inform the voters (and hopefully help deal with irrational opposes like "the candidate doesn't have 10 GAs"). Trainsandotherthings (talk) 18:02, 24 October 2021 (UTC) I am withdrawing this idea, it is clearly not supported by anyone. Trainsandotherthings (talk) 18:03, 30 October 2021 (UTC)
 * The fewer "boards" we have the better. There is an existing process for filtering and gaining insight should candidates choose to use it. It isn't clear what problem this idea is solving. Looks like another layer of officialdom getting in the way of progress. In any event, I am fundamentally opposed to anything on WP being based on formal legal structures. Leaky caldron (talk) 17:59, 24 October 2021 (UTC)
 * That's a fair point. I wanted to throw the idea out there, since we are brainstorming. Trainsandotherthings (talk) 18:02, 24 October 2021 (UTC)

PAGE ]]) 20:22, 24 October 2021 (UTC)
 * That seems like it would give the appearance of a WP:CABAL, which is what we should be trying to avoid. --Ahecht ([[User talk:Ahecht|<span style="color:#FFF;background:#04A;display:inline-block;padding:1px;vertical-align:-.3em;font:bold 50%/1 sans-serif;text-align:center">TALK
 * I don't know how any board would prove its impartiality and it is completely certain that it would not be perceived as impartial by at least a large majority on some occasions. The ABA is criticized on its level of impartiality on many occasions and a board modeled after would likewise be criticized. The aim of this brainstorming, as I understand it, is to reduce the level of drama over the RfA process, not add another point of contention. I believe that such a board would only do the latter. has a point when they mention the CABAL aspects, as well.  If we chose such a board from established admins and non-admins, they will favor users that generally fit the profile of established users.  This is not a prediction based on who I think such a board will be made of, it is a prediction based on human nature and sociology. In-groups pick new members that resemble existing members, even when they try not to. This project already has a WP:SYSTEMICBIAS problem, such a board would reinforce this.   Eggishorn  (talk) (contrib) 18:00, 30 October 2021 (UTC)

Idea: separating DS, GS and AE actions from the admin toolkit (and making it more restrictive)
The idea popped in my mind while reading through the discussion on the Eostrix incident: I read a comment (I think, by GizzyCatBella) that adminship gives candidates the powerful ability to impose sanctions at their discretion in areas covered by DS and GS, and can only be reverted by a majority consensus at AE and AN, respectively, so long as they are uninvolved. It's a crazy idea, and probably wouldn't have gone far even if it had been proposed earlier, as it would require very extensive discussion. Still: it's just a brainstorming phase, so I thought, let's take a chance. For what it's worth, I think that separating this powerful ability from the toolkit and making it available to sysops specifically appointed after a community discussion (at AN?) would reduce a lot of the scrutiny that people would give to adminship, as a major pressure associated with the stakes of the bit would be separated; such tough scrutiny can be directed towards that discussion then. What do you think?  Java Hurricane  03:15, 30 October 2021 (UTC)
 * I would be fine with this; I thought you meant give it to non-sysops, hence my addition to the title. – John M Wolfson (talk • contribs) 14:13, 30 October 2021 (UTC)
 * I forgot to mention that only sysops could ask for dealing with these matters. Thanks for the fix!  Java Hurricane  14:18, 30 October 2021 (UTC)