Please consider joining the feedback request service. An editor has requested comments from other editors for this discussion. This page has been added to the following lists: Wikipedia policies and guidelines Wikipedia proposals When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.

Discussion about refining the implementation details of proposals from Phase I of WP:RFA2024 for community-based recall of administrators. --19:31, 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
• B or C. I think the one-month timeframe strikes a good balance, where it's long enough to avoid being a referendum on single incidents but also short enough to avoid being a permanent sword of Damocles over admins' heads. E is acceptable to me as well but anything beyond 3 months is definitely too long, in my view. ModernDayTrilobite (talk • contribs) 13:45, 10 May 2024 (UTC)reply
• B or C but not A. I think a year may be too long of a time to silently build up animus. SWinxy (talk) 23:11, 10 May 2024 (UTC)reply
• C only. I think the probability is quite high that there are more than 25 unblocked spam EC accounts out there - and it is fairly easy and cheap for a dishonest actor to get more of them. This is the MO of several spam sockpuppeteers. MER-C 14:51, 11 May 2024 (UTC)reply

  I also support D as well. MER-C 16:23, 16 May 2024 (UTC)reply

• C or D Options A, E, and F would keep admins stressed for too long, while Option B seems like too low of a threshold. BluePenguin18 🐧 ( 💬 ) 15:21, 11 May 2024 (UTC)reply
• B as first choice and anything else as second choice. — Bilorv (talk) 08:29, 12 May 2024 (UTC)reply
• D > C > B, but oppose all others; anything longer than a month is far too long, we don't want a sword of damocles hanging over an admin for an extended period. If someone has initiated a recall petition on me, I'm not likely to dive into resolving a contentious dispute, and for a short period that's okay; any substantive length of time, and we're going to be making admins inactive. Vanamonde93 (talk) 17:57, 12 May 2024 (UTC)reply
• B. C is acceptable as a second choice. Frostly (talk) 05:44, 13 May 2024 (UTC)reply
• Strong support B and D, but support anything else (i.e. option find a consensus). HouseBlaster (talk · he/him) 02:18, 14 May 2024 (UTC)reply
• C, but find a consensus. theleekycauldron (talk • she/her) 03:57, 14 May 2024 (UTC)reply
• D. Second choice G. Oppose all others. There should not be "rolling petitions", we are not the 1922 Committee and hoisting swords of Damocles over admins' heads means admins will just not touch anything vaguely controversial once they're halfway to the threshold. I'm not especially against it being a longer period than 10 days, but the essential feature is that if the threshold isn't reached in the given time, it dies. Stifle (talk) 08:21, 14 May 2024 (UTC)reply
• C or D, but something is better than nothing. ~~ AirshipJungleman29 (talk) 17:16, 14 May 2024 (UTC)reply
• C only, per Dilettante and MER-C. Draken Bowser (talk) 20:46, 14 May 2024 (UTC)reply
• C+F is probably best (adapting German A to the larger size of the English Wikipedia community), but we won't really know until we have tried it. Not opposing any of the options at this point. I don't think the "sword of Damocles" rhetoric is apt; I expect most admins will always have one or two editors asking for their recall, and we will get used to that. We do need methods to get more admins though (we have effective methods for desysop but no effective method to create new sysops). —Kusma (talk) 09:35, 15 May 2024 (UTC)reply
• D only I was going to say C but realised the "within the last month" would lead to the recall being open endlessly. This is meant to be about improving RFA not driving admins to quit. -- LCU ActivelyDisinterested «@» °∆t° 22:28, 15 May 2024 (UTC)reply
• ’’’B’’’ — Charles Stewart (talk) 12:21, 16 May 2024 (UTC)reply
• Vaguely fine with any of the first four, with a preference for a lower barrier; as above, 25 editors is a pretty big number. ~ Amory (u • t • c) 15:37, 17 May 2024 (UTC)reply
• Any of the non-rolling options with preference for lower threshold and shorter timelines. Petitions should not "stick around." They should succeed or fail in relatively short order, so that we don't have admins "under a cloud" indefinitely, without an actual RRFA starting. It should be relatively easy for petitions to succeed, because a failed petition with a large number of signatures is not materially different to a rolling petition - people will simply start a new petition as soon as the waiting period (if any) runs out on the old one. --NYKevin 19:29, 17 May 2024 (UTC)reply
• B or C. If we ended up with rolling periods I am likely to revisit this. Xymmax ^{So let it be written} _{So let it be done} 03:38, 20 May 2024 (UTC)reply
• G, substantially per Tryptofish above. All of the other options seem calculated to create more problems than they would solve (if they would, in fact, solve any problems at all). With an eye to the purpose of these reforms, it is difficult to see how any of these proposed petition procedures would create an environment more conducive to people becoming admins, but easy to see how it would create an even less welcoming environment by creating an additional process that is also "toxic and hostile to participants and candidates". I could see D as a last resort, but the threshold seems too low. An admin who doesn't have at least 40 haters probably isn't doing much. -- Visviva (talk) 01:48, 21 May 2024 (UTC)reply
• D > C, + F. Option D seems like a good split-the-difference option, but I could live with C. A and B are too extreme on a site with a userbase this large. F would handle cases where there's clearly a problem but it doesn't form a specific "incident" in the ANI sense that has immediately attracted a short-term pile-up of concerned comments. As with several other commenters above, I'm well aware that numbers and other options might need to be adjusted over time, so I'm not drawing a firm line in the sand. Just want to see some kind of actually usable process of this sort emerge, but neither a situation of every admin having a sword of Damocles over them all the time, nor a pretend-implementation that cannot actually be put into practical effect because the numbers are too high. (In any case like the latter, e.g. behavior that resulted in 75 or 100 recall demanders all at the same time, the admin's actions would almost certainly also be of a sort that could be addressed by ArbCom in the usual route to desysopping).  — SMcCandlish ☏ ¢ 😼  01:28, 23 May 2024 (UTC)reply
• B > C > A > D >>>>>>>> G. Stating no opinion on E and F, support B as the option that provides the community with the most responsiveness without the undesirable year long petition of A. I suggest that B/C can and should be implemented in a way that avoids rolling petitions. BoldGnome (talk) 04:35, 23 May 2024 (UTC)reply
• B2>B I dislike rolling petitions as a concept. I also think the bar for an RRFA would be too high beyond 25. At ANI it's currently rare to see more than 10-20 editors contribute to a discussion, so I doubt any more than 25 would be a viable threshold. --Licks-rocks (talk) 21:22, 25 May 2024 (UTC)reply

  Note: I've removed B2 from this subsection, as it is B with an addendum dealing with a question that I've moved to #Rolling. theleekycauldron (talk • she/her) 23:59, 25 May 2024 (UTC)reply

• Comment for closer: Because of the mechanics of the question, some options strictly encompass others; for example, triggering C will always trigger A, so a support for A is always implicitly a support for C. I would suggest, therefore, counting a support for A as a support for options B, C, D, E, and F; and counting a support for B as a support for options C and E (unless the voter has specifically voted against that for some reason, I suppose). theleekycauldron (talk • she/her) 00:10, 26 May 2024 (UTC)reply
• What MER-C said (and if they change their comment, change mine to match). jp×g🗯️ 18:44, 26 May 2024 (UTC)reply

Discussion (Initiation procedure)edit

• @Fanfanboy: If there's an alternate threshold enough people agree on, we should add it as an option. I have been trying to consider what other thresholds would be fine but looking for alternate suggestions. Something like 50 editors in 1 month or 75 editors in 3 months? Soni (talk) 16:08, 8 May 2024 (UTC)reply
• Why does Option A says "50 EC editors within the last year" when the German Wikipedia, which this proposal is based on, says "50 voting users within six months"? --Ahecht (TALK
  PAGE) 18:11, 9 May 2024 (UTC)reply
• @Ahecht and @Tazerdadog make a good point. E will never be triggered without B being triggered first. Only way to remedy this is to increase the threshold for B, or lower it for E. (Only applies if both B and E pass) Fanfanboy (talk) 12:15, 10 May 2024 (UTC)reply
• I'm a little surprised at the length of the periods being proposed here. Recall should be something used when an admin makes a serious mis-step, or a series of small ones. We shouldn't be creating "sign here if you don't like X" pages. Vanamonde93 (talk) 17:57, 12 May 2024 (UTC)reply

  I think the idea is that we already have pretty effective solutions for serious and obvious mis-steps, but not a good way of dealing with long term patterns of subtle abuse. --Ahecht (TALK
  PAGE) 13:48, 13 May 2024 (UTC)reply

  That's an interesting distinction, between obvious missteps and long-term patterns of subtle things. I'm not convinced that ArbCom is ineffectual at dealing with long-term patterns. I think it's something they've actually gotten pretty good at, and I'm having trouble seeing how a petition signed by extended-confirmed editors would be so much better. In particular, there's a difference between a long-term pattern of subtle but genuine abuse, and a long-term pattern of making difficult but necessary decisions that make some users resentful. Having a petition just sitting there for a long period of time, waiting around for someone, anyone, to come and add another signature, seems to me to be an open invitation to put long-term pressure on admins who make difficult but necessary decisions, to make them feel like such decisions are just not worth the risk. And even if the petition ends up being unsuccessful, or if it's successful but the admin passes the reconfirmation RfA, that still means that admin had to spend a long time looking over their shoulder, when their energies would have been a lot more beneficial to the project if spent in other ways. --Tryptofish (talk) 18:01, 13 May 2024 (UTC)reply

  It also doesn't have to be abuse. It could just be a long-term pattern of incompetence or poor judgement. --Ahecht (TALK
  PAGE) 17:06, 14 May 2024 (UTC)reply

  There's legitimate room for disagreement on whether we need community recall at all; I believe we do, other reasonable people disagree. But that's quite separate from whether we allow rolling recall petitions that remain up indefinitely, and that I'm firmly opposed to. There is no way that having an effectively permanent recall petition is a good thing for community morale. If mis-steps happen, we ought to look at them, determine (via the petition and, if needed, RRFA) if action is warranted, and then move on. Vanamonde93 (talk) 17:02, 15 May 2024 (UTC)reply

