Discussion about refining the implementation details of proposals from Phase I of WP:RFA2024 for community-based recall of administrators. --19:29, 15 May 2024 (UTC)

Welcome! Following the passage of proposals 16 and 16c, we have consensus for a community-based recall of administrators. This subpage is for Phase II, so we can refine the implementation details.

The discussion close by Joe Roe is reprinted here:

Considering Wikipedia:Requests for adminship/2024 review/Phase I § Proposal 16: Allow the community to initiate recall RfAs, Wikipedia:Requests for adminship/2024 review/Phase I § Proposal 16c: Community recall process based on dewiki, Wikipedia:Requests for adminship/2024 review/Phase I § Proposal 16d: Community recall process initiated by consensus (withdrawn), in parallel, there is a rough consensus that the community should be able to compel an administrator to make a re-request for adminship (RRFA) in order to retain their administrator rights. However, there is also a consensus that the process(es) for initiating an RRFA needs to be worked out in more detail before this is implemented. Phase II of this review should therefore consider specific proposals for RRFA initiation procedures and further consensus should be sought on which, if any, is to be adopted. The dewiki-inspired process suggested in Proposal 16c was well-supported and should be a starting point for these discussions.

Proposal 16 suggested that a RRFA could be initiated by consensus following a discussion at the Wikipedia:Administrators' Noticeboard (AN). I don't see a consensus for this specific procedure, since a significant proportion of both those against and those in support the proposal were against it. The original suggestion that ANI and/or XRV could also be used to initiate an RRFA was rejected outright.

Proposal 16d offered a more fleshed-out version of an RRFA initiated at AN, but it did not find consensus and was withdrawn.

Proposal 16c suggested adopting the German Wikipedia's admin reelection process, which obliges an admin to make an RRFA if 25 editors with Extended Confirmed rights vote for it within the last 1 month if 50 editors with Extended Confirmed rights vote for it within the last 1 year. There was a solid numerical majority in favour of this procedure, with supporters pointing to the advantages of using a process that has already been shown to work on another project. However, considering the relatively low participation in this sub-discussion compared to the level of opposition to RRFAs in general expressed elsewhere, this is not necessarily a sign of broad consensus.

Amongst those who opposed this proposal entirely (i.e. not just specific implementation details), their main reasons were that desysopping is already satisfactorily handled by the Arbitration Committee, that it would discourage administrators from making unpopular but correct decisions, or that it could be open to abuse. The primary counter-arguments given to these were that other projects have community desysop procedures (dewiki, commons) without issue and that on enwiki the community can already impose harsher sanctions (i.e. site bans) by consensus alone. I cannot see any policy-based reason to weigh one set of arguments more than the other, so the substantial numerical majority in support (43–22 for 16; 25–9 for 16c) will have to speak for itself.

As written, the original 16C proposal was:

1. WP:Admin Reconfirmation will be created, where any subpages can be created for individual admins. Editors may sign on those subpages to vote for a reconfirmation.
2. The reconfirmation is initiated if 25 editors with Extended Confirmed rights vote for it within the last 1 month. Or if 50 editors with Extended Confirmed rights vote for it within the last 1 year.
3. Once a reconfirmation is started, the admin in question must run for a "Reconfirmation RFA" (RRFA) within the next 30 days. Otherwise a bureaucrat can remove their admin rights.
4. A RRFA will be identical to any RFA, but with lower thresholds. Instead of 75% "generally passing", it'll be 66%. And the discretionary range for Bureaucrats will be 55% to 66% instead of 65% to 75%. Any admins who fail a RRFA will have their admin rights revoked.
5. Any admins may voluntarily stand for RRFAs at any time if they like. This will be otherwise considered identical to a community initiated Reconfirmation.
6. Admins who have successfully run for an RFA, RFB, RRFA, or Arbcom elections in the last 1 year are not eligible for a community initiated Reconfirmation. Any votes for reconfirmation in the 1 year after an admin succeeds any of these will be struck.

Which of these conditions should be sufficient to compel an administrator to run an RRfA? Support more than one option if needed

