Wikipedia talk:Requests for adminship/2021 review/Proposals

1A Formal moderation of RfA

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

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

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

Discussion (Formal moderation of RfA)

• Would the moderators be elected, appointed by someone neutral, or self-appointed?—S Marshall T/C 17:22, 31 October 2021 (UTC)

• That is an excellent question, which I myself raised in the brainstorming phase. Unfortunately there was no further discussion of it at the time. I'm open to input on what would be best here, though self-appointed doesn't make much sense to me. My thoughts are that they should either be a random selection of admins who have opted in to moderating RfAs, or a specific user group that is elected, which would open up moderator elections to non-admins who have shown they are good candidates for moderators. Trainsandotherthings (talk) 17:26, 31 October 2021 (UTC)

• This was moved here without the modification I made to the proposal, which specified that the moderators would either be admins chosen from a group of admins who have opted in to moderation, or members of the community who are either elected or appointed. Further comment is needed from other editors to refine this proposal. Trainsandotherthings (talk) 17:50, 31 October 2021 (UTC)

  Perhaps this was an edit conflict? I will note that assuming sufficient details can be added in the next week this can be restored to the proposals page. So by all means get this built out from a concept (there should be more moderating) to a proposal of how this additional moderating would work. Best, Barkeep49 (talk) 18:07, 31 October 2021 (UTC)

@Barkeep49, sorry, probably being stupid...we wouldn't need an RfC for implementation of formal moderation? —valereee (talk) 18:52, 31 October 2021 (UTC)

@Valereee: formal moderation of RfA would certainly need consensus - most likely through an RfC. However this proposal doesn't state how more moderation would happen it just says there should be moderators. That is not an idea ready to be implemented. How would the formal moderators be chosen? What standards would they use? Would there be any recourse to appeal and if so what would that be? Would moderators have to abstain or is it only a suggestion? This is the start of an idea for sure but it is not a finished one. Hopefully interested editors can do that work in the next 7 days and it can be part of this process. Best, Barkeep49 (talk) 18:58, 31 October 2021 (UTC)

Oh, sorry! I was looking at it backwards lol... —valereee (talk) 18:59, 31 October 2021 (UTC)

• Just thinking out loud: I'm thinking usergroup. Selection probably should be done prior to start of the RfA, so we'd need nominators to notify the usergroup and request service, with preference to round-the-clock coverage by three mods? Personally I'd want moderators to be able to approve questions ahead of posting to prevent irrelevant questions from stressing candidates unnecessarily, but that's possibly a non-starter. Maybe just allow moderators to remove a question that has been objected to on talk (or that the moderator thinks is objectionable) while questions are asked about that question. :D Moderators should be allowed to revdel personal attacks, which means it needs to be admins. That's too bad, it would be nice if this could be done by non-admins. Maybe it could just be strike, and any admin (mod or not for this particular RfA) can revdel if needed? —valereee (talk) 19:15, 31 October 2021 (UTC)
• @Barkeep49: So, based on Valereee's ideas, the proposal will be: a usergroup is created that consists of ANI RfA moderators, who are empowered to police conduct at ANI RfA. A few members from this usergroup will be assigned to each RfA, which they will monitor. Members of the ANI RfA moderator group who are moderating a RfA will not be allowed to vote on said RfA. The moderators will be pulled from a larger pool of administrators who opt in to moderation of RfAs. Moderators will be tasked with maintaining civility, will approve all additional questions before they are added, and ensure that badgering is kept to a minimum. In general, they will be enforcing existing policies for RfA (plus whatever changes come from this RfA reform process). Is this concrete enough to add back to the process? Trainsandotherthings (talk) 18:15, 3 November 2021 (UTC)

  I guess it's not technically out of scope but trying to change ANI and RfA together seems like folly. Leaving that aside the basic idea is that any admin can opt in to being an RfA moderator which would have them moderate RfA with the agreement that they do not otherwise participate in RfA? Want to make sure I have the basic concept right before further responding. Best, Barkeep49 (talk) 19:18, 3 November 2021 (UTC)

  How did I end up adding ANI in there??? I must have been confused when I wrote that. It shouldn't have anything to do with ANI. Changed accordingly, my bad. 19:25, 3 November 2021 (UTC)

  Besides my silly goof (too many processes with 3 letter abbreviations), you are right about the fundamental concept I'm proposing. The one thing that isn't correct is that I am proposing we create a pool of RfA moderators, and which members moderate each RfA will change. This way, moderators won't be blocked from participating in RfA, except for particular RfAs they are moderating. Trainsandotherthings (talk) 19:30, 3 November 2021 (UTC)

  So any administrator could volunteer to be an RfA moderator and some random group of RfA mods are chosen for each RfA? Who does the choosing? How many are chosen? See also the questions I raised in my response to Valereee. This is closer to being a formal proposal but is not yet there. Best, Barkeep49 (talk) 21:40, 3 November 2021 (UTC)

  Sorry, been busy IRL...@Barkeep49, I think it may be worth considering whether moderators possibly shouldn't be voting/asking questions at RfA at all? I'm concerned that they might be seen as someone who somehow has more 'authority' or possibly access to secret knowledge? FWIW, I feel a bit the same about bureaucrats and sitting arbs. —valereee (talk) 11:56, 8 November 2021 (UTC)

• Per my comments in the Brainstorming phase - this can cause more harm than good as it can torpedo every other proposal. If we're looking at it, we need specifics on what can be moderated and why this is different from status quo. Worm^TT(talk) 19:57, 3 November 2021 (UTC)
• In my humble opinion this is the number one change that would make RFA a much better place to be. I was stunned that there was next to zero moderation in my 2015 attempt, other than the nominators themselves who tried valiantly to keep an eye on things. A moderator team would have quickly picked up on the problem of one (now banned) user who was constantly going in and changing their own remarks to support other opponents without disclosing that they were doing so. There were a lot of personal attacks and assorted drama on the nomination page that were only rarely moved over to talk for extended discussion. I know some things changed after my RFA (a few have said because of it… ) but I think a team of moderators, (probably mostly existing admins), who can collapse conversations, move discussions to talk, and even revdel the more egregious personal attacks would be awesome. It’s sad that RFA needs babysitters, but it does. Montanabw^(talk) 22:49, 5 November 2021 (UTC)

  @Montanabw, and unfortunately the nominators are at a disadvantage w/re moderating, as they obviously aren't neutral. I've even stopped !voting at RfA, as recently I've been trying to do some informal moderation. And I've been mostly chary of doing too much even of that without some sort of indication that it's seen as generally productive rather than otherwise. —valereee (talk) 12:00, 8 November 2021 (UTC)

  Precisely. Hence independent, neutral moderators. Montanabw^(talk) 04:50, 9 November 2021 (UTC)

• I'll admit I'm in a bit over my head here. Pinging User:valereee, do you have any further ideas on how to turn this into a concrete proposal? Trainsandotherthings (talk) 22:43, 6 November 2021 (UTC)

  @Trainsandotherthings, I'm not sure. I feel like some sort of guidance on what a formal moderator is authorized to do, and how to allow for a moderator's actions to be overruled. Details to be decided in part II of the RfC after we've decided whether in theory moderation has consensus. So given that the rule here is that no additional RfC be necessary, I'm not sure how to proceed.

  Details to be decided would be like can a mod, acting on their own discretion, remove and redact even minor incivility within the RfA and maybe on the talk? Can any discussion within the oppose section be promptly and completely moved to the talk at the mod's discretion? Can a mod move an irrelevant question to talk for 24 hours to get consensus that it's worth asking? What happens if the poster of the incivility/oppose discussion/question objects? Those aren't things I'd want to detail in the RfC, but they're certainly things we should mention in the RfC as being details that need to be decided in the 2nd part.

  The problem with RfCs is always that we want to be detailed enough to make the concept clear, but not so detailed that we end up getting opposes because of one minor detail that wasn't even important to the overall idea. —valereee (talk) 12:15, 8 November 2021 (UTC)

• Change "1A Formal moderation of RfA" to "1A Formal moderation of RfA" "1A Moderation of RfA". What is the purpose of "Formal". Is there to be no gentle moderation (eg a quiet word elsewhere) below the formal threshold, and then is that subject to challenge of having met the threshold.

This is a very old idea. I suggest volunteer clerks, approved by Bureaucrats. A bureaucrat may moderate directly, but that may colour their impartiality at the time of closing. --SmokeyJoe (talk) 06:48, 8 November 2021 (UTC)

I don't think a bureaucrat should be moderating. I don't think bureaucrats should really be doing anything at RfA in case it goes to a crat chat. —valereee (talk) 17:35, 19 November 2021 (UTC)

4B Establish an optional admin school with approved curriculum

Copied here for further discussion from the proposals page as out of scope - no formal consensus needed to implement. Barkeep49 (talk) 15:38, 31 October 2021 (UTC)

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

Discussion 4B Establish an optional admin school with approved curriculum

It's not clear to em if the person proposing this is aware that we already tried this and it did not work out. See WP:ADMINCOACH Beeblebrox (talk) 21:18, 1 November 2021 (UTC)

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

Copied here for further discussion from the proposals page as out of scope - no formal consensus needed to implement. Barkeep49 (talk) 15:38, 31 October 2021 (UTC) Formalize/establish a program in which qualified volunteers may approach willing administrators as potential sponsors for admin coaching/training. Trainees would be responsible to their mentors and be willing to accept conditions set by the sponsor for activity and judgement. Successful trainees become their sponsor's apprentices, perhaps on a path toward RFA.

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

WP:ADMINCOACH is marked as historical because it's not very effective. Sometimes it actually sinks an RfA because the candidate's coach thinks they are not quite ready and everyone just pile on based on the single coach's opinion. It does nothing to address the issue around RfA. OhanaUnited^{Talk page} 17:48, 9 November 2021 (UTC)

Proposals and signatures

Should proposals be signed by their primary author or authors? User:力 (power~enwiki, π, ν) 16:57, 24 October 2021 (UTC)

I think not though I would certainly be open to it if others think they should be. For now I have commented out John M Wolfson sig. Best, Barkeep49 (talk) 17:02, 24 October 2021 (UTC)

I believe they were signed in 2015, but if we decide against signing them we should rephrase the comment from "there is no need to sign" to the more imperative "do not sign".  – John M Wolfson (talk • contribs) 17:09, 24 October 2021 (UTC)

From my look at 2015 I actually didn't see any signatures. In general these aren't needed because the proposer is generally the first supporter so all is clear. Because we have a proposal period it's not as clear and so feedback is welcome. Best, Barkeep49 (talk) 17:15, 24 October 2021 (UTC)

It's not at all clear to me either. Unsigned proposals are an invitation for editors to WP:BOLDly change them during this week, which probably isn't desired. And "vote 1 as nom" attribution won't be present. So I think the signatures are good. User:力 (power~enwiki, π, ν) 17:24, 24 October 2021 (UTC)

I actually agree that signatures should not be used at this stage since proposals are liable to have some changes, radical and otherwise, and we wouldn't want a clutter of EDIT:~~~~s until phase 2 actually starts. After proposals are "set in stone", signatures are probably good per Power.  – John M Wolfson (talk • contribs) 17:27, 24 October 2021 (UTC)

I'm against signatures because the goal is viable proposals not attributable proposals. Like the rest of the encyclopedia, collaboratively editing proposals is a good way to develop a consensus without needing to discuss everything to death. Signatures inhibit editing and slow negotiation. — Wug·a·po·des​ 23:52, 25 October 2021 (UTC)

I'd recommend signatures. I feel like RFCs without signatures are missing important information. I've seen admins boldly edit in signatures and edit out signatures from the first post of RFCs before, so definitely not a straightforward issue, but that is my two cents. –Novem Linguae (talk) 10:01, 26 October 2021 (UTC)

I feel like signatures can increase the amount of kneejerk oppose/support an idea gets. I'd rather people have to actively go looking to figure out whose idea it originally was. —valereee (talk) 17:27, 31 October 2021 (UTC)

I concur with Valereee. The ideas should be weighed exclusively on their merits, and not by who proposed them. Trainsandotherthings (talk) 17:29, 31 October 2021 (UTC)

2a Question

@John M Wolfson: why would that question only be there for the last 24 hours? Very little voting tends to happen in that time in proportion to the RfA as a whole. Best, Barkeep49 (talk) 17:04, 24 October 2021 (UTC)

• As I said in the brainstorming phase, it's late enough that any questions desired has a chance to be asked beforehand, and any RfA that doesn't make it to the last 24 hours is unlikely to be helped by the question.  – John M Wolfson (talk • contribs) 17:07, 24 October 2021 (UTC)

  To the extent that question has been asked helpfully in the past it has been done well before the last 24 hours. Ultimately I'm neutral on whether this is needed - as people seem to step up and do this when required - but what do you see as the advantages of this compared to allowing the candidate to pose it to themselves once per RfA at a time of their choosing? Best, Barkeep49 (talk) 17:18, 24 October 2021 (UTC)

  Power had a proposal to have a cultural norm of noms "softballing" questions based on concerns to the candidate, which I think would ultimately be a better idea than this, but I do think this is worth proposing. If this proposal passes, I'm fine with extending the "questionable" time to the second half of the RfA, but I do want much if not most of the RfA activity to have already taken place so that the candidate would have a better idea to choose what question to ask, both for their own sake and to prevent undue "self-softballing" before any community concerns are expressed.  – John M Wolfson (talk • contribs) 17:25, 24 October 2021 (UTC)

• I also think that 24 hours is too late: it's only in the discretionary range that the last 24 hours makes a difference. Thinking about the base purpose of this suggestion, I gather that it's so that the candidate has a right of reply to opposes. My idea would be to add a new section, below "Questions for the candidate", titled "Comments by the candidate". This gives them a chance to respond at any point where the discussion is snowballing and the candidate has something to say but hasn't been asked the right question. I believe a new section specifically demarcated for their comments during the RfA process would overcome the bad parts of the social taboo behind a candidate replying to opposes, without making things more toxic for opposers (rather than calling people out by name, I'd expect comments like "I see people are concerned about X; here is my side of the story..."). @John M Wolfson: would you like to change your proposal some way towards this, or is it sufficiently different that I should add it as a 2B? — Bilorv (talk) 20:15, 24 October 2021 (UTC)
  • You should add it as a separate proposal; I don't think I'll support either it or my original proposal, but it's worth some consideration.  – John M Wolfson (talk • contribs) 20:21, 24 October 2021 (UTC)

    It would be better to not have tons of proposals here. This is such a small variation that it would be better to just decide on the right time period and only put forward the one proposal for wider consideration. ProcrastinatingReader (talk) 20:55, 24 October 2021 (UTC)

    I agree that it's very important not to have too many proposals (to get the most focused attention and least vote-splitting/perfectionism in each section), but I think the variation here is sufficiently large that I would oppose John M Wolfson's proposal but support my own. — Bilorv (talk) 20:57, 24 October 2021 (UTC)

    What I mean is (for example) if most people would prefer yours, it would be better to only propose yours. I also personally agree with your reasoning, FWIW, that the last 24 hours doesn't really make a difference (esp in proportion to the RfA as a whole). ProcrastinatingReader (talk) 22:45, 24 October 2021 (UTC)

    @John M Wolfson I would encourage people to only put forward proposals they believe in and are prepared to support, unlike the brainstorming phase where half-baked ideas were permitted, encouraged even (I know I did it) in the hopes that discussion would refine them into something stronger that the community would support. Spurring discussion is something that can be done on this page and even after this process is over but if you're not prepared to support something you've put forward I would ask you to rethink putting it forward so that the high number of editors we're hoping to attract don't have to sort through proposals that from the get-go have limited support. Best, Barkeep49 (talk) 03:10, 25 October 2021 (UTC)

    I agree with the previous commenters: it's time to put forth proposals that are priced to move—that is, they should be designed for broad appeal, making appropriate compromises as needed. To that end, we should avoid similar proposals, which can dilute support both for the set of similar proposals, and for all of them, once the total number hits a threshold that causes commenters to lose interest in the entire RfC process. isaacl (talk) 04:16, 25 October 2021 (UTC)

    I was originally going to withdraw 2A, but Nosebagbear's support seems to suggest that it's an idea that can have some merit and support.  – John M Wolfson (talk • contribs) 16:29, 25 October 2021 (UTC)

    Changing it into something you support (and others will too) is great. It seems like you'll be able to take advantage of the time before the launch to modify the proposal so it does that. Best, Barkeep49 (talk) 16:31, 25 October 2021 (UTC)

• I would certainly prefer it as a free-standing question (rather than the comments section proposed above, which is different enough to warrant its own choice). I considered offering a compromise of 72 hours, but again, the vast majority of votes are in the first 72 hours (let alone 96). Maybe anytime after the first 48 hours would work, but at that point we're nearing the whole week. If John feels that the last 24 is an inherent point of his proposal, do others think I should make a "full week" equivalent - I'll happily !vote for both 1st/2nd choice, which works well enough for ACE !votes. Nosebagbear (talk) 09:10, 25 October 2021 (UTC)
  • I do insist on waiting at least 48 hours into it, but am willing to compromise to that effect.  – John M Wolfson (talk • contribs) 14:11, 25 October 2021 (UTC)
    • It seems to me that 2A may be better changed to "48 hours into an RfA", in which case I might omit my suggestion in the spirit of not diluting support (since I don't think anyone has expressed that they would support the "comments section" but not the "generic question"). — Bilorv (talk) 16:45, 25 October 2021 (UTC)
      • I have so changed the question.  – John M Wolfson (talk • contribs) 16:57, 25 October 2021 (UTC)
        • Amazing, much appreciated. — Bilorv (talk) 19:20, 25 October 2021 (UTC)
• Huh. During the brainstorming, I must have missed the opportunity to say "This is practically unnecessary; the candidate can ask up to two questions to themselves anyway". I did that at my RfA, Q4 was mine. I had also deliberately kept the second question in hand to respond to possible concerns. ~ ToBeFree (talk) 18:47, 26 October 2021 (UTC)
  • Wow, I don't think I noticed that was you asking yourself a question at the time. In any case, it's not normalised for candidates to ask themselves questions to respond to issues raised during the RfA, is it? You may have planned a question for that eventuality, but I don't think I've ever actually seen someone do that, and I wonder if it would be controversial if someone did try that. — Bilorv (talk) 19:12, 26 October 2021 (UTC)

8A issue

One issue with 8A is that if there are a lot of proposed RFAs that should not pass, editors interested in participating may run out of opposes, potentially leading to a not now RFA passing through this processJackattack1597 (talk) 00:13, 25 October 2021 (UTC)

• That runs into what is the bigger issue; editors who oppose every single RfA on principle, whom many people seem to think exist but whom I have yet to see since at least 2019, or too many subpar candidates exhausting any oppose limit. I think a solution may be simply to insist that every oppose be tied to a specific reason, but that leads to definitional/enforcement issues.  – John M Wolfson (talk • contribs) 00:58, 25 October 2021 (UTC)

  What if you just removed the oppose limit to the proposed adminship process, and anyone who disruptively opposed all proposed RFAs on principle could just be dealt with via normal means. Jackattack1597 (talk) 21:10, 25 October 2021 (UTC)

  I wouldn't oppose a rule stating that all opposes had to be specific to the given RfA and be "reasonable", but as said earlier there might not be consensus for that.  – John M Wolfson (talk • contribs) 21:15, 25 October 2021 (UTC)

• @John M Wolfson: - is there a reason your proposal has both a "within 48 hours" and a "anytime in the future" option? Is the effect purely that in effect there will be a logged failed (prod)RfA with the second option whereas the first overwrites it? Nosebagbear (talk) 10:33, 25 October 2021 (UTC)
  • @Nosebagbear: Say, for example, that the PROD RfA has reached 15 objections. The candidate then has the choice to start a regular RfA right then and there, making that decision within 48 hours; if they don't, they have the right to start a fresh new RfA at any time in the future. So essentially, yes, that is the main effective difference.  – John M Wolfson (talk • contribs) 14:09, 25 October 2021 (UTC)
• This seems like a non-starter to me, lack of a fixed number explicit opposes doesn't equate to an actual showing of community support for someone. Also this is rather far from the common "PROD" process - in which any single opposer can stop the process, even after the fact (speedy restorations are granted for expired prods). — xaosflux ^Talk 23:43, 25 October 2021 (UTC)
• The limit on the number of opposes an editor has in a month is going to be problematic. I do not think most editors are reflective opposes, and if it becomes a problem, that could be fixed later. --Enos733 (talk) 00:56, 26 October 2021 (UTC)
• This is really asking to be gamed. Want the bit but have a lot of skeletons in your closet? Wait for a month with a few contentious PRODRfAs, then throw yours in at the end when almost everyone has used their one oppose. – Joe (talk) 13:03, 28 October 2021 (UTC)

6a issue

I think there could be some traction in 6a, however the requiring preapproval by 'crats to use that will likely sink it (and require another entire bureaucratic process) - perhaps that could just be something they put in their RfA statement if they want to volunteer for such - the !voters would be able to discuss if it was something useless. What would be needed would be that this RfC component would need to actually change the policy to require this is binding, and empower the 'crats to act upon it in the future (and probably should specifically state that anyone recalled in this manner that wishes to regain access in the future may only do so via the same process any new admin candidate would use). — xaosflux ^Talk 00:21, 25 October 2021 (UTC)

I'm rusty with RfA stuff, but isn't there a problem that, if a candidate says "the kind of adminship I want is X", then they're likely to get opposes along the lines of "candidate made a poor choice of what they're running for" ... on top of whatever else the candidate is being opposed for? If we let people run for something other than the standard adminship at RfA, it might be safer to offer only one alternative that would work for a wide range of candidates ... say, a standard fixed length of time as an admin. - Dank (push to talk) 00:38, 25 October 2021 (UTC)

@Dank: 6a is only about Binding recall criteria is that what you are referring to? — xaosflux ^Talk 00:47, 25 October 2021 (UTC)

I'm basically making one point, but it applies equally to 6a and 7a I think, and it's roughly the same point that you're making below: "it may increase RfA opposes against candidates that do not 'opt-in' to this new feature". When candidates are perceived to have a choice in what they're signing up for ... what tools they have, when they can be recalled, whatever ... then my recollection from years ago is that that tended to generate additional opposes along the lines of "I believe the candidate made the wrong choice". So, there may be a cost to giving candidates too many choices. - Dank (push to talk) 01:38, 25 October 2021 (UTC)

Barkeep, FWIW, I've decided not to offer this proposal. (I'm letting you know so that you won't hold anything open until the 7th on my account.) - Dank (push to talk) 20:45, 28 October 2021 (UTC)

Thanks for letting me know @Dank. Best, Barkeep49 (talk) 20:54, 28 October 2021 (UTC)

This is actually already the case: candidates attract opposition each for setting their own recall criteria ("waste of time, it's not binding") and for not doing so. However, it is not many people who oppose for such reasons. In the long term—RfAs happening a year after the new feature is added—I do not believe 6A passing would lead to much additional discourse or opposition at RfAs. With 7A, however, this is one of my most major concerns: that people running for "full" RfA would then have to justify the use of each and every gizmo they get given. — Bilorv (talk) 09:55, 25 October 2021 (UTC)

I think 6A can already be done via informal channels, and doesn't require any formal sanction/approval.  – John M Wolfson (talk • contribs) 00:59, 25 October 2021 (UTC)

@John M Wolfson: I am quite certain that at least some bureaucrats would refuse to process a desysop request spawning from a recall petition if there is an objection of the subject of said petition. And if the recall led to a "resignation" at least some 'crats may not see that as a "cloud" in the future. — xaosflux ^Talk 01:05, 25 October 2021 (UTC)

If the proposal is to formalize against that then I fully support it.  – John M Wolfson (talk • contribs) 01:07, 25 October 2021 (UTC)

@John M Wolfson: precisely my intention with the proposal is to formalise against the non-binding nature of recall; a candidate currently has no way to set binding recall conditions, so voters have no reason to take them seriously. Indeed, some people oppose if you set recall criteria, because they see you as making a promise you cannot commit to. — Bilorv (talk) 09:55, 25 October 2021 (UTC)

I certainly believe some crats would refuse to press a button that they disagreed with. That is as it should be, we're all volunteers after all. If this were to pass perhaps there would be a "crat willing to accept binding recall" category/userbox or some other way for crats who were willing to do it to indicate themselves. I find it hard to believe that crats, however, would not respect the community will and, as you seem to suggest Xaos, choose to flat out ignore policy/procedure which had community consensus. Best, Barkeep49 (talk) 01:53, 25 October 2021 (UTC)

As discussed earlier this year archived at Wikipedia talk:Requests for adminship/Archive 259 § Recall magically grows teeth, until the administrators policy is amended to include the concept of recall criteria, bureaucrats have no guiding policy to enforce. It could be argued that support for this proposal is tantamount to approval to change the administrators policy, but it can also be argued (as it was in that discussion) that policy changes should be explicitly proposed, not something that falls out of a discussion on procedural changes. As I said in the previous discussion, the community has a long tradition of examining context for situations. There can be valid reasons to decide that the outcome of a recall process didn't adequately reflect community sentiment, such as a voting-based recall procedure getting vote-stacked by new editors. Admin candidates can pledge not to perform tasks in a given area, and later decide that the area is suitable for them after all. I'm not against the idea of having a binding recall procedure, but to-date the community doesn't support one without first reaching a consensus to update the administrators policy. isaacl (talk) 04:38, 25 October 2021 (UTC)

@Barkeep49: I think it is more of an single issue consensus vs policy problem, if this RfC empowered that action I don't think there would be problems - I'm only referring to a scenario where this sort of guidance is absent. I certainly wouldn't have a problem considering recall as a means to desysop should that be added to the policy. — xaosflux ^Talk 12:43, 25 October 2021 (UTC)

Outside the notes above, this could have an unintended side effect that should be considered: it may increase RfA opposes against candidates that do not 'opt-in' to this new feature. — xaosflux ^Talk 01:06, 25 October 2021 (UTC)

@Xaosflux: I'm more than happy to adapt/remove the "preapproval by crats" condition if that will get this proposal more support, but let me explain my thinking. For recall criteria to be binding, someone other than the candidate needs to enforce them. Since the crats take the bit away, the easiest solution (that will gather the most support) is for the recall criteria to be objective enough that a crat can always uncontroversially assess whether they are met. However, it's easy to imagine criteria that are not sufficiently objective, such as recall petitions that must be "for a specific incident that there has not been a past petition for", or in which participants must "not be INVOLVED", "not be canvassed", or even "a user I highly respect". (These are not quotes from, but based on, past/current admins' actual recall criteria.)

I don't think the crats will agree to litigate whether participants are INVOLVED or whether a recall petition is over a sufficiently new incident. As such, the crats need to decide whether they will enforce the criteria. Given this, they need to do so before the RfA (or voters don't have the right information to decide). It makes no odds to me whether such a procedure is private or public, or even made public after the RfA is announced, but since the vast majority of candidates prefer to keep their RfA plans a total secret until running, I figured private would gather the most support. If you want a public decision at WP:BN, maybe even decided unilaterally by the first crat to review it, I'm willing to change it to that.

I see two alternatives to preapproval by crats: (1) the community establish a bunch of cookie cutter recall criteria to choose from, like "adminship will be removed x years after my RfA is closed as successful"; (2) voters litigate during the RfA itself whether the criteria are enforceable, and it must be by community consensus at ANI that it is decided whether recall criteria are met, as crats have not agreed to enforce them. (Very toxic option that will add another vector of opposition at RfAs.)

With the minutiae, I was considering adding "to claim a desysop under recall criteria, anybody may make a post to WP:BN explaining how the criteria are met, and any uninvolved crat can check if the criteria are met and remove the bit. Someone with adminship removed under this process is treated functionally as an admin who resigned under a cloud." However, it's too much obvious detail and we can save it for if the proposal is actually implemented. — Bilorv (talk) 09:55, 25 October 2021 (UTC)

@Bilorv ideas which gain consensus here need to be substantially ready for implementation with no further RfCs necessary for implementation. Larger changes are, by their nature, going to need more detail than smaller changes to meet this requirement. Best, Barkeep49 (talk) 15:45, 25 October 2021 (UTC)

@Barkeep49: yes, I did read that rubric, but I felt my proposal leaves no questions big enough that you'd need an RfC, or encounter any controversy. If you feel the proposal could not be implemented immediately if approved then please either update it based on my comment about the minutiae here, or ask any questions you feel are not answered. The alternatives to preapproval by crats are not part of my current proposal, but things I would be willing to change before we launch on Halloween if discussion here indicated that they might gather more support. — Bilorv (talk) 16:40, 25 October 2021 (UTC)

When I first read the idea I didn't see anything incomplete with it (unlike the idea below) but since you identified areas as incomplete I did want to note the "needs to be ready to go" requirement. Best, Barkeep49 (talk) 18:18, 25 October 2021 (UTC)

@Barkeep49: after further thought, I've added a bit of the minutiae, particularly as someone wanted the same clarification about regaining adminship for 6B. I'm now exceeding your desired 1-3 sentences rubric a bit, but I don't want to segregate this in a subpage somewhere because it should be short enough for everyone to read before !voting on it. — Bilorv (talk) 22:38, 25 October 2021 (UTC)

Yes the length has proved a challenge widely. See my section below. Best, Barkeep49 (talk) 01:18, 26 October 2021 (UTC)

ArbCom already handles regular desysops and makes the kind of difficult decisions that this could involve. Are there any obstacles to asking them to be the arbiters instead? (And actually, I think it should be possible to use ArbCom for this already. Surely breaking a recall pledge could be seen as a major breach of community trust.)

@Barkeep49: do you have any thoughts on this? Mainly about whether ArbCom might be willing to do some version of this in general, but I'm also curious whether it might already agree to hear a case (or pass a motion, if it's unambiguous) for desysopping a hypothetical candidate who made an RfA pledge to be recalled by ArbCom, maybe something like If criteria XYZ are met, I want ArbCom to desysop me for cause. Sunrise (talk) 03:07, 3 November 2021 (UTC)