• I'm quite concerned about the concept of admins all having recall pages that could gain signatures because they do something that annoys an editor. This creates a chilling effect dissuading people from working in controversial areas, especially if they are close to the threshold. Stifle (talk) 09:24, 14 May 2024 (UTC)reply

  I feel like we need to tackle the issue of rolling v. non-rolling recall petition periods, head on. Levivich (talk) 15:25, 14 May 2024 (UTC)reply

  @Levivich And also whether signatures on rolling petitions are kept indefinitely or removed once they "expire". --Ahecht (TALK
  PAGE) 17:09, 14 May 2024 (UTC)reply

• @BoldGnome Rolling and non rolling petitions significantly enough that it is better to put up Option B2 and C2 (as non rolling counterparts) instead of trying to change the option that already exists. As written, D is the only non rolling petition. Do you have a preference for wording/threshold? Soni (talk) 11:51, 23 May 2024 (UTC)reply

  @Soni: maybe rolling should be a separate question? theleekycauldron (talk • she/her) 15:59, 23 May 2024 (UTC)reply

  I would very much prefer the current format but clarified as needed. "Anyone can sign, rolling petition for 3 months" is very different from "Someone opens a non-rolling petition, it stays open for 3 months". Splitting the question would be strictly more confusing than more options, in my honest opinion.

  I just don't know what non rolling options people prefer, so haven't added more yet Soni (talk) 17:48, 23 May 2024 (UTC)reply

  My understanding is that options C and C+ of "Eligibility to RRFA" below resolves this issue. BoldGnome (talk) 00:06, 24 May 2024 (UTC)reply

  That isn't what I understood when phrased the options, so I've clarified them again above. This was already discussed during "Open discussion" so I hadn't repeated it yet. If we think prior voters might have the same confusion as you, we should probably ping them to confirm. Soni (talk) 01:57, 24 May 2024 (UTC)reply