• Option A: 25 EC editors sign a recall petition within the last 1 month OR 50 EC editors within the last year (same as proposal 16C).
• Option B: 25 EC editors sign a recall petition within the last 1 month.
• Option C: 50 EC editors sign a recall petition within the last 1 month.
• Option D: 40 EC editors sign a recall petition within 10 days.
• Option E: (In addition to another option) 75 EC editors sign a recall petition within the last 3 months.
• Option F: (In addition to another option) 75 EC editors sign a recall petition within the last 6 months.
• Option G: Petitions should not be used as part of the recall process.
• Something else (specify...)

Note - A rolling petition = A petition where anyone can sign, and RRFA can be triggered if there's votes in the last N days. Older signatures are handled as per #Expired signatures on initiation petitions. A non-rolling petition would be started, and then run for N days, after which it will be closed in favour of RRFA/no RRFA.

Note - The word "request" was replaced with petition for consistency with rest of the page. Rolling vs non rolling petitions was clarified further.

Survey (Initiation procedure)

• C basically per all the reasons mentioned in the beginning of part 2. A year-long rolling cycle would be a great way to harm the morale of admins and hasten the day. Sincerely, Dilettante 14:56, 8 May 2024 (UTC)

  To clarify, this is also an Oppose A !vote. Unlike many in this thread, I'd prefer no RRfA to one as broken as A. Sincerely, Dilettante 15:43, 9 May 2024 (UTC) This is a support for any non-rolling (surely there's a more elegant way to say "non-rolling"—quantized? fixed-length? discrete?) petition that lasts for a month or less and an oppose for any rolling petition or any petition which stays open for longer than a month. I am Neutral on G. Sincerely, Dilettante 21:48, 24 May 2024 (UTC)

• B > C > D, I also support E > F in addition to other options if B fails, weak support for F and B together, oppose A and G, , I would go with something like A if we raise the threshold (75 maybe?) for a year. Fanfanboy (talk) 15:32, 8 May 2024 (UTC)

  @Fanfanboy How could you trigger E without already having triggered B? --Ahecht (TALK
  PAGE) 15:15, 9 May 2024 (UTC)

  @Ahecht Good point, you can't. The only way would be to raise the threshold for B or lower it for E Fanfanboy (talk) 15:31, 9 May 2024 (UTC)

• B or C, oppose A. Keeping a recall petition open for a year seems unnecessarily cruel; having a ticker counting up to a desysop would be insanely stressful, and even if option A has its use cases I can't see it being a net positive on the whole. Giraffer (talk) 16:04, 8 May 2024 (UTC)
• A or B. 25 EC editors independently complaining in a single month suggests extraordinarily problematic sysop conduct, and amounts to excellent grounds for the community to open an investigation. For comparison, Arbcom would open a case with far fewer signatures. If, during that investigation, those EC editors turn out to be gaming the system then the community can deal with that.—S Marshall T/C 16:32, 8 May 2024 (UTC)
• Find a consensus - All of the proposed numbers here are workable. This !vote is explicitly in favor of any consensus the closer thinks they can find in this discussion, and explicitly against a no consensus or trainwreck outcome. Split babies, find thin consensuses, flip a coin if you have to. Tazerdadog (talk) 16:46, 8 May 2024 (UTC)

  This is an incredibly cool vote and I'm almost tempted to do the same thing in this thread. theleekycauldron (talk • she/her) 17:17, 8 May 2024 (UTC)

• Prefer B I support any option over none at all, but B is best, C is second. I agree that A could have really negative consequences. Toadspike (talk) 16:49, 8 May 2024 (UTC)

  D is also okay, after coming back to this. Oppose E, F, G. Toadspike (talk) 11:40, 14 May 2024 (UTC)