I'm pretty reluctant to speak for myself about this outside of an appropriate ArbCom forum let alone the committee as a whole. If you are curious you could certainly try a place like WP:ACN which isn't really ideal for this but I don't know that we have any place designed for this. Best, Barkeep49 (talk) 15:14, 3 November 2021 (UTC)

Perfectly understandable. :-) I just thought I'd ask since it came to mind while reading the oppose comments on 6a. Now that I've presented the idea, I will assume it's been seen by those who are more involved in RfA reform than myself. Sunrise (talk) 23:01, 3 November 2021 (UTC)

4a criteria

Going to make a "4a Opt-out sortition to nominate candidates" section, but I don't know what the criteria should be. Does "10,000 edits (userspace/sandbox doesn't count), 2 years of active editing, no blocks in last 5 years, no active restrictions, and at least 1 published article" work? –MJL ‐Talk‐^☖ 01:34, 25 October 2021 (UTC)

Depends which you're aiming for: filtering out most people who would be unsuccessful, or including most people who would be successful. Rather than "at least 1 published article", how about "at least one GA/FA/FL, or 10 created articles"? That fits better with what people who want "content creation" commonly set standards at. You maybe also want "has not run for RfA before". People may oppose over 2 years of editing being too low, especially given how fresh Eostrix/Icewhiz's RfA is. — Bilorv (talk) 10:01, 25 October 2021 (UTC)

Bilorv raises a good "what are your priorities" point. One concern to factor in, @MJL: is that if people accept your criteria, you may end up accidentally raising them. Blablubbs, for example, passed with flying colours on a tenure much shorter than two years (16 months). But I would suggest either "5 articles" or "1 GA (or higher)" on the content side. So, tl;dr, reduce your tenure to 18 months of active editing, but up your content creation somewhat. Nosebagbear (talk) 10:36, 25 October 2021 (UTC)

@Bilorv and Nosebagbear: I guess my priority is to filter out anyone who would obviously be unsuccessful. I suppose the best criteria would be: "(A) 10,000 edits (userspace/sandbox doesn't count), (B) 2 years of active editing, (C) no blocks in last 5 years, (D) no active restrictions, (E) at least (1) one GA/FA/FL (2) or 5 created (non-stub) articles, and (F) has not run for RfA before."

I think 2 years is the safest bet as Blablubbs may be considered an out-lier. –MJL ‐Talk‐^☖ 20:25, 27 October 2021 (UTC)

Yep, I like that. I think Nosebagbear hints at the only possible downside—in the future, people may feel they need to be in the sortition to make it at RfA, rather than nominating themselves outside the process. But I don't see this outweighing the advantages, and in a sense it's not the sortition's fault if opposers who would have too high standards anyway start using that as their reasoning.

On the logistics, if we want this roughly ready to go if it passes, then I'd maybe start picking thresholds of how many people you want called up for duty how often, how much advance notice you're giving (some time for people to find nominators, perhaps), and so on. — Bilorv (talk) 20:31, 27 October 2021 (UTC)

I would want to see at least 10 users per year go through the sortition (regardless of outcome), and I want to make sure that every batch of sorted candidates comes in sets of at least 3-4. I think the best way to accomplish that would be to have 5 sorted candidates selected every 4 months ("the drawing") with a week's time for a final opt-out.