• I think the confusion between rolling and non-rolling petitions, only clarified today, means this whole Initiation procedure section should be closed and restarted, as the options have changed since many votes were made.-Gadfium (talk) 02:12, 24 May 2024 (UTC)reply

  I disagree that options have changed. The original wording was already asked and discussed in the Open discussion section, section #Tweaks_to_16C. See comments by @Suffusion of Yellow and Isaacl: around 18:33, 5 May 2024 (UTC). As written, it's a rolling window: within the last 1 year.reply

  I added more clarity to make it even more obvious, but it's not a change of any sort, and I would prefer we didn't discard all !votes made already just because of bureaucracy. I do agree we should guarantee no confusion, hence my suggestion of a mass-ping for all prior voters. Soni (talk) 02:22, 24 May 2024 (UTC)reply

  I agree that this "clarification" substantially changes the options that many editors have voted on and adds additional options that didn't exist when those editors provided their opinions. Most problematically, options B and C are now explicitly rolling petitions, which is entirely different to the previous options B and C (which were ambiguous on the matter). Also, no one supports rolling petitions. BoldGnome (talk) 05:14, 24 May 2024 (UTC)reply

  I do not think that we should assume, one way or the other, whether editors who commented before the clarification of the meaning would alter their opinion based upon that clarification. We should err on the side of making sure that anyone who might want to know, is made aware. This is also something that whoever closes this discussion should carefully consider. --Tryptofish (talk) 21:43, 24 May 2024 (UTC)reply

  • Shouldn't "This petition can be opened but is not rolling" be changed to, simply, "This petition is not rolling"? Any petition can be opened, otherwise it wouldn't be a petition. --Tryptofish (talk) 22:09, 24 May 2024 (UTC)reply
    • @BoldGnome, Tryptofish, Soni, and Gadfium: I've removed mention of rolling from the available options. This RfC is complex enough without potentially doubling the number of options. I'll open a separate question about rolling below, which hopefully comes to a speedy resolution. theleekycauldron (talk • she/her) 23:41, 25 May 2024 (UTC)reply

      Thank you. I still think both time period and rolling-ness of petitions are too linked, but I'm also good with anything that gets us closer to consensus. Soni (talk) 00:15, 26 May 2024 (UTC)reply

Should RRFA petition signatures "roll"? For example, in a rolling petition with a length of one month, each signature expires when it is a month old; in a non-rolling petition, the petition itself expires a month after it is opened. theleekycauldron (talk • she/her) 23:47, 25 May 2024 (UTC)reply

Survey (rolling)edit

• Certainly not as you have described it. No system on WP relies on calendar dates. When I think of a “rolling” petition, I imagine a system in which the total length any given petition is active is greater than the length of the period the threshold of signatures is evaluated, e.g. petitions are open for a month but success is contingent on reaching a certain number of signatures within a consecutive seven day period during that month. Mach61 00:04, 26 May 2024 (UTC)reply
• Strongly support not rolling, though I would phrase it by saying the petition expires after a month (or whatever timeframe we decide on), rather than the signatures. However, still on team find a consensus, therefore, (regular-strength) support rolling. HouseBlaster (talk · he/him) 00:07, 26 May 2024 (UTC)reply
  • @HouseBlaster and Mach61: thanks for the notes! Clarified :) theleekycauldron (talk • she/her) 00:23, 26 May 2024 (UTC)reply