• B, C, or D. A year is far too long. Literally many active admins could have something open all the time. Admins who work in certain areas probably would always have one open. Valereee (talk) 16:55, 8 May 2024 (UTC)
• D or a variant with a higher than 40 threshold. Oppose A, B, E, F. In the discussion, Mach61 capably noted "a reasonable measure of how much attention an admin contreversey can get is the number of preliminary statements before an arbitration case. Wikipedia:Arbitration/Requests/Case/Portals got 43 uninvolved editors' comments in the span of roughly a week". Based on that, 40 editors who have to do no more than sign their name -- no comment required -- in a week seems like a very reasonable threshold and provides recall opportunity while maintaining a (very) minimum guardrail against excess. Chetsford (talk) 16:59, 8 May 2024 (UTC); edited 23:45, 8 May 2024 (UTC)
• C or D both filter the wheat (complaints very likely to lead to desysop) from the chaff (a loud minority). Neutral on B, Oppose A Mach61 17:04, 8 May 2024 (UTC)reply
• B > C > D > A, in that order. 25 in one month should be sufficient; but I'd support 50 if the community wanted a higher threshold. I don't really like D because 10 days is too short, I fear the deadline pressure will increase conflict. I don't like A because a year is too long for an admin to have this hanging over their head. BTW, not addressed: I don't like the idea of a "rolling" 30 days, I think if there aren't sufficient signatures within 30 days after the first signature, the petition should be "closed" somehow, and there should be some cooling-off period (maybe 30 days) before another petition can be started; this is to prevent the rolling-30-days from being just the same as the one-year thing. Levivich (talk) 17:16, 8 May 2024 (UTC)reply

  ...followed by E > F > G (although really not G until someone proposes an alternative to a petition; but I'm open the idea of alternative). I'll join the find a consensus chorus -- I'd support any of the options over a "no consensus" outcome. FWIW, I think ranking all the choices (ranked voting) helps find a consensus. Levivich (talk) 03:10, 12 May 2024 (UTC)reply

• D preferred, but Oppose A, E, and F - per what I wrote in the first phase. Leaving things open for a long time would be miserable for the admins they concern. — Rhododendrites ^talk \\ 17:37, 8 May 2024 (UTC)reply
• Pro-any-consensus per Tazerdadog. I'd personally prefer an activity requirement based on (perhaps 50) mainspace contributions during the 12 months before the petition in addition to extended confirmation, similar to dewiki's Stimmberechtigung. But that was ignored in the translation of the process and is probably not that important. ~ ToBeFree (talk) 18:14, 8 May 2024 (UTC)reply
• (E or F) + Any of (B,C,D) > A > Find a consensus I personally prefer a way to recall that isn't just reactive to a single incident, which is what the 1 month options effectively are. So adding options E and F, so editors who have non-isolated concerns with admins can still register them. I would prefer having a consensus over every other outcome. Having recall is more important to me than most other things. If necessary, we can change the threshold again by consensus after seeing it in action. Soni (talk) 18:20, 8 May 2024 (UTC)reply
• 50 EC editors sign a recall petition within 45 days - This is something that has a high chance to be weaponised (especially in ethnopolitical CTOPs), and I'm not comfortable with a 1 month or 3 month petition time - 1 month because that might foreclose the admin from correcting the behaviour from a legit complaint, 3 months because at that point people will likely have forgotten. To that end, I propose 45 days (~a month and a half) for a recall petition, with 50 being the threshold for recall. —Jéské Couriano v^_^v ^{AE thread summaries} 18:53, 8 May 2024 (UTC)reply
• Support C2 or D, with the understanding that the petition is closed if the required number of signatures is not gained within the specified time period of it opening (see ActivelyDisinterested's comment below for an alternative understanding of the wording of C). Oppose A or F because the time to complete the process is too long. Oppose B because the number of editors needed is too low. Oppose any rolling petitions.-Gadfium (talk) 02:06, 24 May 2024 (UTC)reply
  • note: I have removed option C2, which is option C with discussion of a separate question added. theleekycauldron (talk • she/her) 23:51, 25 May 2024 (UTC)reply
• Oppose A or F. Both drag it out too far. Support B or C. We should toe the line between a frivolous recall and keeping an unpopular admin, but I'm undecided on which does this better. Neutral D, which I fear may cause many knee-jerk people to tear off the admin's head over a (relatively) minor thing. Support E, which looks fine to me. But, dear <favorite deity here>, FIND A CONSENSUS. Queen of Hearts (talk) 01:32, 9 May 2024 (UTC)reply
• Support B and E. If 25 people are that concerned about someone's conduct, a re-confirmation RfA seems reasonable. Agree with Giraffer that keeping things open for a year is unnecessarily cruel. Clovermoss🍀 (talk) 05:11, 9 May 2024 (UTC)reply

  E will never be triggered if B is also selected - if 75 users sign in 3 months, by the pigeonhole principle, at least 25 must have signed during one of the months. Tazerdadog (talk) 06:02, 9 May 2024 (UTC)reply

  I was not thinking of that math involved at the time, so I've striken E since it'd be duplicative. Clovermoss🍀 (talk) 07:52, 12 May 2024 (UTC)reply

• Support C > B; oppose A, D, E, F – per Rhondo, Clover, and Giraffer, 10 days is too short as to potentially inspire rash maneuvers; anything more than a month is too long as to constitute tedium or torture. I'm not going to muddy the waters further by pondering whether 25 editors should have to do a bit more than sign their name, but 25 is certainly the lowest I would go and feel comfortable supporting. Remsense诉 15:06, 9 May 2024 (UTC)reply
• B+F, which is the closest match to the German Wikipedia's "25 voting users within one month or 50 voting users within six months". --Ahecht (TALK
  PAGE) 18:13, 9 May 2024 (UTC)reply
• First preference D, second preference C, third preference anything else that can get consensus. I'm not fond of the de-wiki permanent petition approach, which creates more of a Damoclean situation than I'm comfortable with (although I prefer it to nothing). Ten days should be more than enough to see if there's widespread community dissatisfaction. I'm not confident that forty or fifty signatures will be a high enough threshold, but it's a good enough starting point for now. Extraordinary Writ (talk) 19:38, 9 May 2024 (UTC)reply
• G. I can't see a number of EC editors that (a) wouldn't drag the process out too long to be useful, and (b) would be superior to what we have now at WP:RfAr. So I'm inclided to oppose any process that's initiated other than as a request for Arbitration. --Tryptofish (talk) 21:28, 9 May 2024 (UTC)reply

  Adding: I'm seeing the "find a consensus" viewpoint being expressed here and in several other sections on this page. A big part of my thinking about G is that it would be a mistake to find consensus by taking an arithmetic mean of all the options. That may be a way to "split the difference", but it isn't how WP:CONSENSUS works. --Tryptofish (talk) 00:15, 10 May 2024 (UTC)reply

  Also, it seems to me that G can include the community initiating the process via a filing (rather than a petition) at WP:RFAR, and then ArbCom determining that a reconfirmation RfA should take place. I think that's consistent with the Phase 1 close, and a far better option than the other options offered here. --Tryptofish (talk) 00:30, 10 May 2024 (UTC)reply

  Second choice D, and strongly oppose all others. --Tryptofish (talk) 21:33, 14 May 2024 (UTC)reply

  Now that this has been clarified, I especially strongly oppose any process that is "rolling". --Tryptofish (talk) 21:39, 24 May 2024 (UTC)reply

• D only (I mean it, everything else would be significantly worse than the status quo) – the whole advantage of admin recall is supposed to be that it avoids a long drawn-out process and enables adminship to genuinely be "no big deal" in that it is easy to remove in cases of misconduct. A petitioning period longer than a week or so completely neuters this advantage, to say nothing of indefinite "rolling" cycles. I also explicitly oppose a mindset where the closer ought to find consensus at any cost – if a no consensus closure is warranted, do not feel pressure to do so, because many of the options here would cause serious long-term damage. – Teratix ₵ 02:21, 10 May 2024 (UTC)reply

  Also, for the editors arguing ten days for petitioning is too short – RfA itself is only seven days and I don't see many arguments this is too short. – Teratix ₵ 02:24, 10 May 2024 (UTC)reply

  The difference in my mind is that RfA is where editors go to become annoyed, where recall would be where they go if they are already annoyed. A month seems like the right ballpark so that nobody feels like they have to rush the process. Remsense诉 08:25, 14 May 2024 (UTC)reply

• B reasonable enough, other options drag the time window too far or make it too short. Ratnahastin (talk) 07:10, 10 May 2024 (UTC)reply
• B or C, not D we don't want to drag the process out too long, but we also don't want to shortchange it. There is a clear desire for community recall, and it should be implemented in such a way as to make it workable. LEPRICAVARK (talk) 12:37, 10 May 2024 (UTC)reply
Zdroj:https://en.wikipedia.org?pojem=Wikipedia:Requests_for_adminship/2024_review/Phase_II/Administrator_recall
Text je dostupný za podmienok Creative Commons Attribution/Share-Alike License 3.0 Unported; prípadne za ďalších podmienok. Podrobnejšie informácie nájdete na stránke Podmienky použitia.

---