We would likely see a class of advocates who get assigned each individual candidate just to serve as someone to help shepard the process along and mitigate any potentially bad experiences. Since there is nothing stopping a candidate from just completely ignoring this process (that's a fine thing to do in my opinion), the advocate will always be there to make the case to voters or explain how the process works as needed. I don't see this part as necessarily much of a policy though; just kind users saying nice things maybe.

To prevent gaming, I would suggest that the sortition list of eligible candidates have a month proceeding the drawing where it is held for review by functionaries. If someone was added when compared to the previous list, it would have to be manually verified that they meet the eligibility criteria. From there, it's basically voluntary jury duty. –MJL ‐Talk‐^☖ 21:08, 27 October 2021 (UTC)

I'd probably agree with Nosebagbear that 2 years is a bit high: in addition to Blabblubs, we've also seen Hog Farm, Ashleyyoursmile, and Less Unless pass (and by very wide margins) with less than 24 months (sometimes substantially less: Hog Farm was at 14 months) just this year alone. The community's tenure requirement seems to be lower than most people realize. In my view, 18 months would be reasonable, particularly since you've added a content creation requirement. (I love this idea, by the way.) Extraordinary Writ (talk) 20:42, 27 October 2021 (UTC)

I still think those are the exceptions, rather than the rule, especially in 2020-2021 where (generally) only slam-dunk people ran, and my comments re sensitivity and specificity still apply.  – John M Wolfson (talk • contribs) 20:44, 27 October 2021 (UTC)

Well, these are 4 of the 7 successful candidates this year, i.e. a majority. I agree regarding specificity and sensitivity, but if the community considers candidates to be slam-dunkers at 18 months, perhaps excluding them would be more sensitive than necessary. (Of course, that's not considering the Eostrix incident: perhaps that will drive up the tenure requirement significantly.) Another note: might some sort of AfD requirement (e.g. !voted in at least 25/50/100 AfDs) be useful? It's an objective metric, and the community seems to frown on candidates who don't have at least some experience there. Extraordinary Writ (talk) 20:52, 27 October 2021 (UTC)

You mean more specific than necessary, in this context *cough cough*. Would 20 months be a good compromise? I'd also like to see some AfD work, how about at least 10 AfD participations and at least a 75% match-with-result rate? You can certainly get by at RfA without it, but it's a good benchmark for adminabili as a ubiquitous admin-centric process that non-admins can partake in, and if this process does unfortunately ultimately raise people's standards it would be good to at least incentivize people to do more AfD stuff.  – John M Wolfson (talk • contribs) 21:05, 27 October 2021 (UTC)

I'm fine with 20 months, but I would object to AfD participation needing to match the result-rate. IMO, that metric always encourages people to try and "win" AfDs by guessing what the result will be rather than try and legitimately participate in the discussion. –MJL ‐Talk‐^☖ 21:14, 27 October 2021 (UTC)

I guess we don't have to do pass rate; how about 50 discussions, which would hardly be onerous for 20 months?  – John M Wolfson (talk • contribs) 21:23, 27 October 2021 (UTC)

It may be helpful to generate the lists based on various criteria and examine some of the editors in question in order to get an idea of the suitability of the criteria. isaacl (talk) 22:14, 27 October 2021 (UTC)

How about 35? 50 seems a little daunting to me. –MJL ‐Talk‐^☖ 05:24, 28 October 2021 (UTC)

I think specificity (i.e., "select out" for undesirables) is more important than sensitivity (i.e., "select in" for desirables), especially if this is opt out and not opt in, and especially if this is a supplement, rather than replacement, for standard RfA.  – John M Wolfson (talk • contribs) 20:36, 27 October 2021 (UTC)

• At the very least, I'd want any candidate passing RfA to actively "accept" the results of their own forced RfA - even if it is only at the end of successful ones - see any issues with that? — xaosflux ^Talk 22:52, 27 October 2021 (UTC)
  • There is no need to be negative and cynical with the "forced" language. In any event, I do at least support letting the candidate withdraw the RfA at any point, and if I'm not mistaken there's a two-week gap between selection and the actual RfA for acceptance and advocate/"nominator" recruitment; I don't know if acceptance at the very end is necessary in light of those.  – John M Wolfson (talk • contribs) 23:02, 27 October 2021 (UTC)
    • @John M Wolfson: so for example, this process could promote someone even if they are on a wikibreak for the entire duration of the process? — xaosflux ^Talk 23:08, 27 October 2021 (UTC)
      • If I'm not mistaken, acceptance would occur at the time of selection. This isn't my idea, however, so @MJL: might be able to better address these concerns.  – John M Wolfson (talk • contribs) 23:09, 27 October 2021 (UTC)
        • Thanks, it looks like a goal was to not have to have them accept at the beginning either? — xaosflux ^Talk 23:14, 27 October 2021 (UTC)
      • I was assuming the "active" requirement means we wouldn't be selecting someone on a wikibreak. Possibly worth clarifying what that "active" criterion is. I agree that somewhere along the line, the user should be saying "I'm happy to be an admin" before you flip the bit (although I have to say we don't actually do this with other advanced rights—I was given Rollback without asking and we see it with Autopatrolled a lot). — Bilorv (talk) 23:30, 27 October 2021 (UTC)
• Regarding RFA then goes on like normal without [sic] or without the candidate present with the advocate playing the role of nominator. - assuming the first without is supposed to be "with", would this mean that for situations "without" them present we would expect all questions posed to go unanswered? If so, is there some sort of expectation that any opposers along the line of (Didn't answer my question #n) have normal weight in determining the outcome still? — xaosflux ^Talk 23:14, 27 October 2021 (UTC)
  • I don't see why that wouldn't be the case—"I'm concerned about this and the candidate hasn't addressed this concern" works equally well if the candidate is not there at all. — Bilorv (talk) 23:30, 27 October 2021 (UTC)

    @Xaosflux, Bilorv, and John M Wolfson: The "active" part just means a demonstrated history of semi-regularly editing. The way I envisioned this, a candidate theoretically could get the bit while on Wikibreak. I can't imagine opposition based off a lack of question-answering would therefore cary much weight (though, I'm sure people would still comment to that effect).

    Honestly, besides question-answering, it's not like a given candidate in the current RFA really does much besides accept the nomination. Users who try to do more than that generally end up shooting themselves in the foot anyways. The less opportunity an otherwise competent candidate has to ruin their own RFA, the better if you ask me.

    I have to imagine it would be ideal to get the candidate's acceptance at some point after the nomination already succeeds before the technical right is given to them. If we never hear from them about it (before the next drawing starts), then we'd have to assume that it means they decline. –MJL ‐Talk‐^☖ 05:13, 28 October 2021 (UTC)

    • @MJL: I'd want to see some sort of 'acceptance' required, as at the very least that the candidate will now be subject to things like WP:SECUREADMIN and WP:ADMINCOND - this could be at any point in the process. I'm not sure what may come of being absent for questions, it will likely come up in the RfC so mostly wanted to give a caution that more definition about it could be needed. I think I might be missing some of the point of this one though - because other than maybe the acceptance part being later, can't this all happen using the current framework? If that is the only thing different, keep the proposal simple and it may get traction. — xaosflux ^Talk 10:37, 28 October 2021 (UTC)

@Xaosflux: I mean, yes. The proposal is not so fundamentally revolutionary that it changes the underlying structure of RFA.
It's just a new method of getting candidates, but with that comes a few weird caveats like the questions thing. I have to imagine candidate statements wouldn't always be present either. –MJL ‐Talk‐^☖ 00:03, 31 October 2021 (UTC)

I think it might be good if the criteria included that the editor in question doesn't generally opt out of adminship, e.g. people with {{User wikipedia/Anti-Administrator}} on their user page. – Rummskartoffel 15:42, 31 October 2021 (UTC)

7a components

@ProcrastinatingReader: I'm in general support of this, and have experience dealing with it at meta-wiki where it is very low-drama. I don't know how much actual utility it would actually have - but don't think that is necessarily a reason to not do it. I'll put forth some considerations that might make this more palatable, take them or leave them (I'm not trying to start a full discussion or debate here - just recalling items that may quickly derail the proposal if they are ambiguous): (a) Specify that IAR tool use isn't really tolerable here; (2) don't require arbcom to deal with violations (it is always an option of course) - either leave it to 'crat discretion and/or an WP:AN discussion to answer the one question "Did user x use the admin toolset in excess of their agreed limitation?" for removal (we have some precedent for this type of process in WP:GRP already; (3) require that these are always time limited (suggest from 1 month to 1 year, requester can pick what is needed) - renewable with the same process or by 'upgrading' via RfA. Not stated, but not require building any special technical controls to enforce the limits - this would only be limited by "administrative controls" (i.e. policy) - no specific policing mechanism would be required, but any editor is open to police the actions. Again, please just take this note as some general guidance and feel free to ignore at this phase - I've seen a lot of potential proposals get derailed by unresolved ambiguity. — xaosflux ^Talk 13:34, 25 October 2021 (UTC)

I'd just like to +1 Xaos' ideas, especially regarding a mechanism short of needing ArbCom and, especially, the 1 month-1 year timelimit. I've no doubt that we could find cases where a limited-use admin IARred and we all agreed it was the right call. Instead it's better off just being treated like one of the admin/functionary border zones where we treat IAR as effectively non-existent, but are aware that the rarest of rare IARs may still come along. Nosebagbear (talk) 13:52, 25 October 2021 (UTC)

Perhaps "discouraged" vs "not tolerated" on that part. — xaosflux ^Talk 13:56, 25 October 2021 (UTC)

Thanks for these thoughts.

1. IMO, a limited admin shouldn't use their perms out of scope, regardless of situation. Though, it seems worth noting that explicitly writing "this point cannot be IAR'd" seems a bit circular, as no policy has language like that (incl the CU example by Nosebagbear above).
2. My only concern is that anything of that sort would create a new un-+sysop process. Bureaucrats currently only make discretionary determinations at the time of sysopping, and AN discussions cannot remove the bit, and if it were allowed we might have questions like "who closes the AN discussion, how much support is needed to call it a consensus, will it be vote-y" and all the other issues of desysopping proposals. That said, I recognise both intadmin and EFM have general "noticeboard consensus" removal clauses without specifics and those work fine, so I suppose that could work too. I'm not sure, to be honest, but I think it is simpler to stick to ArbCom only for the initial proposal.
3. I think this is a good idea, especially as it would provide scope to do a 'full RfA' at some point (as happened in some metawiki examples)
4. Good idea as well.

ProcrastinatingReader (talk) 22:49, 25 October 2021 (UTC)

In fairness, writing a policy that "can't be IAR'd", except for when the WMF/outside legal system does it, would be like the British Parliament arrogating itself the right to bind future parliaments; it leads to a contradiction and is thus impermissible.  – John M Wolfson (talk • contribs) 22:56, 25 October 2021 (UTC)

This is mostly why I tried to avoid the issue entirely. A stern "it's misuse and you will be desysopped" is all that's needed, I think, and IAR will work itself out as it always does. This is actually why I lean towards the lightweight revocation process that xaos floated as it gives the community a chance to work out the issues and build further checks through the development of de facto consensus. I'm fine leaving it to ArbCom, but I don't think the crat/noticeboard clause will be a major sticking point. I don't think it's so vague that we can't work it out later. — Wug·a·po·des​ 23:43, 25 October 2021 (UTC)

Just playing devil's advocate: Bureaucrats have never had a role in removal of permissions, except rubber stamping decisions by the Arbitration Committee. This is a meaningful expansion of their role, as presumably (especially in close cases) they'll have to make the call on whether there is consensus or not. There's (apparently, according to WP:DESYSOP2021) some debate to be had about AN's effectiveness in permission revocation, although much of that debate seems to be around admins making contentious actions, but I don't imagine a limited admin would ever find themselves in that position, since there's not much scope for making contentious decisions. ProcrastinatingReader (talk) 11:30, 26 October 2021 (UTC)

We routinely remove permissions of sysop and iadmin for inactivity (fairly uncontroversial - but has nothing to do with ArbCom). A stop-gap period was used when we bootstrapped the iadmins as well, allowing for 'crat discretionary removal - with appeal at BN (Special:PermaLink/856641107#Stop-gap_users_nominated). — xaosflux ^Talk 17:17, 26 October 2021 (UTC)

I say we have it that any uninvolved administrator, not necessarily a 'crat, may decide whether consensus exist at the relevant discussion, and the bureaucrat's only role is to execute that decision; the bureaucrat should not be the same as the closer.  – John M Wolfson (talk • contribs) 16:50, 26 October 2021 (UTC) (EDIT: Crap, I thought this was 6B, but my exact statement still applies lmao.  – John M Wolfson (talk • contribs) 16:52, 26 October 2021 (UTC))

@John M Wolfson: I'm confused. At 6B, the consensus is decided by three uninvolved admins, and the bureaucrats' only role is to push the de-admin button, as you suggested. — Bilorv (talk) 17:18, 26 October 2021 (UTC)

Yes, I had misunderstood to the contrary since I thought this was 6B. I still think that an uninvolved admin can make the decisions for 7A, however.  – John M Wolfson (talk • contribs) 17:52, 26 October 2021 (UTC)

Solutions that fit in more than one box

Are we planning to have "See Also" for solutions that fit in more than one box - Repeating seems like a bad idea. Worm^TT(talk) 14:19, 25 October 2021 (UTC)

To be clear, I've dropped something in at 2B. It can be moved, altered, etc. Worm^TT(talk) 14:42, 25 October 2021 (UTC)

Hi @Worm That Turned it feels like admin elections really belong under issue 8 - routes other than RfA. But I don't think the proposal is quite detailed enough yet - to use the wording I chose for the page it is not substantially ready for implementation. Questions I would suggest need answering include: how often would the elections run, who would be responsible for running the elections, how long would the short period be (3 days is tentatively offered now but I think a definitive time would be necessary for implementation), who is eligible to vote, and what would a successful percentage be. There are other questions that I have which I wouldn't necessarily say are necessary for implementation with the "biggest" of these "small" questions being how would these be watchlisted (edit: advertised) (I presume in ways identical to RfA now but maybe it would actually be in ways identical to ACE?) and when would the deadline be for signing up to be in an election. I don't know these would be necessary for this RfC exactly, but the goal with this process is to have whatever gains consensus after this ready to go, with little further discussion required. Given the level of this change, this might be a proposal which will have a 1-3 sentence summary and then a subpage which will offer more details for those interested. Best, Barkeep49 (talk) 15:43, 25 October 2021 (UTC)

I was trying to keep it short - though I think it may well be something that would work on a sub-page. I was also trying to focus it in an area where it would have a massive positive effect (scrutiny) but also had more consensus! Perhaps I'm trying to tip the scales. I'll think about how best to manage it over the next few days, and as I say, not precious, if anyone wants to take the idea and run, I'm happy to help :) Worm^TT(talk) 15:53, 25 October 2021 (UTC)

People can certainly mention ways their ideas addresses other issues than the one its under but unlike brainstorming, in an attempt to provide some clarity and ease of organization for !voters, people are being asked to put it under the main idea it addresses. I have duplicated some wording from the main section in the instructions for those proposing ideas. Best, Barkeep49 (talk) 14:44, 25 October 2021 (UTC)

I have moved the admin election idea to Issue 8 (8B, to be specific). Since it proposes an entirely new, radically different method of sysopping from current RfA, it belongs in the issue detailing that current RfA should not be the only way to become an admin.  – John M Wolfson (talk • contribs) 16:27, 25 October 2021 (UTC)

6B

Hello! I'm wondering whether I could edit 6B to include the option to also have consensus at AN(I) to have an admin go through a reconfirmation RfA. I think this would fit better as part of 6B than as another question. Responses could be yes/no, with "yes" !voters asked to clarify if they want AN(I) consensus to have power to deadmin, run a reconfirmation RfA, or both. Tol (talk | contribs) @ 21:24, 25 October 2021 (UTC)

• I would presume that all ANI desysoppings would be "under a cloud" and thus as a matter of course require a resysoping process.  – John M Wolfson (talk • contribs) 21:28, 25 October 2021 (UTC)
• Cloud determinations are always backwards looking, I'd suggest this specifically codify that the subject may only regain administrator access via the standard process for non-admins so there is no question down the road. — xaosflux ^Talk 21:31, 25 October 2021 (UTC)
  • I've made an edit to implement this that close paraphrases you a little, Xaosflux, hope you don't mind. Feel free to adapt the wording if it can be improved. — Bilorv (talk) 22:38, 25 October 2021 (UTC)
• Courtesy ping to Bilorv who wrote that proposal. Best, Barkeep49 (talk) 22:19, 25 October 2021 (UTC)
• @Tol: I've got a few logistical questions about reconfirmation RfAs. Is an admin desysopped before the beginning of the reconfirmation RfA, or do they keep the tools until the result? What time period are they given to create the RfA (presumably they need some time to answer the three standard questions)? If they refuse to participate in the reconfirmation RfA, what happens? Is the RfA self-nominated or can they get nominators? Does the RfA need consensus to de-admin, or consensus to bestow adminship (there's been historic dispute over this in past "reconfirmation RfAs" where users stood for RfA while currently being admins)?
  I think the process is maybe involved enough to separate into a 6C, though I would support both (as both could be useful in different cases). Someone may oppose this reconfirmation option (e.g. "too bureaucratic") but support the on-the-spot desysop option, or support reconfirmation and oppose AN(I) desysops (e.g. "AN(I) is not a good sample of the community like RfA is"). Reconfirmation RfAs also have a lot of historical context and connotations that my proposal may not. — Bilorv (talk) 22:38, 25 October 2021 (UTC)

  @Bilorv: Good questions, all of which should probably be left to the community to fiddle with. Personally, I would think that administrators subjected to a reconfirmation RfA in this method:

  • would keep the tools through the RfA until its close;
  • would be given a week to answer the questions;
  • would be allowed to find nominators within that week;
  • would be forced to undergo the reconfirmation RfA, and could leave the questions blank and/or not submit a statement at his/her peril;
  • would probably need consensus to be de-adminned, not to be adminned (not necessarily the same percent guidelines or discretionary range as a regular RfA, and not 100% minus them either).

  I'll work on a draft proposal. Tol (talk | contribs) @ 01:29, 26 October 2021 (UTC)

  I think that sounds like a good proposal, but I agree that it should be 6C because it seems distinctly separate from 6B.Jackattack1597 (talk) 23:37, 26 October 2021 (UTC)

Just stopping by

There are some real interesting ones here. Looking forward to discussing them. Enterprisey (talk!) 00:17, 26 October 2021 (UTC)

Proposal lengths

When setting up this page I wrote proposals should have 1-3 sentences and to go subpages for proposals beyond that. The idea being that some proposals would require a lot of details but we need to make a page that is approachable for as many as possible. If someone opposes something in its basic format or supports it and is flexible about the details they could participate in that based just on this page. For those who want more information the details would be there. From the first proposal that wasn't my model, they have run longer than 1-3 sentences. So perhaps that length was not reasonable. However, we reach a length which is too long and does need to be a supage. Thoughts on where that balance point is? Best, Barkeep49 (talk) 01:17, 26 October 2021 (UTC)

• I'd say "a paragraph" (or maybe 1-3 paragraphs looking at 7A); of course, that could lead to really long "paragraphs", but I trust that people would intuit where the reasonable length is, and if they don't we can just play it by ear.  – John M Wolfson (talk • contribs) 01:21, 26 October 2021 (UTC)

  At some level it comes down to how many proposals we expect. Wordcounter.net says there are, on average, 100-200 words in a paragraph. If we take the middle of that range and say there will be 15 proposals is 2250 words a reasonable length to read? If there are 30 (as at brainstorming) is 4500 words reasonable? Contrast that with 15-20 words in a sentence (let's say 25 since these would be long sentences) and we get values that are half that big with a 3 sentence limit. Does the extra length justify the increased reading time for participants? Best, Barkeep49 (talk) 01:28, 26 October 2021 (UTC)

  That extra length will either be on the main page or in various subpages, which I think would be somewhat more difficult for people to navigate, especially if we don't redirect all their talkpages to this central talkpage.  – John M Wolfson (talk • contribs) 01:38, 26 October 2021 (UTC)

  I like the "short" top level, with a subpage for those interested. It's an old method that works (newspapers, clickbait). TLDR is a real thing. I'd put a hard limit of 150 words on any proposal on this page. Details can go elsewhere. Worm^TT(talk) 07:39, 26 October 2021 (UTC)

  Word limits rather than sentences makes sense for guidance. Thoughts about something like "Up to a 75 word summary plus 225 additional words of details in a collapsed box are permitted. Anything beyond that should be contained on a subpage"? This would hopefully allow editors to quickly read through ideas, would allow some level of details to be present on the page for those who want it, while still maintaining an overall reasonable cap. Best, Barkeep49 (talk) 15:11, 26 October 2021 (UTC)

  No issues from me on those numbers. Worm^TT(talk) 15:38, 26 October 2021 (UTC)

  75 seems a bit small to me. Fewer words doesn't mean quicker reading: for instance in 6A, the "Example" sentence in the first paragraph (plus the second paragraph) would have to be collapsed. However, it is intended to speed up processing time by giving concrete examples that stop the reader having to question "what does it mean, 'recall criteria'?" (humans learn fastest by examples, not definitions). — Bilorv (talk) 16:47, 26 October 2021 (UTC)

  Or 6A could be reformulated with the 75 words in mind. For example this is 74 words:

Reforumulated 6a

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

Details such as contacting the crats private, the criteria being public, binding, and unchangeable could all be in the collapsed box along with the parenthetical statement. As it stands now 2A, 5A and 6A are under 75 and all suggestions so far are under 300 words. Best, Barkeep49 (talk) 17:13, 26 October 2021 (UTC)

An improvement? — Bilorv (talk) 17:33, 26 October 2021 (UTC)

Update

Since the discussion above was mostly a mix of positive and I "could live with it" I have updated the proposal structure to a summary of up to 75 words and details of up to 225 words more. I plan to be fairly firm with the 75 and 300 word limits but also flexible if someone gives a summary of say 50 words and then has details of 250 words. Courtesy ping to proposers for revision: 7A ProcrastinatingReader, 8A John M Wolfson, and 8B Worm That Turned (also reminder that 8B needs more detail before launch). Best, Barkeep49 (talk) 15:16, 27 October 2021 (UTC)

@Barkeep49: what detail would you be looking for that is not in the subpage? Worm^TT(talk) 15:18, 27 October 2021 (UTC)

Apologies. I missed the link to the subpage @Worm That Turned. Best, Barkeep49 (talk) 15:21, 27 October 2021 (UTC)

Current revision of 7A was written by Wugapodes. I think they put it better than I, in case they're interested in doing the shortening too? ProcrastinatingReader (talk) 16:04, 27 October 2021 (UTC)

It's a collaborative effort. I've taken a first go at shortening it but anyone is free to keep going if they think it can be done better. — Wug·a·po·des​ 19:25, 27 October 2021 (UTC)

I converted it into the 75/225 structure. Also removed some prose relating to bureaucrat discretion (I would imagine crats would only desysop per AN consensus, not unilaterally, with a discussion required similar to WP:EFM & WP:IADMIN.). Reintroduced some prose trimmed, assuming it was only trimmed for character length, since it's within limits now I think. Don't necessarily mind re-trimming if there were non-length reasons to cut it down as well. ProcrastinatingReader (talk) 00:34, 28 October 2021 (UTC)

6C Permissions review

The idea here is to lower the stakes at RfA by providing a venue where admins can be held accountable in as constructive and depersonalised a way as possible. I have tried to come up with something simple that would be a middle ground between the free-for-all nature of AN/I, which is often said to generate "more heat than light" and peter out without resolution, and the all-or-nothing nature of arbitration cases, which is often said to be so highly charged that if an admin conduct case is accepted a desysop is a foregone conclusion. To do that I looked to existing processes like WP:DRV and WP:MRV which have proved themselves effective and relatively drama-free.

By focusing on discrete actions, rather than the person that performed them per se, and on reaching a consensus on the facts, rather than worrying about blame or consequences, the barrier for reporting should be lowered, and admins should be more willing to genuinely engage instead of seeing it as a battle for their bit. Hopefully this should lead to minor problems being spotted early and corrected, meaning in turn that RfA voters can worry less about them. At the same time, serious problems of repeated admin misconduct will be easier to bring to ANI or arbitration, because there will be record of clearly-closed discussions to refer back to.

By opening the process up to all permissions, not just admin ones, we get the additional benefit of giving RfA voters another solid source information to go on (does the candidate have a "clean PRV record", or have they at least corrected any not endorsed patterns?). It also helps to close the perceptual gap between "big deal" permissions like +sysop and the lesser ones handed out at WP:PERM. – Joe (talk) 12:56, 28 October 2021 (UTC)

I was on holiday and missed the "brainstorming" phase, by the way, so any suggested improvements before the 31st would be greatly appreciated. – Joe (talk) 13:05, 28 October 2021 (UTC)

If this were brainstorming, I would be saying that a "Permission" review is very different to Deletion or move review, because removing a permission is a personal criticism, while overturning a decision is simply about a difference of opinion. The community cannot decide on a method to remove permissions without drama, because the personal criticism hurts, and simply modelling it on a less controversial system doesn't make it less controversial. Indeed - if we were brainstorming, I might recommend creating an XRV - a "General review", where any admin decision can be reviewed, keeping it low drama and away from ANI, but equally reducing the high stakes atmosphere. Perhaps something to think about in the future. Worm^TT(talk) 13:27, 28 October 2021 (UTC)

Yes that is a deliberate choice: PRV would not review a person's overall use of a tool, and not decide whether a permission should be removed. Only individual actions or at most small related groups of them; the same way that a DRV can never result in an admin losing the bit, but a series of overturned deletions at DRV might lead to an ARC that results in them losing the bit. The "XRV" you describe is exactly what I was trying to propose with this. Is there anything I can do to make that clearer in the proposal? – Joe (talk) 13:33, 28 October 2021 (UTC)

Ah, in which case, I think it's a great idea. I'll have a little tweak if that's ok, feel free to revert Worm^TT(talk) 13:41, 28 October 2021 (UTC)

Thanks, looks good. Feel free to suggest other names too. "Permissions review" is blandly bureaucratic somewhat by design, but admittedly awkward, and XRV has a nice ring to it. – Joe (talk) 13:57, 28 October 2021 (UTC)

I was thinking "General decision review" or "Miscellaneous decision review", and XRV to match WP:XfD. Worm^TT(talk) 14:24, 28 October 2021 (UTC)

I think "Miscellaneous decision review/XRV" is the best option. If what's under review are specific actions rather than the permission generally, I worry that "Permission review" will prime people for more drama, not less. There's also the bonus of XRV fitting into the established pattern for review pages (though we'd want to add a hatnote at MRV to avoid confusion). — Wug·a·po·des​ 21:14, 28 October 2021 (UTC)

My only reservation with these is that it only makes sense to have a process like this for actions that involve an advanced permission and cannot be undone by anyone. A 'miscellaneous decision' like closing a discussion or issuing a warning template can just be reverted and discussed in the normal way. – Joe (talk) 21:29, 28 October 2021 (UTC)

What about "administrative review"/XRV? – Joe (talk) 21:34, 28 October 2021 (UTC)

Joe Roe My concern with "administrative" implies that the permission itself is under review. How about "Administrative action review/XRV". I'd really like to see a word to clarify the specificity of the review process - it's not a general one. Worm^TT(talk) 08:25, 1 November 2021 (UTC)

Yeah having slept on it "action" is the key word (and it's also plausibly abbreviated as X). So "Administrative action review", "Miscellaneous action review", or just "Action review", is good with me. Can always move it down the line. – Joe (talk) 08:46, 1 November 2021 (UTC)

Thumbs up from me on any of those - though I think you might want to alter it sooner rather than later (strike through should be fine @Barkeep49?) - we're still getting people who think it's a desysop proposal... Worm^TT(talk) 08:48, 1 November 2021 (UTC)

This feels a cosmetic change that could be done and noted appropriately in my view though I agree with sooner rather than later. Best, Barkeep49 (talk) 15:02, 1 November 2021 (UTC)

General Oversight of Decisions Barkeep49 (talk) 19:10, 28 October 2021 (UTC)

Or General Oversight Of Decisions —valereee (talk) 21:12, 31 October 2021 (UTC)

That sounds good to me. ~ ToBeFree (talk) 22:54, 31 October 2021 (UTC)

@Joe Roe and @Worm That Turned changing things once people have !voted poses challenges as I know you both know but since we're still in pre-launch mode obviously brainstorming can still occur. One question I have: if 6C passes will PRV be required to revoke a PERM or can that still be done on the initiative of an individual administrator? Best, Barkeep49 (talk) 19:13, 28 October 2021 (UTC)

My intention is to create a process that purely supplements existing ones, so in that sense no it shouldn't change. The policy would remain that PERMs are granted or revoked at "at administrators' discretion".

On the other hand, part of my thinking here is that we have never had a proper system for reviewing/revoking PERMs in the first place, so this would at least be a step towards also holding PERM-holders accountable. – Joe (talk) 19:31, 28 October 2021 (UTC)

• We used to call this RFCs. And they were so corrosive that we did away with them. Risker (talk) 23:12, 6 November 2021 (UTC)

  I honestly cannot see any resemblance between this proposal and WP:RFC/U beyond that they are both user conduct noticeboards (as are AN, ANI, AE, RFARB, COIN, DRV, etc). But since you're not the first person to bring it up, in case I was misremembering, I went back and looked at its archives. Of the 23 total RFC/Us held in its final years (2013–2014), only three concerned specific incidents (not long-term problems) and only two of those involved advanced permissions. One was basically a block appeal; the other a review of a page protection. These would now typically be handled on the user's talk page and RPP respectively (and would remain so if XRV is created) and the remaining 21 would be explicitly out of scope of XRV. I can only conclude that the people opposing on the supposed similarity are either misremembering what RFC/U was, or have not fully read or not understood what they are voting on. – Joe (talk) 15:04, 7 November 2021 (UTC)

I think the dispute resolution noticeboard is a better analogy - the important thing is to make it about the actions not the editors. Taking that as a starting point, the header at the top of the noticeboard could say: "This is an informal place to resolve small administrative disputes as part of maintenance. It may also be used as a tool to direct certain discussions to more appropriate forums, such as Administrators' noticeboard, the Dispute Resolution Noticeboard, or other venues. ... Noticeboards should not be a substitute for talk pages. Editors are expected to have had discussion on a talk page to work out the issues before coming to XRV." Ritchie333 ^{(talk) (cont)} 15:28, 10 November 2021 (UTC)

Observation

We have clear consensus that RfA is so unpleasant that candidates won't run, and we have clear consensus that this is a serious problem for our encyclopaedia. But in this RfA review process, we currently have no proposals at all in section 1, i.e. those that would constrain or restrict RfA participants from making the experience unpleasant. So to my eyes, all the proposals on the table at the moment --- worthy though some of them are --- aim wide of the mark.—S Marshall T/C 22:08, 29 October 2021 (UTC)

• The corrosive RfA atmosphere is probably more a product, rather than a cause, of the various factors dealt with in the other sections, so doesn't need to be directly addressed.  – John M Wolfson (talk • contribs) 22:25, 29 October 2021 (UTC)
  • I'll assert correlation more than causation. I contend RFA is a steep hurdle by necessity; RFA !voters have every reason to vet the candidate thoroughly and will always need to do so. The process does not have to be unpleasant for prepared candidates. I believe if softer entry-points (sponsorship/training) were available, the pool of potential admins would be larger, well-screened and more confident in their usefulness--better candidates. BusterD (talk) 19:59, 30 October 2021 (UTC)

I would like to point out that actually being an admin is a corrosive and hostile atmosphere. Frankly if RfA is scary to you then you are not going to be happy at the treatment you get when you actually act as an administrator. HighInBC ^{Need help? Just ask.} 01:13, 31 October 2021 (UTC)

That is not my experience as an admin. Best, Barkeep49 (talk) 01:28, 31 October 2021 (UTC)

Being an editor is being part of a corrosive and hostile atmosphere. Admins and non-admins are treated much more frequently with closed-minded contempt than with camaraderie, by those in the same group and the opposite one. Though the level of overt contempt varies from area to area, I do not believe it varies based on whether you are an admin (though the particular wording of rude comments will). RfA is one of the strangest areas of the site, where the calmness and positivity in some RfAs is juxtaposed by the sudden, random, arbitrary and extreme toxicity that breaks out in many others. — Bilorv (talk) 03:27, 31 October 2021 (UTC)

Proposals for better orientation and competence

I have left my two proposals 4B and 4C largely without detail, because I'm interested purely in the concepts of training and mentoring potential candidates, lowering the bar for entry but demanding demonstration of growth. I think if the community likes either of the concepts, they would prefer to flesh out and agree to such broad structures for themselves. I will be happy to discuss relevant topics. BusterD (talk) 20:11, 30 October 2021 (UTC)

@BusterD can you explain how community consensus is needed for either of those proposals? It seems both could just be done without needing anything more than willing editors to staff them. As such it seems like they should be moved here (with a pointer remaining from the main page so editors know they can discuss) per the general guidelines that proposals which need further development or don't need formalized consensus are out of scope. Do I understand what you're suggesting correctly? Best, Barkeep49 (talk) 20:28, 30 October 2021 (UTC)

I cannot understand how either of these ideas merit further detailed consideration and my hope is that they are firmly rejected. They have little support so far and seem to be being kept alive only by their would be sponsor. In particular the idea of some off-wiki training cabal for wannabe admins created in the model of a few selected "leaders" is most troubling. Leaky caldron (talk) 20:56, 30 October 2021 (UTC)

(edit conflict)Thanks for engaging. Unfortunately I'm going be afk for several hours. I also very much appreciate your keeping the review on track. For my part I believe either improvement track would be impractical (and possibly negatively viewed as disruptive or partisan) without a community-approved sanction and curriculum. If I decided to setup WP:BusterD's admin school, I think it would be well-ridiculed and poorly judged. If you believe my 4B and 4C proposals don't meet the guidelines at this moment, then please move them here where they may be better defined. BusterD (talk) 20:59, 30 October 2021 (UTC)

I think providing mentors and/or training programs for complex areas of Wikipedia such as administration is an excellent idea, and I would like to see Wikipedia move in the direction of having more "schools" for complex areas. I went through NPP school with a top reviewer and I learned a ton. There's no reason to meander through these complex areas in a brute force fashion, making a bunch of mistakes and getting chided on your user talk page, when experienced people can just communicate what the standard is. These complex areas are sometimes under-documented or inaccurately documented, and mentorship and/or schools can help with this. Schools are typically conducted on-wiki, here's some random examples: [1] [2]. –Novem Linguae (talk) 21:19, 30 October 2021 (UTC)

I share the view that this doesn't require community consensus, and I agree that the ideas should be moved to the talk page. Feel free to set something like this up on your own; if it's done well I doubt it will be "well-ridiculed and poorly judged". But if the community is asked to give its imprimatur to an abstract concept with to-be-determined implementation, I don't think the proposal would (or should) pass. Extraordinary Writ (talk) 23:47, 30 October 2021 (UTC)

Anyone is free to create guidance pages, hold training sessions, provide targeted assistance, and so forth. The usefulness of the results will determine how they are viewed by the community, which naturally encourages helpers to be receptive to feedback and align their advice with general community views. In the spirit of a wiki, any editors willing to work together on an initiative to aid other editors should just do it! isaacl (talk) 03:04, 31 October 2021 (UTC)

Comment on Standards needed to pass keep rising

Do they? This claim needs sourcing or to be backed by a Quarry. There may be the occasional eccentric demand for a brace of FA, 100 NAC at AfD, 4 years tenure, 100,000 edits, etc., but AFAICS standards are no higher than they have been since the Dec 2015 reforms, and the proof is that most RfA pass with overwhelming support. There is a long list here of criteria applied for years by regular, mature voters, none of which make excessive demands. Kudpung กุดผึ้ง (talk) 19:30, 31 October 2021 (UTC) Moved from main page as general comment Barkeep49 (talk) 19:34, 31 October 2021 (UTC)

• I actually agree with this; standards have generally flattened out since 2015, and any increase before then is exclusively a good thing. Still, it did find consensus in phase 1 and thus needs to be nominally discussed here. – John M Wolfson (talk • contribs) 19:52, 31 October 2021 (UTC)

One would need to go through every RfA and manually count the number and kind of oppose votes to establish a trend of any kind, and nobody is going to bother to do that. It's the kind of ting I used to do for example at WP:RFA2011 when I was stupidly dedicated to Wikipedia, but I don't have the enthusiasm for that sort of research nowadays. Otherwise even if it built a consensus it's just anecdotal evidence . Kudpung กุดผึ้ง (talk) 23:02, 31 October 2021 (UTC)

A modest proposal

Any editor with (say)

• No valid blocks[*] in the last year
• No blocks of over one month duration in last five years
• Activity over at least three months of every one of the last five years
• At least 5,000 edits
• At least 100 edits in the last month

shall be appointed an admin on request.

This could be a one-off offer, open for, say, six months, to prevent people gaming the system

Feel free to bikeshed the values.

[*] By "valid blocks", I mean blocks not rescinded by the blocking admin, or in their absence, as an error. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:59, 31 October 2021 (UTC)

So this requires five years' tenure? —valereee (talk) 21:15, 31 October 2021 (UTC)

Like I said, "feel free to bikeshed the values". And, of course, other avenues would still be open. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:18, 31 October 2021 (UTC)

I'd advise you not to propose this because you can multiply each condition by ten and there will still be no chance of it passing, particularly without a way for the community to revoke adminship. That's not to say anything about my opinion on it. — Bilorv (talk) 21:16, 31 October 2021 (UTC)

It's already proposed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:18, 31 October 2021 (UTC)

This obviously has no chance of passing. The WMF has explicitly threatened to veto this type of proposal in the past. And even without that, the voters who want to prevent various controversial editors from having the tools would kill it. Would the community really vote to give all those editors the mop? User:力 (power~enwiki, π, ν) 21:19, 31 October 2021 (UTC)

"WMF has explicitly threatened to veto this type of proposal" Where, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:27, 1 November 2021 (UTC)

[2] Extraordinary Writ (talk) 19:38, 1 November 2021 (UTC)

In my discussion with legal about this recently, automatic granting to people who meet certain criteria remains an issue for them. Best, Barkeep49 (talk) 19:49, 1 November 2021 (UTC)

Different proposal; says nothing about blocks. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:00, 1 November 2021 (UTC)

I think this has roughly the same chance of passing as the original modest proposal. Extraordinary Writ (talk) 21:25, 31 October 2021 (UTC)

As Power stated, this is a perennial proposal with no chance of succeeding given that the WMF will veto it; some community vetting is required to access deleted material. – John M Wolfson (talk • contribs) 20:50, 1 November 2021 (UTC)

Anyone who meets the criteria suggested has been vetted by the community, in the same way that edits unreverted after five years are deemed to have had consensus. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:00, 1 November 2021 (UTC)

@Pigsonthewing: No, you obstinate silly-goose, I mean that anybody who has access to viewdeleted has to be actively vetted by the community; simply not being blocked is insufficient. This is not a community policy, but one decided from above by WMF and ultimately the external legal system; deleted material may contain defamatory or copyright-infringing material that, if the WMF doesn't do its hardest to reasonably limit viewing to those who are actively trusted by the community, could get it into big trouble and thus compromise the project. While this does technically only apply to viewing deleted material, there is a strong consensus that "delete-block-protect" is the "core trio" of the mop, and unbundling proposals here haven't gone too well. Even ignoring that, however, I would still oppose since this is easy to game. – John M Wolfson (talk • contribs) 21:17, 1 November 2021 (UTC)

The "silly goose" is the one who has not read the proposal: "This could be a one-off offer, open for, say, six months, to prevent people gaming the system ". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:52, 1 November 2021 (UTC)

Comment on "No need for the tools"

I was looking at the issues randomly and this caught my attention. It's been quite some years I think the whole "Wikiworld" suffers from something like this and to be honest the problem is not only on WikiWorld but it goes on on real life too. To be able to get the privilege, you need to have a need for it or knowledge of it or the trust that you can use that privilege but it's very hard to obtain any of those things without having the privilege in the first place. The equivalent of this in real world is "you need experience to get a job but you need a job to get experience". This creates the biggest barrier for anyone starting anything because no one wants to be the environment that becomes an experimentation (read: learning) area for the newcomer, which is almost bound to happen. I'm not sure what kind of solution would be best here. One thought is to just be generally more lenient and dynamical. Give privileges more easily and remove them as much as easily. After all in the whole WikiWorld nothing ever loses. If someone wants to help (and also do errors while doing so), give them the opportunity to do that. The said user's errors can always be corrected with the press of a button (also tools can be designed to prevent that). This can't be done with the errors of a surgeon, for example, a difference with real life. If that someone turns out to be a vandal, remove the privilege, again, with the press of a button. Another thought is to create simulated learning enviroments where people can learn what admins do technically and what it means to be one in the general sense. They can also "work" there and therefore have a way to earn the community's trust. These are mostly just food for thought than objective definite ideas. But I do believe we need to find a way to remove barriers like these. - Klein Muçi (talk) 23:55, 31 October 2021 (UTC)Moved to talk page as general comment Barkeep49 (talk) 00:00, 1 November 2021 (UTC)

• That's true for "entry-level jobs" (but even those you can get in with simply displaying the right attitude); however, adminship is not an entry-level job, and there are plenty of work non-admins can do to lead up to it; AfDs, counter-vandalism, copyright, etc. RfA is essentially a job application, and just like a real job you need experience, and an actual idea of what you'll be doing in the position (even if it's different from what you end up ultimately doing). Allowing people to go on RfA without any need for the tools is like saying you can apply to be a surgeon because you like the pay; even I, who don't Wikipedia that uber-seriously like some do, see if nothing else the mere prestige of the role, and that's a factor that this RfA couldn't hope to address. – John M Wolfson (talk • contribs) 00:14, 1 November 2021 (UTC)

  I must say I find the surgeon allegory inadequate for the exact same reasons I mentioned in my comment above. Having said that, I'm still not sure I agree with your overall allegory even if some other profession was chosen. The reason I say that is because (doing a slippery slope here) one can say with the same line of thought that Wikipedia shouldn't exist at all like it currently does because it is written by unprofessional people of which we can't be sure of their academic level and subsequently of their contributions' accuracy. This argument has been used A LOT in early days and quite a few similar forked projects started because of that that had a highly academical, fully non-anonymous editorial staff. Wikipedia chose to make that leap of faith by developing the whole "edits done in good faith" philosophy and, strangely enough, survived while many of the said projects stopped being active rather fast. What my comment is about, and what I believe the identified issue is too, is rather a similar viewpoint extending from that doctrine. That surely doesn't mean to accept 3 days old accounts as admins. - Klein Muçi (talk) 00:35, 1 November 2021 (UTC)

I don't think the people who use the "no need for the tools" argument (which is also way fewer people than implied in the previous RfC) are using it in such a naïve way. It's not that we won't give you the delete button if you've never deleted anything. Obviously that makes no sense. It's that we won't give you the delete button if you haven't, up until now, showed any interest or inclination towards deletion work.

I also strongly disagree that in "WikiWorld nothing ever loses". WP:NOBIGDEAL is a myth that it is high time we did away with. The ability to exclude other editors from this project, to erase all their work with the click of a button, even just the social status people (rightly or wrongly) afford to admins, if misused, can and does cause irreparable damage to the project by driving people away and degrading our internal culture.

With that in mind, it is entirely reasonable to expect people to demonstrate some prior competence in the kinds of work admins do before we give them the bit. And there are plenty of ways to do so. – Joe (talk) 12:39, 1 November 2021 (UTC)

WP:NOBIGDEAL is not exactly what I had in mind when writing that. I believe admin privilege is an important duty. I was referring mostly to the overall doctrine of trust that Wikipedia applies. In History of Wikipedia you can read about Nupedia and Citizendium, which I believe you are already aware of and how they differ from Wikipedia in that aspect. I'm merely extending that same logic to be applicable to the case in hand. Again, if we are to apply the skepticism aspect, one can go on and apply it in different aspects as well. "Why allow IP edits if they don't even care to open a free account?" "Why allow everyone from the internet edit everything?" The truth is that we do allow them and at the same time create tools and devise ways of mitigating the harm that can come from that given trust. It's just WP:AFG.

Again, that doesn't mean to give admin privileges to anyone looking for it. Some (a lot of, if you want) criteria should be there. If you saw my 2 proposals, one even included a "simulation workplace", more inclined towards the "Admin Academia" idea. And they were both just spontaneous brainstorming seeds. The whole idea is that the "haven't demonstrated a need for the tools" can have a very wide range of meaning in it and therefore be pretty subjective as an argument. I believe that people who have the good will to do something should be motivated on it, especially on volunteer projects like Wikipedia. - Klein Muçi (talk) 13:10, 1 November 2021 (UTC)

2C Cohorts of candidates

Moved from the proposal page due to withdrawal

The RfA process will be restructured so that candidates will run as part of a cohort. Individuals wishing to run will sign up to be part of the next cohort, and once there are five candidates, they will collaboratively pick a day in the next month to launch all of their RfAs simultaneously.

Additional details
As a (hopefully unnecessary) safety valve, if any individual in a cohort has been waiting longer than three months, the cohort may choose to proceed even if it has not been filled. The number of candidates in a cohort could be adjusted at the community's discretion to increase or decrease scrutiny as desired.

Support (Cohorts of candidates)

1. Similarly to elections (8B), this will reduce the intensity of the spotlight by spreading it over a group. I think this method is mildly preferable to fixed dates because the fixed cohort size ensures that they won't get too large for necessary scrutiny or too small for the spotlight to get too harsh. Barkeep49's research on candidates running simultaneously is promising. Another benefit is that it will provide candidates with a built-in group for mutual support. {{u|Sdkb}} ^talk 20:17, 31 October 2021 (UTC)

   #Sure; this can already be done informally (like what Barkeep did a year or so ago), but I'm fine with this. – John M Wolfson (talk • contribs) 20:19, 31 October 2021 (UTC)

2. Support, but isn't 5 a bit wishful thinking? If current trends are anything to go by, that's all there will be in 2022. Kudpung กุดผึ้ง (talk) 21:21, 31 October 2021 (UTC)

Oppose (Cohorts of candidates)

1. No clue what this proposal is supposed to "do", simply because nothing at all has to be changed to make this happen, no RfC is required. Any candidates that want to do this can just do so. — xaosflux ^Talk 21:48, 31 October 2021 (UTC)

   If this is supposed to require that this is the only way to get in to RfA, then I strongly oppose - candidates should not be dependent upon when sufficient other candidates are ready, including having to schedule around others. — xaosflux ^Talk 21:50, 31 October 2021 (UTC)

2. Requiring RFA candidates to wait 6 months or longer for 4 other people to volunteer is a complete non-starter. User:力 (power~enwiki, π, ν) 22:02, 31 October 2021 (UTC)

   Even at 3 months this is too long, especially because people will have off-wiki commitments limiting availability. If you could guarantee a cohort every month ... but then there wouldn't be an admin shortage, nor any reason to require people to use the process. User:力 (power~enwiki, π, ν) 00:05, 1 November 2021 (UTC)

3. I will echo Xaosflux. I don't see what this will solve, it only adds a new layer of complexity to the process. How long does it take to get 5 people who want to run for RfA? HighInBC ^{Need help? Just ask.} 22:43, 31 October 2021 (UTC)
4. If this is mandatory then no. – John M Wolfson (talk • contribs) 22:45, 31 October 2021 (UTC)
5. The proper way to address the issue is described in 8B, which proposes an alternative, periodic process that may well become the new standard if candidates and voters like it. This proposal here has two issues: No fixed timing (potential waiting time: forever), and immediate replacement of the current RfA process instead of a parallel trial. ~ ToBeFree (talk) 00:57, 1 November 2021 (UTC)
6. I would have no problem with a group of candidates voluntarily deciding to run their RfAs simultaneously, but no candidate should be forced to do so, or to wait three months to run. Seraphimblade ^{Talk to me} 01:39, 1 November 2021 (UTC)
7. Absolutely nothing prevents folks from doing this right now. -FASTILY 04:22, 1 November 2021 (UTC)
8. Per ToBeFree. Additionally, I'm skeptical that this would really increase the RfA pass rate: Barkeep's data shows a small enough improvement (with a low enough sample size) that it could easily be within the margin of error. Extraordinary Writ (talk) 04:53, 1 November 2021 (UTC)
9. oppose per several reasons mentioned above and others as well.Paradise Chronicle (talk) 04:54, 1 November 2021 (UTC)

Discussion (Cohorts of candidates)

Preliminary discussion at this section from the brainstorming stage. {{u|Sdkb}} ^talk 20:17, 31 October 2021 (UTC)

This feels too incomplete to vote on. Presumably this is optional? Presumably candidates won't need to wait 9 months to fill a cohort? Presumably somebody organizes this so it's not a public signup list? User:力 (power~enwiki, π, ν) 20:29, 31 October 2021 (UTC)

No, it's proposed as a change to the process, not as an optional add-on. That's the way to ensure that cohorts fill reasonably quickly. Regarding wait time, I'd be fine with a provision along the lines of "if anyone in the cohort has been waiting for more than X period, it'll proceed", but if we're still not getting enough candidates to fill up a cohort within a reasonable timeframe, that means the RfA reform has already failed. Regarding the signup list, I could see it being either private or public-but-out of the way (kinda like someone creating their RfA page but not transcluding it). Do you have concerns about potential ill effects if it's public? {{u|Sdkb}} ^talk 21:47, 31 October 2021 (UTC)

I have updated the proposal's language to spell it out more explicitly. {{u|Sdkb}} ^talk 22:06, 31 October 2021 (UTC)

Courtesy pinging initial !voters @John M Wolfson, Kudpung, Xaosflux, 力, Isaacl, and Extraordinary Writ: {{u|Sdkb}} ^talk 22:10, 31 October 2021 (UTC)

This can be implemented now without requiring a community consensus. isaacl (talk) 21:33, 31 October 2021 (UTC)

Courtesy pinging brainstorm commenters who haven't commented here yet: @Eggishorn, Barkeep49, Extraordinary Writ, Qwerfjkl, Waggers, Trainsandotherthings, and Ganesha811:. Cheers, {{u|Sdkb}} ^talk 21:52, 31 October 2021 (UTC)

I'm not sure I could support making this mandatory: getting five people to find a week that works for all of them could be quite difficult, particularly if the present dearth of candidates doesn't improve. Proposal 8b has similar benefits but fewer downsides, in my view. Extraordinary Writ (talk) 21:59, 31 October 2021 (UTC)

Request to reinstate group editnotice

I'd like to request that Template:Editnotices/Group/Wikipedia:Requests for adminship be reinstated for review when editing this page. I think Wugapodes acted in good faith by suspending its use but also feel that useful information is obfuscated in so doing. As we discuss changing some things, I feel it's helpful being able to easily refer to the existing status quo. In particular, when considering a comment regarding formal moderation, I wanted to review what is currently in place, although rarely enforced, and was surprised that this information was no longer readily available. If no one else agrees with me that it should be reinstated, I'm fine with leaving things the way they are but did want to see if others perhaps agree. Thank you.--John Cline (talk) 12:19, 1 November 2021 (UTC)

If your primary interest is having the information available for review when considering a proposal, then you can put a link to in in the discussion. I think having the edit notice present on the edit page when the instructions were not written with edits for an RfC in mind is somewhat confusing. isaacl (talk) 14:53, 1 November 2021 (UTC)

The potential confusion was my main reason for removing the group notice. Not only does it obscure the page-specific notice, it might lead editors to think they're editing the wrong page. Given the way that I edited the group notice, we can actually set a specific notice for the 2021 review subpages if there is content that editors think would be useful. — Wug·a·po·des​ 22:35, 1 November 2021 (UTC)

Thank you both for your replies. I understand your rationale and agree. The decision was clearly founded upon sound reason. With best regards, I thank you again and wish you both well.--John Cline (talk) 23:08, 1 November 2021 (UTC)

One-party Wikipedia regime

First became acquainted with this kind of situation while I was in Ethiopia in 1974, when Haile Selassie was ousted by his military establishment. The general in charge declared the government to be a "one-party socialist regime". Essentially that is what adminship is, a one-party regime. So the problem we face is that we say admins are "vetted by the community" and thereby they gain the community's trust. But who exactly is the community? A fairly big RfA would involve perhaps 200 or so editors at week's end, but is that really the "community"? I could be wrong, but I think the enwiki community is at least a large chunk of the 121641 editors who are active, and even the large turnouts at RfA constitute only a small fraction of the total "community". Some might say that the silent majority acquiesces, which justifies the "vetted by" thing. Others might say that the silent majority just doesn't care one way or another, which makes the "vetted by" thing just a false security. Either way, this is probably the only place that we will find voting in a one-party regime. Who normally chooses new members in such a regime? New members are not voted in by the community, they are accepted and appointed by leaders of the regime. This leads me to think that new admins ought to be accepted and appointed by experienced admins. So that is my proposal. Toss the very thing that nobody really likes anyway, the thing that has caused so much discussion and contention for so many years: Toss out the RfA. Give admins the go-ahead to devise a system whereby they seek out and choose editors they consider good candidates, find out if the editors would be interested in becoming admins, and so on. There is no reason to give the so-called community a say in the matter. The vast majority of the community doesn't participate anyway. Admins are best suited to choose who should have the mop. P.I. Ellsworth - ed. ^put'r there 13:08, 1 November 2021 (UTC)

• Governments never accurately represent the majority in any event (c.f. Rothbard), but if this is to be a nominally communal process then it needs to be as (nominally) democratic as reasonably possible. Various proposals to do something like what you're proposing – such as having ArbCom or a panel choose admins – were soundly rejected in the brainstorming phase. – John M Wolfson (talk • contribs) 13:22, 1 November 2021 (UTC)
  • Understood. Maybe the idea was not understood correctly in the first phase? The present process is not democratic, because in order for democracy to be effective there must be two or more parties. In a one party regime such as we have with adminship, democratic processes crack, split, crash and burn – as has been noted and discussed time after time after time. The RfA process is not only minimally democratic, it's democracy is minuscule, especially considering that it's not a secretive ballot. There are far too many things wrong with the present process to try to patch it with the bandaids we see argued about on this subject page. It's time to turn the hourglass over and begin again fresh. P.I. Ellsworth - ed. ^put'r there 13:38, 1 November 2021 (UTC)
    • By policy WP is not a democracy [3] Leaky caldron (talk) 14:01, 1 November 2021 (UTC)
      • Another good reason to scrap the RfA process in toto. It actually goes against that policy... and always has! So I'll say it again, admins are best suited to choose who should have the mop. P.I. Ellsworth - ed. ^put'r there 14:26, 1 November 2021 (UTC)
        • Surely those admins. selected via the process you so deeply deprecate are themselves tainted by association with that process? How can they then be the replacement process? Leaky caldron (talk) 14:50, 1 November 2021 (UTC)
          • Tainted? 'Taint true. Experienced admins know what they are doing based upon their admin training and experience, not on their selection process. P.I. Ellsworth - ed. ^put'r there 16:37, 1 November 2021 (UTC)
            • So... a junta? We'd go from Ethiopia to Myanmar? No thanks. (not that I buy that strained Ethiopia analogy one bit anyway) Beeblebrox (talk) 21:55, 1 November 2021 (UTC)
              • Wikimedia projects are rather unique in scope and structure, but as far as analogies go we're organizationally much closer to a co-op or a volunteer charity than a state. _signed, Rosguill ^talk 22:11, 1 November 2021 (UTC)
                • Just as long as we don't have to start taking turns acting as a sort of executive officer for the week or use farcical aquatic ceremonies to derive supreme executive power.[4]. Best, Barkeep49 (talk) 22:38, 1 November 2021 (UTC)
              • It's easy for me to understand why so many editors can't seem to see the connection and the benefits of this analogy. I've even defended the RfA process myself from time to time. And yet, when we look at a page like this subject page, where so many deeply embedded things are found wrong with the RfA process with few agreements in sight, it shows me that even I was in denial along with other editors. The RfA process is dead and should be buried. It should be treated with honors because it has given us many really good admins and only a few bad ones. But this page shows beyond any shadow of doubt that it is dead beyond resurrection and moldy recognition. A new and effective process is needed for this one-party Wikipedia regime, and I believe that because history shows that the only way a one-party regime works well is when the leaders of the regime promote its members, that is the new process that should be created, designed and implemented. This does not mean that we're giving up, it means that we are going forward. Make yourself ready. Honor the dead process and embrace the newborn ideas! P.I. Ellsworth - ed. ^put'r there 07:49, 2 November 2021 (UTC)
• The figure of 124816 active editors uses an extremely generous definition of activity, namely making any edits at all in the last 30 days. Very few people who meet that standard will consider themselves to be part of any sort of community or have any interest in participating in discussions. 200 editors is really quite a lot, few discussions on Wikipedia get substantially more than that many participants (see WP:300 and WP:1000). It's fair to say that RfA gets substantial attention from amongst the people who are sufficiently engaged in the project to participate in its governance. Hut 8.5 18:45, 1 November 2021 (UTC)
• Simply giving admins the power to choose other admins is a bad idea, and creates the kind of self-perpetuating corrupt elites that are even more characteristic of dictatorships than of our existing (inevitable somewhat flawed) democracies. (And quite likely one gets the same effect when roughly the same 200 or so voters elect admins, even without the kind of rigged voting system we've had to use here). But in real democracies (all of which are of course somewhat flawed, because human nature is somewhat flawed) we don't elect individual low-ranking police officers either, especially not with the kind of rigged voting system understandably used here in order to try not to discourage people from applying to be admins (no secret voting, no right to criticize anonymously but with civility, no right to oppose without giving a reason, etc, all of which is why I rarely take part in RFAs, and why proper democracies don't have this kind of rigged voting system). The solution would seem to be to elect a body that appoints admins, just as we do with the appointment of low-ranking police officers in the real world. Put another way, it doesn't have to be a one-party regime if the appointing body is elected (or is appointed by an elected body). Tlhslobus (talk) 18:26, 8 November 2021 (UTC)

De-bundling of tools

Many tools are already assigned to editors on an individual basis if they demonstrate an understanding of their usage and are not likely to abuse them. Perhaps more of the admin tools could be meted out this way? What tools, ofher than say blocking and revdel really need to be limited to admins? This could be a path to creating more admins. Even though the somewhat pejorative term "hat collecting" is used to describe people with multiple user rights, it should be encouraged. A user could get to the point where they can do almost everything an admin can do, with a record to back it, meaning adminship could really be considered "not a big deal", and RfAs for the few remaining tools could be less contentious. Also, more people with more user rights could lead to less backlogs in various admin areas. (jmho) - wolf 19:15, 1 November 2021 (UTC)

I have long been in favor of this. I think that the big hammer of blocking other users needs to have people with a solid track record. But a lot of the knowing tasks in particular, such as protecting articles, building DYK queues, or closing discussions, or revdel, etc, could be awarded on a case by case basis. Montanabw^(talk) 22:54, 5 November 2021 (UTC)

​​ This idea has been discussed to death in the brainstorming phase, and except for the autopatrolled it doesn't appear that any unbundling proposals being currently proposed will get anywhere. – John M Wolfson (talk • contribs) 23:15, 5 November 2021 (UTC)

RfA !votes

I believe it's generally accepted, but should also be made clear, that "support" !votes don't, and shouldn't, require any explanation to be considered for consensus by the crats. These !votes are obviously based on the RfA: the information presented by the nominator(s), the answers provided to the questions, and the candidate's record. Conversely, any "oppose" !vote should require a clear and valid explanation, or be struck. I believe this would help reduce conflict at RfAs. (jmho) - wolf 19:15, 1 November 2021 (UTC)

• I believe this is the case, yes, and might be stated as such in one of the RfA guides. I don't know where else it would go to be anywhere that wasn't awkward, however. – John M Wolfson (talk • contribs) 20:58, 1 November 2021 (UTC)
  • Oppose: If this is already unofficially the case, then this may be part of the problem (at least if the problem is widened to include questions such as factors perhaps working against editor retention, etc). There's a reason why I rarely take part in RFAs. and that is that I know that if I vote against a nominee, let alone criticize them, I may be making a dangerous enemy with the power to make my life miserable. That is precisely why secret ballots were introduced throughout the democratic world, while here in practice we seem to have even worse than the exact opposite - historically you didn't need to give reasons for voting against a candidate in early British elections (tho that did not stop the frequent and severe punishment of those silently but publicly voting against powerful candidates, or against candidates with powerful backers). From my point of view what we actually need is both secret voting and a clear right to criticize anonymously (though with civility). But of course that would presumably be even more of a deterrent to new admins. So I'm not quite sure how you would go about squaring this circle, but I don't think making the current bad situation official would seem to do anything apart from just making things even worse. Of course the real problem may be that democracy may be inappropriate here (in the real world we don't elect low-ranking police officers, etc), but that's a separate question. Tlhslobus (talk) 17:49, 8 November 2021 (UTC)

A !vote's due weight

I'd like to actually see an annotation, from the closing crat, reqarding oppose !votes that were given less than full weight for failing the long-standing expectations of constructive/civil opposition with diffs linked to support RfA contentions and concerns. As often as I've heard that lazy oppose !votes are not given full weight, I've never seen it in practice, and challenge anyone to find an RfA whose tally isn't a statistical demonstration of every !vote receiving a full and equal share. I think if some of the !votes, that deservedly should be discounted, were (in clear and observable fashion) some of the chicanery that does occur at RfA would begin to wane. To clarify, I'm not commenting on !votes stricken during an RfA which does happen, they just don't happen for reasons related to poor form and questionable faith !voting. If this is something that others agree should be happening already, maybe it could be inserted as a proposal. Surely this is something that could easily be done?--John Cline (talk) 00:26, 2 November 2021 (UTC)

In Wikipedia:Requests for adminship/RexxS/Bureaucrat chat, several crats explicitly said that they down-weighted oppose votes in order to justify passing an RfA with under 65% support. This led to the RexxS RfA bureaucrat chat arbitration request and was part of the background to Wikipedia:Arbitration/Requests/Case/RexxS. – Joe (talk) 06:44, 2 November 2021 (UTC)

Number of proposals

• Way too many proposals going on. Dennis Brown - 2¢ 00:17, 2 November 2021 (UTC)

  @Dennis Brown: Some of them can probably be SNOW closed even now. Some are obviously not going to pass, while there's one which has unanimous support for. RandomCanadian (talk / contribs) 18:27, 2 November 2021 (UTC)

  @Dennis Brown and RandomCanadian: A large number of proposals has been a concern going back to Phase 1 which, when it started, already probably had too many proposals just from the ones I'd documented. I agree with RC that some number of proposals can be snow closed as unsuccessful and I have plans to do so when the proposal period ends. But beyond that the strict word counts and the fact that there will be 23 days for editors where no new proposals can be made, so they could take their time going through them, are all designed to produce a process that is open in the Wikipedia way but also manageable to the average editor who might care about this. Best, Barkeep49 (talk) 19:05, 2 November 2021 (UTC)

  If there's any issue with this reform attempt it's the opposite. Not enough proposals, specifically there doesn't seem to be one that would make it significantly easier for good candidates to pass, such as a significant threshold reduction. Perhaps someone will add one in the 11th hour. If not, at least this has been a valiant attempt at a near impossible task, wisely modelled on admin Biblioworm's successful 2015 reform. This classic essay on prepping an effective RfC might help any further attempts. FeydHuxtable (talk) 14:26, 7 November 2021 (UTC)

A proposal that will go nowhere

So here we are again ... yet another review dealing with how broken RfA is; this is the fourth one I've seen over the years. And once again there are a heap of proposals touching on this and that, and no doubt once again there'll be some cosmetic BS purporting to fix it all ... hey, wasn't announcing new RfAs at the top of Main Page supposed to fix it all last time?

What I'll propose yet again (being a fool, I admit) addresses something that was manifestly obvious in 2015 and 2012 and 2008: that the community cannot be trusted with the process. The same abuses pertain now as over the many years: that people oppose based on their personal hobby horses or a candidate's associations, that failure to have the right percentage of whatever the current shibboleth holds is a death sentence, that optional questions are everything but, that the process is ruled by headcount, so many others.

And nothing will come of this Review -- as nothing came of all the Reviews that came before it -- until folks realize that only one fix will possibly work: that admins are chosen by a select committee (or by ArbCom, or whomever), and that the process is taken out of the community's hands. Ravenswing 12:39, 3 November 2021 (UTC)

• I don't doubt that if the admin corps gets critically low the WMF would probably swoop in and appoint some more. Unless and until that happens, though, RfA needs to remain as democratic as reasonably possible. If the community can't get RfA right, it doesn't really deserve communal "governance" in the first place. ArbCom has enough to deal with already, and any other "commission" setup will lead to cabalism and Esperanzaing. As I've said before, the "brokenness" of RfA is grossly overstated in any event; its reputation as a hive of scum and villainy is far worse than the reality, and clearing up that misconception would fix a lot of any issues that actually exist. – John M Wolfson (talk • contribs) 13:19, 3 November 2021 (UTC)
• I'm not aware of anyone touting the previous review as resulting in a cure-all; I recall there being disappointment in how there is a lack of consensus on major changes. English Wikipedia's consensus-based decision-making traditions stalemate significant changes. Editors are reluctant to yield the veto power they have with consensus discussions, where a relatively small vocal minority can block change as the majority really does want to find a solution that people can live with. Additionally, some may be happier with the devil they know versus the devil they don't.
  Regarding a selection committee, the idea was suggested during the brainstorming (as it has multiple times over the years). Perhaps when enough of the community has shifted away from Wikipedia's libertarian roots, it will have a greater chance for being accepted. isaacl (talk) 15:11, 3 November 2021 (UTC)
  • Like Ravenswing, I too am disappointed and saddened that the community can recognize the problem but can't coalesce around anything that could make any serious progress towards solving it.—S Marshall T/C 17:25, 3 November 2021 (UTC)

    I'm disappointed that there wasn't more participation in the brainstorming phase. While it's possible for a proposal to gain acceptance without first refining and revising it during discussion, the odds are improved considerably by getting more input early on. As long as consensus-based decision making is being followed, getting changes approved is about the art of the possible, and more people collectively figuring out what they can live with is a big help. Nonetheless, I'm encouraged there are a lot of people willing to consider new approaches. isaacl (talk) 20:07, 3 November 2021 (UTC)

Have some patience, it isn't over yet, and some editors may not register votes until the final days (because they only want to read the page once). Everyone should realize that when a discussion is open and some people opine, while it is still open, that the discussion will go nowhere, that might become a self-fulfilling prophesy, as it may discourage new participants from investing the time to read and participate. So maybe we should all refrain from negative meta-commentary about a discussion being fruitless while it's still open. If what we want is for a discussion to be successful, it is counterproductive to discourage people from participating by predicting that the discussion will not be successful. Levivich 17:45, 3 November 2021 (UTC)

I should have noted that I do feel that incremental change can be achieved, and over time with discussion and different editors, viewpoints can shift. Thus I do feel it's good to have focused discussion occasionally, to help coalesce thinking, develop views on goals, and figure out paths that can achieve them. (I recognize that my preferred approach for deliberate consideration is somewhat out of sync with the majority of the community, so I appreciate that some are eager for faster changes to occur.) isaacl (talk) 19:57, 3 November 2021 (UTC)

RfA has been a hot mess for the better part of fifteen years. The community shows no signs of being able to get its act together to make meaningful changes in it, and never has shown such signs. Of course it's over, Levivich. Now if I prove to be wrong, I'll apologize beautifully, but I'm not. Ravenswing 22:28, 4 November 2021 (UTC)

More broadly I would challenge that nothing has come from past efforts. Obviously I don't think RfA has been fixed but efforts were taken to address the problems as they were understood at that time. So in 2015 there was a sense that there should be broader participation and since then we can prove that there has been broader participation. There was a sense the discretionary range should be larger and sure enough it was made larger and candidates who wouldn't have passed before that reform have since passed. Perhaps these don't qualify as meaningful changes. I would suggest, however, that everytime something has been unbundled that has been a meaningful change and in this discussion there seems to be some willingness to propose options that I would consider meaningful change including Limited Adminship and Admin Elections among others. I do not know if any of these will end up with consensus. I do hope that even if we don't solve a particular issue identified here that the consensus from this process can still serve to guide subsequent discussions. Best, Barkeep49 (talk) 17:09, 5 November 2021 (UTC)

The 2015 RfC might've solved the problems identified by editors at the time. However, did those actually improve RfA? Well, if we measure the answer to that based on the graph on the right, all that's happened since 2015 is the continuation of a trend where less people run for RfA, and the percentage of people that pass is higher (indicative of a culture where people don't wish to run). The 2015 reforms don't seem to have changed the trend in the direction it seems the community wants it. My feeling based on this RfC so far, noting that we're not even a week into it, is that there is disagreement on which direction to take moving forward, which prevents any movement from status quo. ProcrastinatingReader (talk) 12:21, 7 November 2021 (UTC)

You're not saying anything different from me. With respect to the 2015 people, whose work I obviously emulated, I think they focused on the wrong issues. And so might we. But things have changed and it was that sense of fatalism that I was really disagreeing with. Best, Barkeep49 (talk) 12:27, 7 November 2021 (UTC)

I think "focus" has a connotation of a bit more intentionality than what actually happened. Because of the limitations of consensus-based decision making, it's hard to reach agreement on what are the major issues and how to address them. However I didn't think the 2015 review would reach consensus on anything and yet it did. So I think very gradual change can be feasible, with larger reforms potentially kickstarted by shifts in the editor population. isaacl (talk) 16:20, 7 November 2021 (UTC)

I am surprised that admin elections has gained as much net support as it has so far, given that the idea of making RfA more like a vote has failed in the past (as recently as in phase 1). Anonymous voting seems to be more popular than I suspected. isaacl (talk) 02:04, 8 November 2021 (UTC)

Couldn't agree more, so see #One-party Wikipedia regime above where I reminded that it would be best for the leaders to choose our leaders. The vast majority of the "community" are not seen at RfAs, so "vetted by the community" gives us only a false sense of security. We can understand why editors would shy away from such an idea. As bad as RfA has become, still it has given us a lot of awesome admins and only a very few who leave a bit to be desired. And it is hard to accept that inside promotions of admins selecting admins would not develop into a tyranny or something. There would have to be reassurances that such a thing would not happen, that admins would not reduce adminship to such things. Mostly, editors are just uncomfortable with change, especially major changes. Wikipedia is all about change. Go back and check some of your old contributions and see how other editors have improved on your work. It's time to improve the selection process and bandaids are not the answer. P.I. Ellsworth - ed. ^put'r there 18:28, 5 November 2021 (UTC)

I'm struggling to see how this reform process could possibly make any meaningful difference unless the admin elections proposal passes. Of the four proposals with at least majority support that's the only one with even the possibility of making a significant difference to the process. The others are very minor changes which can't have any significant effect. I suspect nothing will happen until admin numbers get so low that it becomes an undeniably serious problem, and then we will probably have to institute something like appointment of admins by committee. Hut 8.5 18:53, 6 November 2021 (UTC)

@Hut 8.5: As said earlier, I would presume that the WMF would swoop in at that point. – John M Wolfson (talk • contribs) 19:37, 6 November 2021 (UTC)

It's a credit to WMF that circumstances would have to be what most of us call pretty "dire" before they would swoop in. I respect the foundation and its members enough to think that they would hope our community would be the first to swoop in. P.I. Ellsworth - ed. ^put'r there 08:09, 7 November 2021 (UTC)

If there's one thing we've learned from recent years, it should be that no problem is "undeniably serious" to the determined, particularly gradual, continuous changes. IMO many existential problems on Wikipedia already are extremely drastic, and not taken sufficiently seriously. — Bilorv (talk) 17:57, 7 November 2021 (UTC)

• I generally agree with Ravenswing. The mobocracy that is RFA is the job interview from hell. Anyone can turn up, even at the last minute, and ask any question on any subject, potentially completely derailing an RFA. This is more like what politicians are exposed to, not someone being asked to fulfil an administrative role. This imo is the main factor discouraging potential candidates. An appointments board would be much saner. It would be clear from the outset what was required from candidates and the process would be much less dramatic. The appointments board would have to be elected of course, but that's a much smaller cohort.

Instead of addressing this central issue, most of the proposals are addressing something else entirely. They are addressing what to do about potential admin bad behaviour or decisions. That is just way off-topic here and will not solve the problem. In fact, it is a further example of mobocracy. The community mob are not really interested in encouraging more admins. In fact they view admins as dangerous who need to be kept under control. They would be happier with fewer admins, not more of them. SpinningSpark 18:24, 7 November 2021 (UTC)

Well you could have made your own proposal. Instead you've ... voted against 14 different proposals. That'll mix things up for sure! --JBL (talk) 01:42, 8 November 2021 (UTC)

The proposal was made as stated earlier in the thread, but did not make it to the voting stage. So of course I'm going to vote against everything because I can't vote for the one thing that will fix this problem. SpinningSpark 16:22, 8 November 2021 (UTC)

I think if everyone decides to only vote for their preferred solution, we will never achieve consensus on something. It's why I've personally abstained on some proposals I think are meaningful although give me some pause. I'd also be happy to support multiple different directions, as long as the directions are decent, in the hope that at least one will achieve consensus. I think voting oppose on everything but a preferred solution is how we create deadlocks and end up stuck with the status quo we know doesn't work. ProcrastinatingReader (talk) 17:48, 8 November 2021 (UTC)

The rationale for proposals making it easier to censure/desysop admins is that editors would no longer have such high standards at RfA, as the consequences of a poor promotion would be perceived as less consequential. Perhaps there would be less incentive to search out a candidate's mistakes as well, but some level of that is probably inevitable due to human nature, regardless of what system is used. Sunrise (talk) 01:57, 8 November 2021 (UTC)

I understand the rationale, I just don't believe that's how it will work out. Historically, admins have been put under greater and greater scrutiny over the years. People who have a poor opinion of admins will continue to go through histories with a fine toothcomb no matter what. SpinningSpark 16:22, 8 November 2021 (UTC)

• Broadly agree with Ravenswing, my only possible disagreement being that it should be made clear that whatever body appoints the admins should be democratically elected (or at least appointed by a democratically elected body). As I've already said elsewhere, simply giving admins the power to choose other admins is a bad idea, and creates the kind of self-perpetuating corrupt elites that are even more characteristic of dictatorships than of our existing (inevitable somewhat flawed) democracies. (And quite likely one gets the same effect when roughly the same 200 or so voters elect admins, even without the kind of rigged voting system we've had to use here). But in real democracies (all of which are of course somewhat flawed, because human nature is somewhat flawed) we don't elect individual low-ranking police officers either, especially not with the kind of rigged voting system understandably used here in order to try not to discourage people from applying to be admins (no secret voting, no right to criticize anonymously but with civility, no right to oppose without giving a reason, etc, all of which is why I rarely take part in RFAs, and why proper democracies don't have this kind of rigged voting system). The solution would seem to be to elect a body that appoints admins, just as we do with the appointment of low-ranking police officers in the real world. The question would then be whether we should use our current elected body (Arbcom) or a new elected body, but that's a question for another day. Tlhslobus (talk) 18:34, 8 November 2021 (UTC)

Hopefully it's a question for another era. Some misconceptions needs to be dispelled. Admins are NOT leaders. They are community selected editors with tools, extra rights and sensitive responsibilities. They don't lead - they follow the community. Same with Arbcom - selected by the community to deal with challenging editorial behavior. We need to get away from Admin as a promotion and Admin - 'Crat - Arbcom as a defacto hierarchy to be aspired to. Leaky caldron (talk) 20:47, 8 November 2021 (UTC)

Well ... my rebuttal is basic: what exactly do admins DO that there'd be any legitimate worry of a "self-perpetuating corrupt elite?" Admins have no more say in the creation of policy than any other editor, I can't see that there's an "admin outlook" on things all that different from most editors, there are many editors out there watchful (indeed, sometimes overwatchful) of bungling, and we should put this in perspective: we're talking admin tasks on Wikipedia, not governing the finance or energy ministries of a nation-state. Not that your average RfA doesn't give the impression that a lot of editors don't view the mop as being just that important and dangerous. I'd honestly be pretty comfortable with RfA voting being restricted to admins. Ravenswing 17:44, 9 November 2021 (UTC)

I wouldn't. Put the idea to the test - ask the community. Leaky caldron (talk) 18:08, 9 November 2021 (UTC)

What admins do (among other things) is try to enforce policy as they see fit, often by punishing actual or alleged transgressors. In effect they are our police force (and to some extent our judges and prison officers as well). And, human nature being what it is, any force that has power over others will tend to abuse that power, with the abuse tending to be worse if those at the bottom have no say in the matter. That is largely why democracy was invented, and why democratic control of any proposed appointing body seems essential, at least to me. But I'm a bit surprised that you seem to be rebutting a person (and perhaps people) who seem to be broadly agreeing with most of what you at least appeared to be originally saying (after all, I have agreed with you that we should not be electing individual admins; I just want us to have direct or indirect democratic control over the appointing body, as happens in every normal democracy). Tlhslobus (talk) 18:55, 9 November 2021 (UTC)

TOC

I wanted to ask why the TOC is limited to two levels and the proposals are listed in the box like "1B 1C 2A"? I have no idea what proposal 1B or 2A is. (Similar with references to "issue 1", "issue 2", etc. Can we just use descriptive names so I don't have to keep consulting an index?) I'm trying to find the "quarterly election" proposal but it's not linked at all on the top of the page (have to use ctrl+f instead, which isn't how we should have to find sections). This page is totally impossible to use on mobile, but it's also very hard to navigate on desktop. Am I the only one? Anyone else prefer a normal TOC? Levivich 15:24, 3 November 2021 (UTC)

• I have removed the TOC limits; it is larger than normal, but not unwieldy; I have decided to compromise and omit the "support" and "oppose" sections from it. While new proposals may come before the 7th, I think most proposals are already present. – John M Wolfson (talk • contribs) 15:35, 3 November 2021 (UTC)

A different sortition idea

Instead of sortition for candidates, sortition could pick the voters. Twice per year, a pool of 20 selectors is chosen from a pool of volunteer Extended-Confirmed editors. A cohort of candidates may nominate themselves for adminship. The selectors assess and vote on each of the candidates. Candidates who receive 14 positive votes become admins. I'm not sure I actually like the idea (and there are quite a few moving parts to get right), but I do think that if "sortition" is viewed as a solution that is what the proposal should be. By having fewer voters, the sense of scrutiny should be decreased. User:力 (powera, π, ν) 23:42, 3 November 2021 (UTC)

I've de-watchlisted this page so ping me if you really need my input. User:力 (powera, π, ν) 23:42, 3 November 2021 (UTC)

• This suffers from the same problems as any "appointment board" idea, but as those ideas go this isn't a particularly bad one. – John M Wolfson (talk • contribs) 00:03, 4 November 2021 (UTC)

Huh... That could actually work. @力: Just to ensure I understand this right, is the pool of volunteer EC editors self-selecting or simply all EC editors? Should we make sure that the selectors have some sort of activity requirement? –MJL ‐Talk‐^☖ 04:09, 4 November 2021 (UTC)

The idea is any extended confirmed editor is eligible; the only activity check (at least until problems are pointed out) is "were you active enough to volunteer for that specific election". Presumably editors would sign up at the same time (and choose between) for the "running for admin" cohort and the "eligible to be selected as voter" list. I did notice one other detail: the voting should probably have 13 or 14 votes be a "discretionary zone" to avoid the situation where the last voter determines on their own whether an editor gets the bit. User:力 (powera, π, ν) 04:31, 4 November 2021 (UTC)

@MJL: I'm not going to propose this. I think 8B is better at addressing the issue. User:力 (powera, π, ν) 21:01, 5 November 2021 (UTC)

@力: In that case, I'll have to ponder whether or not I think this is something I could pursue. I'll try to figure that out before tomorrow's deadline. –MJL ‐Talk‐^☖ 03:59, 6 November 2021 (UTC)

Additional question

I'm about to be away from my computer for a long time, and I only just discovered this page. Am I allowed to propose that people limit themselves to one question at RFA's? Scorpions13256 (talk) 16:36, 5 November 2021 (UTC)

• Yes; that would, I believe, go under Issue 2. – John M Wolfson (talk • contribs) 16:48, 5 November 2021 (UTC)

  Courtesy ping for @Scorpions13256. Best, Barkeep49 (talk) 17:02, 5 November 2021 (UTC)

Update: End of Proposal Period & Closers

With the end of the proposal period, I have SNOW closed several proposals. This has also been added to watchlists so I expect we'll get some number of new editors for the next week while that is there. Additionally, Lee Vilenski has agreed to help close this discussion. I am wondering if Primefac (who helped close Phase 1 and has not participated in Phase 2) or any other uninvolved editors with the experience to do so would like to help with the close. Best, Barkeep49 (talk) 16:33, 7 November 2021 (UTC)

@Barkeep49: the third "Introduction and format" paragraph reads a bit oddly now it's been changed a few times, and it's also got a bit mixed up in tenses. Can I suggest this as the simplest phrasing:

To attempt to ensure the most editors possible could supply feedback for ideas, for 7 days prior to the start of Phase 2 and during the first 7 days of the 30 day discussion period, editors could propose changes, and no votes were allowed before the discussion period. Now these periods have closed, new ideas suggested will be moved to the talk page. To help editors navigate proposals, proposed changes are grouped according to the main issue they are addressing.

— Bilorv (talk) 17:52, 7 November 2021 (UTC)

@Bilorv  Done. Best, Barkeep49 (talk) 17:59, 7 November 2021 (UTC)

Assuming I'm not busy, sure. Primefac (talk) 21:24, 7 November 2021 (UTC)

Just as an update, as we are to close very soon, is there anyone else (uninvolved) who would also like to form a closing committee? Are you still up for this Primefac? Best Wishes, Lee Vilenski ^{(talk • contribs)} 12:07, 29 November 2021 (UTC)

Per my general feelings on panels, I think this could be closed by a single qualified person, but do think this is one of the few times e where there is enhanced legitimacy by having more than one closer and am very appreciative of the work Primefac and Wugs did for Phase 1. Best, Barkeep49 (talk) 19:46, 29 November 2021 (UTC)

I have done a (very) quick skim and concur with your assessment; many of the discussions are in fairly "clear consensus" territory with only a handful needing a deep dive. While extra assistance is always appreciated, I do not think it will be unmanageable to close this myself should it become necessary to do so. Primefac (talk) 12:10, 30 November 2021 (UTC)

Still acting under the assumption that I am not busy, sure. Primefac (talk) 12:10, 30 November 2021 (UTC)

@Primefac @Lee Vilenski with the RfC tag having been removed by Legobot, you can decide if you'd like to put a closing template up or if you'd like to allow further discussion as you explore your close. Best, Barkeep49 (talk) 16:06, 30 November 2021 (UTC)

It might be worth holding off on closure for a few more days: there's been a big spike in participation lately (probably due to the Signpost coverage?) and it would be a shame if we missed out on further comments. While 30 days is a good guidepost, it shouldn't be observed religiously, particularly when the discussion isn't yet stale. Extraordinary Writ (talk) 20:36, 30 November 2021 (UTC)

I'm pretty easy on this, but I don't really want to hold up the next stage of discussion just to retain a conversation on things that aren't going to pass at this time. With the agreement of Primefac, I think it's suitable to close the items that aren't very likely to be retained even with a day or two extra discussion. Best Wishes, Lee Vilenski ^{(talk • contribs)} 09:35, 1 December 2021 (UTC)

I just closed two that obviously did not achieve consensus, and obviously weren't going to; there are several more of those. --JBL (talk) 17:05, 1 December 2021 (UTC)

Do you still need closers? I have not touched the RfC (and did not read it to be honest), I can help but probably not before the weekend.--Ymblanter (talk) 17:14, 1 December 2021 (UTC)

To RfC participants who are evaluating consensus for indvidual proposals: I appreciate you feel you are determining the consensus views for obvious scenarios. All the same, personally I think it would be better to wait for non-participants to evaluate consensus. Given there is no immediate urgency, I feel showing patience helps establish a more collegiate atmosphere for the next steps going forward. isaacl (talk) 23:11, 2 December 2021 (UTC)

• @Lee Vilenski and Primefac: I see that Primefac started closing specific proposals, and I will also do some. I suggest that we individually close the obviousl cases, and come with a joint statement for the whole RfC, as well as (if needed) for non-trivial specific proposals.--Ymblanter (talk) 09:31, 3 December 2021 (UTC)

  To copy it from the topic below, there are three open discussions 6C, 6E, and 8B. I suggest that we read them and then exchange opinions about the closing. I am likely out (busy at work) for the next seven-eight hours.--Ymblanter (talk) 09:55, 3 December 2021 (UTC)

  Works for me. Primefac (talk) 10:07, 3 December 2021 (UTC)

  I think 6C needs a collective close indeed. Have not read the other two yet, will try to read through them tomorrow.--Ymblanter (talk) 23:27, 3 December 2021 (UTC)

  6E is on the edge but is probably also best closed collectively.--Ymblanter (talk) 22:37, 4 December 2021 (UTC)

  And 8B has obvious issues as well. @Lee Vilenski and Primefac: Should we open an e-mail thread and discuss them one by one?--Ymblanter (talk) 20:11, 6 December 2021 (UTC)

  Yeah, shoot us an email. Primefac (talk) 11:45, 7 December 2021 (UTC)

  Indeed. Best Wishes, Lee Vilenski ^{(talk • contribs)} 13:01, 7 December 2021 (UTC)

• We have closed all specific proposals, but will take time to consider whether closing the whole RfC needs a separate (non-trivial) statement.--Ymblanter (talk) 16:40, 14 December 2021 (UTC)

  Now, good luck with this one.(Personal opinion, not discussed with Primefac or Lee Vilenski)--Ymblanter (talk) 06:32, 24 December 2021 (UTC)

Comment on culture

Observation: Reading the whole page, each support, oppose, and discussion, I see some signs of a corrosive culture. I think the issues might be greater than the RfA process. Cultural change is hard. —¿philoserf? (talk) 17:25, 7 November 2021 (UTC)

• Also, the RFC is about how to change the rules, but changing the culture and changing the rules are two entirely unrelated phenomena. Marcocapelle (talk) 07:13, 8 November 2021 (UTC)
  • Surely not entirely unrelated -- existing rules inform culture, and existing culture informs rules. --JBL (talk) 14:41, 8 November 2021 (UTC)

  I borrowed the word from here: Wikipedia:Requests for adminship/2021 review/Proposals#Issue 1: Corrosive RfA atmosphere —¿philoserf? (talk) 20:20, 10 November 2021 (UTC)

Proposal removed

The following proposal was removed by Chicdat as being posted after the period for new proposals. I guess Chicdat felt it would be appropriate to preserve it here. --JBL (talk) 14:40, 8 November 2021 (UTC)

6F Fixed limited term with mandatory follow-up desysop period (optional)

Rather than having a probationary term, I suggest the following for new admins to get back to "not a big deal" and not something that permanently creates a two-class system:

1) Editor runs an RfA, (however we decide that is to be done after this RfC) but declaring this option up front.

2) If editor is selected for admin bit, they are given full admin rights for six months upon closure.

3) Upon six months expiry of admin bit, the editor is desysop'ed automatically, and forbidden from holding admin privileges for a further six months.

4) One year after initially getting the admin bit under this scheme and six months after desysop, an editor is free to run for RfA again, under whatever options, (this, traditional appointment for life, or any other option)

This might appeal to some editors, to others it might not. The community doesn't have to worry about privileges-for-life-unless-revoked-for-cause. Editors who have been great editors but hate adminning don't have to stick with it. Editors who suck at adminning and realize this simply never run again, or don't realize it and aren't selected if they do run again. Jclemens (talk) 05:40, 8 November 2021 (UTC)

Support 6F Fixed limited term with mandatory follow-up desysop period (optional)

1. As proposer. Jclemens (talk) 05:40, 8 November 2021 (UTC)

Discuss 6F Fixed limited term with mandatory follow-up desysop period (optional)

@Jclemens: This differs substantively from 6E only in the presence of a mandatory 6-months-of-not-being-an-admin-after-being-an-admin-temporarily period, but your comments do not indicate what the advantage of that specific change is supposed to be (everything concrete you say about this proposal already applies to 6E). Could you either articulate a case for a mandatory cool-off period of 6 months, or else withdraw this and support 6E instead? --JBL (talk) 10:59, 8 November 2021 (UTC)

Agreed. I don't understand the point of revoking the tools for six months. Seems like just long enough to forget anything they learned while having the tools. Beeblebrox (talk) 18:32, 8 November 2021 (UTC)

The point is to encourage admins to function as non-admins. The project is not served well by admins who forget what it's like to be a non-admin. This would eventually be part of a move to include encouraged, perhaps eventually mandatory, admin sabbaticals, to blur the lines and mix up the division between "has-the-tools" and "has no tools" classes. Jclemens (talk) 18:57, 8 November 2021 (UTC)

Not seeing how this would make it more likely to attract candidates for RFA, or voters to RFA. This is an example of admin tool reform, not RFA reform. The purpose of this exercise is to get more people to run for adminship, not to reform the admin tool set. People need to stop conflating the two; you're certainly not alone in that. Risker (talk) 19:03, 8 November 2021 (UTC)

• Concurring with Risker, this original reform project as begun by Barkeep49 has become so blurred and sidetracked that I have a growing sense of doom that the participation overall is so thinly spread among the many proposals and the low number of participants (140) that none of the results of the single issues under discussion will be a representative quorum of the community. Indeed, the average RfA itself has a higher participation. Important policy issues need important participation, not in the dozens, but in the hundreds. Kudpung กุดผึ้ง (talk) 20:35, 8 November 2021 (UTC)

Yeah, I discuss this problem in my essay on policy proposals. The only solution I've ever come up with is a more restrictive format (to be used only after mulriple failed attempts at using more conventional RFC models) such as the one used in Wikipedia:Pending changes/Request for Comment 2012. The format was based on mutually exclusive options, and each user had to chose one to support. No additional proposals were permitted. A lot of planning had to go into that, including recruiting a team to administrate and close it before it was even opened. Something like that may be needed to take another crack at this problem. Beeblebrox (talk) 21:02, 8 November 2021 (UTC)

To the above critiques, the goal is to stop electing Admins for life, let people step into the role for an intentionally limited duration, and thus have far less tolerance for the high-stakes scrutiny and follow-up contribution proctoscopy. Is RfA currently a place where people can say "Sure, why not?" without seeming irresponsible? Whether or not this could change that, that's the idea behind it. Jclemens (talk) 21:36, 8 November 2021 (UTC)

What you're saying is that you don't like the current removal process. You have zero reason to think that the "RFA regulars" would stop carrying out the proctoscopy, and in fact I'm quite sure they will. Your "solution" is essentially for people to go through the same process with the guarantee that if they like the job, they'll have to do it again and again. I do wish people would stop their utopian thinking. Risker (talk) 22:13, 8 November 2021 (UTC)

I'm sorry if I gave the impression that I thought this timing/rotation proposed change, in isolation, would solve everything. Rather, I think in combination with several of the other ideas, it might make a meaningful, positive cultural change. I've got to chuckle a bit at the "utopian thinking" comment--thanks for the compliment, but I'm still far too cynical for that. I mean, even talking about drastic change in private can have deleterious effects on one's Wikipedia career, as you saw me discover the hard way. Jclemens (talk) 22:47, 8 November 2021 (UTC)

Process question - Did I miss something?

I've been trying to keep an eye on this process but the notified part seemed to go immediately from "list the problems" to "we've listed the only solution ideas that are open for discussion" Or is the process till open for ideas? Sincerely, North8000 (talk) 22:26, 8 November 2021 (UTC)

@North8000 it seems you did miss something. After the issues part was closed, we did a 2 week brainstorming period. As part of that time there was agreement that limiting the time to propose new ideas would be helpful. So there was a 1 week "no discussion, proposals only" period followed by the launch of the 30 day discussion with proposals accepted for a further week. Both the proposals only and the kick off of the 30 day discussion were advertised on CENT, AN, and VPP among other places (in addition to WP:RFA2021). I had also created a mass message list but it seems you didn't make it on there. I am sorry you missed this as it was my intent to try to advertise widely while saving the watchlist notice for when things would be stable enough for other editors to weigh in. Best, Barkeep49 (talk) 23:02, 8 November 2021 (UTC)

I suppose for future big discussions like this, "brainstorming" could be a numbered phase. Not like it would help much, just a tweak. Enterprisey (talk!) 02:43, 9 November 2021 (UTC)

@Barkeep49: I'm not sure if I misunderstood the above but one note....good to identify a "submit & develop proposals" phase which is different than brainstorming. Also it needs to be longer; developing & refining good proposals IMO is the most important and difficult part of the process. Regardless, I have to say it anyway. One of the two biggest fixes (the other being bifurcation and there's not even a viable proposal on that) would be to provide some structure to RFA. Decide on the key qualities needed for admin and encourage responses to comment on the strength of the candidate in those areas. Much better than the current random-walk discussion with the mob. And a little fix would be to emphasize that one can volunteer/self nominate. Right now it has the appearance of an unwritten rule that you need to get a prominent person to nominate and vouch for them. Sincerely, North8000 (talk) 15:03, 9 November 2021 (UTC)

That approach was talked about in various ways both during Phase 1 and Brainstorming and even had a form of it here as a proposal. A comprehensive review of a topic like RfA is always going to be tricky. As I indicated in a reply to Kudpung after this is all over I will have thoughts to share about the process, including what I'd done differently had I known more. That said one of the reasons I launched this is because both the issues and solutions had been talked about repeatedly for several years. It did not feel like the conversation was progressing in any meaningful way through abstract discussion - lots of editors had their pet theory about what was wrong with RfA and/or what RfA needed to be fixed. The idea with this process was to provide a predictable and fair way to find out what the issues where and then which solutions had consensus on fixing them. In the end this process will have begun in late August and wrap-up sometime in early December. I made a judgement call that the Brainstorming phase was facing decreasing marginal utility - indeed there were suggestions post-Eostrix that the whole process should be scrapped something I think subsequent discussions have proven would have been an over-reaction - and we were ready to proceed to concrete proposals. In a multi-month process, building off of years of discussions, there's always going to be a balance between having a process that allows enough time to adequately and fully do the work and one where people drop out over frustrations of nothing happening or just because they lose interest. Best, Barkeep49 (talk) 16:09, 9 November 2021 (UTC)

Thanks for your work on this! Sincerely, North8000 (talk) 16:12, 9 November 2021 (UTC)

Yeah, the idea of weighing the qualities desired in an administrator got even less attention than when I proposed it in 2015. It's an approach that would probably gain more favour if a nominating or appointment committee were put in place, as that would basically mirror what's done in organizations everywhere. isaacl (talk) 16:23, 9 November 2021 (UTC)

There's two degrees of doing that. The more extreme one (and thus less likely to get support) would be to make the decision based on judgment per those criteria. I was positing a milder form, which is to list some of those points and encourage responses to comment on those. North8000 (talk) 18:44, 10 November 2021 (UTC)

Perhaps some of the regular RfA commenters would be willing to set an example by formatting their comments as, say, a standard checklist of characteristics with their evaluation of each one? Maybe it'll then catch on. isaacl (talk) 21:48, 10 November 2021 (UTC)

An idea for a revived WikiProject Admin Nominators, or for anyone who is seeking administrator candidates: get some of your prospective candidates to write their own nomination statements, to show by example that this is a viable option. isaacl (talk) 16:18, 9 November 2021 (UTC)

Suggestion to the moderators

There are a number of withdrawn or closed proposals; could you either add strike-through < s > ... < /s > or have something like "(closed)" appended to the top-level heading for those sections, to aid navigation using the ToC to active discussions? --JBL (talk) 12:16, 10 November 2021 (UTC)

@JayBeeEll  Done. Best, Barkeep49 (talk) 17:42, 10 November 2021 (UTC)

Why are 4A and 4D relating to sortition not closed? Neither has received more support than opposition, either numerically or by weight of argument. Leaky caldron (talk) 08:34, 12 November 2021 (UTC)

When I closed some last Sunday I just closed those with more than 2/1 opposition at that time. Given that there was going to be a watchlist notice I had some thinking that consensus could change from that group of people. The two sortition ones didn't qualify (well maybe 4D did but it also hadn't been open long). At this point the overwhelming majority of people who are going to participate have at least made 1 edit and so I don't know how much benefit there is to closing. But if there's some sense that it should happen I can do another pass for SNOW. Best, Barkeep49 (talk) 20:27, 12 November 2021 (UTC)

the "neutral" section

This issue has been discussed many times: on many instances editors comment under neutral section something similar to "I am currently busy, I will look into the candidate, and vote later". Neutral section is not a placeholder place. Maybe we should add something in invisible comment? ^{Or maybe we should rename the section to "suppose"? (portmanteau of support+oppose) /end humour.} —usernamekiran • sign the guestbook • (talk) 19:58, 18 November 2021 (UTC)

While certainly not the most pressing issue, I have long found such comments to be useless self-important noise of no value. Beeblebrox (talk) 02:02, 19 November 2021 (UTC)

yeah, I find them annoying. —usernamekiran • sign the guestbook • (talk) 04:53, 19 November 2021 (UTC)

Very! Leaky caldron (talk) 07:59, 19 November 2021 (UTC)

late addition?

At Wikipedia:Requests_for_adminship/2021_review/Proposals#5A_Revise_standard_Question_1, which clearly is going to pass, in the Discussion section the question was raised of what to do with opposes for "no need", and WereSpielChequers asks that if the community is intending crats to ignore such opposes, we make that clear. Is it possible to add a new sub-proposal, or do we need to deal with that detail subsequently? —valereee (talk) 16:23, 19 November 2021 (UTC)

There is already a community consensus that no need for tools opposes is a poor reason. I would hope crats, who are trusted to be skilled evaluators of discussions, could apply that consensus appropriately. Further discussion or BOLD editing to document the consensuses reached during this process does, of course, seem helpful and normal. Best, Barkeep49 (talk) 16:42, 19 November 2021 (UTC)

A leading question on which my views are conflicting: if "no need for the tools" is a bad reason to oppose at RfA, why is it a good reason to decline at (all areas of) WP:PERM? — Bilorv (talk) 12:57, 28 November 2021 (UTC)

@Bilorv: we're probably in the wrong venue for this, but I'd say the primary difference is that PERM is actually driven by need more than anything else. The bar for entry is much lower, and things like trial periods are often used. Some of those tools can be disruptive, so a large part of the review is "can you use this without breaking things" not just "are you trustworthy enough to use this according to policy". For RfA there is an implicit "are you trustworthy enough to not try to use tools that you don't understand" part of the trust review, as admins get such a large tool box. — xaosflux ^Talk 20:02, 28 November 2021 (UTC)

• This does generally seem to be a "poor reason" to oppose, and a reference to the identified issues (e.g. Wikipedia:Requests_for_adminship/2021_review/Issues#O) should probably be part of the closure of this RfC. That being said, literal opposes of "Oppose - no need for the tools" are quite uncommon, and I know I would already consider them less helpful to the consensus gathering process. Unless, this concern was explicitly developed elsewhere in the discussion (such as a fanciful candidate who ran on a position of something like "Why are you interested in becoming an administrator? :: Because I want the prestige of saying I'm an administrator here, I have no intention of ever helping in any administrative areas"). — xaosflux ^Talk 19:53, 28 November 2021 (UTC)

  Crap, now I gotta rewrite my answer to Q1. Levivich 03:09, 29 November 2021 (UTC)

Why no watchlist notice?

I've just found out about this process now, because it was mentioned in the Signpost. I had no idea anything like this was going on, yet it seems fully-fledged proposals are already being aired. Please can we put this in a watchlist notice so that everyone in the community has their chance to air their views?  — Amakuru (talk) 09:33, 29 November 2021 (UTC)

It's due to end tomorrow, so it's probably too late for a watchlist notice. It has been listed at WP:CENT for three months. – Joe (talk) 09:40, 29 November 2021 (UTC)

There was a watchlist notice from November 7 to November 15. Rummskartoffel 10:11, 29 November 2021 (UTC)

People are always discussing ways of reforming RfA. See WP:PERENNIAL. Andrew🐉(talk) 11:01, 29 November 2021 (UTC)

Well yes, and 99 times out of 100 it never comes to anything so although I should have been paying attention, I hadn't really clocked that anything was going on. Yet here we are on the verge of scrapping the existing RFA altogether, yet there's been no specific mention of that on the watchlist, just a generic message that was gone inside a week and I had to find out via the Signpost. If I'm the only one who's not known about this, then that's fine - it's not like I'm going to sway any of this process either way by myself, but I do worry that others may not be aware of this either.  — Amakuru (talk) 11:06, 29 November 2021 (UTC)

Are we "... on the verge of scrapping the existing RFA altogether ..."? I assume you're referring to 8B, the admin elections suggestion, but that is clearly marked as "complementary" to to the existing process. Worm^TT(talk) 11:42, 29 November 2021 (UTC)

There will always be people who feel left out of discussions like this, but with a three-month schedule set out in advance, WP:CENT notices throughout, notices on WP:VPP,[5] WP:AN,[6] WT:ADMIN,[7] WT:RFA,[8] and a watchlist notice that ran for a full week, I think Barkeep49 has done as much as anyone can to make sure this RfC gets wide participation. – Joe (talk) 12:02, 29 November 2021 (UTC)

In addition to what Joe notes, I'll also say that I put together an update list for people to be notified and that this is the third consecutive month the Signpost has covered it[9][10] (thanks to Mikehawk10 for that unsolicited coverage). Widespread participation was always my hope with this process and I'm glad you found your way here now. Best, Barkeep49 (talk) 20:23, 29 November 2021 (UTC)

There seems to have been a surge of interest after the recent Signpost article, so perhaps closing it a few days late would be appropriate? Espresso Addict (talk) 22:09, 30 November 2021 (UTC)

Close date

Quick suggestion. Maybe put the close date at the top of the page. I skimmed the top and was unable to determine the date confidently. Nov 30? Dec 7? Closing at an exact time or flexible on the time? Thanks. –Novem Linguae (talk) 13:18, 2 December 2021 (UTC)

• I'm "closing" it right now; people had enough time to know about this and put down any appropriate concerns, and somewhat importantly I don't believe any eleventh-hour extensions will materially affect any outcomes. – John M Wolfson (talk • contribs) 19:26, 2 December 2021 (UTC)

  Although I agree there isn't much long-term effect to closing discussion (after all, people can keep discussing elsewhere), I think it would have been better for someone who didn't participate in the RfC to close it. isaacl (talk) 20:53, 2 December 2021 (UTC)

  I agree with an immediate close, but I am a bit confused at how John M Wolfson thinks their closure won't be an WP:INVOLVED problem. These aren't just discussions—there's several major proposals we can start implementing if they pass. I thought Barkeep49 found some prospective closers at #Update: End of Proposal Period & Closers, above. When one of them starts reading the discussion to deliberate on outcomes, that would be the time to mark with {{Closing}} and temporarily fully-protect the page. — Bilorv (talk) 21:23, 2 December 2021 (UTC)

  Yes, my understanding was that uninvolved closers would be responsible for that as well. What's going on? Trainsandotherthings (talk) 21:35, 2 December 2021 (UTC)

  There are 3 editors who've volunteer to help close and who are uninvolved in this process. Ultimately I think closing the discussion was the right decision but felt it best for one of the closers to make that call which is why I pinged the (then 2) closers when the tag was removed so they could make a decision. By their inaction and Lee's subsequent comment it seems that they felt some additional commentary was OK. This kind of judgement is probably helped by their being completely uninvolved which, while agreeing on substance with him, think @John M Wolfson was not the right editor to have done it (just as I was also not the right editor). Best, Barkeep49 (talk) 21:36, 2 December 2021 (UTC)

  For convenience I was a bit reductionist in my statement. Although there is at least one proposal I can think of where consensus will have to be weighed closely, personally I don't feel that the trickle of opinions being made at present will significantly alter this determination. But on the other hand, since the discussion lacks acrimony, I don't see any upside in someone other than Barkeep49 or the closer(s) in closing the entire RfC. isaacl (talk) 21:40, 2 December 2021 (UTC)

  @Isaacl:, @Bilorv: and @Barkeep49: You're all right and I agree that John M Wolfson did not actually close the discussion, they had only placed a closure header in good faith so as to prevent any more new !votes because the scheduled time for this RfC has already ended. Since, this is a very important community wide RfC impacting Wikipedia, I have therefore removed closure template and would welcome uninvolved editor/s to close it as per the procedure. TheGeneralUser (talk) 21:47, 2 December 2021 (UTC)

  It seems I was perhaps the only one to misunderstood the situation, but I thought John M Wolfson's comment meant that they had marked the discussion with {{Closing}} and were just about to close each discussion with rationales. So were I an admin planning to close the discussion, I would have seen somebody else was doing it and walked on. Anyway, I still think my comment above stands and removal of the tag was best. — Bilorv (talk) 21:56, 2 December 2021 (UTC)

I apologize for any miscommunication. I have no intention of actually determining consensus in the discussions given my !votes therein, I simply put the "closing in progress" template to stop further !votes given the timing issues. The three volunteers may start analyzing the results at their earliest convenience, and have my utmost gratitude in that job – John M Wolfson (talk • contribs) 22:14, 2 December 2021 (UTC)

@John M Wolfson: That is exactly how I read your update. —¿philoserf? (talk) 22:35, 2 December 2021 (UTC)

Again, I don't think it's a good idea for a participant to close discussion, and since Barkeep49 asked the closers to exercise their judgment, I think they should decide when they want to do it. isaacl (talk) 22:39, 2 December 2021 (UTC)

Update on closing

Echoing something written elsewhere by Isaacl, I want to ask anyone considering closing a section to not do so. This is a multi-month process and any results are likely to play-out for a long time. We are in no rush here. We have a great group of closers lined up, in Lee Vilenski, Primefac, and Ymblanter. They have, for the moment, made the decision to let discussion continue. I would ask that this decision of theirs be respected. There are advantages to having a cohesive close, considering discussion as a whole in addition to discussion of each particular idea. Best, Barkeep49 (talk) 23:30, 2 December 2021 (UTC)

• You're completely right Barkeep49. I also fully agree with Isaacl on what they had said above. There is no immediate urgency as such and it would be better to have completely uninvolved editors (who have not taken part in this RfC anywhere) to close all the individual proposals and in general the whole RfC overall as well with their full detailed rationale. TheGeneralUser (talk) 23:41, 2 December 2021 (UTC)
• I've added a note to this effect at the top of the RFC page. User:力 (powera, π, ν) 23:44, 2 December 2021 (UTC)
• With all due respect, the main 2021 reform page states that November 30 was when the 30 day discussion period end[ed], not that the period was some sort of minimum. While the closers are free to close this phase as they wish, I suggest they do so at a timeline that respects the spirit of that page and not draw discussion out too much longer. As said earlier, people had months to figure this whole process out and those couldn't, or didn't, should not be given undue leave. I highly doubt that any material outcome would be changed much by such extensions in any event – clear-cut cases will remain clear-cut, and controversial cases will remain controversial. – John M Wolfson (talk • contribs) 00:24, 3 December 2021 (UTC)
• Just as a note, there are only three discussions left: 6C, 6E, and 8B. One or two of them might require some inter-personal discussion between closers, but on the whole I think we are nearly there. Primefac (talk) 09:49, 3 December 2021 (UTC)
• I was mulling over whether or not to say this, but in my personal opinion (which you are free to disagree with), I see a narrow consensus for 6C. In terms of numbers, there is a two-thirds supermajority of supports. The opposition is centred around a) ANI being already suitable for this, b) too similar to the deprecated RfC/U and c) the wrong place to discuss this. I think c) is a procedural remark that carries less weight than the other two, which means I see a consensus for an Administrator Review noticeboard, but ensure further discussion takes place with "ground rules" to make sure the concerns of a) and b) are minimised. Ritchie333 ^{(talk) (cont)} 13:00, 6 December 2021 (UTC)

  In the interest of forestalling a spread of discussion to multiple locations, perhaps views on the key points made by different participants can be put forth in the corresponding "Discussion" section of the proposals page. isaacl (talk) 20:14, 6 December 2021 (UTC)