• Oppose rolling For admins working in difficult areas this would result in an endless petition. The admins willing to do such work is already a small subset of total admins, as part of a process to improve RFAs (and so improve admin numbers) we shouldn't be making being an admin worse. -- LCU ActivelyDisinterested «@» °∆t° 00:13, 26 May 2024 (UTC)reply

  I think a rolling endless petition, just like every administrator on dewiki has one, with the occasional feedback vote against a recent action, would be quite okay. An entire desysop petition started in response to the same action would be far more discouraging, and I guess more likely to attract pile-on votes from people who had waited for the opportunity. ~ ToBeFree (talk) 00:22, 26 May 2024 (UTC)reply

  That is just Damocles hanging forever above an admin, and is so more likely to discourage unpopular but correct actions. -- LCU ActivelyDisinterested «@» °∆t° 15:48, 26 May 2024 (UTC)reply

  I certainly wasn't aware that the dewiki model implicitly entailed rolling petitions, I would have opposed if I had. But even so the dewiki model is a starting point, it's limits and models may not be completely correct for enwiki due to differences in scale. -- LCU ActivelyDisinterested «@» °∆t° 15:51, 26 May 2024 (UTC)reply

• Reiterate my opposition to rolling petitions from the other section. Petitions should be specific and actionable, not ongoing "the king is a fink" discussions. --NYKevin 01:58, 26 May 2024 (UTC)reply
• The whole point of basing a desysop process on dewiki's is to have rolling petitions. Without them, the recall process just means voting on an individual bad decision. Oppose non-rolling. —Kusma (talk) 04:57, 26 May 2024 (UTC)reply
• Prefer not rolling, but also want to make sure this discussion ends in a consensus, per Houseblaster. Tazerdadog (talk) 05:12, 26 May 2024 (UTC)reply
• Strongly prefer rolling petition, but find a consensus. Keeping petitions non rolling has the potential to put too much weightage on one single event. We have Arbcom to handle egregious one off incidents. Soni (talk) 05:40, 26 May 2024 (UTC)reply
• There are strong arguments both in favor of and against rolling petitions. I, too, really want this to close with consensus, so I'm inclined to support both, with a preference for a rolling petition. Toadspike Talk 08:20, 26 May 2024 (UTC)reply
• Yes, but I agree with HouseBlaster that the petition expires after extended lack of activity; the signatures on it do not. Also have to agree with Kusma: If the petitions are non-rolling, i.e. are nothing like the de.wikipedia model there was a consensus to base our model on, then we've just come full circle back to a failure yet again to come to a consensus to do anything at all. Even if something did emerge as an action item under a non-rolling system, then Kusma is correct that it would be basically an "incident report". We already have ArbCom desysopping procedure for that. The entire point of all of this is for the community to have a means of removing an admin who is long-term problematic due to a pattern of behavior that in total has a deleterious effect but in which any given specific action or "incident" isn't quite actionable (otherwise the extant ArbCom process would already have been invoked). PS: To the extent this might have something to do with the poorly worded "Expired signatures on initiation petitions" section below, see my comments there. In short, our petition comments and their signatures do not really "expire" in a meaningful way (as statements of editorial-community-member concerns about an adminstrator's behavior; rather, under one of the proposed systems, they would stop, after a cut-off-period, being counted toward a mimum number of responses for action to be taken on the basis of the petition; but they are not in any other way invalidated or of lesser import than anyone one else's comments and signatures.  — SMcCandlish ☏ ¢ 😼  09:33, 26 May 2024 (UTC); rev'd. 09:59, 26 May 2024 (UTC)reply
• Support both, slight preference to try non-rolling first. I do not agree that having a non-rolling petition somehow invalidates Phase 1's consensus; the consensus was to have recall based on or similar to dewiki, not to have recall exactly like dewiki (and indeed we are discussing here all sorts of variations on dewiki's model). There are good arguments in favor of both options, and it's hard to predict how this will go since we've never tried it before. But I think non-rolling will take some pressure off of admins. I'm worried about admins having a constant "hate log" that never dies but never hits the threshold to trigger a recall, so that's why I slightly prefer non-rolling. I expect that a non-rolling petition that has merit will quickly attract dozens of signatures because many people will be familiar with longstanding problems, and so it would hit the threshold quickly, or else if it's not merited, it'll just attract a few signatures because it's just a small minority that are unhappy. We won't know until we try out one system or the other. So I'm fine with trying either one first, but slight preference for trying non-rolling first. Levivich (talk) 13:39, 26 May 2024 (UTC)reply
• Oppose rolling, for two main reasons. First, a rolling process leaves admins vulnerable to ongoing threats of recall, even when there wasn't enough concern about them to begin with. Put another way, if there is a legitimate reason to recall an admin, that should be apparent within a limited amount of time, and it's counterproductive to always have "another bite at the apple" always hanging around. Second, I am not persuaded by arguments that we need to base this on the de-wiki process. There was no consensus in Phase 1 that we must do so, and we should instead focus on what is best for en-wiki. --Tryptofish (talk) 18:43, 26 May 2024 (UTC)reply
• Oppose rolling - there is no consensus for creating a demerit point system for admins, which is what this will be, and it did not come up in proposals in round 1. With rolling endorsements, each petition will just be an endless laundry list of every time someone feels wronged by an admin. This will be the community-approved system of admin harassment, and it will impact admins the most who work in the most contentious areas of the project, where admins are needed the most, and it will drive admins away and lead to chaos. It's a bad idea. Ivanvector (^Talk/_Edits) 19:12, 26 May 2024 (UTC)reply
• Oppose rolling – I think this tracks with the reasoning behind how I !voted on the recall proposals earlier. As for long term problematic patterns, I'm fairly certain a nonrolling process could deal with this successfully... people can collectively decide that some action is a final straw and say "this is enough and this behaviour obviously isn't changing". Alternatively, such a thing a situation could go to ArbCom. Clovermoss🍀 (talk) 22:25, 26 May 2024 (UTC)reply
• Oppose rolling, as it would be dreadful for morale. Dealing with a long-term pattern of poor judgement does not require a long-term de-sysopping process. As I've said elsewhere on this page, we'd be setting up permanent pages filled with negativity about our most active admins; it's a sure-fire way of making sure they eventually stop doing what they're doing. Vanamonde93 (talk) 05:21, 27 May 2024 (UTC)reply