• 6C, 6E, and 8B(+8B.a) are still open - just a check-in to make sure someone was still working on this, even if off-line? Note, should 8B be approved there will certainly be some implementation work to do, and it won't be "fast" (I've started a little behind the scenes work in case it gets approved, details may need to adjust depending on how the closure goes). 6C should be able to be immediately worked on, will need someone to help get process documentation updated if it passes. 6E should be fairly rapid as well, as it is just process and policy adjustments. — xaosflux ^Talk 14:42, 7 December 2021 (UTC)

  Yes, the closers are aware that these threads are still open.--Ymblanter (talk) 15:27, 7 December 2021 (UTC)

Collegial thanks

I feel that the entire 2021 RfA review has been positive and productive. I thank every participate for their time and ernest effort which, today, gives cause for some wiki-pride. Sincerely.--John Cline (talk) 10:33, 3 December 2021 (UTC)

7D implementation

Tracked in Phabricator
Task T297058
Resolved

Hello all! In regards to remove autopatrol from admins, thank you for the RfC section closure User:Primefac. I suggest we do this in a month, after advertising the change on WP:AN and in WP:ADMINNEWS, to give existing sysops an opportunity to self-assign autopatrolled as appropriate. Admins that do certain maintenance functions may want to use this, even if they don't normally "author" articles themselves - to avoid flooding unpatrolled pages. — xaosflux ^Talk 13:01, 3 December 2021 (UTC)

Seems sensible. HighInBC ^{Need help? Just ask.} 13:06, 3 December 2021 (UTC)

Yep, sounds good to me. — Bilorv (talk) 16:54, 3 December 2021 (UTC)

I've added this to the next administrators' newsletter issue. Unfortunately, we just missed the December issue, which means that it'll only be sent out in January. Due to this, I think it may be preferable to wait a week or two until after the issue is sent before removing the right. Tol (talk | contribs) @ 17:29, 3 December 2021 (UTC)

I would suggest that this might be worth a separate mass message to administrators rather than just including it in the administrator's newsletter. I can't find the history around the creation of EFM, but I don't think we've ever explicitly broken out a self-assignable tool from the toolbox. Waiting a week a week or two after that announcement (and post to other appropriate places) before doing the technical side also sounds right. Best, Barkeep49 (talk) 19:17, 3 December 2021 (UTC)

@Barkeep49: we could let them know via Wikipedia:Administrators/Message list - want to craft a message? Should probably include: (a) Pointing to this RfC; (b) Letting them know they can do this, possibly with a link to [[Special:UserRights/{{BASEPAGENAME}}]]; (c) Neutral explanation of why they may or may not want to do this; (d) link to Wikipedia:Autopatrolled. — xaosflux ^Talk 19:31, 3 December 2021 (UTC)