Discussion (rolling)edit

• I think a simpler way to describe this option is whether or not petitions should have a fixed duration, or be continuously ongoing with supporting statements expiring after a set time, thus implementing a rolling window of supporting views. isaacl (talk) 23:55, 25 May 2024 (UTC)reply
  • Ah, I think I know how I can punch up the wording. theleekycauldron (talk • she/her) 23:57, 25 May 2024 (UTC)reply

    Your changes are not what I feel most people are thinking of. I do not believe anyone's suggested that petitions continuously expire each month. I think the choices that have been discussed so far are a continuously open petition with expiring statements, as with the German language Wikipedia, or petitions with a fixed duration, with other proposals describing options on how often petitions can be opened. isaacl (talk) 00:16, 26 May 2024 (UTC)reply

    Yeaah, fixed that one up. theleekycauldron (talk • she/her) 00:24, 26 May 2024 (UTC)reply

    Thanks for the update. Note the first sentence is still confusing because the whole point of having a rolling window is that the signatures do not, in fact, roll anywhere. However the rest of the description clarifies the proposal. isaacl (talk) 00:11, 27 May 2024 (UTC)reply

• Courtesy pings to @Dilettante, Fanfanboy, Ahecht, Giraffer, S Marshall, Tazerdadog, Toadspike, Valereee, Chetsford, Mach61, Levivich, Rhododendrites, ToBeFree, Soni, Jéské Couriano, Gadfium, Queen of Hearts, Clovermoss, Tazerdadog, Remsense, Ahecht, Extraordinary Writ, Tryptofish, Teratix, Ratnahastin, Lepricavark, ModernDayTrilobite, SWinxy, MER-C, BluePenguin18, Bilorv, Vanamonde93, Frostly, HouseBlaster, Stifle, AirshipJungleman29, Draken Bowser, Kusma, ActivelyDisinterested, Chalst, Amorymeltzer, NYKevin, Xymmax, Visviva, SMcCandlish, BoldGnome, and Licks-rocks. theleekycauldron (talk • she/her) 23:57, 25 May 2024 (UTC)reply

What percentages of support are necessary for an administrator to pass a reconfirmation RfA?

• Option A: 65% for a pass, 55% and above is at bureaucrat discretion (similar to proposal 16C)
• Option B: 75% for a pass, 65% and above is at bureaucrat discretion (same as RfA)
• Option C: 60% for a pass, 50% and above is at bureaucrat discretion
• Option D: 55% for a pass, 45% and above is at bureaucrat discretion
• Option E: Desysopping should gain consensus. Rights are removed if 65% editors !vote to desysop, 55% and above is at bureaucrat discretion.
• Something else (specify...)

Note - Option A stated 66.6% for a couple hours. It was altered to 65% per discussion section below.

Survey (reconfirmation threshold)edit

• D Sincerely, Dilettante 14:56, 8 May 2024 (UTC) E > D > C oppose B and A. Sincerely, Dilettante 15:46, 9 May 2024 (UTC)reply
• C > D > E > A oppose B Fanfanboy (talk) 15:35, 8 May 2024 (UTC)reply
• C —S Marshall T/C 16:33, 8 May 2024 (UTC)reply
• 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:47, 8 May 2024 (UTC)reply
• C seems like the best by pure intuition and common sense Toadspike (talk) 16:50, 8 May 2024 (UTC)reply

  To clarify, I oppose B. I am neutral on A. Support D, weak support E. If more than 50% of editors vote to desysop, that should get at least a crat chat, if not an outright desysop. Toadspike (talk) 11:43, 14 May 2024 (UTC)reply

• E or D and oppose A, B, C Since the standard RfA threshold to create an admin sets the bar at a (super-) majority, it would make no sense that reversing the process sets the bar at a (super-) minority. Chetsford (talk) 17:03, 8 May 2024 (UTC); edited 17:18, 8 May 2024 (UTC); edited 23:47, 8 May 2024 (UTC)reply

  Correct me if I'm wrong, but I'm pretty sure reconfirmation adminship isn't meant to remove adminship, but to see if the admin is worthy of keeping it, so passing an RRFA means the admin gets to keep the mop. Basically another RFA that's easier to pass (depending on the consensus of this vote). Fanfanboy (talk) 13:36, 13 May 2024 (UTC)reply