My version of the draft is:

A recently closed Request for Comment (RFC) reached consensus to remove Autopatrolled from the administrator user group. This change will go into effect on (Date 2 weeks from date of sending). You may, similarly to Edit Filter Manager, choose to self-assign this permission to yourself. If you have any questions ask them at the [[Link to AN announcement]]. ~~~~~

As we trust administrators to use the tools they have wisely and competently, I would suggest the link to the RfC, Autopatrol, and a place for questions is sufficient background and a neutral explanation would be unnecessary. Best, Barkeep49 (talk) 19:48, 3 December 2021 (UTC)

With apologies for pedantry, I would suggest changing "similar" to "similarly", as it modifies the verb "choose". Tol (talk | contribs) @ 21:38, 4 December 2021 (UTC)

I have edited the text above with this change. For ease of reading for anyone else who might want to comment on the message I have done so without annotation of the refactor. Best, Barkeep49 (talk) 04:02, 5 December 2021 (UTC)

Hmm. I hadn't considered this aspect. Is it a good idea to encourage admins to assign it to themselves? Will almost everyone then do so, negating this successful proposal as soon as it begins? Instinctively I would say that you shouldn't be giving yourself perms, you should be asking a colleague to give it to you, for transparency. Apart from EFM, a counter-precedent could be that we expect admins not to unblock themselves, even though we technically can?

On another note, when you say do this in a month, can we actually do it in a month? I thought there would have to be a phab ticket, and who knows how long that could take. – Joe (talk) 21:24, 3 December 2021 (UTC)

@Joe Roe: yes it will be a phab, but it is an "easy" type (config file, not software patch) - it will likely go live 1-2 weeks after we enter it. — xaosflux ^Talk 22:49, 3 December 2021 (UTC)

That's good. I suggest we open the phab ticket and I agree a date with whoever is going to flip that bit before any notifications. – Joe (talk) 07:39, 4 December 2021 (UTC)

This has now been done by Wugapodes. Best, Barkeep49 (talk) 04:33, 5 December 2021 (UTC)

It's at phab:T297058 for reference with a patch at gerrit:743646. I can't deploy, so whatever date we want them deployed should be noted at those locations as well. — Wug·a·po·des​ 04:55, 5 December 2021 (UTC)

Well, I had an autopatrolled flag before becoming an admin, and the flag was given to me on the basis of my main space contribution (actually, without me asking for the flag). Earlier today, I restored this flag, and I do not see any problem with it to be honest, my contribution is still 70% or so in the main space, and I still create several articles per week. If someone thinks I have abused my privileges, please say so, but absent exlicit objections I do not consider this action controversial.--Ymblanter (talk) 21:31, 3 December 2021 (UTC)

Oh yeah, if you had it before, that's absolutely fair enough. (Though I had it before too, and I don't plan on retaining it, because after a few years being one of the main admins working WP:PERM/A, I'm convinced that the right should be abolished for all but the most prolific mass-creators.) – Joe (talk) 21:34, 3 December 2021 (UTC)

The RfC wording clearly says it can be self assigned so implementing on that basis is clear. I would suggest my proposed wording does not encourage it. Do you feel differently @Joe? Best, Barkeep49 (talk) 05:32, 4 December 2021 (UTC)

Can, not should. And I think saying a mass message with that in it will have that effect. If we just don't mention, a convention on (re-)assigning it is going to emerge organically, no? – Joe (talk) 07:39, 4 December 2021 (UTC)

Leaving it out makes it unclear whether admins are permitted to assign it to themselves. They may think they have to go through the normal WP:PERM/A process. — Bilorv (talk) 10:45, 4 December 2021 (UTC)

Only a small subset of admins self assigns EFM. Making that parallel makes things clear. Finally I will re-iterate that admins have been trusted to use autopatrol correctly now and it is being removed to make RfA easier not because of current documented abuse. Admins are generally trusted to use their tools wisely and so I trust that telling them that they may do this is no different than the many other things that we tell them they may do but most do not. Best, Barkeep49 (talk) 15:27, 4 December 2021 (UTC)

I feel that newly approved administrators will understand that rights not assigned to them automatically shouldn't be self-assigned without appropriate reflection. Additionally, if the hypothetical commenters whose approval hinged on the absence of the autopatrolled right express their concerns during the request for administrative privileges, there will be a reminder to the admin on this matter. (In an extreme case, if the commenters really don't trust the candidate to avoid self-assignment of the right, they should put forth an argument for opposing the request and convince others to oppose.) isaacl (talk) 16:09, 4 December 2021 (UTC)

I am worried about the increase in articles in the NPP backlog from this. We are already at around 9,000 articles, and our recent NPP backlog drive barely made a dent. Adding a bunch of articles from non-problematic users is not going to help the backlog size. In short, I think it'd be wise to encourage admins to self-assign this right, to help with the backlog, as their creations are almost always un-problematic. –Novem Linguae (talk) 04:57, 5 December 2021 (UTC)

I believe most administrators do not create new articles, and those who do are active enough to assign themselves the flag.--Ymblanter (talk) 18:45, 5 December 2021 (UTC)

@Ymblanter: admins may do other things that benefit from autopatrol, in and out of mainspace. Certain article maintenance tasks related to mergers, moves, transwiki's etc -- so if an admin works in those areas they may also want to avoid bothering NPP. — xaosflux ^Talk 23:23, 5 December 2021 (UTC)

This is correct, but I still believe the effect of removal of the autopatrolled from the admin toolset would only have very little effect on the NPP queue. The main NPP effort is anyway checking whether articles should stay in the mainspace due to sourcing and copyvio issues.--Ymblanter (talk) 06:14, 6 December 2021 (UTC)

Arbitrary ease of reading break

• I asked for Autopatrolled some time before I ran for RfA. Will I need to ask for the permission again? Ritchie333 ^{(talk) (cont)} 13:06, 6 December 2021 (UTC)

  I think that's a judgement call you, as an admin, are capable of making. Personally, I would see zero issue with you re-granting yourself a permission you were given before you even became an admin, just as we will often re-grant the perms given to those handing in their mops voluntarily without the need for them to re-apply at PERM. Of course, I also do not see much issue with any admin granting themselves the flag if they feel it will be necessary, since "good judgement" is one of those things admins are supposed to have in the first place ;-) Primefac (talk) 13:08, 6 December 2021 (UTC)

  Exactly. Keep in mind that the bar to move a new page from unpatrolled to patrolled isn't that high. It doesn't mean this page is brilliant, and in the case of non-article pages it basically only means "this page isn't a CSD". — xaosflux ^Talk 13:13, 6 December 2021 (UTC)

• @Wugapodes: appears to have jumped the gun on this timing disucssion at phab:T297058; not sure if I got a block on it quick enough. We certainly all agree this should happen - but at the least it seems getting communication out before implementation has support above. — xaosflux ^Talk 19:35, 6 December 2021 (UTC)

  @Xaosflux while @Wugapodes had written the change, it was never scheduled for deployment. I'm going to start a subsection with more in just a moment. Best, Barkeep49 (talk) 19:39, 6 December 2021 (UTC)

• @Xaosflux, Regarding your final sentence: Is there any reason we don't just have a bot automatically patrol pages created by extended-confirmed users outside of the four wholely or partly reader-facing namespaces (main, category, portal, template)? (Could also whitelist certain things that aren't reader-facing, like user categories, and could blacklist a user if they somehow get a reputation for constantly creating problematic TimedTalk text pages or something.) I'm aware that this would require a separate discussion, but if we're about to see an influx of non-content-creator admins +AP'ing themselves since they mass-create usertalk pages, now might be a good time for that discussion, assuming it has a chance of success. -- Tamzin^{[cetacean needed]} (she/they) 17:58, 7 December 2021 (UTC)
  • I've never understood this situation at all. What is the purpose of having the patrol feature on editor-facing namespaces? Who monitors these unpatrolled pages and why? When I encounter innocuous unpatrolled pages (like GA review pages), should I be marking them as patrolled? — Bilorv (talk) 18:35, 7 December 2021 (UTC)

  @Tamzin and Bilorv: there are odd workflows such as creating a page, getting it patrolled by someone that doesn't actually look at it (like a bot) - then sub-sequentially moving that page. Other maintenance activities can get mixed in between native patrolling and the PageTriage extension - it is just a messy situation. As far as something like "just mark any namespace_x page by someone as patrolled" - that detracts from literal new page patrol (not "new article patrol") from spotting bad pages being published and overlooked. It is just as bad for us to host Mediawiki talk:A page full of libel about Tamzin as it is to host A page full of libel about Tamzin, and even worse if a workflow would patrol the former and let it survive certain moves in to article space. Unpatrolling after moves has been stalled for many years (phab:T159028). Now for admins, perhaps a bot to patrol any page by an admin would be fine - but without that last change leaves open the door that those sneaky admins would create a page, get the bot to patrol it, then slip it in to an article without the new article patrol people catching it (<sarc> they are very nefarious after all, why we obviously can't trust them with autopatrol </sarc>). — xaosflux ^Talk 18:52, 7 December 2021 (UTC)

  @Xaosflux: I agree that problematic pages are just as problematic in any namespace, but the current situation (even before factoring in AP unbundling) makes that more of an issue, not less. There's only a few people (or maybe just Elli?) who regularly patrol pages in a lot of these namespaces. You, as an OS, can check Ticket#2021052710009446, where I found OSable info that had sat in projectspace for months. I have a currently-stalled project to go through a number of projectspace pages that have slipped through the cracks like that. As such, unless there's a sudden surge in interest in patrolling pages outside of mainspace, I think we'd obscure less abuse by mass-patrolling extended-confirmed editors than we obscure by not. After all, if someone's going to game EC, creating Mediawiki talk:A page full of libel about Tamzin seems like a weird thing to spend that effort on. (Also I'm pretty sure that's just User talk:Tamzin.) If EC is too low a barrier, I still think we should have some sort of whitelist. Patrolling usertalkspace is basically pointless when we have non-AP recent change patrollers creating a few usertalk pages every minute. Likewise I created 39 projectspace pages last month.

  I do agree that the pagemove thing is an issue, though... Seems like something we should have a bot for regardless? -- Tamzin^{[cetacean needed]} (she/they) 21:28, 7 December 2021 (UTC)

  @Bilorv: - anyone that wants to of course! For an easy example, it can be useful when patrolling Special:NewFiles. — xaosflux ^Talk 19:00, 7 December 2021 (UTC)

  @Bilorv: I monitor these pages, you can see a lot in my CSD log. Yes, please mark ones that are fine as patrolled when you come across them. Elli (talk | contribs) 19:49, 7 December 2021 (UTC)

  Xaosflux and Elli, thanks for the information. — Bilorv (talk) 22:11, 7 December 2021 (UTC)

  It is my impression that NPP focuses almost completely on mainspace (articles, redirects, disambiguation pages), and that other namespaces are hardly reviewed at all, are not reviewed in a methodical (every article) way, and are even actively discouraged from getting reviewed. For example, someone asked at WT:NPPR one time if we should be marking userpages as reviewed, and folks said no. There exist checklists for some unusual-to-review namespaces such as template, Wikipedia, and file, but I do not believe reviewing these to be the norm. In conclusion, I do not think we would need a bot to mark these patrolled/reviewed since these don't really show up in a queue that we are trying to empty. –Novem Linguae (talk) 22:32, 7 December 2021 (UTC)

  I think there is a bit of a cult mentality in a vocal subset of editors in "NPR", thinking patrolling of new articles is the most important review function that exists; I think most of the traditional "new page patrol" functions have been combined with "recent changes patrol" (as everything is a change anyway). I agree that patrol of new pages in mainspace is more important than patrol of new pages in some other namespaces - but that doesn't mean that they should be ignored. — xaosflux ^Talk 22:54, 7 December 2021 (UTC)

  Well, note that Special:NewPagesFeed does not even include anything outside article (and user) namespace. That's the feed new page patrollers use. The older Special:NewPages also defaults to showing just articles. I believe the autopatrolled right is also solely granted based on articles created. As such, I too don't think it's desirable for admins who create maintenance pages to add it to themselves, as other editors who create a maintenance pages aren't given autopatrolled. Problematic pages in other namespaces are handled just via RCP. – SD0001 (talk) 18:43, 15 December 2021 (UTC)

  Due to the open nature of the project, and the many tools available, those that want to patrol new "pages" can do it however they want, and they don't need to associate themselves with that wikiproject if they don't want to. — xaosflux ^Talk 19:11, 15 December 2021 (UTC)

7D Rollout plan

It appears that things are fairly set on the "back-end" to implement this change, with the remaining step being to choose a "window" to enact this. My suggestion is to announce, at WP:AN, WT:ADMIN, WT:Autopatrolled, and Wikipedia talk:Requests for permissions in the next day or so with points to discuss at AN. As soon as there is some agreement on the MMS we do that. Revised draft proposal of that message:

A recently closed Request for Comment (RFC) reached consensus to remove Autopatrolled from the administrator user group. You may, similarly to Edit Filter Manager, choose to self-assign this permission to yourself. This will be implemented the week of December 13th, but if you wish to self-assign you may do so now. To find out when the change has gone live or if you have any questions ask them at the [[Link to AN announcement]]. ~~~~~

Because we've already had 1 admin show up to WP:PERM/A asking for this userright which, I am suggesting we put things into motion to avoid further confusion. Best, Barkeep49 (talk) 19:58, 6 December 2021 (UTC)

One further piece. My intent, once we have agreement on all this, is, using my administrator discrestion, to grant the user group to the 129 admins who've had it in the past (or at least since Nov 2011). Best, Barkeep49 (talk) 20:10, 6 December 2021 (UTC)

This sounds sensible to me. — Bilorv (talk) 18:35, 7 December 2021 (UTC)

I don't think there has been any "confusion"? Eddie891 knew he could self-assign it, he just didn't want to (I'd feel better if I weren't the one granting the perm to myself). That makes sense to me and I don't see why admins aren't welcome to use PERM like everybody else? – Joe (talk) 20:37, 6 December 2021 (UTC)

I agree Eddie wasn't confused. The confusion stemmed from MusikAnimal. Best, Barkeep49 (talk) 20:44, 6 December 2021 (UTC)

• @Barkeep49: I don't think there is any reason to delay the communications - lets get it going as soon as possible. (perhaps update Wikipedia:Autopatrolled to reflect the new-state at the same time) My only hold was to not push the config change until a sufficient (2-4 weeks?) period elapsed from the communications. — xaosflux ^Talk 14:34, 7 December 2021 (UTC)

Regarding grammar: the previous wording was an elision of "in a similar manner to Edit Filter Manager". With the change to "similarly", then I think it should be "similarly as with Edit Filter Manager", since the admin is choosing similarly as they would with Edit Filter Manager. isaacl (talk) 14:54, 7 December 2021 (UTC)

I have gone ahead and sent the MMS and posted as I indicated above. I will next be going to the phab to ask for the removal of the hold and the implementation some time next week per the message. Best, Barkeep49 (talk) 20:10, 7 December 2021 (UTC)

Any strong opinions when to schedule the rollout? I'm free during the Monday evening backport window, but if we want to do it later in the week, I can do Thursday as well to line up with WP:THURSDAY changes. — Wug·a·po·des​ 01:03, 11 December 2021 (UTC)

@Wugapodes: think dev's choice is fine - we've sent out our communications, so whenever is convenient over the next week should be fine. — xaosflux ^Talk 03:03, 11 December 2021 (UTC)

Sounds good, I've scheduled it for 19:00, 16 December (UTC). — Wug·a·po·des​ 19:05, 15 December 2021 (UTC)

 Done — Wug·a·po·des​ 19:35, 16 December 2021 (UTC)

RWHITELIST?

With the stripping of autopatrol from admins, should we add all of the admins to Wikipedia:New pages patrol/Redirect whitelist - or make them all go through the request or self-assign process there if not getting back in to normal autopatrol? — xaosflux ^Talk 19:07, 7 December 2021 (UTC)

Great question @Xaosflux. I'm going to ping Rosguill who is the admin who most actively works that but my first impression is I think we should add all admins to the redirect whitelist. If we have an admin whose redirects aren't even OK that would strike me as an issue of overall competency. Best, Barkeep49 (talk) 19:10, 7 December 2021 (UTC)

We used to have an admin who created a lot of redirects which we not ok. The admin was eventually blocked and the redirects deleted. I guess if we discover another one (unlikely in my opinion) we can delete their redirects as well.--Ymblanter (talk) 19:29, 7 December 2021 (UTC)

I had exactly that user in mind when writing that if someone can't be trusted to create redirects, I would question their fitness to be an admin. Best, Barkeep49 (talk) 19:41, 7 December 2021 (UTC)

Wouldn't we want that to come to light through NPPs stumbling on the bad redirects, then? Personally, as a redirect patroller, I'd rather we take a short-term hit in the size of the queue, but liberally add admins to the whitelist without requiring as large a body of redirects as we do with non-admins (basically just an "are you recreating anti-trousers?" test). -- Tamzin^{[cetacean needed]} (she/they) 21:34, 7 December 2021 (UTC)

This change wasn't justified under the rational that admins are abusing autopatrol. It's being made to make RfA easier. Barkeep49 (talk) 21:43, 7 December 2021 (UTC)

Yes, but now that it is being unbundled, the question of whether admins should be automatically redirect-whitelisted is a question of what's in the best interest of redirect patrol. -- Tamzin^{[cetacean needed]} (she/they) 22:07, 7 December 2021 (UTC)

Barkeep49, I don't have much of an opinion either way as far as adding admins to RWHITELIST is concerned. IMO we could add them all, or we could leave it be and only add them if I or other reviewers identify them as high volume/high precision redirect creators. _signed, Rosguill ^talk 19:47, 7 December 2021 (UTC)

Limitation on digging into the history of candidates

I'm probably late to the party, but I just came up with this. Put some sort of limit on how much digging is allowed when a candidate presents themselves in an RfA. Example of possible restrictions:

Questions or concerns about anything that is over 1 year old may only be brought up/discussed if at least one of the following is true:

• The candidate brings it up first.
• It concerns general statistics. (for example: "in 2015 the candidate made 100 edits, 50 of which were reverted")
• It concerns an issue related to adminship on any Wikimedia project. (for example: a failed RfA or wheel warring on another project)
• It concerns an issue that was handled by the Arbitration Committee.

Something like this would perhaps help to stop users from digging up mistakes that just aren't relevant anymore. Exact requirements may need adjustment, but possibly an idea worth exploring. — Alexis Jazz (talk or ping me) 14:41, 6 December 2021 (UTC)

@Alexis Jazz, I would expect the community will need a little breathing time after this process. But one of my hopes is that in the medium term that the consensus reached during Phase 1 could still be used for further improving RfA. As to the merits of this proposal in my attempt to spur discussion I had thrown out an idea during the Brainstorming phase which you might be interested in. I think there are real limits to these kinds of rules, but there does seem to be community agreement that digging through candidates' pasts does not help with RfA so perhaps with further refinement there is a viable proposal to be had. Best, Barkeep49 (talk) 16:04, 6 December 2021 (UTC)

Barkeep49, I see. I think changing the weight of votes is difficult to apply, potentially gives crats too much power and once something has been mentioned it can influence other voters anyway. It's also too late: the point is too make potential candidates more comfortable that we let bygones be bygones. Simply putting a restriction on what may be dug up (and revdelling anything that violates that) should be more effective, at least in theory. — Alexis Jazz (talk or ping me) 16:38, 6 December 2021 (UTC)

6C Implementation

I have started a discussion on implementing 6C Administrative action review. Interested editors are invited to join in. Best, Barkeep49 (talk) 23:11, 10 December 2021 (UTC)

Question related to 6E close

Thanks Ymblanter, Primefac, and Lee Vilenski for the close of 6E -- obviously it is not the outcome I would have preferred, but your close is a thorough and fair summary and analysis of the discussion, so I have nothing to complain about. In the close, you raised the possibility of running an RfC for an improved version of this proposal. I am not going to pursue that immediately (I think it would be good to wait at least to see to what extent other implemented proposals have a positive effect). However, if at some point in the future I do decide to pursue it, is WP:PROPOSE the correct venue? Or somewhere else? Thanks again, JBL (talk) 13:44, 13 December 2021 (UTC)