• A or C Mach61 17:05, 8 May 2024 (UTC)reply
• E or D. The community should not be allowed to desysop by cold feet. Desysop should happen when the community comes to the clear conclusion that its previous judgement was in error, not when it starts to waver a bit on its previous commitments. Imagine if we could nullify policies and guidelines by simply holding RfCs until we arrived at a "no consensus to continue", and then killed it. theleekycauldron (talk • she/her) 17:13, 8 May 2024 (UTC)reply
  • Comment: It looks like C has the most support as the center choice, with E and A being the popular options on either side of it. I prefer C to a no consensus close, and I strongly encourage everyone to help avoid a no-consensus close on this. theleekycauldron (talk • she/her) 18:36, 12 May 2024 (UTC)reply
• B, although I'd just specify it as "same as RFA." Reconfirmation RFA should be same as RFA, all admins should be judged by the same standards of support, and if RFA thresholds change, then RRFA should, too. If not B, then, in order, A>C>D (the closer to actual RFA standards, the better). Oppose E; someone with 60% against and 40% in favor should not be an admin, period. Levivich (talk) 17:20, 8 May 2024 (UTC)reply

  Although I really don't like E, that's still better than a "no consensus" outcome; I'll take recall with E over no recall at all. Levivich (talk) 03:11, 12 May 2024 (UTC)reply

• Pro-any-consensus per Tazerdadog. ~ ToBeFree (talk) 18:14, 8 May 2024 (UTC)reply
• C looks reasonable to me.-Gadfium (talk) 23:31, 8 May 2024 (UTC)reply
• Levivich summarizes my thoughts well. But find a consensus. Queen of Hearts (talk) 01:37, 9 May 2024 (UTC)reply
• A or C, the threshhold should be lower than for RfA, since admins are likely to have ticked off a fair number of problematic editors, but not as low as E since there will be many people who would not vote against a standing admin for fear of reprisal if the recall didn't pass. --Ahecht (TALK
  PAGE) 18:03, 9 May 2024 (UTC)reply
• E for now, simply because it's important to move cautiously so as not to end up alienating a critical mass of the community. We can always raise the threshold later, but it's very hard to repair the process's reputation if it starts sweeping out admins unreasonably. I do prefer any threshold to nothing, though. Extraordinary Writ (talk) 19:26, 9 May 2024 (UTC)reply
• D. Any admin who gets to this stage is going to be at a disadvantage, and this still allows for consensus, in my opinion. --Tryptofish (talk) 21:31, 9 May 2024 (UTC)reply
• E – It's hard to imagine cases that require desysopping getting to this stage but failing to meet this threshold. Remsense诉 02:18, 10 May 2024 (UTC)reply
• E or D there's a certain logic to Levivich's idea we should just use the RfA thresholds, but I fear anyone going into this process will attract prejudice against them simply for the fact they are facing a reconfirmation RfA in the first place. The thresholds need to correct for this. – Teratix ₵ 02:30, 10 May 2024 (UTC)reply
• B & E reconfirmation threshold should be same as the rfA process and desysopping can be considered incase editors vote overwhelming in support for it. Ratnahastin (talk) 07:15, 10 May 2024 (UTC)reply
• C or D. As others have stated, I believe facing a reconfirmation RfA inherently puts an admin at somewhat of a disadvantage, so I think the thresholds should be tailored to account for that. Additionally – while I feel that E's threshold is somewhat too generous (per Levivich's reasoning), I do sympathize with its claim that "desysopping should gain consensus". For RRfAs that end in a crat chat, I would encourage the crats to view a "no consensus" finding as "no consensus to remove the tools"; most consensus-finding processes retain the previous status quo if no consensus is found, and I believe RRfA should do likewise. ModernDayTrilobite (talk • contribs) 13:55, 10 May 2024 (UTC)reply
• B The standard for removal of adminship should be an exact mirror of the standard for granting it, otherwise absurd results ensue. * Pppery * _{it has begun...} 22:43, 10 May 2024 (UTC)reply
• A or C are fine with me. It's a lower threshold for sure, but given the original confirmation as an admin there had been strong community consensus in favor of granting privileges. SWinxy (talk) 23:11, 10 May 2024 (UTC)reply
• E. One would imagine consensus be needed to change the status quo (that is, the admin remain an admin). MER-C 14:54, 11 May 2024 (UTC)reply
• B Agree with Pppery. The RRfA is a review of the admin's work thus far to decide whether they continue to hold the same high level of community trust seen in their initial RfA. BluePenguin18 🐧 ( 💬 ) 15:34, 11 May 2024 (UTC)reply
• E (preferred) or D Agreeing with Theleekycauldron. Happy days, ~ Lindsay^Hello 18:43, 11 May 2024 (UTC)reply
• Find a consensus. Per Tazerdadog. Every editor has 1-3 preferences on the exact threshold they think fits recall best. But almost all of those would like to see a recall mechanism over none. All of these options are reasonable enough that I support each of them, as long as it results in a consensus. Please find a consensus. Soni (talk) 19:04, 11 May 2024 (UTC)reply

  But almost all of those would like to see a recall mechanism over none.

  Perhaps a majority, but count me out of it. If I supported more than one option, I would say so. Remsense诉 08:14, 13 May 2024 (UTC)reply

  One can only find a consensus where one exists. Otherwise, it is a WP:Supervote. --Tryptofish (talk) 16:54, 13 May 2024 (UTC)reply