I think that would be a reasonable place to put it, yes. Additional cross-posting to WP:AN and T:CENT would probably be wise as well. Primefac (talk) 14:19, 13 December 2021 (UTC)

Yeah, that's the idea. I don't have any prejudice against another RfC being created about this, unfortunately this one wasn't quite clear enough to enact. Indeed it would be wise to give it some time before doing so as you suggested. Best Wishes, Lee Vilenski ^{(talk • contribs)} 14:37, 13 December 2021 (UTC)

Thanks both! --JBL (talk) 18:48, 13 December 2021 (UTC)

What a waste of time

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

---

Seeing that the proposal to create admin elections has inexplicably failed, this whole process has resulted in admins losing the autopatrolled tag - which they can still give to themselves - and another community forum that lacks the ability to desysop admins. What a fucking waste of time. Calidum 17:03, 14 December 2021 (UTC)

• By the way, I'm considering taking the close of the admin election section to WP:AN if someone doesn't beat me to it. The so-called reasons for it failing are merely issues that can be hashed out in the future, not items that had to be addressed in an RFC like this. Calidum 17:06, 14 December 2021 (UTC)

Agreed. * Pppery * _{it has begun...} 17:04, 14 December 2021 (UTC)

Agreed. The closure was wrong. The technical issues with SecurePoll had been refuted. It's strange to see that a project as large as the English Wikipedia believes that SecurePoll is restricted to one election in the whole wiki-verse at a time! 4nn1l2 (talk) 17:09, 14 December 2021 (UTC)

Q1 was also slightly modified. — xaosflux ^Talk 17:10, 14 December 2021 (UTC)

My hope is that WP:XRV can later be given the ability to desysop, with another RfC. This would effectively lead to a pass of 6B (which I proposed), except at a different venue. Most opposition to 6B was on the grounds of AN(I) being a cesspit, perhaps ironic given I say as much loudly and frequently. However, I at least believed at the time of proposing that suggesting the same thing at a new venue would have garnered exactly the same amount of opposition but with different arguments. (If you go too broad, it's "oppose: too few details"; too specific and "oppose: based on this one detail" Also "we don't need a new venue for this", "it won't work because I haven't already seen it existing and working", "slippery slope to X", "nothing to do with solving RfA" etc.) — Bilorv (talk) 17:38, 14 December 2021 (UTC)

Are there still issues to be worked out? Yes. But there was also significant consensus that this idea should be pursued further. For that reason, I don't agree with this close. Trainsandotherthings (talk) 18:13, 14 December 2021 (UTC)

~ ToBeFree (talk) 18:48, 14 December 2021 (UTC)

• Making major policy changes is hard. It often takes multiple tries to even get incremental changes. I would suggest that planning a follow-up RFC is likely to be more constructive than challenging the close and having an ANI dramafest about it. There is some advice here on some alternate structures that might be considered to avoid the sort of sprawl we saw in this process. If you reduce the issue down to the absolute core issue, "should we have admin elections using secret ballots, or should we not do that?" and decide just that one point, that would be progress. It's not an RFC format that should be used often as it is rather restrictive, but is effective in situations like this one. Beeblebrox (talk) 19:45, 14 December 2021 (UTC)

  If you ask that core question, you'll get a resounding "no". People can at least rally in support of a new idea meant to get new admins that can be trialled as soon as the RfC passes. Asking questions in the abstract results in people giving you their idealistic post-hoc reasoning to justify the status quo. (I'd love to be proven wrong though.) — Bilorv (talk) 22:17, 14 December 2021 (UTC)

  Not sure how you came to the conclusion the answer would be no. Support ran fairly high, and a significant number of those in the oppose camp suggested that they supported the general idea, but not the specifics. That being said, the goal is to get a concrete yes-or-no result. The restricted process forces that. I'm not at all sure it's been used since Wikipedia:Pending changes/Request for Comment 2012, but it succeeded in answering that one question, implementation was delayed until three smaller, less restricted follow-up RFCs worked out the details. That model could work here. Beeblebrox (talk) 22:26, 14 December 2021 (UTC)

  In a way, the question was asked during phase 1, and the answer was a resounding "no". – bradv^🍁 22:35, 14 December 2021 (UTC)

  There was a resounding "no" to "get rid of discussion", which isn't what 8B proposed... —Kusma (talk) 11:57, 15 December 2021 (UTC)

  Agreed. I think it was/would have been naive to expect major change from this, considering how a large part of the proposals involved creating something new as opposed to a policy change. A fully-functioning community desysop process or even an alternate RfA process was unlikely to happen from the get-go, but establishing XRV is a good first step, and (inevitably) the next time there's an RfA reform attempt it'll be easier to improve on that then try to whip up an entirely new and likely controversial desysop process. Was it all worth a 3-month RfC? I dunno. Giraffer ^{(talk·contribs)} 10:02, 15 December 2021 (UTC)

• I didn't particularly expect anything else; all the major stuff has been perennially proposed and defeated in the past for various reasons, and there's a reason RfA is currently what it is. I opposed the admin elections idea myself, and still do, so I recuse myself in considering whether its close was accurate, though it does seem like it's at least reasonable. I do think whoever proposed the autopatrolled removal will be sorely disappointed to find that admins will still be expected to make content, however. – John M Wolfson (talk • contribs) 22:38, 14 December 2021 (UTC)
• It's a disappointing outcome, but I can't really fault the closers. From a numerical perspective, the support percentage was below 65%, outside the traditional RfA discretionary zone: it would certainly be counterintuitive to fundamentally restructure the adminship process with less support than it would normally take to pass even a single RfA candidate. And while I evidently think more highly of the supporters' arguments that the closers did (I !voted for 8B, after all!), it nonetheless seems to me that, despite the concrete issues with the proposal raised by the opposers, many supporters tended to justify their !vote with little more than the politician's syllogism. I don't think challenging the close is likely to be very productive, and dragging this out further doesn't seem like a good idea: it can't be a total coincidence that the longest drought of successful RfA candidates in history is overlapping with this discussion. It seems to me that, at least for now, it would better to play with the cards we've been dealt. There's been some great work recently trying to recruit new candidates for adminship: that's something that anyone can do, with no further discussions required. Again, this isn't the outcome I would have preferred, but there really isn't anything we can do about that. Extraordinary Writ (talk) 23:23, 14 December 2021 (UTC)
  • From a numerical perspective, the support percentage was below 65%... Well, it was 72/111 = 64.86%. Also interesting, among editors who have already been through RFA, support was only 43% (19 support, 25 oppose), while among editors who have not already been through RFA, support was 79% (53 support, 14 oppose) (by my count). Levivich 01:27, 15 December 2021 (UTC)

    Huh. Can you give me a breakout by recent RfAs? Asking because of that chip in your head that lets you do that kind of analysis with a snap of your fingers. —valereee (talk) 03:25, 15 December 2021 (UTC)

    Sadly, no :-( But we already know "recent admins" are less than 10% of active admins. Levivich 13:56, 15 December 2021 (UTC)

    Out of curiosity, when you refer to editors have been through an RFA, are you referring to only admins or all editors who've been through an RFA? Calidum 17:52, 15 December 2021 (UTC)

    You're right, just admins; I didn't try to count former admins or unsuccessful candidates; basically just going off the admin highlighter. Levivich 17:56, 15 December 2021 (UTC)

    • Merci beacoup. Calidum 18:00, 15 December 2021 (UTC)

• It's very depressing that we have general agreement that RfA is problematic but every proposed solution gets kneejerk opposition from a contingent who simply argue "ain't broke, don't fix it" and "solution in search of a problem". If we've already agreed RfA is problematic, those arguments ought to just be discounted by closers as off-topic. —valereee (talk) 00:41, 15 December 2021 (UTC)
• Definitely not a waste of time. This was an ambitious exploratory RFC trying to deal with an enormously complex issue, but limited to the RFA process itself. I found the RFC moderation and closure very sensible. I find the 8B close perfectly reasonable (as described by User:Extraordinary Writ). I would contend this process was overbold in that it anticipated clear solutions to be generated during a multi-track RFC on a single pass !vote. I felt my 8B issues (politics, outside actors) unaddressed in discussion. My biggest surprise was seeing the large group of respected editors who might choose a less consensus-based voting process. I don't like the idea of any elections on Wikipedia but am willing to hear good cases made. The next step is to generate and discuss a voting proposal which might get support from 8B opposers and let THAT run at RFC. Contributors who want to expand and explore the RFA process by actual vote have been shown to have significant community support. This seems a step forward. I am more amenable now to hearing those cases made. BusterD (talk) 01:12, 15 December 2021 (UTC)
• It's especially ironic that the secret ballot proposal was dismissed by a cabal that insists that their discussion and voting must remain private while that of the majority should be public. The Iron Rule trumps the Golden Rule! Andrew🐉(talk) 09:37, 15 December 2021 (UTC)

  It is just bullshit. We did not vote.--Ymblanter (talk) 09:55, 15 December 2021 (UTC)

  (edit conflict) We simply closed a discussion. There is no vote. Suggesting volunteer users are a cabal is a bit disrespectful. We all agreed that this was a suitable interpretation of the discussion. Similarly, the discussion is not a vote. There being outstanding issues with the opposers make it difficult to support implementation. However, that doesn't mean this will not happen, it means that this discussion didn't show a pure consensus of how to progress with it. I'm in little doubt that if a little more thought went into a future RfC, with the merits of the oppose !vote here addressed, it would fare better. That would be the solution for this to move forward. If you have ever seen a committee close of an RfC take place on-wiki, let me know, it's not common. Best Wishes, Lee Vilenski ^{(talk • contribs)} 10:16, 15 December 2021 (UTC)

  See WP:CRATCHAT as a relevant example of a public process for determining consensus. Andrew🐉(talk) 10:37, 15 December 2021 (UTC)

  That is very much a different process to the close of an RfC. Best Wishes, Lee Vilenski ^{(talk • contribs)} 10:56, 15 December 2021 (UTC)

  If somebody wants to formalize the RfC closing process, for example add a policy/guideline/whatever that joint closing process must occur on wiki and be logged, one would need to start some consensus-building process for that. The current practice for RfC closing is that there is no onwiki deliberation.--Ymblanter (talk) 11:22, 15 December 2021 (UTC)

  This method of closing seems quite undocumented as a policy or process. It needs work because the closers currently seem to be self-appointed. And, in this case, Primefac should have recused because, as a bureaucrat, they have a vested interest in maintaining the current process. Use of mechanisms like SecurePoll would tend to eliminate the discretionary power which arises in the close calls which go to crat chats. Andrew🐉(talk) 13:49, 15 December 2021 (UTC)

  Why would I have a vested interest in maintaining the current process? It's not like I get paid per byte added to a 'crat chat. Primefac (talk) 14:03, 15 December 2021 (UTC)

  (ec) These might be or might be not valid objections, but they must have been raised before we started closing. There was sufficient time to do this. This is also correct that closing, and, in particular collective closing, is not well documented, however, it is a very widespread current practice, and if you want to stop it as illegal or significantly change it this page is probably not the best venue for it.--Ymblanter (talk) 14:06, 15 December 2021 (UTC)

  The writing of panel closes almost always happens offwiki. So while it may be undocumented it is not out of process in some way. It is no less transparent than if a single editor makes the close and it appears from nowhere. In general I am against panel closes. But where they add value they do so because all the closers sign their name to a single statement and agree to the finding of consensus (or finding the lack of it). A CRATCHAT is an entirely different kind of exercise - it is essentially a !vote in the same way that RFA is a !vote and since individuals are representing themselves it follows that they !vote for themselves in a way similar to other processes. I would suggest a Village Pump discussion if you'd like to document this and/or change our culture rather than attacking this particular close as improper because it used an accepted (if somewhat infrequent) procedure. Best, Barkeep49 (talk) 15:57, 15 December 2021 (UTC)

  And, in this case, Primefac should have recused because, as a bureaucrat, they have a vested interest in maintaining the current process – The problem is that all admins have a vested interest in many topics touched on by this proposal (e.g. anything relating to desysopping), and in the other topics they will have biases ("I had to pass RfA proper, so why should new people get a shortcut?"). I would have liked to see a non-admin as one of the discussion closers, but I understand this would not be the most appropriate based on current policy. As it stands, Primefac was one of the best people to close the discussion, per their extraordinary expertise and respect amongst the community. — Bilorv (talk) 17:41, 15 December 2021 (UTC)

  @Bilorv I am not sure how much vested interests admin or crats have. They may have a different perspective but saying different perspective is very different than "vested interest" which implies an unfitness, under our definition, to be a closer. All that said I agree that being an admin wasn't strictly necessary to close which is why I worded the open solicitation as any other uninvolved editors with the experience to do so would like to help with the close. The problem is that I think many of our uninvolved non-admin editors with the experience to close something like this choose to participate so it wasn't a particularly large pool to pull from. Best, Barkeep49 (talk) 18:02, 15 December 2021 (UTC)

• The close of 8B is baffling. I've read it many times now and as far as I can understand (seriously, guys, you had two weeks: give it a quick read through and edit before you post), the assessment is that the oppose side had "more arguments" and, because supporters didn't explicitly refute all of them, that carries the day. I have never encountered this understanding of consensus before. – Joe (talk) 10:12, 15 December 2021 (UTC)
• (edit conflict) It seems like the main issues outlined were behavioral ones, and I doubt a new RfA process would have changed that – whatever the method, it would have involved deciding who should administrate the entire website, and naturally the atmosphere at that venue would (and does) get heated as people try to support or oppose someone who is or isn't part of their idea of how the wiki should be run. Giraffer ^{(talk·contribs)} 10:20, 15 December 2021 (UTC)
• 8B's close is clearly wrong (saying that as someone who voted oppose), but even then, anything reasonable that could've had substantial impact on RfA was declined (6E, 7A, 8B). I think the only useful thing to come out of this process is WP:XRV. ProcrastinatingReader (talk) 11:22, 15 December 2021 (UTC)
• I agree that the close of 8B was wrong. I could have accepted an argument that the numbers are insufficient for such a large policy change (but note that some opposers are supporting the general idea), but the strength of argument thing boils down to whether "technical problems with SecurePoll kill this" is true or not, something that could have been figured out later. —Kusma (talk) 11:33, 15 December 2021 (UTC)

  Indeed. Technical implementation 'concerns' are almost never a valid reason to block an RfC. Perhaps if what's being proposed is completely infeasible and/or no reasonable path to implementation is given, but otherwise no, and in this case paths were given. Same as in WP:PHAB where a technical person can write a patch but its deployment can be 'blocked on community consensus', you can have an RfC that passes which says the community supports the implementation of a certain idea, and if technical people can figure out how to make that happen then it can be implemented. (see eg WP:DC2016). Trying to require implementation details be worked out while also remaining simultaneously blocked on community consensus is an unworkable and tiring way to proceed. ProcrastinatingReader (talk) 11:41, 15 December 2021 (UTC)

  @ProcrastinatingReader: that is certainly a consideration - what this closure seems to signal now is: don't bother working on any technical tools to support this idea, because communities don't want it anyway. — xaosflux ^Talk 12:01, 15 December 2021 (UTC)

  100% agreed. This is just one of many "damned if you do, damned if you don't" barriers in attempts to reform any area of Wikipedia. — Bilorv (talk) 17:41, 15 December 2021 (UTC)

• I don't understand how the closers could call the "secure poll won't work" argument "strong" or even "accurate". What evidence was there that this was even true? Most voters (a supermajority) weren't swayed by it, so it seems it would need some strong objective evidence to "prove the majority wrong" as it were, but I don't see that evidence, whereas I see a refutation in one of the support votes. Ymblanter, Primefac, Lee, can you explain this part? Levivich 13:56, 15 December 2021 (UTC)

  Folks in this discussion seem to be missing the point made by the closers that there were multiple objections raised by the opposition, SecurePoll issues being just one of them. Primefac (talk) 14:03, 15 December 2021 (UTC)

  I'm not missing that there were multiple objections, I'm asking about one on the list. I don't feel the SecurePoll objection was "stronger" but you said it was, and I'm asking why. The closing statement is a little light on specifically what those multiple objections were and why exactly they were stronger or unanswered. The implementation-was-unclear objection is the one that's more glaring. I also don't understand why the scrutineer objection was considered strong, or even relevant. What I'm really asking is why you didn't find that supporter's responses refuted those concerns. Levivich 14:09, 15 December 2021 (UTC)

  We could probably debate whether "stronger" in the close applies to the opposition as a whole or each individual part of said opposition, but my position is with the former. That being said, there were not only the technical issues about SecurePoll (and/or some unknown alternative which had one person comparing the issue to this ACERFC2020 option that passed but never got implemented), but also how it would be scrutineered (if at all, and would CUs do this or stews, do we really want to CU everyone for every RFA, etc), uncertainty about voter guides, lack of feedback, and the drive-by nature of secret ballots and how they tend to cause a dramatic drop in supports. I don't think any of these issues are necessarily impossible to surmount, but there was a distinct lack of answers for many of these questions that should be answered before this question/proposal is asked again. Primefac (talk) 14:19, 15 December 2021 (UTC)

  I appreciate you taking the time to answer me but I literally don't understand the words you're writing. Can you pick any one of those on the list and explain to me how you determined that this item was a "question that should be answered"? For example, I don't care about voter guides. Why do voter guides need to be figured out before this proposal has consensus? According to whom are voter guides a threshold issue? Not according to a supermajority of voters. So is there some global consensus about voter guides you're implementing? Otherwise, why are we talking about voter guides at all? I have the same questions for the other items on your list: securepoll, scrutineers, I don't know what "lack of feedback" or "drive by nature" means... these are features not bugs, I voted for this because I want "lack of feedback" (less arguing) and "drive by nature (secret polling), so I don't know what it means to say these things were "unanswered" and need to be "answered". So I'm asking why you felt these things (a) needed to be addressed and (b) weren't addressed. Levivich 14:27, 15 December 2021 (UTC)

  Those in support wanted quick-and-easy voting with less stress so that we get more candidates running for adminship. Those opposed found issue with how they wanted to do that. You might not find scrutineering to be an issue, but some were worried that if the CUs and stewards refuse to do the scrutineering (as any SecurePoll election should have to avoid socking) there is the risk of socks unfairly tipping the vote in one direction (either electing a problematic candidate or tanking a good one). Regarding (in my words) "drive-by-voting", the current cutoff for an admin to be promoted is 75% support; multiple examples were given by the opposition that SecurePoll voting (and secret voting in general) drastically decreases the support percentages in a race (be it a no-candidate-passes CUOS or the fact that hardly any ArbCom candidates even reach that mark).

  Again, it's not that every issue was a huge deal (I concur that questions about voting guides are on the lower end of "weighty"), but it was more the quantity of problems listed. If it were just one or two issues this would be a pass, but when there are a half-dozen problems that the opposition find, it starts to add more weight to that group's overall opinion on the matter. Primefac (talk) 14:39, 15 December 2021 (UTC)

  @Primefac: dependence on scrutineering seems to be getting a bit more attention than I think it should - even with the current securepoll extension, as the list of voters is public - just like it is at RfA, and logged in accounts (with suffrage requirements as proposed) were going to be required -- this should have had negligible difference between the ability to investigate sock puppets over those !voting in the traditional RfA page - as suspicious accounts could still be locally investigated and the election rules could allow for striking of votes for sockmasters and sockpuppetets (or for any other supported reason). I certainly would have expected some more work on the election "rules" would have needed to be defined, but I'm not seeing this argument as being any different than unchecked socks tipping the vote today --- really the only difference would be if sock phishing expeditions are being undertaken primarily because of the value of one's vote today (e.g. only investigate fishy opposes, not fishy supports). — xaosflux ^Talk 16:15, 15 December 2021 (UTC)

  (ec) And, specifically concerning the secure poll, it is not surprising that most folks never had to deal with it (other than being voters) and probably did not notice the opposition or did not consider it significant, but, to start with, the secure poll is not something which is run by the English Wikipedia. It is run by the WMF, and every single ArbCom election has to be coordinated with the WMF, and we had issues in the past when the voting was delayed or about to be delayed because the secure poll was not prepared. Any future discussion / RfC / whatever must take this into account: Either the opinion of the WMF on whether they are going to do it is needed, or somebody has to write a local analog and make sure that all security issues etc have been carefully considered so that we do not have data leakage. As we pointed out in the closing statement, this probably can be figured out, but it needs to be done for a proposal to be successful.--Ymblanter (talk) 14:33, 15 December 2021 (UTC)

  Exactly: "did not consider it significant" ... so why are the closers imposing their view of significance? Dozens of editors did not consider it significant but you consider it a threshold issue. Why do you get to decide that? Closers are supposed to summarize the discussion and you just did it: most voters did not consider the objections significant. Ergo, consensus. Levivich 14:42, 15 December 2021 (UTC)

  We do not know. They did not address them in any way. It is my guess that some of them did not consider they objections significant.--Ymblanter (talk) 14:49, 15 December 2021 (UTC)

  @Ymblanter on that, I rather disagree, Secure Poll need not only be run through WMF. @Xaosflux has been working hard behind the scenes to look at options with regards to secure poll. At present it is run by WMF on Vote Wiki, but there's a possibility (depending on encryption requirements) of having the extension installed on en.wp and managed completely by us. There were other technical options being looked at as well - I fully accept that we weren't "techncially" ready for an RfA election tomorrow, but the I do think that we were pushing towards a consensus that it was something that we should be considering. I had generally expected the close to be something along the lines of "Consensus for the idea but with reservations, and a subsequent RfC to tidy up". Worm^TT(talk) 14:42, 15 December 2021 (UTC)

  We thought instead that the issues were so serious that different voters though they were voting for different proposals. Indeed, I think the proposal if prepared with taking the opposition into account has a chance to pass, but this is what we have written in the closing statement.--Ymblanter (talk) 14:53, 15 December 2021 (UTC)

• This "argument counting" principle seems to argue that a large number of weak arguments should outweigh one strong argument. This seems contrary to the notion of consensus based decision making and the nature of Wikipedia. Editors weighed the strength of the various arguments on their own merits when deciding to support or oppose. Closing administrators should not come along and discard an existing consensus by imposing their own judgement on the community. W42 14:32, 15 December 2021 (UTC)
  • Notwithstanding the "!", numbers do in fact matter when the results get tight in determining rough consensus. – John M Wolfson (talk • contribs) 16:35, 15 December 2021 (UTC)
• I'll just say I do think it's a shame that the closers came to an "unsucessful" conclusion. I see that there was a firm consensus for trying something along these lines, although I also see a need for a follow up RfC to address some of the questions around the election system - and had I been closing this I'd be closing it in exactly that sort of form, something like "While there is a consensus that something around admin elections should be tried, there were too many questions remaining open to call this a successful proposal. The closers recommend a follow-up RfC to clarify this proposal". Now, I get that I'm biased (having suggested 8B in the first place), but I do feel the close has rather kaiboshed future development from a technical perspective as well as closed the avenues of future RfCs due to voter fatigue, combined with clear "unsucessful" outcome. Given the level of support to opposition, well, it's a real shame. Worm^TT(talk) 14:53, 15 December 2021 (UTC)

  I agree with this thought. I think the community does generally want to keep moving forward, and I hope that this close (which does make sense), does not kibosh the momentum this RFC created. --Enos733 (talk) 17:14, 15 December 2021 (UTC)

• Poor close. A 72:39 tally being closed as unsuccessful is always suspicious. First, the technical side of the proposal (...) is unclear should not even have been irrelevant. The goal of the RFC should be to establish whether the community wishes to use SecurePoll (or an equivalent system). Working out the technical details could be done later – and the right people to do it in this case isn't even the community. All that matters is that there should be plausible ways to implement, which do exist in this case. These refutals were made in the discussion [11] [12] [13] [14] It's pathetic the "issue" of voter guides is even mentioned. Are we incapable of holding a mini-discussion to work out what should be done about voter guides? It is not something that needs to be sorted out in advance. – SD0001 (talk) 17:02, 15 December 2021 (UTC)
• 7D should never have passed, I'm curious to know which admin(s) create terrible because as far as I'm aware none have (or I did know and have completely forgot). Either way the proposal has achieved nothing more than it did on the 7th Dec. –Davey2010^Talk 18:11, 15 December 2021 (UTC)

"Additional reasons to oppose"

The technical aspects relating to secure poll have been raised above, but one issue in the close I feel needs to be brought up are the "additional reasons to oppose" cited by the closing statement. Among those is a "drop in support due to the secret ballot nature," an apparent reference to arb com elections. As far as I can tell, this argument was raised by one user (or maybe two) who didn't even cite actual evidence of this. A quick look at recent arbcom election results will show most candidates get at least 60% percent these days, and maybe half get two-thirds support (I of all people managed nearly 55% in 2016). Also cited by the close is opposition due to "absence of the feedback to both successful and unsuccessful candidates," but that is a feature, not a bug, and is meant to address the community's findings in the initial stage of this process as evidenced by Wikipedia:Requests_for_adminship/2021_review/Proposals#Issues_identified. Calidum 15:18, 15 December 2021 (UTC)

• In Phase 1 I proposed a secret ballot with feedback options, which did not advance very far from an idea (admittedly due to my subsequent opposition to the whole election idea). It is thus certainly possible to have secret ballots without losing feedback associated with votes, which can prove valuable; a corrosive RfA atmosphere due to abuse of feedback ability is not a reason to fully discard such feedback and it thus remains an issue.
  Notwithstanding all that, there is certainly the argument that the support:oppose ratio, which was less than 2:1 and would be at best an extremely controversial individual RfA, is simply insufficient to support a great overhaul of the whole RfA system. While I'm certainly biased by having !voted against the proposal myself, I think a no-consensus close would be supported by that. There are certainly arguments against applying such a strict standard and if one really wanted to he or she could insist on respecting a result that was substantially above the majority (and, as said earlier I'm unqualified to close anything against that), but per Speaker Denison's rule the status quo should be the favored default. – John M Wolfson (talk • contribs) 16:28, 15 December 2021 (UTC)

  @John M Wolfson: as the purpose of Phase 1 was to identify current problems - changing the ballot type is more of a solution attempt then a "current problem"; so that it didn't advance far in that phase doesn't surprise me - as phase one wasn't for solutioning. — xaosflux ^Talk 16:33, 15 December 2021 (UTC)

  @Xaosflux: In fairness, I only proposed it in passing and only bring it up now as an example of relevance of "feedback" even with balloting. – John M Wolfson (talk • contribs) 16:35, 15 December 2021 (UTC)

Goal of this discussion?

At this point I would suggest that there has been fairly extensive discussion of the close with the closers. I see no indication that they are re-evaluating the close. Sometimes with an issue like this people just need a place to express their frustration that under WIkipedia practice sometimes a nearly 2/3 majority isn't enough to change things. I know that feeling well and so if that's what people want please don't let me stop you. If people are hoping to have the close of 8B changed, however, I'm not sure more discussion here is going to achieve that would suggest thinking about what WP:CLOSECHALLENGE suggests as next step(s). Best, Barkeep49 (talk) 16:53, 15 December 2021 (UTC)

It's only been a little over 24 hours since 8B was closed. I'd say give it some more time (another day or so) before anyone considers close challenge to allow editors to learn about the close, read it, read this discussion, and chime in if they want to. The closers should also be given at least a day to read and reflect on the post-close comments. Levivich 17:47, 15 December 2021 (UTC)

That's fair. There's been a high volume of edits but not a lot of time. Best, Barkeep49 (talk) 17:51, 15 December 2021 (UTC)