• A as the first choice, a conservative option to allow for the potential that people with grudges make up a non-trivial bloc at the RfA. Anything else as second choice. — Bilorv (talk) 08:29, 12 May 2024 (UTC)reply
• C > A > B, oppose the others. We need to recognize that most administrative decisions, even good ones, make someone upset, and therefore a reconfirmation percentage is extremely likely to be lower than a corresponding RFA percentage. However, I'm not comfortable with someone remaining an admin with <50% of the community's support. Vanamonde93 (talk) 17:57, 12 May 2024 (UTC)reply
• B. The standards should be the same as a regular RfA. All administrators must hold the same level of trust in the community. Frostly (talk) 05:45, 13 May 2024 (UTC)reply
• Find a consensus. HouseBlaster (talk · he/him) 02:27, 14 May 2024 (UTC)reply
• E over D, and oppose all others, consensus should be needed to change the status-quo. Bear in mind that just as RFAs tend to happen when the admin is at their best, recalls would tend to happen when they are at their worst. Stifle (talk) 08:18, 14 May 2024 (UTC)reply
• E>D per Stifle, lest we do to our admins what Athens did to her generals. Draken Bowser (talk) 21:01, 14 May 2024 (UTC)reply
• D > E, oppose the others. A simple-majority vote count has worked well at Commons, so I think we can replicate it here. I agree with the spirit of E, "Desysopping should gain consensus", but think 65% is too high a threshold for desysopping; if you lose majority support of the community, you should not be an admin. So numerically I support D: 55% in either direction is a consensus, else up to the discretion of the closing bureaucrat. The main issue with making reconfirmation RfA the same as RfA (option B) is that a slight shift in turnout can lead to a different result; I fundamentally believe that the burden of making a change lies with those seeking to make that change. -- King of ♥ ♦ ♣ ♠ 23:31, 14 May 2024 (UTC)reply
• C or D for a start, we can revisit this after the process has run a few times. —Kusma (talk) 09:38, 15 May 2024 (UTC)reply
• E only If the point is to desysop an editor then the threshold should be set as such, otherwise a minority could eject admins. -- LCU ActivelyDisinterested «@» °∆t° 22:33, 15 May 2024 (UTC)reply

  An RRFA is basically another RFA. If an RRFA passes, the editor is NOT desysoped, they instead keep their admin. Fanfanboy (talk) 12:19, 16 May 2024 (UTC)reply

  Are they desysoped by the recall petition passing? If not they are a admins when the RRFA happens, and if they fail they are desysoped. It's a desysop process however you name it, and if 40% can desysop an admin then thats a problem. Also the community hasn't repeatedly asked for a process to allow admins to be reconfirmed, they have asked for a process to desysop admins. -- LCU ActivelyDisinterested «@» °∆t° 12:45, 16 May 2024 (UTC)reply

  From my understanding. A recall petition only desysops if the admin doesn't start an RRFA (per #Desysop after Recall petition). An RRFA is a vote to see if we think the editor should keep the mop. Passing RRFA = Keep the mop. Fail = Lose it. Again this is from my understanding (and I'm still new here so I don't know as much as everyone else who's voting) Fanfanboy (talk) 13:32, 16 May 2024 (UTC)reply

  Yes the RRFA is to see if the admin should keep the mop, if they fail they will be desysoped. RRFA is not another RFA as the editor will already be an admin, it's a process that will allow the community to desysop an admin if they fail the grade. So if the pass is set at 60% then only 40% is needed to desysop an admin. The question should be 'should the admin be desysoped', not default to being desysoped if a minority want it to happen. -- LCU ActivelyDisinterested «@» °∆t° 14:36, 16 May 2024 (UTC)reply

  Ah, now I see your point. Thanks for clarifying! Fanfanboy (talk) 16:19, 16 May 2024 (UTC)reply

• Consensus as is the case for RfA, so I suppose B. ~ Amory (u • t • c) 15:37, 17 May 2024 (UTC)reply
• Find a consensus, but I prefer A ≥ C > B (i.e. I like A slightly more than C, and both A and C significantly more than B) and weakly oppose D and E. Admins should have the trust of the community, but standard RFA is too much of a gauntlet. I would vote to make RFA use A or C instead of B, but that's an entirely separate discussion. --NYKevin 19:37, 17 May 2024 (UTC)reply
• B, same as RfA. Don't complicate things for no reason, and we have a bar for what "community trust" means that has taken many years and lot of angst to establish, so don't mess with it.  — SMcCandlish ☏ ¢ 😼  01:29, 23 May 2024 (UTC)reply

Discussion (reconfirmation threshold)edit

• Unlike typical RfA candidates, RRfA candidates have already been an admin so we have a track record to go off of. With the former group, we always have to account for the chance that the user will end up making mistakes more frequently as an admin than as a normal editor so a higher threshold makes sense. Additionally, admins shouldn't be discouraged from controversial moves/areas (AE in particular is on life support) because of the risk of recall due to a minority holding a grudge. Sincerely, Dilettante 15:54, 8 May 2024 (UTC)reply
• It's very minor, but can option A be modified to 55-65% (rather than 66.6%)? It would be equivalent to shifting RfA thresholds down 10% and is slightly more intuitive, with no real impact, since crats hold cratchats for things a few % either side of the threshold anyway. Giraffer (talk) 15:56, 8 May 2024 (UTC)reply

• Done. Soni (talk) 16:57, 8 May 2024 (UTC)reply

• What does the German Wikipedia use for threshholds? The same as their standard RfA? --Ahecht (TALK
  PAGE) 18:15, 9 May 2024 (UTC)reply

  Yes. Two thirds (and at least 50 supports), no discretion. —Kusma (talk) 12:47, 21 May 2024 (UTC)reply

When is a recall petition not allowed for an admin?

• Option A: For 12 months after an admin successfully runs for an RFA, RFB, RRFA, or Arbcom elections (same as proposal 16C)
• Option B: For 12 months after an admin successfully runs for an RFB, RRFA, Arbcom elections
• Option C: (In case of non-rolling requests) For 6 months after any failed recall petition
• Option C+: (In case of non-rolling requests) For 12 months after any failed recall petition
• Something else (specify...)

Note - "RRFA request" was edited to "recall petition" to easier clarify the petition versus the actual RRFA.

Survey (Eligibility to RRFA)edit

• A and C. Admins should not have the threat of an RRfA being opened at all times. They're people too. Sincerely, Dilettante 14:56, 8 May 2024 (UTC)reply
• A and C > C+ Fanfanboy (talk) 15:43, 8 May 2024 (UTC)reply
• Find a consensus - All of the proposed options 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:48, 8 May 2024 (UTC)reply
• A and C Toadspike (talk) 16:52, 8 May 2024 (UTC)reply
• C Chetsford (talk) 17:05, 8 May 2024 (UTC)reply
• C. I think A is a bit too generous to the admin, A 3 or 6-month cooldown from election may be better, but I'm not opposed to it Mach61 17:08, 8 May 2024 (UTC)reply
• A and C per above :) theleekycauldron (talk • she/her) 17:18, 8 May 2024 (UTC)reply
• I'm at "none of the above" for now. I'd support something like 3-6 months after gaining the admin bit, regardless of how it's gained (RFA/RRFA/admin elections/Act of God/etc.). I don't see why RFB or Arbcom elections would matter at all if we're talking about de-sysop and not de-crat or de-arb. If recall also applies to crats and arbs, then I'd say the same 3-6 months. I'd have a 1-3 month "waiting period" or "cooling off period" for failed RRFA requests. Levivich (talk) 17:26, 8 May 2024 (UTC)reply

  OK, A and C or C+. I don't really have an opinion between 6 months (C) or 12 months (C+); I'd support whatever others support. Levivich (talk) 17:33, 12 May 2024 (UTC)reply

• A and C and C+ are fine. ~ ToBeFree (talk) 18:35, 8 May 2024 (UTC)reply
• A and C or C+.-Gadfium (talk) 20:49, 13 May 2024 (UTC)reply
• A and C+ (edited to change from C to C+). --Ahecht (TALK
  PAGE) 15:31, 9 May 2024 (UTC)reply
• A and C seem fair. Regarding A, if an admin isn't doing something that earns them an ArbCom desysop, the harm of giving them twelve months to get their act together and "learn on the job" is low. Extraordinary Writ (talk) 19:38, 9 May 2024 (UTC)reply
  • C+ is also fine by me (and probably preferable). Extraordinary Writ (talk) 02:39, 10 May 2024 (UTC)reply
• C, but probably for 12 months, not 6. (Edit: thus really C+.) If someone screws up during their first year, I don't want to have to wait a year. But we should be cautious about "double jeopardy". --Tryptofish (talk) 21:33, 9 May 2024 (UTC)reply
• A and C+ 12 months after initial election and 12 months after unsuccessful petitions. Administrators simply should not have to face such intense public scrutiny so often. – Teratix ₵ 02:34, 10 May 2024 (UTC)reply
• A & C, seems reasonable. Ratnahastin (talk) 07:18, 10 May 2024 (UTC)reply
• A or C. I would also be amenable to a split system of something like "12 months after initial election, 6 months after RFB/RRFA/Arbcom/failed recall petition". ModernDayTrilobite (talk • contribs) 14:00, 10 May 2024 (UTC)reply

  Option C+ is acceptable to me as well. ModernDayTrilobite (talk • contribs) 14:15, 17 May 2024 (UTC)reply

• C, although I'd agree that a year is better. In an unusually crazy circumstance there's always arbcom. Valereee (talk) 20:12, 10 May 2024 (UTC)reply
• A and C. A successful run means that the community has overwhelmingly promoted them, and the recall should reflect that by granting a grace period. SWinxy (talk) 23:11, 10 May 2024 (UTC)reply
• A and C Per Extraordinary Writ, the horrific misuse of admin tools that would justify a recall petition during their first year after a successful RfA is surely already addressed by ArbCom desysopping. BluePenguin18 🐧 ( 💬 ) 15:45, 11 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.

---