• I concur that 8b was wrongly closed. The close does not reflect community consensus. It should be reverted and reclosed by others.—S Marshall T/C 11:27, 16 December 2021 (UTC)
  • ... and no response from the closers. The proper venue for a close challenge is AN and I suggest we raise it there.—S Marshall T/C 15:14, 17 December 2021 (UTC)
    • We just disagree. AN is indeed the place to make sure that the close is reverted and reclosed by others.--Ymblanter (talk) 17:20, 17 December 2021 (UTC)
• I concur that somebody ought to challenge this close, but I for one do not feel qualified to do so. I note for any prospective challenger that, even without getting into the validity of technical opposes, at least one oppose vote was based on an entirely false premise (Scottywong's), saying that they only opposed because they didn't want it to be the only method of attaining adminship, despite the fact that it would not be the only method of attaining adminship. Also, invalidOS's vote was also based on the same false premise. Jackattack1597 (talk) 22:32, 17 December 2021 (UTC)
• I guess I should chime in here as the person who started this thread. First, I must say I appreciate all the comments here agreeing the close was improper -- many of you made the case much better than I could have. I must also say I am disappointed that the closers have shown no willingness to reconsider their close, but I guess that is to be expected. While I mentioned I was considering taking this to AN, I feel like others above would make a much better case than I could and would prefer someone else handle opening it. Calidum 23:14, 17 December 2021 (UTC)
  • It's not "improper", it's just wrong. Taking into account that level of community participation and that level of reasoned debate, the available closes were "no consensus" or "consensus to approach the WMF to discuss technical requirements". A close as "unsuccessful" was not available to the closers in the face of those numbers. Our closing guidelines say a close isn't a headcount, but then go on to say at WP:NHC: Consensus is not determined by counting heads, but neither is it determined by the closer's own views about what is the most appropriate policy. The closer is there to judge the consensus of the community, after discarding irrelevant arguments: those that flatly contradict established policy, those based on personal opinion only, those that are logically fallacious, and those that show no understanding of the matter of issue. If the discussion shows that some people think one policy is controlling, and some another, the closer is expected to close by judging which view has the predominant number of responsible Wikipedians supporting it, not personally select which is the better. In this case, the rule is modified by the context: we're talking about changing a policy, so it necessarily follows that arguments that would modify current policy must be permissible, and it also necessarily follows editors' personal opinions about policy are to be given full weight. But the closing statement is quite clear that the closers did not judge which view had the predominant number of responsible Wikipedians supporting it, and they did personally select which view was the better. To my eye, the word "improper" doesn't really express the problems with this close. I'd go with "inaccurate" or simply "wrong".—S Marshall T/C 12:07, 18 December 2021 (UTC)
    • If there are no further comments, I will open a close review in the next day or so.—S Marshall T/C 10:02, 19 December 2021 (UTC)
      • It's unclear to me what this is likely to achieve. How does one validly review a joint close by three highly respected editors, chosen in advance to perform the close, who stand by their close despite some adverse comments? Espresso Addict (talk) 01:21, 20 December 2021 (UTC)
        • The same way one reviews any other close: ask other highly respected editors to read it and weigh in. Levivich 01:31, 20 December 2021 (UTC)
          • Yes, the how of it is really straightforward. I'm delaying mainly to give the closers every last chance to enter into a dialogue, as it would be discourteous and uncollegial to rush to AN without doing so.—S Marshall T/C 02:31, 20 December 2021 (UTC)

            Thing is, they've quite clearly said We just disagree. AN is indeed the place to make sure that the close is reverted and reclosed by others. and clearly aren't considering changing it, and have openly invited close review at AN. It's not discourteous or uncollegial to do exactly that. ProcrastinatingReader (talk) 02:42, 20 December 2021 (UTC)

• Wikipedia:Administrators' noticeboard#Close review at Wikipedia:Requests for adminship/2021 review/Proposals, please.—S Marshall T/C 13:59, 20 December 2021 (UTC)

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

8B: No consensus, how to continue?

The closure of 8B as "unsuccessful" has fortunately been overturned now. How do we continue? And where? ~ ToBeFree (talk) 00:58, 25 December 2021 (UTC)

Let's figure out whether the 'SecurePoll technical concerns' are real or a myth, as that seemed to be divisive. Perhaps at WP:VPT and ping in Risker & 4nn1l2 as the primary claimant and counter-claimant, along with some other technical editors experienced with SecurePoll. If the fact of the matter is there's no technical issue, maybe re-RfA? If there is a technical issue, it's probably better to resolve that first. ProcrastinatingReader (talk) 02:48, 25 December 2021 (UTC)

I'd rather it be along the lines of "Does the community support selecting administrators via election by secret ballot" and leave off the technicalities of how that would be implemented - because if there is no support we shouldn't waste dev time. — xaosflux ^Talk 02:57, 25 December 2021 (UTC)

I agree with Xaosflux. This proposal was way too significant a change to be proposed as point 8B in an enormous omnibus RFC. This needs a standalone RFC, clearly labeled so that community members know exactly what they're supporting/opposing, instead of being stuck near the end of a mishmash of suggestions and ideas. I'd suggest that the RFC question be phrased as Xaosflux proposes, but I think it might be useful to have someone from the WMF who is familiar with both the technical and practical aspects adding an impartial comment on what SecurePoll can and cannot do. I have a lot of respect for 4nn1l2, but at the end of the day they're a volunteer just like the rest of us, and I think it is essential that we get information on matters such as which WMF department is responsible for the technical maintenance and improvement of the extension, what it can and cannot do from a technical perspective, what it can and cannot do from a practical perspective (e.g., are there sufficient human resources to educate and assist in the management of SecurePoll) what kinds of limitations we should expect (e.g., requiring multiple candidates to run simultaneously rather than allowing each candidate to run at their own time), and so on. It's really great that 4nn112 has been supporting the use of SecurePoll; however, if we were to move in this direction, we as a community need to know that the WMF is going to accept responsibility to manage and support both the software and the users of the software as required. (Note that, to date, this kind of support has NOT been guaranteed.) This information is probably important for the community to make an informed choice. Risker (talk) 04:52, 25 December 2021 (UTC)

I fully agree. Let's ping Joe Sutherland from the WMF to opine on this matter. User:JSutherland (WMF), you probably know me. I'm one of the organizers of fawiki elections (phab:T292685). I know that you are mostly single-handed in the Trust and Safety team, but I also hope that User:NahidSultan (WMF) can help you too in this matter.

1) At first, I want you to confirm that at the moment only 3 communities (namely enwiki, fawiki, and zhwiki) hold their elections on votewiki using SecurePoll (of course besides WMF and its affiliates).

2) Secondly, I want you to confirm that simultaneous election are possible on votewiki for multiple projects from a technical point of view. The reason that fawiki postponed its elections for one week (phab:T292685#7412256) was that we only wanted more cosmetics for our voters to see Farsi text (in Arabic script) from right to left (unlike this screenshot which shows RTL text in an LTR environment).

3) Finally, I want you to confirm that you can help enwiki community to hold administrative elections (as opposed to ArbCom elections) every six months in a proper predetermined time (for example Febs and Augs).

Thanks 4nn1l2 (talk) 12:09, 25 December 2021 (UTC)

I will just note that *all* WMF staff are on the organization's end-of-year break (with the exception of extremely time-sensitive or "emergency" situations), so while I think we'll get a response at some point, it probably won't be until early January. This isn't a criticism by any means, but it does give us more time to think about what we really need to know and to think more closely on what we would want to ask the community. I'm a little more hesitant to concur with Xaosflux below about the possibility of developing *different* secret-ballot software because there isn't guaranteed support for the one we have now; I don't think adding more unsupported or volunteer-only supported software is an answer to anything. Risker (talk) 19:30, 25 December 2021 (UTC)

@Risker: agree, I think where I was going was that if staff wanted to support some sort of COTS solution, or the community wanted to use an external solution - that is something that could be fluid, but that any of those type of ideas are useless if the concept of "elections" with "secret ballots" are outright rejected. — xaosflux ^Talk 20:02, 25 December 2021 (UTC)

To be fair, there is critical infrastructure that is maintained by volunteers, both in the WMF ecosystem and outside, and has no WMF support. Consider the AbuseFilter extension, for example. I don't think WMF support is critical to proceed here. After all, SecurePoll is unsupported right now and still used for ArbCom elections. ProcrastinatingReader (talk) 20:05, 25 December 2021 (UTC)

I don't think saying that we already have an election using unsupported software is a good argument for saying that we should have *more* elections using unsupported software. And the underlying AbuseFilter extension is supported by WMF staff/contractors; each project determines locally how to use that software (i.e., we write our own filters, determine which ones will be active, etc.). Risker (talk) 20:15, 25 December 2021 (UTC)

The underlying extension is maintained by Daimona Eaytoy (per mw:Developers/Maintainers#MediaWiki_extensions_deployed_at_Wikimedia_Foundation), who is a volunteer. A future overhaul is supported by a project grant (meta:Grants:Project/Daimona Eaytoy/AbuseFilter overhaul), but the current version and prior versions are supported mainly on volunteer time I think. ProcrastinatingReader (talk) 20:23, 25 December 2021 (UTC)

Looking at the MediaWiki page, it seems some extensions don't even have maintainers (like CheckUser). FlaggedRevs doesn't even have a code steward. SecurePoll at least has a volunteer maintainer, even if it has some functional inadequacies. ProcrastinatingReader (talk) 20:33, 25 December 2021 (UTC)

@Risker: I assume that holidays in the West are over, but I still see no replies from the WMF staff. Am I wrong? 4nn1l2 (talk) 12:13, 7 January 2022 (UTC)

I just sent an email to Mr. Sutherland asking him to participate in this discussion. 4nn1l2 (talk) 11:08, 11 January 2022 (UTC)

I immediately received an automatic response that he would be out of office until 18 January 2022. 4nn1l2 (talk) 11:10, 11 January 2022 (UTC)

Agree with Risker that it is still worth looking in to SPoll options, including options for community-run polls that don't require use of another server or staff (some work on this is occuring over on testwiki still - it is slow) - I certainly don't think that if the concept of using secret ballots and moreso the concept of actually using an election for this process is supported that it should be dependent on any specific piece of technology. Securepoll is a good example of what could be used, but it could evolve or something better could come along. — xaosflux ^Talk 12:17, 25 December 2021 (UTC)

Merry Christmas, all. I think it would be wrong to go to the community for a decision without a fully thought through proposal accompanied by chapter and verse from WMF IT staff confirming that it can be done exactly as envisaged. I think the next stage must necessarily be to ask the WMF to talk to us about the limits of SecurePoll.—S Marshall T/C 09:59, 25 December 2021 (UTC)

Hi folks - sorry for the delay, between end-of-year holidays, personal time off, and other stuff, it's been a wild few months. Hope you're all well! To answer 4nn1l2's questions above:

1. At first, I want you to confirm that at the moment only 3 communities (namely enwiki, fawiki, and zhwiki) hold their elections on votewiki using SecurePoll (of course besides WMF and its affiliates).

   At this moment, yes. The history of every poll ever run is public information on votewiki.

2. Secondly, I want you to confirm that simultaneous election are possible on votewiki for multiple projects from a technical point of view. The reason that fawiki postponed its elections for one week (phab:T292685#7412256) was that we only wanted more cosmetics for our voters to see Farsi text (in Arabic script) from right to left (unlike this screenshot which shows RTL text in an LTR environment).

   This is also my understanding. This seems to be a pretty common misunderstanding of what SecurePoll can or can't do. It is totally possible to run two elections at the same time. The reasons we haven't and don't historically are:

   • There just aren't that many elections (typically there were only two local elections and, every three-ish years, a Board election), so clashes didn't really happen
   • As you describe, the "skeleton" of votewiki is only available in one language at a time. You could run the Farsi elections with the project set to English but it would be extremely disorienting because of the LTR issue
   • (This is the primary reason:) Running an election is a long and drawn out process and we simply do not have the staff time to support multiple elections running at the same time.

   So it's not really a technical reason, it's a staffing reason.

3. Finally, I want you to confirm that you can help enwiki community to hold administrative elections (as opposed to ArbCom elections) every six months in a proper predetermined time (for example Febs and Augs).

   For the reasons outlined above, and the fact that I would need to liaise with potentially dozens of colleagues at the Foundation to make this happen, I cannot confirm this or really anything like this myself. Joe Sutherland (WMF) (talk) 18:07, 26 January 2022 (UTC)

Spend plenty of time with at least several people involved crafting an excellent proposal, and invite participation in the crafting. And then everybody who worked on it and more or less agrees actively support it in an RFC, even if you disagree with 10% of it. North8000 (talk) 14:43, 25 December 2021 (UTC)

I'm seeing a lot of sense in what is being suggested. Those with addressable concerns should be heard. Concerns might be mitigated somewhat. BusterD (talk) 15:50, 25 December 2021 (UTC)

The main problem is the mechanics of these things mean that no significant changes get made in Wikipedia. My advice was on the mechanics of a way to actually get something done. A lot of time & work formulating a really good proposal, and then everybody who generally supports it actively support it in the RFC, even if they only 90% agree. North8000 (talk) 20:48, 25 December 2021 (UTC)

For my part, I do not wish to insert any "poison pill" or discourage change; it is apparent from the 8B discussion and resulting upset after the first close a significant segment of wikipedians wish to at least try straight secret voting. I don't like it myself but would hope to reduce my concerns about any such proposal before the RFC is put to a !vote. BusterD (talk) 21:06, 25 December 2021 (UTC)

@ToBeFree @4nn1l2 @Bilorv @BusterD @Kudpung @Leaky caldron @North8000 @ProcrastinatingReader @S Marshall @W. Tell DCCXLVI @Risker: Would anyone consider proposing this at meta:Community Wishlist Survey 2022/Proposals, considering technical issues seem to be the main problem? ― Qwerfjkltalk 16:18, 22 January 2022 (UTC)

I don't agree that technical issues were the main problem; one claimed "issue" was an outright falsehood. It's not worth wasting a wish on this, given how few the WMF pay attention to and how many more critical technical issues for Wikimedia exist. — Bilorv (talk) 16:26, 22 January 2022 (UTC)

I wouldn't do so, for two reasons: 1) The Community Wishlist Survey is a vote. People from all communities vote for the features they desire most. Fixing SecurePoll to work with one specific community's RfA reform proposal that was closed as "no consensus" won't gather enough support to be implemented. 2) If we need this and there is a strong community consensus to use SecurePoll for the task, my personal position is that WMF developers are obligated to fix SecurePoll, independently of the Community Tech team's annual wishlist. ~ ToBeFree (talk) 16:33, 22 January 2022 (UTC)

Bilorv is correct that the problem wasn't technical. What would potentially drive it forward is a RFC specific to this proposal.—S Marshall T/C 17:00, 22 January 2022 (UTC)

I too believe there are no technical barriers. I am shocked that the WMF has effectively ignored us for almost a month. I already knew that WMF did not give a hoot about a medium-sized project such as fawiki, but this is news to me that WMF does the same about enwiki, its flagship project which is the root cause of about 50% of the received donations (Wikipedia:Wikipedia Signpost/2021-12-28/News and notes#WMF's audited financial statements released)! 4nn1l2 (talk) 19:01, 22 January 2022 (UTC)

You do know they don't read these pages, right?—S Marshall T/C 10:41, 23 January 2022 (UTC)

How to continue?

I deliberately did not vote on this, I still have no opinion on it, and it's probably not a solution that I would have proposed, but FWIW having read it now three times, I would have closed it with 'Consensus'. The opposers each wrote more but IMO it didn't give more weight to their arguments.

So just my opinion, but the way to go is to hold a stand alone RfC. This reform project has dragged on now for nearly four months, the sky is not falling (yet), and another few weeks to get it done properly won't sink the AdminShip, even if participation in these particular debates and talk elsewhere about adminships that sail in the night remains terrifyingly low in the face of their importance. BTW, canvassing per mass message is expressly permitted but I know of at least one experienced user who disagrees with this policy.

In my experience the most successful RfC of this kind are based on a clean proposal statement calling for Support/Oppose (practically a straw poll) and excluding any details of how, in the case of consensus, it should be addressed. The RfC proposal wording is critical and should be composed by a small drafting committee (what I used to call a 'task force'). How to get such a team together is up to the editor who wishes to take the initiative to coordinate and propose it, but the lists of participants below may help.

Hence it should be mentioned in the preamble for example:

• This RfC is strictly 'For and against' holding secret polls for adminship.
• This RfC is for a trial to be offered parallel to the traditional RfA, for a period to be determined in a in a follow up RfC if successful.
• Alternative suggestions were made and discussed during the run up to this RfC and should not be redebated here.
• Any opposes based purely on the technical issues of a secret poll will be inadmissible. The WMF is wallowing in funds so the classic excuses won't gel. If the community wants a secret poll, the WMF must provide the infrastructure for it (we've been there, done that, and I and a couple of others got the T-shirts for it).
• Frequency of the poll should be discussed in a follow up RfC.
• Scrutiny of votes should be discussed in a follow up RfC.
• Durations of nomination period, discussion period, and voting period should be discussed in a follow up RfC.

Here is a break down of voting that may or may not be useful:

Voter breakdown

This might help when mass messaging users who previously participated or getting a task force together (Note: this form of canvassing is expressly permitted) Stages of the project Issues 123 participants Brainstorming 68 participants Proposals 214 participants A full list of names for the total of the three stages would need to be extracted by Quarry or RegEx. As all the reform proposals were inconveniently all on one page, I don't know how to do it. Many of the participants are familiar names from the discussion and noticeboard circuits while a significant number are already admins, so it’s fair to assume they have some clue. The major contributors (content and/or number of signed comments) to all the stages however, were, in alphabetical order: Barkeep49 Bilorv Chetsford Extraordinary Writ HighInBC Isaacl Izno JayBeeEll Joe Roe John Cline John M Wolfson Kudpung Kusma Leaky caldron Liz Nosebagbear ProcrastinatingReader RandomCanadian Rhododendrites ToBeFree Valereee WereSpielChequers Worm That Turned Wugapodes Xaosflux 力 Participants at 8B Admin elections RfC Support (72) 4nn1l2 Adumbrativus Ajraddatz Amorymeltzer Andrew Davidson Aoi Asukite BDD Bilorv Calidum Carlosguitar Chiswick Chap Danaman5 Dank Daß Wölf Davey2010 DGG Dreamy Jazz Enterprisey EpicPupper Extraordinary Writ Femkemilene Ganesha811 Giraffer Gog the Mild HelpfulPi Hut 8.5 Ifnord Isabelle Belato J947 Jackattack1597 JavaHurricane JayBeeEll Jclemens Joe Roe John Cline Kusma Levivich Lollipoplollipoplollipop MER-C Mysterymanblue Novem Linguae Pharaoh of the Wizards Philoserf Pppery Qwerfjkl RandomCanadian Ritchie333 Robert McClenon S Marshall Scope creep SD0001 Sdkb Tamwin Tavix Tazerdadog The wub TheGeneralUser ToBeFree Toohool TrangaBellam Vaticidalprophet Valereee Whiteguru Winner 42 Worm That Turned Xaosflux XOR'easter 力 Oppose (38) Amakuru Beeblebrox Bradv BusterD Chetsford Chicdat Colin M Cryptic Dennis Brown Espresso Addict Fastily GeneralizationsAreBad George Ho Guerillero HighInBC Homeostasis07 InvalidOS Jo-Jo Eumerus John M Wolfson Johnuniq Leaky caldron Lepricavark Lunacats Nosebagbear Obi2canibe ProcrastinatingReader Risker Scottywong Seraphimblade Smartse Spinningspark Theleekycauldron Tim Smith Tol Wbm1058 Wehwalt Wugapodes YttriumShrew Commented but did not vote (7) Barkeep49 Isaacl Kudpung MxWondrous RoySmith Rschen7754 Trainsandotherthings

Kudpung กุดผึ้ง (talk) 06:29, 26 December 2021 (UTC)

• ProcrastinatingReader thank you so much for correcting those lists. I don't do RegEx so it's possible I overlooked something. Thank you too for having read it. Kudpung กุดผึ้ง (talk) 07:38, 26 December 2021 (UTC)

Holy cow, Kudpung. Why is all that statistical info in here? Doesn't matter if it's hidden behind a comment; in order to respond to you, we have to scroll through the entire thing to get here. Is it really necessary, when the actual votes are on the project page? How about removing that stuff, at least.

Please explain in detail why you think that one project will be able to force the hand of the Wikimedia Foundation on this point? As an aside, there are some pretty strong global sentiments that the WMF should be dramatically downsized (some proposals strip them of everything but literally running the servers and protecting the trademarks), so what makes you think that they'll be in a position to support this or any other issue, or would be in a position to maintain support? I'll note that there was some interest on the part of one WMF department to suggest the use of SecurePoll for RFAs on another project, so that people who opposed a candidate could do so without fear of reprisal; this was a realistic concern for that specific project. In other words, the whole point was to make it harder for candidates to succeed, not to increase the likelihood of successful RFAs. Do bear that in mind. I can't remember the last time that I opposed a candidate; it's probably been 10 years or more; it's strictly because I don't want to be harangued. I guarantee I'd be using the oppose button using secret balloting. Risker (talk) 07:32, 26 December 2021 (UTC)

Risker, I'm so glad you wholeheartedly agree with what I have been saying should be done about the WMF for at least 4 years. It's just made my Christmas! The sooner that could happen the better. I've already stated that I don't give a hoot what form an RfA election should take. I'm more concerned that an RfC, if it is held, should be done as optimally as possible. If my junk in the collapsed section is useful to me, then someone else might just find it useful. Hey, chill - grab a glass of hot mulled wine and relax up there in the cold north ;) Kudpung กุดผึ้ง (talk) 07:51, 26 December 2021 (UTC)

I'm not sure what you think I'm wholeheartedly agreeing with, to be honest; I've mentioned several varied points that include a reference to the WMF. Could you please be more specific? To be honest, I don't particularly agree that the WMF should be dramatically downsized (I'm not persuaded that many of the things the WMF does would be done adequately or equitably in a massively decentralized system, which wouldn't be project-based), and I'm not really sure what to make of the idea of using a secret ballot on RFA because of fear of reprisal. I don't think I've "wholeheartedly" agreed as far as I can tell. And mulled wine is....ewww. I'm more of a hard liquor kind of girl;-) Risker (talk) 08:06, 26 December 2021 (UTC)

Like I said: I've already stated that I don't give a hoot what form an RfA election should take. I'm more concerned that an RfC, if it is held, should be done as optimally as possible. And if the consensus is for secure polling (and I'm not so sure that would address the attrition of admins), then the WMF would either have to provide the service - otherwise what does the WMF actually do for it's Wikipedias other than as you say, running the servers and protecting the trademarks, and spending the money on their salaries? Or they should release the funds to en.Wiki so that the community can hire their own devs and a small server. Or it's back to the status quo and this four-month long series of discussions has been a much greater time waster than my little contribution above. This needs to be kept in perspective. Kudpung กุดผึ้ง (talk) 09:00, 26 December 2021 (UTC)

I can't remember the last time that I opposed a candidate; it's probably been 10 years or more; it's strictly because I don't want to be harangued. I guarantee I'd be using the oppose button using secret balloting. As well you should! What you're telling us, Risker, is that public voting in the atmosphere we have necessarily causes voter suppression in cases like yours. Shouldn't you support a system where you can vote freely? It doesn't matter if we want to make RfA easier to pass: voter suppression should not be a tactic that we tolerate. Ways to increase admins elected (such as lower thresholds for success, like ArbCom, or more pre-voting ways for skeptics to have their voices heard and candidates given chance to properly address all constructive criticism) come later. — Bilorv (talk) 12:09, 26 December 2021 (UTC)

Bilorv To be clear, you wish to replace !votes with an absolute totals vote, remove the current ability for preposterous opposes to be disregarded by 'Crats and, as a consequence, likely increase oppose vote totals (since, in a discretionary range case, they are more likely to be disregarded for cause)? Seems an odd approach to increasing successful RfAs. Leaky caldron (talk) 14:13, 26 December 2021 (UTC)

Yes, Leaky, this is a terrible idea. All the alternatives are worse, including staying on the current trajectory. We're here because there's a consensus that major changes are needed and this is the only major change that you and your fellow opposers haven't killed off yet. You'll get another chance to !vote strong oppose in due course.—S Marshall T/C 23:40, 26 December 2021 (UTC)

A proposal, probably

I saw this reform RfC a little too late, and didn't feel like I had much to add to it so late in the discussion. I see that there is still no consensus about admin elections. I do not know if it is too late to propose new methods of election, or even if this is the right place, but I think there's always room for proposals and discussions (and also I thought it would be slightly hypocritical of me to enthusiastically agree with the statement "RfA is broken" without doing a single thing to help make it better).

I was wondering, is it not possible to make a tool/system/whatever by which we can have a semi-secret ballot?

My idea is as follows:

1. Nomination: Same as what we have now.
2. Conversation: Usual statements, questions to the candidate, and general discussion. This will be a non-voting period (the time period can be decided if this passes).
3. Voting: The discussion is closed, and something akin to a Google Form is created, where you click "Support", "Oppose" or "Neutral", and then give a rationale in a text box. Crats will be able to see the voter's username, vote and rationale.
4. Counting: Crats release the vote count, and also all the given rationales in a table - without usernames.
5. Result: I'm not too sure about what they'll do after this bit - I'm thinking of either:

• Crats give a preliminary result - Pass or Fail - and their rationale, and the community does a once-over to see if they fairly considered all the vote rationales given. In the absence of any major opposition to the crats' decision, it is made final.
• Mostly same as the above, but with the community "ratifying" the crats' decision, in another formal vote or in the usual consensus-building fashion (note: I'm including the non-anon consensus-building method because I expect it will be less controversial, given that it merely involves seeing the vote rationales and the crat rationales and seeing if they match).

This incorporates the advantages of both a secret ballot and the current system, and I believe this will be an improvement over the current system because:

• It prevents oppose-badgering. (Which I myself, regrettably, have been involved in in the only RfA I took part in.)
• It gives a way for crats to filter out votes with nonsense rationales.
• It gives a way to filter out sockpuppets' votes.
• It potentially makes the process less fatiguing for everyone and faster, with (hopefully) the same amount of scrutiny.
• It is potentially less toxic and emotionally taxing on voters, noms and the candidate.

One challenge I foresee is the technical limitation, given that we will almost certainly need a new tool with OAuth enabled for this kind of voting. I think, however, that if this proposal garners enough interest, we can get it done. This is the first time I've made such a proposal, and I'm not sure if I should put it on the project page itself rather than here; if this is not the right place to discuss such proposals, please tell me where to move it. If it is, please discuss and support/oppose below. Kind regards, W. Tell DCCXLVI (^{talk to me!}/_c) 06:05, 27 December 2021 (UTC)

2022 Community Wishlist Items

Make SecurePoll accessible through local wikis

Support this wish if you want not to be dependent on WMF and its staff for running elections: m:Community Wishlist Survey 2022/Larger suggestions/Make SecurePoll accessible through local wikis 4nn1l2 (talk) 08:41, 2 February 2022 (UTC)

SecurePoll is not fit for service

It's worth reading and supporting IMO: m:Community Wishlist Survey 2022/Larger suggestions/Votewiki/SecurePoll are not fit for service 4nn1l2 (talk) 13:44, 11 February 2022 (UTC)

Improvement of private vote systems

Another relevant wish: m:Community Wishlist Survey 2022/Larger suggestions/Improvement of private vote systems. 4nn1l2 (talk) 14:08, 11 February 2022 (UTC)