Wikipedia:Requests for adminship/2024 review/Phase II/Administrator recall

2024 Requests for adminship review

Status as of 19:01 (UTC), Thursday, 7 November 2024 (update time)

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 [or] 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:

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.

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.

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.

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.

Any admins may voluntarily stand for RRFAs at any time if they like. This will be otherwise considered identical to a community initiated Reconfirmation.

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.

Initiation procedure

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

There is consensus for option B. Numerically, the first choices for editors were options B, C, and D, with many editors !voting for a subset of those as their first choice or ranking one of the others as their second or third choice. There was strong opposition to options A, E, and F and a strong consensus against adopting a petition period longer than one month. As between options B, C, and D, there was consensus that one month and 25 EC editors complaining about an admin within that time period satisfies the Goldilocks principle. There was consensus that 10 days is too short a time period and might encourage reactive petitions over a single incident. There was limited argument regarding the precise number of editors required to trigger a recall, but also consensus that 25 editors is a sufficient threshold to establish that there is a loss of confidence in an admin. Those editors who advocated for a higher threshold argued that 25 is too small a number and might allow gaming the system, particularly by editors involved in CTOPs voting en masse to recall an admin. However, more editors believed that the community would be a sufficient backstop against such bad faith efforts. (non-admin closure) voorts (talk/contributions) 22:46, 13 September 2024 (UTC)[reply]

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)[reply]
~~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)[reply]
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)[reply]
@Fanfanboy How could you trigger E without already having triggered B? --Ahecht (TALK
PAGE) 15:15, 9 May 2024 (UTC)[reply]
@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)[reply]
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)[reply]
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)[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:46, 8 May 2024 (UTC)[reply]
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)[reply]
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)[reply]
D is also okay, after coming back to this. Oppose E, F, G. Toadspike (talk) 11:40, 14 May 2024 (UTC)[reply]
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)[reply]
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)[reply]
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). House Blaster (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. --N Y Kevin 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]
Oppose E, F and G, that stretches it out way too long. Senior Captain Thrawn (talk) 11:22, 27 May 2024 (UTC)[reply]
D, C is ok, oppose others If there is a real community concern about an administrator, it will not take too long to collect the appropriate number of signatures. --Enos733 (talk) 16:44, 27 May 2024 (UTC)[reply]
Option G – unless 1) petition pages are going to include oppose sections where users can !vote against starting a reconfirmation RFA and/or state their confidence in the candidate, and this gets weighed against the supporting signatures; and 2) petitions are not publicised on watchlists. Strongly oppose Option A – a year is far too long. If there are legitimate concerns about an administrator, it won't take a year to get the requisite number of signatures. SuperMarioMan (Talk) 01:14, 30 May 2024 (UTC)[reply]
Also Oppose E and F as being similarly excessive. I see no reason for petitions to be dragged out for months. No petition subject deserves to be in a limbo for that long. That's just a highly effective way of putting them off Wikipedia for good, regardless of the petition outcome. SuperMarioMan (Talk) 20:20, 9 July 2024 (UTC)[reply]
Support B and F. Tony (talk) 07:35, 2 June 2024 (UTC) Reinserted vote on behalf of Tony1 who moved it from a wrong section. --George Ho (talk) 00:09, 24 June 2024 (UTC)[reply]
Support C, D, or G. Oppose all other options. It is fairly easy for LTAs to get extended confirmed accounts and I would be concerned that a combination of the longer timescale / smaller threshold of editors could make it possible for an LTA to meet the conditions through their sockpuppets. Dreamy Jazz ^{talk to me | my contributions} 15:06, 2 June 2024 (UTC)[reply]
Option G - Not a fan of any of these. Whatever is selected though should not be set to be longer than 30 days - the length of an WP:RFC. In other words, this should be handled roughly the same as any other "Request for comment" on Wikipedia. (To be clear: Strong Oppose anything longer than 30 days.) That said, if I had to pick one, maaaybe Option D? 10 days with 40 people sounds like a decent size XfD discussion. And 10 days is around the length of time of an RfA currently. - jc37 16:41, 2 June 2024 (UTC)[reply]
Option H xor G. No policy breach, no recall. Policy can be expanded where necessary. Also Option C if H looks reasonable, but flexible on this point Oppose option A , too long, not keen on E and F as unnecessarily complicated. Cheers, · · · Peter Southwood ^(talk): 08:58, 3 June 2024 (UTC)[reply]
nb: I removed option H on relevance grounds, as it pertained to the content of the initial petition rather than the signature threshold. theleekycauldron (talk • she/her) 09:07, 3 June 2024 (UTC)[reply]
Full and Strongest Possible Oppose to any Community Initiated Administrator Recall Process - I strongly and fully oppose the adoption of any community-initiated administrator recall process. It is already very hard for anyone to become an admin, and this will just encourage admins to work in less contentious areas, which defeats the whole purpose of being an administrator while also increasing the backlog and workload for other admins. Therefore, this type of system should never be adopted. We already have a working and well-established method through Arbcom for removing undesirable administrators. TheGeneralUser (talk) 09:43, 6 June 2024 (UTC)[reply]
I think that should be interpreted as equivalent to G. --Tryptofish (talk) 20:05, 6 June 2024 (UTC)[reply]
This user has cast identical !votes in several other sections, most of which have no obvious G-like equivalent. I would tend to interpret it as "I want to overturn the consensus reached in Phase I." I also think it is unambiguous enough that asking for further clarification would likely shed more heat than light. I think we should let the (Phase II) closer determine whether that is a reasonable position to take under the circumstances, and weigh the !vote accordingly. --N Y Kevin 00:35, 9 June 2024 (UTC)[reply]
They "thanked" me for my comment, so I assume they have no problem with what I said. I never said it should be interpreted that way in any other section of this page. Personally, I don't think that one can overturn a "consensus" that has not yet come into being. But I'm not going to tell the eventual closer how they should evaluate your reply to me. --Tryptofish (talk) 23:43, 9 June 2024 (UTC)[reply]
25 autoconfirmed editors sign a recall petition within the last 6 months. Using a longer time period (6 months rather than 1 month) will help to catch admins with a pattern of low-level abuse. I put "autoconfirmed" because the EC requirement for 500 edits seems too high here. Tim Smith (talk) 01:06, 19 June 2024 (UTC)[reply]
Option G as first choice – No need to have the petition requirement as it does nothing except to make the recall process some sort of mini-ArbCom: petition signatures = support vote to start a case, right? On the other hand, if the consensus favors requiring petitiong signatures, then options A and F in conjunction as second choice, especially to favor looser restrictions of petitions. Alternatively, option B as third choice. Not in favor of (rigid) short-term petitions, honestly, but I guess I'm not a fan of dragging the petition process too long either. George Ho (talk) 22:22, 19 June 2024 (UTC)[reply]
Modified option A, B second choice 50 editors in a year? Make it 6 months, a year drags it out too long, whilst 6 months is a clear concern. 25 editors in a month is certainly also a concern! Justarandomamerican (talk) Have a good day! 18:58, 22 June 2024 (UTC)[reply]
Primarily oppose (option G) any petition recall process because I think a desysop process through ArbCom and the current resignation under a cloud regime works as intended. This is essentially to say that a community-elected body should be the ones to decide whether an admin retains their rights or not, that's sort of why they're elected, admin conduct is a major part of what the ArbCom is for, I'm deeply uncertain that a petition recall process will be more efficient. --qedk (t 愛 c) 00:33, 23 June 2024 (UTC)[reply]
Support B > C > E, Oppose A, D, F, Strongly oppose G: 10-day petitions are way too short (even active editors could be on a short vacation) and a 3+ months-long petition would be a Sword of Damocles hanging (figuratively) on the admin's head for far too long. A petition gives a clear and unequivocable criterion to start the procedure, so I strongly support this method. Broc (talk) 11:21, 25 June 2024 (UTC)[reply]
Support B; any thin consensus excluding G as second choice. 10 days encourages hasty actions. If RfCs take 30 days, I don't see any reason to deviate from that. As for thresholds higher than 25 and arguments regarding chilling effects on bold actions and contentious topics work, well, I trust the community to back up the involved administrator. I don't believe that a truly unpopular-amongst-the-broader-community but right admin action can even exist; after all, we delegate power to administrators based on community consensus. As for concerns about gaming the system in CTs, the broader community will back up the admin and, with the 1-year immunity period, give them a strong mandate to continue their work. Iseult^Δxparlez moi 06:33, 27 June 2024 (UTC)[reply]

Discussion (Initiation procedure)

@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]

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.

Rolling

Clear consensus against rolling. (non-admin closure) Queen of Hearts (talk) 23:57, 24 August 2024 (UTC)[reply]

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

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)

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]
- I still oppose rolling, for the reasons discussed below, but note that the above vote was for completely different text than what is currently shown. Mach61 10:16, 20 June 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. House Blaster (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. --N Y Kevin 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 concern[s] 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]
Oppose rolling for a couple of reasons: As Vanamonde93 says immediately above, has the potential for destroying admins' morale; anything that isn't bad enough to gain the support of whatever the sufficient number of petitioners is in a short time is going to be too complex and will need to go the current option of Arbcom; i agree with Levivich about a "hate log" which seems to be a terrible possibility. Happy days, ~ Lindsay^Hello 16:55, 27 May 2024 (UTC)[reply]
Oppose rolling. Vanamonde sums up my thoughts better than I could myself. Giraffer (talk) 19:20, 27 May 2024 (UTC)[reply]
Oppose rolling. Essentially becomes a point system with the added disadvantage that the offences are anything that an editor dislikes. The consequence of such a system would be extreme difficulty getting any admins to take controversial decisions, especially when they have live signatures. No, any petition, if we must have one, should be a closed-ended period at the end of which all signatures expire. Stifle (talk) 07:39, 28 May 2024 (UTC)[reply]
Oppose rolling. An LTA could easily keep the petition open for several months by occasionally using a sockpuppet account to add another signature, making it a possibly long-term process for the admin. I also like the reasoning made by Stifle, in that a rolling petition is essentially a points based system without the safeguards to prevent points being given for no just reason. While an admin might be continually making bad decisions that causes signatures, this is the kind of thing arbcom will likely need to deal with to establish a pattern of behaviour. Dreamy Jazz ^{talk to me | my contributions} 15:12, 2 June 2024 (UTC)[reply]
Strong, Strong, STRONG OPPOSE - Discussions are closed on Wikipedia. There are many significant reasons for that. We shouldn't need to list them here in this WP:LOCAL discussion. - jc37 16:51, 2 June 2024 (UTC)[reply]
Oppose rolling There must be the equivalent of a statute of limitations. This would be an effective way to deter candidates for RfA.· · · Peter Southwood ^(talk): 09:18, 3 June 2024 (UTC)[reply]
Strongly oppose rolling As an administrator on German Wikipedia I can confirm that having a recall page where thinly veiled personal attacks persist continually, is quite demotivating. Often it is even worse on the corresponding talk page on which users put Vormerkungen (pre-nominations) even in the grace period one year after election. --Count Count (talk) 10:30, 3 June 2024 (UTC)[reply]
Strongly oppose rolling petitions. If there are legitimate concerns about an administrator, it should be possible to amass the requisite number of signatures within a month of the petition being opened. SuperMarioMan (Talk) 00:07, 10 June 2024 (UTC)[reply]
Addendum: (This goes for the proposal as a whole, not just this specific question.) Based on the comment immediately above mine, and criticisms I've read elsewhere, I oppose aligning this proposed process with de.wiki's or those on other-language Wikipedias. The process should develop independently and organically from en.wiki culture. SuperMarioMan (Talk) 20:53, 9 July 2024 (UTC)[reply]
Support rolling, which is used on the German and French Wikipedias, and per Kusma. We want to catch admins with a pattern of low-level abuse, not just vote on a single bad action. Tim Smith (talk) 01:32, 19 June 2024 (UTC)[reply]
Oppose rolling – Let's not do what German and French Wikipedias have been doing. I appreciate Kusma's and others' concerns about emphasizing on older past actions, but rolling the votes would lead editors into revoting every month in the same RFA recall, which would be gaming the process. Furthermore, a repeated offense in one month and then another and invalidating a vote from a prior month would be (disadvanges of) the statute of limitations that criminals would exploit. George Ho (talk) 21:01, 19 June 2024 (UTC)[reply]
Oppose rolling The fact is that enwiki is different, I understand the point of inspiration but it doesn't work, things need to be closed based on consensus - and can also be reopened based on consensus. Adding more arbitrary redtape is not the solution. A non-rolling process can achieve the exact same outcome if there is an actual policy that the community has observed to be appropriately violated. --qedk (t 愛 c) 00:24, 23 June 2024 (UTC)[reply]
Oppose rolling same reasoning as in my comment in the initiation section, we should not have a Sword of Damocles hanging on the sysop's head for too long. If the first petition fails and new questionable administrative actions come to light, a new petition can always be started. Broc (talk) 11:25, 25 June 2024 (UTC)[reply]
Oppose Been a while, but I'm back. Rolling would be a terrible idea. Fanfanboy (talk) 03:42, 9 August 2024 (UTC)[reply]
Full and Strongest Possible Oppose to any Community Initiated Administrator Recall Process - I strongly and fully oppose the adoption of any community-initiated administrator recall process. It is already very hard for anyone to become an admin, and this will just encourage admins to work in less contentious areas, which defeats the whole purpose of being an administrator while also increasing the backlog and workload for other admins. Therefore, this type of system should never be adopted. We already have a working and well-established method through Arbcom for removing undesirable administrators. TheGeneralUser (talk) 03:55, 12 August 2024 (UTC)[reply]

Discussion (rolling)

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]

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.

Reconfirmation threshold

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

There is consensus for option C. There is consensus that being haled into an RRfA will put editors at a disadvantage and that the threshold for reconfirmation should therefore be set lower than RfA to correct for that disadvantage. While there is also significant support for option E, most editors are of the view that the community should show that it has continued faith in an admin, rather than reach a supermajority consensus to desysop. (non-admin closure) voorts (talk/contributions) 23:09, 13 September 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)

~~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. House Blaster (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. --N Y Kevin 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]
Option F: de-sysoping should gain consensus but specific percentages of support and oppose should be a secondary concern, as RFAs are discussions, not mere polls. Alternatively, just copy current RFA practice, so Option B. Consensus thresholds should not be different from those of non-reconfirmation RFAs. SuperMarioMan (Talk) 23:09, 29 May 2024 (UTC)[reply]
C is my first choice, but any option is better than no consensus. LEPRICAVARK (talk) 00:24, 1 June 2024 (UTC)[reply]
Any except B. Dreamy Jazz ^{talk to me | my contributions} 15:15, 2 June 2024 (UTC)[reply]
Option B - definitely, per Pppery and SMcCandlish. If we want a different threshhold, then discuss to change RFA first. - jc37 16:55, 2 June 2024 (UTC)[reply]
This is about desysopping, so Option E is appropriate. · · · Peter Southwood ^(talk): 09:48, 3 June 2024 (UTC)[reply]
Full and Strongest Possible Oppose to any Community Initiated Administrator Recall Process - I strongly and fully oppose the adoption of any community-initiated administrator recall process. It is already very hard for anyone to become an admin, and this will just encourage admins to work in less contentious areas, which defeats the whole purpose of being an administrator while also increasing the backlog and workload for other admins. Therefore, this type of system should never be adopted. We already have a working and well-established method through Arbcom for removing undesirable administrators. TheGeneralUser (talk) 09:56, 6 June 2024 (UTC)[reply]
B (same as RfA), per Levivich and SMcCandlish. Tim Smith (talk) 01:45, 19 June 2024 (UTC)[reply]
B as first choice per Levivich and SMcCandlish as well – The purpose is reaffirming admin promotion, so why should the RFA recall be any different from, i.e. have lower standards than, the normal RFA? If an incumbent admin gains less than 65% support, then that admin may not deserve to be an admin anymore.
But if there's no consensus on A, B, C, and D, then either E as a second choice or gain consensus, 55% !vote to desysop, 50~54.999% at crat discretion. Even slightly more than half of votes to desysop should be enough to determine admin's failure to meet current standards. George Ho (talk) 21:16, 19 June 2024 (UTC)[reply]
Same standards as a normal RfA, consensus is necessary. --qedk (t 愛 c) 00:26, 23 June 2024 (UTC)[reply]
B. I mean, the admin now has a track record. We're not talking about what she promises to do and how she promises to behave. We know these things. Say 100 people vote. 25 are like "No, we now know how this person behaves, and we don't want her to be an admin anymore", and that's not enough? Good grief. Herostratus (talk) 11:48, 30 June 2024 (UTC)[reply]

Discussion (reconfirmation threshold)

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]

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.

Eligibility to RRFA

Alright. There is a clear consensus:

for A
against B

Although there's a clear consensus to adopt some version of C, whether to adopt option C (6 months) or C+ (12 months) was the subject of some debate; although not many !votes had detailed rationales, supporters of 6 months mainly argued that a year was too much in the face of egregious issues, and that it granted a year of immunity for admins to perform improper actions. Supporters of 12 months argued that a year defended against double jeopardy and that cases that cannot wait a year can still go through the arbitration process. Although this is not a vote, 6 months has roughly 2:1 support versus 12 months. These factors considered, I do not see a strong consensus either way, and am thus closing this proposal in favor of option C (6 months) as the most conservative option. Thanks, (non-admin closure) Queen of Hearts (talk) 01:54, 25 August 2024 (UTC)[reply]

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

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)

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]
A and 'C per Extraordinary Writ. Dreamy Jazz ^{talk to me | my contributions} 15:18, 2 June 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]
A & C+ Seems obvious that new admins should have time to learn the job, and it wouldn't be right to subject them to RRfAs or the threat thereof again and again without some respite. Happy days, ~ Lindsay^Hello 18:47, 11 May 2024 (UTC)[reply]
A & C, per above. A year is not too long to allow a new admin to learn the ropes; ARBCOM still exists for egregious mis-steps. Vanamonde93 (talk) 17:57, 12 May 2024 (UTC)[reply]
A and C+ to avoid double jeopardy. If it can't wait, it can go to ArbCom. MER-C 18:22, 13 May 2024 (UTC)[reply]
A and C. Stifle (talk) 08:18, 14 May 2024 (UTC)[reply]
A & C ~~ AirshipJungleman29 (talk) 17:18, 14 May 2024 (UTC)[reply]
C+ ArbCom is still going to be option. -- LCU ActivelyDisinterested «@» °∆t° 22:39, 15 May 2024 (UTC)[reply]
A and C+ Draken Bowser (talk) 21:59, 16 May 2024 (UTC)[reply]
A and C – C+ may be too long, but I am also in favor of it. Toadette^Edit! 00:19, 17 May 2024 (UTC)[reply]
A&C ~ Amory (u • t • c) 15:38, 17 May 2024 (UTC)[reply]
A and C, oppose C+ - A year is too long. If an admin's conduct is so controversial that six months is not long enough, then that suggests a broader controversy (bigger than just one admin), and the community should probably open an RFC or something to figure it out. Alternatively, it suggests one or two users are harassing this admin, and we have policies for that as well. In either case, C+ is just WP:CREEP. --N Y Kevin 19:11, 17 May 2024 (UTC)[reply]
A and C. Tend to agree with NYKevin with regard to C+. — SMcCandlish ☏ ¢ 😼 01:34, 23 May 2024 (UTC)[reply]
C > C+. I don't believe that recall petitions should be subject to any other process than other recall petitions. C or C+ are necessary to avoid "rolling petitions". BoldGnome (talk) 04:42, 23 May 2024 (UTC)[reply]
A and C+ to discourage people from repeatedly attempting the RRFA process if the first attempt fails. If there's still problems with an admin that are bad enough to consider a desysop after an RFA has failed, I think that should become an Arbcom job almost by default, because two RFA's in a row means the community process is in some way not working as intended. --Licks-rocks (talk) 21:39, 25 May 2024 (UTC)[reply]
A and C+ > C I don't want people to game the process because they are in a dispute with an administrator. I also would want any second recall petition to state new grounds for the recall and not rehash old(er) disputes. --Enos733 (talk) 16:54, 27 May 2024 (UTC)[reply]
C 12 months is too generous. LEPRICAVARK (talk) 00:39, 1 June 2024 (UTC)[reply]
12 month period after the community has consensus to entrust them with additional tools/responsibilities beyond WP:XC, such as adminship, bureaucratship, arbcom. - the same length of time as typically recommended for waiting to appeal a WP:BAN. Could also support 24 months: the length of time of an arbcom seat. (The provided options are really odd to parse, so not even going to try.) - jc37 17:05, 2 June 2024 (UTC)[reply]
Full and Strongest Possible Oppose to any Community Initiated Administrator Recall Process - I strongly and fully oppose the adoption of any community-initiated administrator recall process. It is already very hard for anyone to become an admin, and this will just encourage admins to work in less contentious areas, which defeats the whole purpose of being an administrator while also increasing the backlog and workload for other admins. Therefore, this type of system should never be adopted. We already have a working and well-established method through Arbcom for removing undesirable administrators. TheGeneralUser (talk) 10:01, 6 June 2024 (UTC)[reply]
Option C+: once a year ought to be enough for attempts to recall. If re-examination is warranted within a year, go to WP:RFAR. SuperMarioMan (Talk) 00:15, 10 June 2024 (UTC)[reply]
Also support A and B. A year's grace after passing RFA/B or an election is not unreasonable. Oppose C as being too short. SuperMarioMan (Talk) 20:45, 10 July 2024 (UTC)[reply]
A and C — I do favor RFA recall process, but then why not limit the eligibility? We still would like to see how newly promoted admins do within their own first years, and we'd still like to see how nominated admins perform withing six months after recall process. If no incidents in those periods, then no need to nominate that said admin for recall. Not in favor for waiting for one year after the recall attempt, honestly. --George Ho (talk) 21:29, 19 June 2024 (UTC)[reply]
Never. Admins should always be subject to recall. If an admin survives a recall and immediately commits some egregious act, they should be recalled again. Tim Smith (talk) 22:44, 20 June 2024 (UTC)[reply]
A and C+ thinking of this similar to anti-SLAPP regulations. --qedk (t 愛 c) 00:28, 23 June 2024 (UTC)[reply]

Discussion (Eligibility to RRFA)

We could even say something like "Bureaucrats can disallow any RRFA that is found to be repetitive or tendentious via a crat chat. Tazerdadog (talk) 16:50, 8 May 2024 (UTC)[reply]

Given the barrier to entry (i.e. pretty large-scale community action) that we're going to create for opening a recall, a gaggle of 'crats are not in a position to declare the community's concerns "tendentious", and whether something is "repetitive" or not is immaterial (all of this RfA reform stuff is extremely repetitive, for years, because it takes a long time and lot of adjustment to arrive at something the community will accept, and that's also true of a lot of things, including "who should be an administrator and why", etc.). — SMcCandlish ☏ ¢ 😼 01:37, 23 May 2024 (UTC)[reply]

Just to clarify my thinking on this (and to open myself up to rebuttal, in case people disagree): I do not like C+, because it confers an unnecessarily long period of immunity on an administrator, with no process or discussion (other than a list of signatures, which must be a short list or else the petition would have succeeded). C is a necessary evil to prohibit back-door rolling petitions, but the only other process I can think of with this kind of rerun immunity is WP:PROD, which has numerous important differences that should be obvious to anyone familiar with it (but just in case: articles are not editors, PROD is subordinate to AfD which has no such limitation, CSD is also available for simple cases, etc.). I also feel strongly that, if an admin has multiple recall petitions within a year, and it is not the result of harassment from the people filing the petitions, that fact alone is seriously concerning, and sweeping it under the rug with a blanket prohibition is not going to fix anything. It's merely going to redirect the discussion to other forums like ANI, most of which are less capable of dealing with this sort of discontent (RFAR can deal with it, but eugh, nobody wants to go to RFAR with three paragraphs of "User:Example keeps using their tools slightly wrong and reacting badly to criticism, and we tried talking to them but..."). --N Y Kevin 02:36, 26 May 2024 (UTC)[reply]

If C+ passes then even a frivolous petition by a single user would make an administrator immune to recall for a year. Seems to me like it would be open to abuse -> a co-conspirator opens a frivolous petition -> petition times out -> proceed to make controversial admin actions without fear of repercussions. Charcoal feather (talk) 14:58, 26 May 2024 (UTC)[reply]
- You still have arbitration for this situation. Stifle (talk) 07:41, 28 May 2024 (UTC)[reply]

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

Recall Petition Suffrage

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

There is consensus to adopt options C and D. Option A is obviously mutually exclusive with options B, C, and D. Thus, anyone !voting for the latter options implicitly opposed option A. Options B, C, and D, however, are not mutually exclusive with each other. Starting with option B, those in support contended that it would prevent particular editors from hounding the same admins over and over. In response, editors argued that this limit was arbitrary and that it would prevent editors who have the best knowledge of an admin's (mis)behavior from signing a recall petition. I find that both arguments have about equal weight. As there were about equal numbers on each side, I find no consensus to adopt option B. Those in support of option C argued that it provides a safety valve to prevent editors from frivolously or maliciously signing several petitions at once. The strongest argument in opposition was that our current processes for dealing with disruptive editing are sufficient to prevent abuses. However, that argument failed to persuade the majority of editors supporting option C, and thus I afford it significant weight and find consensus for option C. By my count, option D was supported by 6 editors who persuasively argued that it would be absurd to allow editors who cannot !vote at RfA to sign a recall petition. As there was no opposition to option D, I find consensus to adopt that option as well. (non-admin closure) voorts (talk/contributions) 04:19, 14 September 2024 (UTC)[reply]

When can eligible editors vote for a recall petition?

Option A: No limits
Option B: If they've not supported an recall petition for the same admin in the last 2 years
Option C: If they've supported less than 5 currently open recall petitions
Option D: Same as for RfA voting. [The exact limits for which are under development in Phase II also.]
Something else (specify...)

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

Survey (Recall Petition Suffrage)

B and CSincerely, Dilettante 15:00, 8 May 2024 (UTC)[reply]
A > C, Oppose B. If an editor has concerns over a given admin, they should be allowed to re-state it later. C makes sense as a protection against spurious "vote to recall every admin" but I'd personally still prefer other ways to do it (Say #Removing_signatures so uninvolved admins have leeway to remove votes on RRFA requests). Soni (talk) 15:20, 8 May 2024 (UTC)[reply]
C > A Fanfanboy (talk) 15:46, 8 May 2024 (UTC)[reply]
A > C, Oppose B, precisely per Soni.—S Marshall T/C 16:35, 8 May 2024 (UTC)[reply]
C is an important safety valve. This is not a hypothetical - it happens on DE wiki. Tazerdadog (talk) 16:53, 8 May 2024 (UTC)[reply]
A definitely, C also Per Soni, Tazer. Toadspike (talk) 16:54, 8 May 2024 (UTC)[reply]
B and C per Dilettante, oppose A. Chetsford (talk) 17:21, 8 May 2024 (UTC); edited 23:48, 8 May 2024 (UTC); edited 00:26, 9 May 2024 (UTC)[reply]
A and strongly oppose B ~~or C~~ neutral on C. I don't want to have to choose whether to support an admin recall because I'm worried that later another admin might get recalled who I would support recalling even more. This is especially true in the first year or so of recalls, when there will be more recalls than usual (because backlog). Limits like B or C are a terrible idea IMO. We don't limit how many admins we can support for RFA, or how many we can oppose at RFA, why would we limit how many admins we can vote for recall? Levivich (talk) 17:29, 8 May 2024 (UTC)[reply]
If you have 5 requests for recall that you are currently supporting and a 6th opens up you want to support even more, you may strike one of your 5 and support the 6th. Tazerdadog (talk) 17:48, 8 May 2024 (UTC)[reply]
Why would we limit ourselves in this way? If there are 6 admins that should be recalled, why can't I vote to recall all 6? Levivich (talk) 17:51, 8 May 2024 (UTC)[reply]
What are the chances of there being 6 requests open at one time? Fanfanboy (talk) 19:04, 8 May 2024 (UTC)[reply]
OK that's a good point, but this is a heck of a roundabout way to institute a throttle. I don't oppose capping the number of simultaneous open recalls, and 5 is a perfectly reasonable cap, but if that's what we want to do, let's just have a rule that says "no more than 5 can be open" rather than "no one can vote in more than 5 at the same time," because the latter just seems, well, roundabout. Levivich (talk) 03:06, 9 May 2024 (UTC)[reply]

It’s improbable but it’s not impossible. There are no needs for any arbitrary limit. If more than 5 admins are being recalled at the same time, voters should be able to vote on all admins. There are no advantages to limit the votes. ✠ SunDawn ✠ (contact) 12:33, 17 May 2024 (UTC)[reply]

A=D, i.e. no suffrage requirements beyond what is required for RFA. Levivich (talk) 02:31, 31 May 2024 (UTC)[reply]
Pro-any-consensus as described by Tazerdadog at #Initiation_procedure. ~ ToBeFree (talk) 18:39, 8 May 2024 (UTC)[reply]
C. We do not want to allow mass desysop nominations.-Gadfium (talk) 23:35, 8 May 2024 (UTC)[reply]
C as a safeguard. Queen of Hearts (talk) 01:55, 9 May 2024 (UTC)[reply]
C --Ahecht (TALK
PAGE) 15:33, 9 May 2024 (UTC)[reply]
C is fine, but it's not going to be useful if we choose a non-rolling option for petitions. I think there's an argument for "you may sign x petitions per year" as well, although I'm not going to be the one to propose it. Extraordinary Writ (talk) 19:43, 9 May 2024 (UTC)[reply]
B, although I'm unenthusiastic about the whole idea. At least we don't want people to keep "going after" the same admin. --Tryptofish (talk) 21:35, 9 May 2024 (UTC)[reply]
And under no condition may anyone re-add their signature to a rolling petition. --Tryptofish (talk) 21:45, 24 May 2024 (UTC)[reply]
A Levivich is right about the weird incentives an outright limit would create. If editors indiscriminately support mass recalls, just sanction them. – Teratix ₵ 02:46, 10 May 2024 (UTC)[reply]
A or C either of them are fine. Ratnahastin (talk) 07:20, 10 May 2024 (UTC)[reply]
A. I share Levivich's concerns about the drawbacks of limiting editors' ability to participate in recall petitions. If editors are using the recall process disruptively, I believe our existing disciplinary procedures should be sufficient to handle them. ModernDayTrilobite (talk • contribs) 14:08, 10 May 2024 (UTC)[reply]
C, but I don't envision that many admins will have to go through a recall each year. SWinxy (talk) 23:11, 10 May 2024 (UTC)[reply]
C Given the strong support for blocking recall petitions against an admin during the six months after one fails, Option B would unnecessarily disenfranchise concerned editors. Levivich has argued that it is better to throttle the number of open recall petitions to five, rather than limiting a user to voting on five open petitions. However, during the initial rollout, we can easily imagine one of the 70K extended-confirmed editors initiating five frivolous petitions, blocking legitimate ones until they close. BluePenguin18 🐧 ( 💬 ) 16:12, 11 May 2024 (UTC)[reply]
A, because this is needless bureaucracy. If someone is supporting any and all recall petitions out of spite, we should sanction them, and you can't legislate away spiteful behavior. Vanamonde93 (talk) 17:57, 12 May 2024 (UTC)[reply]
B and C - C to stop mass desysop nominations and B to stop WP:DEADHORSE. If a recall petition was not successful, then the admin should not be recalled over the same issues unless other concerns arise. MER-C 18:20, 13 May 2024 (UTC)[reply]
B and C to provide somewhat of an inhibitor on frivolous or vexatious requests. Stifle (talk) 09:32, 14 May 2024 (UTC)[reply]
~~A if editors start signing all and every recall disruptively they can be dealt with through the pre-existing processes.~~ -- LCU ActivelyDisinterested «@» °∆t° 22:43, 15 May 2024 (UTC)[reply]

Striking any support for this due to better understanding after my comment at #Discussion (Expired signatures on initiation petitions). Any form of rolling petition is going to require to much bureaucracy to stop the petitions from being endlessly open. -- LCU ActivelyDisinterested «@» °∆t° 09:24, 16 May 2024 (UTC)[reply]

A, weird to suggest anything else? We don't limit e.g. XfD or ArbCom participation, unless/until it becomes disruptive/axe-grinding, at which point we have policies. ~ Amory (u • t • c) 15:40, 17 May 2024 (UTC)[reply]
A > C, oppose B, but with no prejudice against an uninvolved 'crat removing an obviously frivolous or harassing petition (and applying such sanctions to the initiating user as are otherwise appropriate under WP:HARASS and other relevant policies and guidelines). --N Y Kevin 19:22, 17 May 2024 (UTC)[reply]
A is the way to go. It is less bureaucratic and in the unlikely event that more than 5 admins need to be recalled all eligible voters should be able to say their piece. If someone has honestly voted to recall 5 admins, should they be barred from voting for the 6th one? We didn't need arbitrary barriers like this. We must remember WP:AGF - that all voters would vote in good faith - instead of propping up barriers because "someone might do something bad." ✠ SunDawn ✠ (contact) 12:43, 19 May 2024 (UTC)[reply]
Option D (added just now). Don't complicate things for no reason. Fallback option would be A. I oppose B and C as irrational and punitive. (In particular: B is contrary to the entire purpose of this stuff. If an admin is engaging in a long-term pattern of problematic behavior, no one is in a better position to know and explain this than those who have long-term dealings with that admin's misbehavior and who have previously tried to resolve it. Or look at it another way: If you shoot one of my dogs, and I fail to gather enough evidence to prove you did so in court, this does not give you a get-out-of-jail-free card to sneak over and murder all the rest of my pets on the nutty basis that I'm somehow barred from ever taking you to court for such a thing again. C is simply a fantasy, since it's highly unlikely we'll ever have 5 simultaneously open recall petitions, given the barrier to entry we are creating for them, and the only reason for their creation is odd cases when ArbCom doesn't have a bright-line rule to use as the basis for a desysopping; ArbCom is going to remain the primary desysopping mechanism.) — SMcCandlish ☏ ¢ 😼 01:46, 23 May 2024 (UTC)[reply]
Best I can tell, D is effectively identical to A. So far, all proposals in #Initiation procedure involve EC editors signing the recall petition. This section is just asking if there should be any more restrictions on top. I don't think any other proposal in Phase II is currently changing RFA voting. Soni (talk) 02:31, 23 May 2024 (UTC)[reply]
Then you're not trying hard to tell. :-) It is not possible for "use the same limits we have a consensus to impose on RfA, after the exact numbers of those limits are decided" to be the same as "use no limits". — SMcCandlish ☏ ¢ 😼 09:42, 26 May 2024 (UTC)[reply]
D/A, strongly oppose B, oppose C - There's no need for additional restrictions. C is unnecessary: an editor abusing the process is easily identifiable, while an editor may have legitimate reasons for supporting so many recalls. BoldGnome (talk) 04:47, 23 May 2024 (UTC)[reply]
Find a consensus. theleekycauldron (talk • she/her) 08:04, 23 May 2024 (UTC)[reply]
~~Option A~~ - Wikipedia is not a bureaucracy; petitioning for a recall RFA should be as lightweight as having an autoconfirmed account. Editors abusing the process can be topic banned or blocked, just like disruptive editors everywhere else. Ivanvector (^Talk/_Edits) 12:44, 25 May 2024 (UTC)[reply]
Changed to option D - the requirements should be the same as for RFA, which also should be nothing more than "be autoconfirmed" but that's not the question here. Ivanvector (^Talk/_Edits) 16:34, 28 May 2024 (UTC)[reply]
Option C. Otherwise I can picture the process being overrun by gaming, frivolous votes and bandwagon-ism. ("5 currently open recall petitions"?? If we ever see that day, some kind of RFC might be in order, because active petitions for 5 sysops at the same time implies something seriously wrong with adminship as an institution.) SuperMarioMan (Talk) 23:39, 29 May 2024 (UTC)[reply]
A or D, oppose B and C any limits beyond the usual for RfA may needlessly stifle the voices of our community. LEPRICAVARK (talk) 00:45, 1 June 2024 (UTC)[reply]
Option D - but they should also at least be WP:XC. This should generally mirror RFA. Oppose the rest. - jc37 17:09, 2 June 2024 (UTC)[reply]
Full and Strongest Possible Oppose to any Community Initiated Administrator Recall Process - I strongly and fully oppose the adoption of any community-initiated administrator recall process. It is already very hard for anyone to become an admin, and this will just encourage admins to work in less contentious areas, which defeats the whole purpose of being an administrator while also increasing the backlog and workload for other admins. Therefore, this type of system should never be adopted. We already have a working and well-established method through Arbcom for removing undesirable administrators. TheGeneralUser (talk) 09:50, 6 June 2024 (UTC)[reply]
Option D as first choice – Still don't need to make the recall process any more different than RfA already. On the other hand, option C as third choice to keep out or curve anti-admins bandwagoning, but I favor option A as second choice more if there's a consensus for it. George Ho (talk) 21:45, 19 June 2024 (UTC)[reply]

Discussion (Recall Petition Suffrage)

I can think of a few serial opposers who would potentially sign recall petitions en masse. Just as no-one stops them from participating in RfAs, likely no-one is going to be removing them from petitions. I don't think every admin should start off with a baseline of two or three of the same signatories. Sincerely, Dilettante 15:54, 8 May 2024 (UTC)[reply]
I can think of more than 5 current admins who should be recalled. So what? If editors abuse the recall system by initiating too many frivolous recall petitions, they should be dealt with the same way in which we deal with editors who abuse any other editing privilege. But if one editor starts 10 recall petitions and they're all successful, give that editor a barnstar, they've done a great service to the encyclopedia. The idea of limiting how many recalls an editor can support is just... disenfranchisement. We don't limit how many AFDs people can start or how many they can vote for -- though we do TBAN those who abuse this privilege. Should be the same with recalls. Levivich (talk) 17:32, 8 May 2024 (UTC)[reply]
Can you think of more than 5 who realistically have a chance of being recalled? At any given moment, it's rare more than 1 or 2 have the impetus necessary to reach the minimum. Even if it is disenfranchisement, it's still more suffrage than non-arbcom users have now. Sincerely, Dilettante 18:04, 8 May 2024 (UTC)[reply]

I have started a related discussion about this in #Discussion (Striking/Removing signatures). I think that will be a simpler solution for this concern. Soni (talk) 17:40, 8 May 2024 (UTC)[reply]

Also, just for the record, there is no such thing as a "serial opposer." Go ahead and look through recent RFAs: there is not even one person who opposed all or even a majority of them. Maybe that happened someday in the distant past, but it hasn't happened in the last five years (since I've been reading RFAs). "Serial opposer" is a myth. Levivich (talk) 17:52, 8 May 2024 (UTC)[reply]
I view this comment as prima facie evidence of... Suffusion of Yellow (talk) 23:53, 8 May 2024 (UTC)[reply]
So wait this is who can participate in the readminship vote or who can vote to start the readminship vote? In either case, I'd assume extend all the requirements for participation at RfA. I'd figure the thing we'd want to create rules for would be who can initiate the vote -- avoid the same person repeatedly initiating votes about the same person, etc. — Rhododendrites ^talk \\ 17:36, 8 May 2024 (UTC)[reply]
Per the terminology of this page, "vote for RRFA request" means just "I signed for Rhododendrites to go through RRFA (another RFA, pretty much)". A "vote in RRFA" means "I Support/Neutral/Oppose Rhododendrites continuing as admin".

There is no distinction made yet for "vote for RRFA request" and "initiating RFA request". Any editor can be the first vote on an 'RRFA request', and it would not matter for most of #Initiation procedure options as well. Soni (talk) 17:46, 8 May 2024 (UTC)[reply]
I have altered the terms to be clearer. The first is now called "recall petition" and the latter just "RRFA". Soni (talk) 18:04, 8 May 2024 (UTC)[reply]

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

Striking/Removing signatures

Although I am involved here, I believe the consensus for option C is clear enough here for me to proceed. The latter sentence of option A has been shot down by the CUs, while the first sentence is mooted by C passing; B and D were also opposed as giving admins too much discretion and being a drama source. (non-admin closure) Queen of Hearts (talk) 02:04, 25 August 2024 (UTC)[reply]

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

Under what circumstance can a vote on a recall petition be stricken or removed? Support more than one option if needed.

Option A: If a CheckUser confirms an editor as a possible sock. ~~Recall petitions cannot be successfully closed without a CheckUser confirmation~~ (struck by a checkuser - not permissible; see comments below Ivanvector (^Talk/_Edits) 17:10, 28 May 2024 (UTC))[reply]
Option B: If an uninvolved admin determines the editor as disruptive
Option C: The same circumstances as an RFA
Option D: If they are voting frivolously at multiple recall petitions, as determined by an uninvolved admin
Something else (specify...)

Note - This section was titled 'Removing signatures' for a couple hours. It was altered to 'Striking/Removing signatures' (and the question adjusted) per discussion below. "RRFA request" was edited to "recall petition" to easier clarify the petition versus the actual RRFA.

Survey (Striking/Removing signatures)

C Fanfanboy (talk) 15:50, 8 May 2024 (UTC)[reply]
Never, see discussion.—S Marshall T/C 16:37, 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:53, 8 May 2024 (UTC)[reply]
A Obviously sock votes should be struck. Otherwise, I think consensus was that RRfA request votes do not need to be justified, so they can't be struck for content/reasoning. Toadspike (talk) 16:56, 8 May 2024 (UTC)[reply]
Support D, but emphasis on “frivolously”. There must be clear evidence of unserious signing or a “take down all admins” mentality, we can’t strike signatures simply because they signed three petitions in rapid succession. Toadspike (talk) 11:46, 14 May 2024 (UTC)[reply]

Reaffirming support for A after modification – I did previously suspect that forcing a checkuser to check all votes was impermissible fishing, but I wanted to make clear that sockstriking is allowed. And to clarify, obvious sock votes can be struck by an admin who knows what they’re doing without a checkuser getting involved. Toadspike [Talk] 07:21, 29 May 2024 (UTC)[reply]
A and B I made this comment in the discussion, however, I firmly believe that all petitions should require a mandatory CU review of all signatories prior to advancing to reconfirmation, with the CU only being permitted to strike "possible" socks (blocks would still require a full SPI). There are sock farms that control multiple Extended Confirmed accounts and, on EN, the brokerage rates are becoming very high (I personally know of one recent case involving more than $20K in unsuccessful paid editing on a single article). Given that, there is an escalating pecuniary incentive for surreptitious paid editors to attempt to kneecap Admins active in certain areas. This is just a very minimum guardrail and one that wouldn't even be difficult to get around. Updated: I simultaneously oppose every option other than "A" and oppose adoption in the absence of any option. To clarify, my !vote continues in support both of mandatory recall and Option A in this section, while also acknowledging Option A - if it achieved consensus - could not be implemented without a WMF-initiated amendment to the global checkuser policy and waiting for this amendment, which may or may not come or even be technically feasible, would cause a delay of an indeterminate period of time in implementation of the mandatory recall process. Chetsford (talk) 17:11, 8 May 2024 (UTC); edited 17:30, 28 May 2024 (UTC)[reply]
Comment: I think this is in reference to my proposal that Any admin (uninvolved with the user in question and admin the petition is against) may unilateraly topic ban/page block disruptive users from starting or supporting positions. This was meant to import one facet of Contentious topics, without designating all of RRFA as a CT. The idea was that if one person was constatnly opening frivolous requests, or signing in bad faith, they could be blocked from doing so without the trouble of finding consensus at WP:AN. Striking individual signatures wasn't what I was concerned about. So support A only Mach61 17:19, 8 May 2024 (UTC)[reply]
C, which I just added. RRFA should run the same as RFA. Right now we're talking about RFA moderation; whatever the outcome of that, it should apply equally to RRFA. RFA = RRFA, is my view. Levivich (talk) 17:36, 8 May 2024 (UTC)[reply]
@Levivich This is about the petition to start the RRFA, not the RRFA itself Mach61 18:08, 8 May 2024 (UTC)[reply]
Yes, Soni set me straight on that :-) I think the recall petition (RRFA request) should be governed by the same rules as RFA, when it comes to moderation (e.g. striking/removing votes). Levivich (talk) 18:25, 8 May 2024 (UTC)[reply]
Neither B nor D. Too discretionary. ~ ToBeFree (talk) 18:42, 8 May 2024 (UTC)[reply]
Prefer A, not opposed to B, C or D.-Gadfium (talk) 23:37, 8 May 2024 (UTC)[reply]
C per Levivich. Queen of Hearts (talk) 01:56, 9 May 2024 (UTC)[reply]
Find Consensus. My individual preferences are A, D > C > B. My central !vote is for 'Find a consensus' so I broadly support every Option here if it results in consensus. I specifically added D based on below discussion because I would like admins to have leeway when dealing with individual editors, as an alternative to hard limits like Option C of #Recall Petition Suffrage. If someone is voting recall on every admin, the community should have some tools to handle that, I just prefer this tool slightly more. Soni (talk) 05:24, 9 May 2024 (UTC)[reply]
A. It would need buy-in from the checkuser team, otherwise the second sentence should be struck. Oppose B and D for giving the appearance of WP:CABAL. --Ahecht (TALK
PAGE) 15:35, 9 May 2024 (UTC)[reply]
C is fine for now; if signatures are being removed inappropriately, we can rethink at that time. Extraordinary Writ (talk) 19:46, 9 May 2024 (UTC)[reply]
A, C, and D. I think all three of these are potentially valid reasons. --Tryptofish (talk) 21:38, 9 May 2024 (UTC)[reply]
Furthermore, any signature re-added to a rolling petition should automatically be struck. --Tryptofish (talk) 21:46, 24 May 2024 (UTC)[reply]
C per Levivich. – Teratix ₵ 02:54, 10 May 2024 (UTC)[reply]
A if confirmed to be a sock, as filing the recall petition would in violation of their original block. Ratnahastin (talk) 07:23, 10 May 2024 (UTC)[reply]
C to make it closer to RfA. SWinxy (talk) 23:11, 10 May 2024 (UTC)[reply]
C per above. Checkuser doesn't work all that well for sophisticated abusers and UPE spamming should always be a disqualifying factor. MER-C 14:47, 11 May 2024 (UTC)[reply]
C RfA-associated processes should seek similar procedures to minimize WP:CREEP. BluePenguin18 🐧 ( 💬 ) 23:15, 11 May 2024 (UTC)[reply]
C is flexible and allows for unspecified kinds of disruption beyond sockpuppetry or frivolous votes. — Bilorv (talk) 08:22, 12 May 2024 (UTC)[reply]
C, which I understand as "when someone is found to be violating WP:SOCK or the TOUs when they cast their !vote." B & D are likely to cause drama, and I believe A is a violation of CU policy as written; see comments below. Vanamonde93 (talk) 17:57, 12 May 2024 (UTC)[reply]
C per Levivich. Frostly (talk) 05:47, 13 May 2024 (UTC)[reply]
C, but find a consensus. theleekycauldron (talk • she/her) 23:41, 14 May 2024 (UTC)[reply]
C per Levivich, and to keep it simple. -- LCU ActivelyDisinterested «@» °∆t° 22:46, 15 May 2024 (UTC)[reply]
C per Levivich. Draken Bowser (talk) 22:01, 16 May 2024 (UTC)[reply]
C per above. D can't even pass.... Toadette^Edit! 00:26, 17 May 2024 (UTC)[reply]
C ~ Amory (u • t • c) 15:41, 17 May 2024 (UTC)[reply]
C is the only correct way to go. Option B and D would create so many dramas that we didn't need. ✠ SunDawn ✠ (contact) 12:44, 19 May 2024 (UTC)[reply]
C (which includes A already). Keep it simple; do not "bureaucracy-fork" things for no good reason. There is basically no good reason for any of this RRFA stuff work any any differently at all from RfA in the first place (to the extent the processes are analogous, which is mostly, other than the barrier to entry for creating a recall). — SMcCandlish ☏ ¢ 😼 01:49, 23 May 2024 (UTC)[reply]
C. Anything further is unnecessary. BoldGnome (talk) 04:50, 23 May 2024 (UTC)[reply]
None of the above - sock votes can already be struck (see for example {{sockstrike}}) without a checkuser confirmation, and requiring checkuser to close a petition is a fishing expedition which violates both the local and global checkuser policies. Ivanvector (^Talk/_Edits) 12:51, 25 May 2024 (UTC)[reply]
C because A is never going to happen (it violates the CheckUser policy, as numerous people have pointed out), B will obviously be an endless source of drama, and while D superficially looks reasonable, there will always be people signing things without giving a rationale (or a terse reason like "per everyone else"), and there will always be admins who want to label those signatures as "frivolous," so D will only produce slightly fewer pointless arguments than B. --N Y Kevin 04:59, 26 May 2024 (UTC)[reply]
C because the rules should apply evenly over the petition/request, the RRFA, and an RFA. Dreamy Jazz ^{talk to me | my contributions} 15:22, 2 June 2024 (UTC)[reply]
Only at Bureaucrat, Checkuser, or Oversighter, discretion in the course of performing their duties. - jc37 17:13, 2 June 2024 (UTC)[reply]
Full and Strongest Possible Oppose to any Community Initiated Administrator Recall Process - I strongly and fully oppose the adoption of any community-initiated administrator recall process. It is already very hard for anyone to become an admin, and this will just encourage admins to work in less contentious areas, which defeats the whole purpose of being an administrator while also increasing the backlog and workload for other admins. Therefore, this type of system should never be adopted. We already have a working and well-established method through Arbcom for removing undesirable administrators. TheGeneralUser (talk) 10:43, 6 June 2024 (UTC)[reply]
Supported the modified A, and D. Votes by sockpuppets should not be allowed to stand. If there has been cause outside this process for a signatory to be CheckUser'd, and the conclusion is sockpuppetry, then their petition contributions should be struck. Option D is necessary as a safeguard against abuse of the process. SuperMarioMan (Talk) 00:36, 10 June 2024 (UTC)[reply]
Option C – Should making strikethrough easier for admins maganing RFAs regularly. No need to make the recall process distinct further. George Ho (talk) 21:49, 19 June 2024 (UTC)[reply]

Discussion (Striking/Removing signatures)

Should never be removed under any circumstances, but may be struck if it turns out the contributor was mistaken or not in good faith.—S Marshall T/C 16:36, 8 May 2024 (UTC)[reply]

I see striking and removing to be effectively identical for RRFAs. If that distinction matters for others, we can broaden the scope to include both. I wanted to ask "When are votes not counted" more than "Should votes be specifically removed". Pinging @S Marshall: Soni (talk) 16:52, 8 May 2024 (UTC)[reply]

As a counterpart to discussion in #RRFA Suffrage, I'd like to add an alternative Option C, probably something like "If an uninvolved admin determines the editor as voting frivolously on RRFA requests". Instead of limiting all editors, I would prefer to give more leeway to admins on removing votes. If someone is voting for a bunch of admins on RRFA requests, this would be a simpler way to handle it. I'll wait for a bit before adding the Option, just in case others have suggestions Soni (talk) 17:37, 8 May 2024 (UTC)[reply]
Added this as Option D. Soni (talk) 05:24, 9 May 2024 (UTC)[reply]
Has anyone consulted with the Checkusers as to whether "A" is actually feasible? I know other similar proposals have been rejected in the past due to WP:NOTFISHING (which, as I understand it, is based both in policy and technical limitations of the tools). --Ahecht (TALK
PAGE) 13:49, 10 May 2024 (UTC)[reply]
I've added a note on WT:CheckUser. Not sure if there's another location watchlisted by active Checkusers. Soni (talk) 17:15, 11 May 2024 (UTC)[reply]
Checkuser here (you asked for an opinion and this is mine). I don't see any reason to deviate from our normal site-wide sock-striking practices. The clearest expression is probably the essay at WP:SOCKSTRIKE, which is rooted in the policy at WP:EVADE. These procedures are both longstanding and well agreed. If a vote is from a sock of a blocked user then you block the sock and the vote can be struck or removed (IMO probably just struck with an explanation, but there are times it's best to remove entirely). No sockblock no strike, adds stakes to the equation. Normal blocking admins are usually quite capable of doing that, and normal editors are usually good at identifying and bringing to attention suspicious accounts. However if additional certainty is required for a particular account or two, then sure a checkuser can be consulted as normal. The NOTFISHING problem potentially arises in the second part of the proposal and some of the comments: Recall petitions cannot be successfully closed without a CheckUser confirmation. Checkusers are not going to check every account (or even a significant proportion) in a recall proposal - that would be fishing, as well as probably also ineffective. If you want a checkuser to just sign off on a recall motion, then that's not going to provide the guarantee it implies, nor add much to what's already out there, IMO. Considering these two aspects it seems to me to be unnecessary to mention checkusers at all here, and there should be reference to standard sock-striking procedures (I guess that's option C). -- zzuuzz ^(talk) 18:53, 11 May 2024 (UTC)[reply]
I began writing this before seeing zzuuzz's comment above, so I'll just not my agreement briefly. My reading of A as written is that it asks CUs to sign off on every account signing a petition, and that would require checking each of them, which is not permitted by policy. And, of course, it is no guarantee of anything. Vanamonde93 (talk) 17:57, 12 May 2024 (UTC)[reply]
Per the few comments directly above this, I've struck the portion of option A that is absolutely not going to happen. Even if we could manage a strong consensus here in favour of blanket-checking every account that edits a petition, the global checkuser policy is a legal policy written with considerations for privacy laws around the world, and it's extremely unlikely the WMF would modify it to permit this collection of private data for what amounts to a "good vibes" check. It's simply not worth discussing the idea any further here. @Fanfanboy, Toadspike, Chetsford, Gadfium, Tryptofish, and Ratnahastin: you all expressed support for option A before zzuuzz's comment above and the subsequent comments by other checkusers; courtesy ping in case you'd like to amend your comments. Ivanvector (^Talk/_Edits) 17:10, 28 May 2024 (UTC)[reply]

Makes sense to me. Thanks for the ping. Chetsford (talk) 17:17, 28 May 2024 (UTC)[reply]
Thanks for the ping. I'm going to leave my comment as is, with the following thinking. I do understand, per subsequent comments, that we already have "sockstrike" without the need for a checkuser run, but my lingering support, in part, for A indicates that I still agree that it's a valid reason to strike. --Tryptofish (talk) 18:42, 28 May 2024 (UTC)[reply]

Per Tryptofish, I'm also maintaining my !vote for A, while also acknowledging that implementation will require an amendment to the global checkuser policy and have amended my rationale above. Due to the significant pecuniary interests involved in paid editing (I was recently made aware of one case in which an individual paid an Outside U.S. entity that controls multiple accounts more than $25,000 to make a handful of edits on a relatively obscure article - in this case the paid edits weren't even "successful") I feel adoption of the entire proposal without such a WMF-initiated amendment to the checkuser policy steers this ship into extremely dangerous waters without introduction of exceptional, albeit admittedly imperfect, security measures. But I do think it's important, as Ivanvector has done, to clarify to editors that A is technically infeasible through this process and !votes for it may bog down the entire effort due to external factors we don't control. Chetsford (talk) 01:51, 29 May 2024 (UTC)[reply]

This is probably a discussion to have elsewhere, but checkuser is not really all that useful in rooting out paid editing. For one thing it's designed to detect particular common patterns of sockpuppetry, and the sort of paid editing you describe often takes a different form. The "preventing disruption versus protecting user privacy" scale I mentioned earlier tends to weigh heavily on the privacy side, and related to that, our policies direct that checkuser is only to be used where there is reasonable suspicion that it will reveal something useful to an investigation. If abusive behaviour can be detected without the use of checkuser then its use is contraindicated; this tends to be the case for paid editing where detection is often based on off-wiki interactions where checkuser can't reveal anything. I recall around the time I joined the functionary team we were given the instruction that "suspicion of paid editing" is not sufficient grounds to check: the suspicion needs to come with a reasonable expectation that checkuser will reveal something, otherwise we're fishing, and then we come into those interactions with privacy legislation that are way over my pay grade. But overall I agree that a conversation about what tools we have and/or need to develop to combat this highly organized paid editing is a conversation that should happen, but it's well out of scope for this process. Ivanvector (^Talk/_Edits) 13:22, 30 May 2024 (UTC)[reply]

I wholeheartedly agree that checkuser is a tool not fit for purpose if the objective here is to actually detect paid editing in recall petitions. However, I still believe it provides an imperfect - but only available - psychological deterrent not unlike a security guard; the security guard has no actual power or ability to intervene but the mere presence of a uniformed person has a moderately suppressive impact on criminal activity. The cultivation of sock farms is a labor-intensive activity so when there is even the perception of discovery related to uncompensated activities it may deter or limit sock involvement. The actual ability of checkuser to do so is not a consideration I'm taking into account in my !vote.

"our policies direct that checkuser" Another good reminder. Still, as per my amended !vote, I acknowledge that implementation (versus adoption) of A will require global policy amendment. For that reason, I maintain my "A" !vote for adoption, while recognizing that implementation is currently infeasible without the introduction of additional steps involving stakeholders not currently engaged here. Chetsford (talk) 13:34, 30 May 2024 (UTC)[reply]

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

Desysop after Recall petition

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

There is consensus for options A and E. Option B received significant opposition; 10 days was thought to be too short. There was a consensus against option C and option D. The argument that a recall petition does not equate to a complete loss of faith in the community was stronger than the argument of a need to protect from abuse. Editors also pointed out that if an admin engaged in any of the conduct described in option D, they would have their tools removed quickly and likely be swiftly blocked. Option A received overwhelming support. Option E also received significant numerical support. The opposition to option E was that it might not give administrators time to prepare; other editors pointed out that "immediately" comes with the common-sense caveat that the 'crats will ensure that the admin has been given an opportunity to request a delay. This close is without prejudice to further refining option E. (non-admin closure) voorts (talk/contributions) 04:41, 14 September 2024 (UTC)[reply]

After a successful Recall petition, when should an admin be desysopped?

Option A: If an admin does not start an RRFA within 30 days of a successful Recall petition, within a bureaucrat's discretion (same as proposal 16C)
Option B: If an admin does not start an RRFA within 10 days of a successful Recall petition
Option C: If an admin does not start an RRFA within 30 days of a successful Recall petition, although the admin should not use the tools during those 30 days.*
Option D: If an admin does not start an RRFA within 30 days of a successful Recall petition, although the admin should not use the tools during those 30 days in a manner that could be seen as prejudicial to the ultimate outcome of the RRFA (by, for instance, blocking petitioners).
Option E: (In addition to another option) A bureaucrat should open an RRFA immediately after a successful Recall petition by default, but the admin may instead request a delay of no more than whatever the other option specifies (e.g. if Options A and E pass, then the maximum delay is 30 days, subject to 'crat discretion).
Something else (specify...)

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

Survey (Desysop after Recall petition)

A > C Fanfanboy (talk) 16:06, 8 May 2024 (UTC)[reply]
A.—S Marshall T/C 16:38, 8 May 2024 (UTC)[reply]
...and Oppose C, which is a well intentioned but poorly thought out proposal. We don't want some sockfarm using the process to knock out an inconvenient sysop in the run up to an election/stock market floatation/whatever. Remember that a sysop is still a duly elected sysop until we reach consensus otherwise, and we should expect a lot of recall petitions to fail.—S Marshall T/C 22:07, 9 May 2024 (UTC)[reply]
A I think the admin should have some time to prepare and allow tempers too cool. Candidates can choose to RfA whenever they want and are expected to pick a time when they'll be available throughout the process. RRfA should give some of that courtesy where possible. Toadspike (talk) 16:57, 8 May 2024 (UTC)[reply]
Oppose C, paralyzing admins is a bad idea. Support D (common sense), although such behavior is highly inappropriate and probably already covered under other policies. Toadspike (talk) 11:48, 14 May 2024 (UTC)[reply]
A, the admin will know any conduct they have before starting the RRFA will be intensely scrutinized. Mach61 17:09, 8 May 2024 (UTC)[reply]
A per Toadspike's rationale. Also D, which I just added. Chetsford (talk) 17:13, 8 May 2024 (UTC); edited 23:57, 8 May 2024 (UTC)[reply]
C, which I've just added. 30 days is the right time frame, to give the admin plenty of time to think about it, consult with others if they want to, prepare for an RFA, and launch the RFA at a convenient time within a reasonable time frame--10 days is not enough for that. I disagree with "within a bureaucrat's discretion" of option A, because I don't know what that means. I added a prohibition against tool use during the 30 days. Recently, an admin was desysoped by arbcom, and between the time that it was obvious that the admin was going to get desysoped, and when the case closed and the desysop happened, the admin used their tools to their benefit; I felt this was improper and should not be allowed. Levivich (talk) 17:40, 8 May 2024 (UTC)[reply]
If not C, then D > A > B > E. Levivich (talk) 02:33, 31 May 2024 (UTC)[reply]
A. Give crats leeway for actual unusual circumstances (fishy votes in the petition, candidate unavailable due to IRL issues, waiting on an arbcom case to resolve). Conduct with the tools during these 30 days will be sufficiently scrutinized by the community. Tazerdadog (talk) 18:38, 8 May 2024 (UTC)[reply]
C is a good idea: The recall petition was successful and the adminship is in peril. It should not be used during the RRFA. I'm fine with any other option too, though. ~ ToBeFree (talk) 18:44, 8 May 2024 (UTC)[reply]
I don't think the limitation added in D is necessary; the provided example "blocking petitioners" is an absurd scenario that's pretty much already forbidden by WP:INVOLVED and would quickly lead to numerous oppose votes in the RRFA. A better example would be "assigning oneself permissions that would otherwise be gone with a desysop". ~ ToBeFree (talk) 11:38, 9 May 2024 (UTC)[reply]
Support C and D, weaker support for A. Bureaucrat discretion should always be possible, e.g. if a recalled admin is restricted from editing by personal circumstances during the period.-Gadfium (talk) 23:41, 8 May 2024 (UTC)[reply]
C or A. D is too arbitrary, B is too small a window. Queen of Hearts (talk) 01:59, 9 May 2024 (UTC)[reply]
C, I guess (followed by A). I've never been fond of the (presumably unenforceable?) "gentlemen's agreement" not to use the tools, which ArbCom has shied away from in recent years. But an interim desysop might prejudice the re-RfA, and I prefer to err on the side of caution at this point (as explained above). The problem with A is that it creates warped incentives to wait out the 30-day period. Extraordinary Writ (talk) 19:52, 9 May 2024 (UTC)[reply]
D. There should be more than 10 days to act, as 10 days is an awful lot of pressure. As for tools, saying they cannot use the tools at all is like saying they are guilty until proven innocent. --Tryptofish (talk) 21:41, 9 May 2024 (UTC)[reply]
Temporarily withholding the use tools doesn’t always mean that the user is guilty. A police officer that has done something questionable will usually be sent into a paid leave or a desk job where their powers will be curtailed - but that didn’t mean that the officer has been sentenced. ✠ SunDawn ✠ (contact) 06:23, 23 May 2024 (UTC)[reply]
In the interests of speedy resolution, RRfAs should, by default, begin immediately after a successful clean recall petition, but the administrator under scrutiny should have discretion to ask bureaucrats for a different timing if there are real-life issues or they need time to reflect or de-stress. – Teratix ₵ 03:05, 10 May 2024 (UTC)[reply]
- This is a good idea. — Frostly (talk) 05:49, 13 May 2024 (UTC)[reply]
B , reconfirmation rfA should begin ASAP after a successful recall petition. Ratnahastin (talk) 07:04, 10 May 2024 (UTC)[reply]
Agree with Teratix's suggestion - no need for arbitrary waiting periods. * Pppery * _{it has begun...} 22:45, 10 May 2024 (UTC)[reply]
My big concern with that is that you need to guarantee the admin in question can actually spend a full week running through an RRFA process if a petition passes. If a RRFA begins immediately after successful recall petitions with no controls, admins may be forced to go through a potentially strenuous process without the time and energy. Soni (talk) 09:31, 11 May 2024 (UTC)[reply]
Honestly I think Teratix is correct, as once the threshold has been reached, it should automatically commence the full process. SWinxy (talk) 23:11, 10 May 2024 (UTC)[reply]
C Agree with Teratix that RRfAs should begin immediately after a successful recall petition, but the same busyness that could justify asking bureaucrats for up to 30 days of delay could justify being unable to ask for that extension, so we can treat the account sitting idle (tools-wise) as proof of the need for delay. BluePenguin18 🐧 ( 💬 ) 23:29, 11 May 2024 (UTC)[reply]
A as first choice, giving reasonable leeway for the subject to fit what will work best given their availability. In regards to C, I'm not sure we want to be in the business of monitoring whether a person is using the tools (who would even be able to tell whether they'd used some rights such as viewing deleted pages?). If C passes then instead we should remove the tools (temporarily) until/unless the re-RfA passes. — Bilorv (talk) 08:27, 12 May 2024 (UTC)[reply]
A. I don't like the crat discretion, but I dislike the timeframe of B and the tool-use prohibitions of C & D even more. 10 days is far too short; 30 days is still on the short side (I've stepped away for months at a time for RL reasons, and I expect that that will continue). And I don't like that we're making the recall petition, rather than the RRFA, the determinant of whether someone can use the tools. Admin actions between a successful petition and an RRFA are going to be under a lot of scrutiny; I can't see how any inappropriate tool use would not violate our existing policies. Vanamonde93 (talk) 17:57, 12 May 2024 (UTC)[reply]
A if any. Stifle (talk) 08:19, 14 May 2024 (UTC)[reply]
A. -- LCU ActivelyDisinterested «@» °∆t° 22:49, 15 May 2024 (UTC)[reply]
In my thoughts, B would feel more imminent than the rest of the option so it couldn't pass, as for C and D, D is a stripped version of C, and I am opposing C as in cases of an emergency, for instance, a person who creates many inappropriate pages in a bot-like manner, the admin who would see that first wouldn't be able to use their tools and rather 1) report it or 2) wait. I will select A as the most preferred option. Toadette^Edit! 00:34, 17 May 2024 (UTC)[reply]
A, folks got lives. ~ Amory (u • t • c) 15:43, 17 May 2024 (UTC)[reply]
A and E, the latter of which I have just added based on my understanding of Teratix's proposal. --N Y Kevin 06:02, 18 May 2024 (UTC)[reply]
E. There is absolutely no reason for someone who has failed to retain the trust of the community to continue to retain the admin bit. And it's just a bit; if they successfully re-RfA, the bit can be added back easily. Other options in order of more to less acceptability: C > D > B > A. — SMcCandlish ☏ ¢ 😼 01:51, 23 May 2024 (UTC)[reply]
E and C - Reading "immediately" as "as soon as possible", noting that people have lives outside of Wikipedia. Essentially the expectation should be that they're not active on the project while ignoring the results of the successful recall petition. C provides the necessary accommodations for any needed delays as well as the necessary protective measure of 'not using the tools that are pending a review to be initiated by themselves'. BoldGnome (talk) 04:58, 23 May 2024 (UTC)[reply]
I used the word "immediately" to mean "at the same time as the bureaucrat closes the petition as successful, or shortly thereafter." My assumption was that the 'crats would be the ones closing the petitions in the first place, and that petitions would normally run to their full length even if they've already got all signatures needed, but if either of those is not the case, then there might well be a short delay (either to contact a bureaucrat, or to make sure the admin has actually seen the petition and gotten an opportunity to request a delay). I think the 'crats are smart enough to figure out minor details like this, so I'm not overly concerned about exactly how they end up implementing "immediately" in practice, so long as it doesn't end up meaning "it will sit in the queue for days on end until somebody gets around to it." --N Y Kevin 03:58, 24 May 2024 (UTC)[reply]
A and D The problem with E is that it presumes that the administrator has acknowledged the petition and is already working with a bureaucrat on timing for the recall. We want a process where the administrator is able to participate completely in the process, and starting the process immediately after a successful petition does not necessarily allow for that to occur (as "immediately" can not be read as "as soon as possible"). As for use of the tools. while I would hope that administrators are judicious in the use of the tools if they are in a recall process, and any interim use of the tools will likely be questioned, but they are still trusted members of the community (until they are successfully recalled). --Enos733 (talk) 17:08, 27 May 2024 (UTC)[reply]
Oppose C per S Marshall and others: we cannot provide opportunities for effective admins to be ousted by organized brigades. Regarding admins performing actions that would bias their recall or retaliating against petitioners, either WP:LEVEL1 or WP:LEVEL2 already covers that depending on the exact situation, and we shouldn't add conditions here that could conflict with those established processes. Ivanvector (^Talk/_Edits) 13:44, 30 May 2024 (UTC)[reply]
A and E. Oppose all other options. We should give time for admins to fit the RRFA around their schedule, but unless the admin wants this delay it makes sense for the RRFA to start soon after to avoid unnecessarily delay. Furthermore, I would argue that unless the RRFA is definitely started then the community in a wider sense does not get to voice their opinions, especially if the petition only allowed editors to express a wish for a RRFA. Therefore, an admin may pass RRFA even if the petition looked initially bad because those wishing to support were not able to lodge their opposition to de-admin'ing the admin. Dreamy Jazz ^{talk to me | my contributions} 15:28, 2 June 2024 (UTC)[reply]
Option E immediately (well, within 10 days, to give the crats a chance to get it done) - or within 30 days, whichever comes first. - jc37 17:19, 2 June 2024 (UTC)[reply]
Option E, with 30 days' grace (Option A). I agree that the RRFA page should be started by Bureaucrats. Oppose Option B as being much too short. Endorse Option D, as that ought to go without saying. Oppose Option C – an administrator should be permitted to act as one until they've actually failed a RRFA. SuperMarioMan (Talk) 00:35, 3 June 2024 (UTC)[reply]
Full and Strongest Possible Oppose to any Community Initiated Administrator Recall Process - I strongly and fully oppose the adoption of any community-initiated administrator recall process. It is already very hard for anyone to become an admin, and this will just encourage admins to work in less contentious areas, which defeats the whole purpose of being an administrator while also increasing the backlog and workload for other admins. Therefore, this type of system should never be adopted. We already have a working and well-established method through Arbcom for removing undesirable administrators. TheGeneralUser (talk) 10:17, 6 June 2024 (UTC)[reply]

Discussion (Desysop after Recall petition)

There should be a rule stated here that the clock pauses while the admin being recalled is under scrutiny in an active case or case request at arbcom. Arbcom should be allowed to go first to give the community the maximum amount of information. Tazerdadog (talk) 16:56, 8 May 2024 (UTC)[reply]

Agreed. If I am not mistaken, this is generally how community processes work – when ArbCom steps in, we step back. Toadspike (talk) 16:58, 8 May 2024 (UTC)[reply]

I added an Option D. Option C seems ripe for abuse by a well-organized minority. Chetsford (talk) 23:57, 8 May 2024 (UTC)[reply]

Option D seems just paranoid and should be removed. Any admin who runs around blocking their "foes" willy-nilly would be speedy-banned (as well as desysop'd, of course) by any other admin with a pulse, or a steward worst comes to worst. That's already the case today, we don't need a new rule about it. SnowFire (talk) 02:26, 11 May 2024 (UTC)[reply]

Seeing multiple editors agree with Teratix's suggestion, it should probably be added as an option explicitly to help gauge the consensus. My suggested wording was something like *Option E: (In addition to another option) RRFAs should be started as soon as possible after a successful recall petition. I still think it should include some explicit leeway for editors who are around but cannot go through RRFA right away. But someone who supports the Option is better off phrasing it as they best can Soni (talk) 03:27, 12 May 2024 (UTC)[reply]

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

Recall petition discussion

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

There is consensus for option E per the reasoning that discussion is how we determine consensus. Options B and C gained limited support and significant opposition. No strong reason was presented for having discussion occur on a separate talk page, and Option A+D received about half the support of option E. (non-admin closure) voorts (talk/contributions) 04:51, 14 September 2024 (UTC)[reply]

Should votes in a Recall petition be limited to signatures? Can they have discussion?

Option A: Reasoning can be added, but no further discussion
Option B: Only signatures can be added. No reasoning or discussion
Option C: Signatures and one link can be added. No reasoning or discussion
Option D: (In addition to another Option) General discussion section separately on talk page
Option E: Reasoning and discussion allowed
Something else (specify...)

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

Survey (Recall petition discussion)

A, ~~but I would also like a 'General discussion' section separate from voting.~~ Support D for a trial run. Fanfanboy (talk) 15:53, 8 May 2024 (UTC)[reply]
C > B > A, Neutral D, Oppose E. The recall proposal as written is intended to reduce the amount of drama and stress that happens in the name of discussion. Having a discussion section separately will only encourage more back-and-forth bickering. General discussion should either not happen, or be limited to user talk and AN/ANI, if needed. Soni (talk) 16:16, 8 May 2024 (UTC)[reply]
A and D. Preventing discussion reduces the quality of our decisions.—S Marshall T/C 16:39, 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:56, 8 May 2024 (UTC)[reply]
A and D, though I might support a word count cap on comments and a ban on replies, so that the request pages don't get bloated. There has to be a place for discussion, because pushing it to User Talk will not relieve stress on the admins. Toadspike (talk) 17:01, 8 May 2024 (UTC)[reply]
A and D. If we allow replies on petitions, people will mistakenly apply the expectation that RfA opposers must explain their !vote, which doesn't make sense for a petition. Mach61 17:20, 8 May 2024 (UTC)*[reply]
B Chetsford (talk) 17:14, 8 May 2024 (UTC)[reply]
E (which I added) I don't see the need to do it differently than we do at any other discussion, e.g. RFA, RFC, AFD, etc. etc. Levivich (talk) 17:56, 8 May 2024 (UTC)[reply]
E first choice. Support D in addition to other options. If not E, then A > C > B. Levivich (talk) 03:19, 12 May 2024 (UTC)[reply]
C>B>A>E. D is okay together with the others. Any is fine. ~ ToBeFree (talk) 18:48, 8 May 2024 (UTC)[reply]
A and D. Not opposed to E, but I think allowing/encouraging a reason is important, so oppose B and C.-Gadfium (talk) 23:45, 8 May 2024 (UTC)[reply]
E Queen of Hearts (talk) 02:01, 9 May 2024 (UTC)[reply]
E, followed by A+D. Just like at RfA, letting someone's spurious claims be (visually at least) unrebuttable isn't a good idea. Extraordinary Writ (talk) 19:55, 9 May 2024 (UTC)[reply]
E. Because discussion is how we find consensus. --Tryptofish (talk) 21:42, 9 May 2024 (UTC)[reply]
Find a consensus per Tazerdadog :) theleekycauldron (talk • she/her) 22:04, 9 May 2024 (UTC)[reply]
B and D The actual petition votes should be signatures only, but there should be a section or talk page for general discussion. – Teratix ₵ 03:08, 10 May 2024 (UTC)[reply]
A , to avoid drama that can be caused by the gravity of the recall process. Ratnahastin (talk) 07:08, 10 May 2024 (UTC)[reply]
E preferred, A and D also acceptable. Oppose B and C. In my opinion, it's important for petitioners to be able to provide a rationale; admins should be able to know what the complaints against them are, and being able to view the rationales would also help uninvolved editors discern whether a currently open petition has merit or not. Encouraging rationales also disincentivizes random drive-by recall votes, which would be likely to be unhelpful or demoralizing. ModernDayTrilobite (talk • contribs) 14:18, 10 May 2024 (UTC)[reply]
E, or whichever is closest to RfA. SWinxy (talk) 23:11, 10 May 2024 (UTC)[reply]
E as first choice. Consensus on Wikipedia is found through discussion. — Bilorv (talk) 08:28, 12 May 2024 (UTC)[reply]
E While reasoning and discussion may create conflict as admins justify their behavior, greater communication may resolve some disputes and avoid proceeding to a RRfA. BluePenguin18 🐧 ( 💬 ) 16:18, 12 May 2024 (UTC)[reply]
Oppose B & C; if people are acting in bad faith (and I include the admin under scrutiny, and their potential supporters, in this) we should be able to say so. Vanamonde93 (talk) 17:57, 12 May 2024 (UTC)[reply]
E. Recall petitions should have similar procedures as RfAs. Frostly (talk) 05:50, 13 May 2024 (UTC)[reply]
Strong support E, but really find a consensus. House Blaster (talk · he/him) 02:25, 14 May 2024 (UTC)[reply]
A but oppose E, recalls are likely going to be contentious and discussion can be had at RRFA if needed. -- LCU ActivelyDisinterested «@» °∆t° 22:54, 15 May 2024 (UTC)[reply]
This type of vetting should be built on consensus and not votes. Only adding signatures, or signature with a single link, won't really help with that. Judging A, it may lead to discussions taken elsewhere (expect on user talk pages) so the option won't go that well. I will accept both D and E, and if it fails, it should be A. Toadette^Edit! 00:41, 17 May 2024 (UTC)[reply]
This type of vetting should be built on consensus and not votes. Per #Initiation procedure, most proposals we have are are using votes. There may be a case for an initiation procedure of something like "if consensus is found after a recall petition discussion", but nobody suggested it yet. Soni (talk) 00:48, 17 May 2024 (UTC)[reply]
E. This is a community process, not ArbCom (kinda the whole point), and this is a community in which discussion and rationales matter; we are not [except for extremely limited functions, like ArbCom elections] operated on a bare-vote basis. — SMcCandlish ☏ ¢ 😼 01:55, 23 May 2024 (UTC)[reply]
E > A, strongly oppose B and C - this is a community discussion. BoldGnome (talk) 05:02, 23 May 2024 (UTC)[reply]
Option Zero - same rules as RFA, whatever they are at the time. Since changing the commenting rules at RFA is a common thread in reform discussions, it's sensible to simply state that a petitioned recall RFA should have the same rules. Ivanvector (^Talk/_Edits) 12:54, 25 May 2024 (UTC)[reply]
Option F: reasoning required with signature; other discussion encouraged. If a user is questioning an administrator's competence to the point of wanting them to go through RFA again, it needs to be clear why. Bare signatures don't tell the reconfirmation candidate where they're going wrong. SuperMarioMan (Talk) 00:00, 30 May 2024 (UTC)[reply]
Absolutely. This should 'not devolve into an WP:ILIKEIT/IDONTLIKEIT situation. Our goal is always to "prevent not punish", per all the rest of our WP:DE policies and guidelines (like WP:BLOCK, etc.). - jc37 17:47, 2 June 2024 (UTC)[reply]

Oppose B and C on the same grounds. Reasoning and discussion are to be encouraged, if not required. SuperMarioMan (Talk) 20:35, 10 July 2024 (UTC)[reply]
Option E - If anything deserves a consensual discussion, surely this does. Plus, we should never disallow evidential links for such discussions. - jc37 17:22, 2 June 2024 (UTC)[reply]
Full and Strongest Possible Oppose to any Community Initiated Administrator Recall Process - I strongly and fully oppose the adoption of any community-initiated administrator recall process. It is already very hard for anyone to become an admin, and this will just encourage admins to work in less contentious areas, which defeats the whole purpose of being an administrator while also increasing the backlog and workload for other admins. Therefore, this type of system should never be adopted. We already have a working and well-established method through Arbcom for removing undesirable administrators. TheGeneralUser (talk) 10:21, 6 June 2024 (UTC)[reply]
Option E – No need to restrict rationale and discussion at all if petition process is approved. I appreciate Ivanvector's alternative, but as noted, this section involves a petition procedure before starting the RRFA, not the whole RRFA itself, which I think shouldn't be any different from normal RFA honestly. George Ho (talk) 22:55, 19 June 2024 (UTC)[reply]

Discussion (Recall petition discussion)

@Fanfanboy: I have explicitly added an Option D. As written, just all of A-B-C were intended to skip having a "general discussion" section. Soni (talk) 16:16, 8 May 2024 (UTC)[reply]
@Levivich: To be clear, a "RRFA request" is the same as saying "I want them to stand for recall" not the actual RFA like process (Which is just RRFA). If this is too confusing, we can replace all instances of "RRFA request" with "RRFA request petition" to make it clearer in the sections. Soni (talk) 17:51, 8 May 2024 (UTC)[reply]
@Soni: Thank you for clarifying, that did confuse me! Maybe we can call it the "recall petition" and the "RRFA"? Levivich (talk) 17:54, 8 May 2024 (UTC)[reply]
Done. Soni (talk) 18:03, 8 May 2024 (UTC)[reply]
@Soni: Thank you! And also thank you for your ongoing efforts shepherding this process! Levivich (talk) 18:24, 8 May 2024 (UTC)[reply]

Thanks for the change. I felt that "Re-request for adminship request" was a confusing phrase, and could be interpreted as the admin in question starting their re-request for adminiship. isaacl (talk) 18:39, 8 May 2024 (UTC)[reply]
@Levivich: I don't see the need to do it differently than we do at any other discussion, e.g. RFA, RFC, AFD, etc. etc. So my reasoning for doing it differently here was because general discussion risks litigating the same matter multiple times at different locations. An admin going through recall may have to potentially respond to AN/ANI threads, recall petition and RRFA; and the same for other editors discussing the concerns. This risks the entire process getting strifed to an exceptional degree, which is the central concern I have been working against.

As a completely separate sidenote, the dewiki process can be probably summarised to A+D. Soni (talk) 22:07, 9 May 2024 (UTC)[reply]

Long reply Levivich (talk) 02:49, 10 May 2024 (UTC)[reply]

@Soni: TLDR: we give up the opportunity to resolve things at the petition stage if we don't have discussion during the petition phase.

Thanks for sharing your reasoning, which I understand I think it's a perfectly reasonable view, or a perfectly reasonable prediction of how the process might unfold and the risks we might face. Let me expand on my reasoning, which boils down to having a different prediction of how things might go and focusing on different risks (and rewards).

First, I think it would very strange, and unfair to the admin, if a recall petition were initiated without an explanation as to why. It would also be unfair if that explanation were just a series of generalizations or characterizations, so I think the explanation needs to come with diffs. So I think a recall petition should come with something that could fairly be called an indictment: an explanation of why the admin is unsuitable, with diffs. This doesn't mean proof that the admin abused tools, but if it's something like "bad temperament" or "bad judgment," there'd be examples (in the form of diffs/links/quotes/etc.).

Second, in order to evaluate the recall petition, editors should be able to discuss the indictment, and the admin generally. This includes expanding on the diffs in the indictment, or rebutting it. (One thing that hasn't been raised (yet) is whether the admin can respond during the recall petition, and if so, where and how.)

Third, I don't think there are going to be very many RRFAs, although I think there will be a fair amount of recall petitions (like a bunch in the first year and then a few every subsequent year). But I don't think these petitions will result in many RRFAs because I think one of two things will happen during the petition process: (1) the admin reads the writing on the wall (the complaints are widely shared), resigns and does not run for RRFA, or (2) editors read the writing on the wall (the complaints are not widely shared) and the petition will fail. (This is assuming people can discuss during the petition phase.) RRFAs will happen, also in two general circumstances: (a) the admin is, what's the word I'm looking for... unobservant enough to not read the writing on the wall and will run a doomed RRFA out of, um, what's the word, misguided persistence. Or (b) the true edge cases, where there is just enough support to get over the petition but it's unclear that there it's really consensus. Like a 50/50 scenario. Or for the RFA analogy, a crat chat zone scenario. I think both of these will be rare; there aren't that many people who are unobservant and persistent enough for the doomed RRFAs, and edge cases are inherently rare.

Fourth -- and this is the most important -- I think the above-described process (a recall petition with discussion) will lend itself to the possibility of both airing grievances, and working through grievances, at the petition stage. Right now we have no process for just saying, "hey I think you're not a good admin and should hang it up." We can say that on an admin's user talk page, but let's be real, that would be viewed as harassment and likely met with a bunch of the admin's friends (talk page watchers), so nobody is gonna do that. We can complain about an admin at ANI or to Arbcom for "cause," which means tool abuse, but not for "poor behavior that doesn't explicitly violate any policies." The recall petition provides that formal process. That doesn't mean that every recall will end in a hanging or an acquittal. It's quite possible that the airing of grievances, and discussing them, will lead to their resolution. One resolution is the admin agrees they're not suitable, or at least comes to believe a lot of people think they're not suitable, and resigns. Another resolution is that the grievances are rebutted, and the petition fails. A third resolution is that the admin takes the feedback on board and promises to do better, and people either don't sign or withdraw their signature from the petition after discussion. If any of these things happen, and it avoids an RRFA, we will have saved a TON of time, and also saved a TON of heartache (that comes with any RFA). Even though there would be some heartache in the petition phase, at least it wouldn't be extended to an RRFA.

Conversely, if petitions were just signatures, we'd delay all the discussion, and all the potential benefits, to the RRFA. There would still be heartache (at least for the admin) during the petition phase, maybe more heartache if they aren't told exactly what the problem is, and nobody is allowed to rebut anything. And then there would be more heartache in an RRFA. And this might be unnecessary heartache if it could have been avoided by a rebutted petition indictment, or a resignation, or discussion that leads to some kind of accord.

So I don't like options A, B, or C, because they forfeit the opportunity to resolve things at the petition phase through discussion, and make it more likely that an RRFA will commence, and more likely that an unnecessary or doomed RRFA will commence. I don't like D much just because I don't think moving things to the talk page matters or is necessarily helpful, although I'm rather neutral on that option (I mean, it still would allow for discussion). But I'm not convinced that moving discussion to the talk page helps anything in any context. So I think E is the place to start: just let it be like any other RFC, AFD, or RFA -- let people discuss unfettered, see how it goes. If the discussion turns out to be more disruptive than constructive, we could revisit in the future. But I'd start with discussion.

Sorry this was so long, thanks for reading :=) Levivich (talk) 23:12, 9 May 2024 (UTC)[reply]

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

Reconfirmation by admin elections

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

The ayes have it by overwhelming consensus. (non-admin closure) voorts (talk/contributions) 04:54, 14 September 2024 (UTC)[reply]

Can an admin stand for reconfirmation via Administrator Elections?

Survey (Reconfirmation by admin elections)

Sure - if an election happens to line up in their 10 or 30 day window. Tazerdadog (talk) 17:54, 8 May 2024 (UTC)[reply]
Yes, any method for +sysop should be available, meaning RFA and elections. If elections end up being scheduled (meaning, you can't just launch one whenever you want, there have to be certain times when they're run), then the admin should be allowed to stand in the next scheduled election even if it's more than 30 days (although they shouldn't use their tools in the interim). Levivich (talk) 17:46, 8 May 2024 (UTC)[reply]
Yes, as if they were never an admin at all Mach61 18:10, 8 May 2024 (UTC)[reply]
Absolutely. It also would make no sense to prohibit this – someone prefering the admin election process could else also simply resign and immediately apply for an admin election. ~ ToBeFree (talk) 18:50, 8 May 2024 (UTC)[reply]
Yeah Might as well. Fanfanboy (talk) 19:15, 8 May 2024 (UTC)[reply]
Yes; no reason not. Queen of Hearts (talk) 02:02, 9 May 2024 (UTC)[reply]
No. This process is going to be complicated enough as it as; adding a strategic element where you have to decide which process you'll "score" better at and/or how long you can drag the process out isn't a good idea. If admin elections (which have only been approved for a once-only trial) become well established down the road, we can revisit at that point. Extraordinary Writ (talk) 19:58, 9 May 2024 (UTC)[reply]
Yes, so long as the community is continuing the elections option for other RfA candidates. --Tryptofish (talk) 21:43, 9 May 2024 (UTC)[reply]
OK. SWinxy (talk) 23:11, 10 May 2024 (UTC)[reply]
Yes I agree with Extraordinary Writ that we know too little about how admin elections will compare to the traditional RfA process, but the hypothetical posed by ToBeFree shows that prohibiting reconfirmation via admin elections could be easily sidestepped. We could dictate that all admins that resign in the face of a successful recall petition can only regain the tools through an RRfA, but what if the admin resigned while the recall petition was one vote short of passing? With too many scenarios to account for, let us WP:Keep it short and simple. BluePenguin18 🐧 ( 💬 ) 00:30, 13 May 2024 (UTC)[reply]
Agree There were RfAs from former administrators and those who were at the AOR category. We'll see how this goes. Toadette^Edit! 00:45, 17 May 2024 (UTC)[reply]
Yes, subject to any time constraints. ~ Amory (u • t • c) 15:45, 17 May 2024 (UTC)[reply]
Yes, with Tazerdadog's caveat. — SMcCandlish ☏ ¢ 😼 01:56, 23 May 2024 (UTC)[reply]
Support this, including any other process that an editor can apply to be an admin. However, it should fit within the time constraints. Dreamy Jazz ^{talk to me | my contributions} 15:31, 2 June 2024 (UTC)[reply]
Yes, since elections will run independently of the existing RFA process. These two routes to adminship should have equal validity and weight. SuperMarioMan (Talk) 00:44, 10 June 2024 (UTC)[reply]
Per above, must be in conjunction with approved proposal(s) from the #Desysop after Recall petition section. Otherwise, per Extraordinary Whit, without such conjuction, there's no purpose for putting recalled admin into Elections ballot other than to curb a successful recall (i.e. desysopping). George Ho (talk) 23:03, 19 June 2024 (UTC)[reply]
Full and Strongest Possible Oppose to any Community Initiated Administrator Recall Process - I strongly and fully oppose the adoption of any community-initiated administrator recall process. It is already very hard for anyone to become an admin, and this will just encourage admins to work in less contentious areas, which defeats the whole purpose of being an administrator while also increasing the backlog and workload for other admins. Therefore, this type of system should never be adopted. We already have a working and well-established method through Arbcom for removing undesirable administrators. TheGeneralUser (talk) 04:13, 12 August 2024 (UTC)[reply]

Discussion (Reconfirmation by admin elections)

What would the threshold be? Obviously it can't be whatever we agree on above, since there's no room for bureaucrat discretion in a pure vote. If it's just the same 70% cutoff at WP:AELECT, then there's no need to shoehorn this into the reconfirmation process: the admin should just resign and run at the next election. (In practice this will never happen as long as the reconfirmation threshold is lower.) Extraordinary Writ (talk) 02:16, 9 May 2024 (UTC)[reply]

I think this would best depend on whether the discussion at #Reconfirmation threshold above leads to a consensus for default RfA thresholds or lower ones. And I'd say that if the reconfirmation RfA has a 10-percent-point lower threshold than a normal RfA, the same should apply to reconfirmation elections. ~ ToBeFree (talk) 11:45, 9 May 2024 (UTC)[reply]

The summary of consensus from phase one was that the community should be able to compel an administrator to make a re-request for adminship (RRFA) was for a "Re-request for adminship" procedure that could be initiated by the community. Thus I think the re-request procedure itself should be the same, whether it is done on the administrator's own initiative, or as a result of a petition from the community. This includes the criteria for determining if the re-request has succeeded. isaacl (talk) 16:51, 9 May 2024 (UTC)[reply]

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

Reconfirmation threshold for admin elections

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

There is consensus for option C, that is, ~~60%~~ 55% to be elected outright~~, with 50%+ being within 'crat discretion~~. (non-admin closure) voorts (talk/contributions) 04:57, 14 September 2024 (UTC), amended 20:42, 22 September 2024 (UTC)[reply]

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

Option A: 70% (equal to normal admin elections)
Option B: Less than 70% (specify a preferred percentage)
Option C: Depending on the consensus at #Reconfirmation threshold above, in the middle of a normal RRfA's discretionary range. That's 70% for option B, 60% for option A, 55% for option C, 50% for option D, 40% for option E.
Something else (specify ...)

Survey (reconfirmation threshold for admin elections)

C. ~ ToBeFree (talk) 11:57, 9 May 2024 (UTC)[reply]
C Fanfanboy (talk) 12:09, 9 May 2024 (UTC)[reply]
A C Levivich (talk) 15:32, 9 May 2024 (UTC)[reply]
C --Ahecht (TALK
PAGE) 15:37, 9 May 2024 (UTC)[reply]
C, with the caveat that we may change this as we get experience with the process. --Tryptofish (talk) 21:45, 9 May 2024 (UTC)[reply]
C (which is equivalent to A in my preferred world). * Pppery * _{it has begun...} 22:46, 10 May 2024 (UTC)[reply]
C, which I also hope aligns with A for RfA-RRfA-election consistency. BluePenguin18 🐧 ( 💬 ) 04:06, 13 May 2024 (UTC)[reply]
C, with the note that it should be pegged to the admin elections threshold. If it changes, this should too. theleekycauldron (talk • she/her) 07:47, 15 May 2024 (UTC)[reply]
- Wait, no, I don't mean C, I mean A. but find a consensus. theleekycauldron (talk • she/her) 03:24, 26 May 2024 (UTC)[reply]
C to be synchronized. Toadette^Edit! 00:47, 17 May 2024 (UTC)[reply]
C per leeky. Queen of Hearts (talk) 19:58, 22 May 2024 (UTC)[reply]
C, but A if for some reason that other consensus discussion fails to conclude with an actual consensus. Keep it the same as RfA; do not invent conflicting bureaucracy for no good reason. cf. KISS principle. — SMcCandlish ☏ ¢ 😼
A, but I'm okay with C as long as it's above 50%. Toadspike [Talk] 08:31, 26 May 2024 (UTC)[reply]
C to ensure consistency and to avoid an admin trying to find the method that gives best chances for them based on support/oppose counts. Dreamy Jazz ^{talk to me | my contributions} 15:33, 2 June 2024 (UTC)[reply]
Support Option A. Oppose other options. Just as reconfirmation RFAs should follow the same consensus-derived model as non-reconfirmation RFAs, reconfirmation by election should use the same support percentage as first election, i.e. 70%. This ensures that all candidates are held to the same standard in terms of support threshold. SuperMarioMan (Talk) 22:58, 12 June 2024 (UTC)[reply]
Full and Strongest Possible Oppose to any Community Initiated Administrator Recall Process - I strongly and fully oppose the adoption of any community-initiated administrator recall process. It is already very hard for anyone to become an admin, and this will just encourage admins to work in less contentious areas, which defeats the whole purpose of being an administrator while also increasing the backlog and workload for other admins. Therefore, this type of system should never be adopted. We already have a working and well-established method through Arbcom for removing undesirable administrators. TheGeneralUser (talk) 04:09, 12 August 2024 (UTC)[reply]

Discussion (reconfirmation threshold for admin elections)

It took me a while to realize that this isn't the same as #Reconfirmation threshold above, as this deals with Wikipedia:Administrator elections in conjunction with the question above. SWinxy (talk) 23:11, 10 May 2024 (UTC)[reply]

Oh, sorry. Yeah, the classical RfA process is also "election" enough to make this terminology a bit confusing. ~ ToBeFree (talk) 08:32, 13 May 2024 (UTC)[reply]

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

Notifications for petitions

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

There is consensus to adopt option B. Those arguing for TCENT and a watchlist notice did not provide strong reasons for using those forums, and the arguments against—that both are overkill and should be reserved for the RRFA process—were strong arguments. Option A did not gain consensus because no strong reason was given for not notifying at least AN. (non-admin closure) voorts (talk/contributions) 05:07, 14 September 2024 (UTC)[reply]

When a petition is created at the Wikipedia:Admin Reconfirmation page, what notifications should be made (beside the admin's talk page)? Choose all that apply.

Option A: None; watchlist the reconfirmation page if you're interested.
Option B: Wikipedia:Administrators' noticeboard
Option C: Template:Centralized discussion ("there are x admin reconfirmation petitions pending")
Option D: Watchlist notice ("there are x admin reconfirmation petitions pending")

Survey (notifications for petitions)

B, C, and D. --Tryptofish (talk) 21:46, 9 May 2024 (UTC)[reply]
Only A. Anyone should be able to create petitions, but this shouldn't generate too many notifications for everyone else. The other options also incentivise high stakes and drama to the petition process that I was hoping to avoid. If there's sufficient concerns about an admin, they can happen normally at WP:AN without every petition expressedly being posted there. Note that I still support all successful petitions being posted at AN, and the actual RRFA being added to all the locations RFAs currently are. If a non-rolling recall petition passes, I am okay with B and C. Soni (talk) 21:58, 9 May 2024 (UTC)[reply]
Note that if A is not passing, my preferences would be Only B > Only C > B+C > D. I am explicitly for find a consensus over not finding it Soni (talk) 01:02, 13 May 2024 (UTC)[reply]
A for petitions, all RfA notifications for the actual RRfA, as per Soni. Fanfanboy (talk) 12:10, 10 May 2024 (UTC)[reply]
B, but C and D go too far. --Ahecht (TALK
PAGE) 13:53, 10 May 2024 (UTC)[reply]
C and D. Cremastra (talk) 19:54, 10 May 2024 (UTC)[reply]
In the exact same places that RfAs are notified in, which currently means D. * Pppery * _{it has begun...} 22:46, 10 May 2024 (UTC)[reply]
- Agree. — Frostly (talk) 05:51, 13 May 2024 (UTC)[reply]
C and D to reflect RfAs. (The CD template also notifies for RfAs.) SWinxy (talk) 23:11, 10 May 2024 (UTC)[reply]
Same as RFA, so C + D. Second choice is either C or D, third choice is B, fourth choice is A. I worry that both A and B will reach a skewed, predisposed, or "involved" audience, while C and D are more likely to alert more uninvolved editors. Levivich (talk) 17:47, 12 May 2024 (UTC)[reply]
B I proposed listing at WP:CENT and watchlists once petitions hit 50% of the thresholds during open discussion, but after further thought, let us avoid the headache of un- and re-listing petitions as signatories shift around that amount. While it seems most want individual recall petitions to last a month, at most, I expect that on the majority of days during the next two years, we will have at least one open recall petition, so C and D seem likely to make editors ignore what goes on at WP:Admin Reconfirmation instead of widening participation. BluePenguin18 🐧 ( 💬 ) 00:47, 13 May 2024 (UTC)[reply]
A and B are okay. C and D don't work properly. These petitions are open for a year without early closing or even just "oppose" being an option. Their number will always be larger than 0 as soon as the system is accepted by the community, and the worst petitions would gain the longest visibility. ~ ToBeFree (talk) 15:55, 13 May 2024 (UTC)[reply]
The current consensus at #Initiation procedure seems to be against the petitions being open for a year long. Fanfanboy (talk) 15:41, 14 May 2024 (UTC)[reply]
Thanks Fanfanboy and sorry, I forgot to take this into account. I was still thinking about the originally proposed 1 year. My concerns about C and D are lower if 6 or 3 months, and mostly alleviated if 1 month is the consensus there. ~ ToBeFree (talk) 20:05, 14 May 2024 (UTC)[reply]
A or B. The only reason I can think of that a petitioner wouldn't want to post to AN anyway is that they're afraid of blowback. I'd prefer they be forced to factor in that social cost before starting a petition in the first place. theleekycauldron (talk • she/her) 07:49, 15 May 2024 (UTC)[reply]
A or B. RRFAs should be notified as per RFAs, but there's no need to before hand. If an editor has a problem with admin they can find the recall and sign it. -- LCU ActivelyDisinterested «@» °∆t° 22:57, 15 May 2024 (UTC)[reply]
A, I think, although I think once a RRfA is open, participants in the petition should be notified. ~ Amory (u • t • c) 15:47, 17 May 2024 (UTC)[reply]
B at least is fine. C may be appropriate depending on which option we pick in "initiation procedure", but we can sort that out once we see how the process works in practice. D is a bridge too far, I think. Extraordinary Writ (talk) 22:41, 17 May 2024 (UTC)[reply]
C and D to match RfA. Oppose both B and C as redundant, as T:CENT is right at the top of AN. Queen of Hearts (talk) 20:02, 22 May 2024 (UTC)[reply]
D, C, and B in that order of importance (to me). — SMcCandlish ☏ ¢ 😼 01:59, 23 May 2024 (UTC)[reply]
B is sufficient. Petitions may last too long to justify C. LEPRICAVARK (talk) 20:25, 24 May 2024 (UTC)[reply]
B and D - AN because recalls are of interest to administrators and users interested in administrative issues, which is the purpose of that board, and D because we advertise RFAs that way already. We don't promote RFAs in CENT and I don't see a reason to only advertise RRFAs there, considering the multiple other notification methods. Ivanvector (^Talk/_Edits) 12:57, 25 May 2024 (UTC)[reply]
B, C, D but only if the petitions aren't open "forever" (i.e. a year). My answer really depends on how many petitions end up being opened at one time – if they're a rarity, notifying CENT is good, but if there are constantly a dozen open then I'd prefer if there were no special notifications. Toadspike [Talk] 08:34, 26 May 2024 (UTC)[reply]
A only, strongly oppose all others as harmful generation of extra drama. —Kusma (talk) 08:57, 26 May 2024 (UTC)[reply]
A for petitions. --Enos733 (talk) 17:12, 27 May 2024 (UTC)[reply]
Option A, same reasoning as Kusma. Strongly oppose Option D unless petition pages are going to include oppose sections where users can !vote against starting a reconfirmation RFA and/or state their confidence in the candidate, and this gets weighed against the supporting signatures. Otherwise, it's just inviting everybody with a watchlist to join in a one-way pile-on. It's not the same as publicising RFAs via watchlists. In fact, the more I think about Option D, it just seems cruel and demoralising to the person who's the subject of the petition. It's one thing for a petition to be started, but quite another for it to be linked from everyone's watchlist. SuperMarioMan (Talk) 00:48, 30 May 2024 (UTC)[reply]
A or B. Dreamy Jazz ^{talk to me | my contributions} 15:35, 2 June 2024 (UTC)[reply]
B - Because this is relevant to admins. Didn't pick C, because Cent seems more for RfCs about things one might find on the WP:VP. I started to support D, but people's comments above give me pause. We really shouldn't want this to turn into a public shaming. Arbcom cases aren't watchlist notices, and neither should this be. - jc37 17:31, 2 June 2024 (UTC)[reply]
B, you can't oppose a petition so any notification, even if neutrally worded, acts as de facto promotion of the petition. Mach61 19:37, 9 June 2024 (UTC)[reply]
B if petition requirement is approved – Admins should know which admins are petitioned before RRFA is initiated, and AN is one of highly (not very highly, actually) viewed pages. Petitions are pre-RRFAs, so favoring a watchlist notice banner to list petitions would lead editors into treating petitions as no different from RRFAs. George Ho (talk) 23:18, 19 June 2024 (UTC)[reply]
Full and Strongest Possible Oppose to any Community Initiated Administrator Recall Process - I strongly and fully oppose the adoption of any community-initiated administrator recall process. It is already very hard for anyone to become an admin, and this will just encourage admins to work in less contentious areas, which defeats the whole purpose of being an administrator while also increasing the backlog and workload for other admins. Therefore, this type of system should never be adopted. We already have a working and well-established method through Arbcom for removing undesirable administrators. TheGeneralUser (talk) 04:16, 12 August 2024 (UTC)[reply]

Discussion (notifications for petitions)

Other options welcome. Extraordinary Writ (talk) 20:09, 9 May 2024 (UTC)[reply]

If other notifications are precluded with option A, it seems unduly restrictive. If no one knows about a petition, they won't be able to sign on. The decision would be made by a self-selected group of page watchers. It might be more effective to appoint a designated committee in that case. If other notifications are still permissible with option A, then there would be incentive for a "get out the vote" style campaign, which I feel would be unnecessarily divisive. isaacl (talk) 03:13, 10 May 2024 (UTC)[reply]

The question assumes that you have to notify the admin in question. Is that actually codified anywhere, or should we create it as its own question? --Ahecht (TALK
PAGE) 13:55, 10 May 2024 (UTC)[reply]

I don't think we need to ask the question, I think we can just create a user talk page notification template and mention it in the petition instructions. Nobody would object to that, it's what Wikipedia does for all the other processes. Levivich (talk) 01:44, 11 May 2024 (UTC)[reply]

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

Expired signatures on initiation petitions

This is moot since I closed the above discussion as consensus against rolling. Queen of Hearts (talk) 02:09, 25 August 2024 (UTC)[reply]

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

If a rolling petition is used, what should be done with signatures that have "expired" because they are older than the longest rolling period (e.g. 1 year for Option A, 1 month for Options B and C, etc.)?

Option A: Expired signatures should remain untouched.
Option B: Individual signatures should be struck when they expire.
Option C: Individual signatures should be moved to a separate archive page when they expire.
Option D: Individual signatures should be removed when they expire.
Option E: Entire petition pages should be archived once they have gone an entire longest rolling period with no signatures.
Option F: Entire petition pages should be blanked once they have gone an entire longest rolling period with no signatures.

Survey (Expired signatures on initiation petitions)

C > E > F although the only option I'm really opposed to is A. I think the last thing we want is a giant list of old grievances on display. --Ahecht (TALK
PAGE) 17:32, 14 May 2024 (UTC)[reply]
Oppose rolling, but if it is to be implemented then C > E > F. I agree with Ahecht on this one. Fanfanboy (talk) 17:39, 14 May 2024 (UTC)[reply]
B and E. Keep a record of signatures, but don't keep that list of old grievances looking like it's still active. --Tryptofish (talk) 19:34, 14 May 2024 (UTC)[reply]
Also, per the discussion for this proposal, it should be made explicitly clear that expired signatures may not be re-added with a new date to circumvent this rule. --Tryptofish (talk) 20:12, 16 May 2024 (UTC)[reply]

As I think about this, the more I become concerned that it's important to make that latter point clear. Although I understand the logic that this should be self-evident, I also think that we are dealing with human beings, and this kind of recall process is likely to attract users who are given to things like "you tried to archive my vote to make it not count! admin abuse!". Unless we say this very explicitly, we are going to be dealing with users who want to edit war expired signatures back onto petitions, and that's not worth the drama. --Tryptofish (talk) 19:08, 17 May 2024 (UTC)[reply]
Any/all of these are fine. ~ ToBeFree (talk) 20:01, 14 May 2024 (UTC)[reply]
D > C. Neutral F > E > B. Oppose A. Keeping expired concerns permanently in one location risks making a permanent "list of everything wrong this admin did" attack page. Because page history exists, it should be fairly straightforward for someone to read through removed individual signatures (and associated discussion if any). However, the page, even archived, could risk becoming a permanent list of detractors and flaws. If an admin is being serial opposed by someone, we do not want to give them undue weightage by having their points be repeatedly kept in the same place. Soni (talk) 00:16, 15 May 2024 (UTC)[reply]
Oppose rolling petitions, but if they are taken forward, E > C > F > D > B. Oppose A. Stifle (talk) 09:33, 15 May 2024 (UTC)[reply]
Prefer "not A" for reasons expressed above; support any of the other choices equally. Levivich (talk) 18:28, 15 May 2024 (UTC)[reply]
C > B > A. D is not acceptable. We need to be clear that signatures (i.e. statements of concern by editors, and signed by them) do not actually "expire"; rather, after a long enough time they no longer count toward a particular sort of tally used for a narrow purpose. Nothing about them is otherwise invalidadated. Options E and F are actually an independenent matter of (unless I'm misunderstanding the wording) a recall petititon with zero signatures (beyond the opener of it); of those two options, I support E, because a blank but "open" recall page should not be kept for any administrator. The erstwhile proceeding should be archived so it can be examined later, but it should not linger as a potentially actionable thing that someone with a bone to pick can try to revive. If they think they have new, additional cause for an administrator's recall, they need to open a new petition to that effect. As for C, B, A: C does little "violence" to the original signed statements, but B would easily be confused with the editor striking their own comment because they changed their mind. Opt. A might be confusing because only people paying close attention to the temporal math will know whether those comments are or aren't applicable with regard to the totals-within-a-time-limit count. What would probably really be best is for signed posts that are outside that range to be "flagged" in some way, such as moved into a collapsed section that remains on the same page, or annoted with an icon, or something otherwise not very disruptive to the record. — SMcCandlish ☏ ¢ 😼 02:04, 23 May 2024 (UTC); revised 09:55, 26 May 2024 (UTC)[reply]
Oppose rolling petitions per WP:POLEMIC, nobody should be subject to a perpetual sword of Damocles. Oppose all suggestions regarding "expiring signatures" here. Ivanvector (^Talk/_Edits) 13:00, 25 May 2024 (UTC)[reply]
Oppose A, support the rest, preferring C and F. Toadspike [Talk] 08:38, 26 May 2024 (UTC)[reply]
Strongly Opposed "rolling", but if it does manage to gain consensus, then archiving seems the fairest for that process. - jc37 17:34, 2 June 2024 (UTC)[reply]
Oppose doing nothing, blanking pages, or removing signatures. Support Option C for signatures and Option E for pages. Option B is acceptable, but I think that archiving, to separate anything expired from what's "active", would be better for the transparency and clarity of the process. SuperMarioMan (Talk) 00:17, 3 June 2024 (UTC)[reply]
C, which makes clear that expired signatures are no longer part of the petition, while preserving them in a readable format for the record. Tim Smith (talk) 23:34, 20 June 2024 (UTC)[reply]
Full and Strongest Possible Oppose to any Community Initiated Administrator Recall Process - I strongly and fully oppose the adoption of any community-initiated administrator recall process. It is already very hard for anyone to become an admin, and this will just encourage admins to work in less contentious areas, which defeats the whole purpose of being an administrator while also increasing the backlog and workload for other admins. Therefore, this type of system should never be adopted. We already have a working and well-established method through Arbcom for removing undesirable administrators. TheGeneralUser (talk) 04:18, 12 August 2024 (UTC)[reply]

Discussion (Expired signatures on initiation petitions)

What happens when a signature expires? I doubt the editors concerns will have just gone away. Will they just be allowed to re-add their signature keeping the recall open permanently in the case of rolling recalls, or does their need to be some kind of call down? If there is no cool down why have them expire at all, the process simply becomes 'x' amount of signatures over an endless period. -- LCU ActivelyDisinterested «@» °∆t° 23:02, 15 May 2024 (UTC)[reply]
This question is being asked at #Recall Petition Suffrage. Soni (talk) 04:29, 16 May 2024 (UTC)[reply]
I think the discussion about suffrage is about participating in a new petition, whereas the question here is about someone re-adding their signature after, for example, it has been struck as expired. --Tryptofish (talk) 20:10, 16 May 2024 (UTC)[reply]
An expiry for signatures on a petition is only needed if the petition has an ongoing rolling window. In that case, I'm not sure how useful is the concept of a new petition. I think if there is a mandated waiting period between times when a user can sign onto a petition for a given admin, the period should apply to a rolling petition. isaacl (talk) 21:17, 16 May 2024 (UTC)[reply]

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

Initiator time limit

Clear consensus that a restriction on this is instruction creep and that there are already processes to deal with disruptive recalls, so option D. (non-admin closure) Queen of Hearts (talk) 02:15, 25 August 2024 (UTC)[reply]

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

In order to prevent harassment and other nonsense, we should restrict how often someone can participate in initiating one of these.

Option A - Once every 2 years
Option B - One every 12 months / 1 year
Option C - Once every 6 months
Option D - No restriction: A user can initiate one of these any time

To be clear, this isn't a limitation on participating in the subsequent discussion, but merely being an "initiator" as laid out in the proposals above.

Survey (Initiator time limit)

Option A - Same length as an arbcom term. I weakly could support 1 year, as matching the default length of time suggested before an individual appeals a site ban. The correlating idea for either choice, being that we tend to decide these things for a long term, and also should avoid wasting the community's time. I strongly oppose any length of time less than 1 year. 6 months would turn this into a potential revolving door of harrassment. - jc37 20:34, 27 May 2024 (UTC)[reply]
Option B. I oppose any shorter period. I'm not strongly opposed to A, but it seems a bit longer than needed. Although I see some logic to the argument that the focus should instead be on limiting petitions for a given administrator, it does seem to me that we will have a risk of users who want to go after multiple admins without good reason. Although I would hope that such petitions would fail, and that the initiator would be dealt with based on their conduct, I think it would be useful to have a stated metric that would define when that conduct would become vexatious. --Tryptofish (talk) 21:45, 27 May 2024 (UTC)[reply]
D, and I don't think this is something we need to worry about. I don't view recall as harassment, and I don't think we need to legislate things like how often an editor can start a recall petition, or vote in a recall petition, etc. We don't need to protect admins from editors, this and similar questions strike me as too much "us vs them" mentality, or treating editors with concerns about admins as being like barbarians at the gates that need to be held back. Second choice: shorter = better. Levivich (talk) 21:59, 27 May 2024 (UTC)[reply]
Option D if the question is to initiate a recall against any administrator. Option A if the question is to initiate a recall against a specific administrator. I can see instances where a community member is upset with decisions made by a group of administrators. --Enos733 (talk) 23:48, 27 May 2024 (UTC)[reply]
Option D only. #Eligibility to RRFA already deals with making sure a given admin does not go through RRFA too often. #Recall Petition Suffrage asks about limiting editors voting in too many RRFAs at once. We do not need a third set of restrictions on initiating petitions. If someone is being disruptive with their RRFA petitions, I want the community to be empowered to directly take action against them. Adding extra limitations and restrictions on every subclause of recall does not do that; none of the options here significantly solve a problem, and some of them make problems worse. Soni (talk) 04:25, 28 May 2024 (UTC)[reply]
Well, I oppose limiting how often an editor can comment/"vote" in a discussion. So I agree with you in that. So, I think this is the better place to draw the line. - jc37 21:08, 30 May 2024 (UTC)[reply]
D, per above ~ Amory (u • t • c) 12:26, 28 May 2024 (UTC)[reply]
D, per Soni. Vanamonde93 (talk) 15:59, 28 May 2024 (UTC)[reply]
D, per Soni and the Asshole John rule. Disruptive editing is disruptive. theleekycauldron (talk • she/her) 01:22, 29 May 2024 (UTC)[reply]
D per above, we’re already going to give immunity and I think mass creation of these petitions is covered by policies on disruptive editing, so we don’t need more protections. And if there’s a good reason to start a petition, editors shouldn’t be prevented from doing so by arbitrary bureaucratic time limits. Of the others, I would prefer C as the shortest. Toadspike [Talk] 07:34, 29 May 2024 (UTC)[reply]
If the question is successive petitions against the same administrator, Option B – if the issue needs to be revisited within 12 months, go to WP:RFAR. With Option D, there's nothing to prevent the unhappy starter of a failed petition from simply trying again next week or next month, even if there haven't been any developments since the last petition. Re-running petitions until one gets the desired result is an abuse of community time and definitely a form of harassment. Option C feels too short, and A too long, so going with B as the middle-of-the-road option. SuperMarioMan (Talk) 00:00, 3 June 2024 (UTC)[reply]
Full and Strongest Possible Oppose to any Community Initiated Administrator Recall Process - I strongly and fully oppose the adoption of any community-initiated administrator recall process. It is already very hard for anyone to become an admin, and this will just encourage admins to work in less contentious areas, which defeats the whole purpose of being an administrator while also increasing the backlog and workload for other admins. Therefore, this type of system should never be adopted. We already have a working and well-established method through Arbcom for removing undesirable administrators. TheGeneralUser (talk) 10:32, 6 June 2024 (UTC)[reply]
Option D as first choice. Less is more, honestly. If not, how about option C as second choice instead? George Ho (talk) 03:22, 27 June 2024 (UTC)[reply]
D per Soni. Fanfanboy (talk) 07:23, 12 August 2024 (UTC)[reply]

Discussion (Initiator time limit)

I think I would prefer there be a minimum period between petitions for a given administrator. (Any serious concerns that arise during this period would have to be handled through an arbitration request.) If someone is starting petitions vexatiously, it can be handled through existing policies on collaborative behaviour. isaacl (talk) 21:19, 27 May 2024 (UTC)[reply]

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

General Discussion

Confirming Extended Confirmed as Voter Requirement

The original proposal 16c clarified that voters in an RRfA request must be extended confirmed, which is now also a requirement for voting at RfA. However, 16c didn't necessarily get "broad consensus". We might need to add a section to this page to confirm that only extended confirmed editors' votes in an RRfA request count. Toadspike (talk) 17:04, 8 May 2024 (UTC)[reply]

#Initiation procedure is already intended to cover this. If there is a suggestion for non EC editors to count for an RRFA request, it can be added as an option and gain consensus there. All three proposals suggested during "Open discussion" phase happened to include EC, so all options currently do as well. Soni (talk) 17:09, 8 May 2024 (UTC)[reply]
Good point, I somehow forgot that. Thank you. Toadspike (talk) 11:51, 14 May 2024 (UTC)[reply]

Dispense with the questions section for an RRfA

By the time we get to an RRfA, there's been extensive discussion about the issues at hand and the admin has already gone through a full RfA process. Let's get rid of the "questions" process and all the baggage that goes with it. — Rhododendrites ^talk \\ 17:28, 8 May 2024 (UTC)[reply]

Then where/how does the admin address the concerns? Levivich (talk) 17:49, 8 May 2024 (UTC)[reply]

A dedicated section? The point isn't to say the admin can't respond; the point is that we would be deadminning for cause, so keep it focused on that cause rather than have another round of loaded questions, pop quizzes, and personal bugbears. — Rhododendrites ^talk \\ 01:28, 9 May 2024 (UTC)[reply]

I don't perceive RRFA as a discussion as to whether an admin should not be an admin, but whether an admin should continue to be an admin. The issue at RRFA isn't "did they misuse the tools" (that's what arbcom is for), the issue at RRFA is "do they have the trust to be an admin?" It's the same issue at issue at RRFA as at RFA; the difference being that at RRFA we have a track record of admin tool use to examine and not just a track record of edits. I'm not a huge fan of the questions at RFA (or RFA at all), but I still think that because it's the same issue being decided, it should be decided in the same way: an RRFA should be a full RFA process. Levivich (talk) 02:58, 9 May 2024 (UTC)[reply]

+1 Soni (talk) 05:25, 9 May 2024 (UTC)[reply]

I feel compelled to point out that this really sums up the problem with these RRFA proposal(s): The issue at RRFA isn't "did they misuse the tools" (that's what arbcom is for), the issue at RRFA is "do they have the trust to be an admin?" ). There is no thing-in-itself of adminship separately from use of the tools. If there is a lack of "trust" in someone's adminship that is somehow unrelated to misuse of the tools, then that lack of trust isn't a valid concern to begin with. Separated from any concerns over actual abuse of admin powers, this proposal aggravates the already dangerous tendency to equate adminship with some kind of social rank or esteem -- while also creating a new mechanism for removing any dissenting voices within this "trusted" group. It's difficult to overstate how disastrous that could be for the project. -- Visviva (talk) 05:33, 10 May 2024 (UTC)[reply]

A series of bad or suboptimal closes. Unhelpful sanctions on CTOP areas. Chronic or serious incivility (eg opposing an rfa because of the candidate's gender identity). Anything we'd WP:CBAN over. These are examples of potential reasons to desysop someone other than tool abuse. Levivich (talk) 05:55, 10 May 2024 (UTC)[reply]

Bad or suboptimal closes by what measure? Unhelpful sanctions by what measure? Incivility by what measure? Cheers, · · · Peter Southwood ^(talk): 10:58, 3 June 2024 (UTC)[reply]

By the same measure that made the person an admin in the first place: consensus, the only measure that matters. Levivich (talk) 16:03, 3 June 2024 (UTC)[reply]

I can see doing away with the pre-fabricated set of stock questions, but the questions that people come up with themselves belong in the questions section, and this what would be created, under a confusing other name by Rhododentrites's "dedicated section" for "where/how does the admin address the concerns". My consistent theme throughout this entire page: do not invent new bureaucracy of any kind when existing process and procedure already work. — SMcCandlish ☏ ¢ 😼 02:07, 23 May 2024 (UTC)[reply]

Delete RRfA petition after conclusion?

What happens to the page in the case of non-rolling petitions? Is it deleted, blanked, kept, or is the fate wholly up to the user in question? and does that vary based on whether it meets the threshold? The obvious argument for keeping is that it makes determining suffrage for petitions easier. The obvious argument against is that keeping a list of an admin's detractors is demotivating and easy to abuse. Copied from talk. Sincerely, Dilettante 18:25, 8 May 2024 (UTC)[reply]

It shouldn't be deleted - Wikipedia keeps a permanent record for a reason and admins should not try to hide from their past. Fine with blanking, or not, though. * Pppery * _{it has begun...} 22:47, 10 May 2024 (UTC)[reply]

Making the case for need

Editors who are formulating this proposal should give some serious thought to making the case for why such a proposal is needed. After each of the survey points above has been hashed out, there will need to be a community-wide RfC on whether or not to make the proposal a policy. (Arguing that there was a consensus in Phase 1 to create some sort of proposal will be insufficient.) Are there examples of ways in which the status quo is not meeting the community's needs, that the new proposal will address? How will you answer concerns that good admins will be mistreated by the proposed process? --Tryptofish (talk) 00:51, 9 May 2024 (UTC)[reply]

I think these are reasonable concerns and, specifically, that this - "After each of the survey points above has been hashed out, there will need to be a community-wide RfC on whether or not to make the proposal a policy." - is a good and salient observation. Chetsford (talk) 01:00, 9 May 2024 (UTC)[reply]

While I'm sure you're correct about the need for a RFC to present the final proposal, I'd like to pause and grumble that we need 3 full monthlong independently closed RfCs and a community consultation period to make a change. We are clearly not a bureaucracy ™Tazerdadog (talk) 01:19, 9 May 2024 (UTC)[reply]

I'm coming at this as someone who attempted, unsuccessfully, to get consensus for a similar proposal many years ago, and I know what you are going to be up against. What's worse than spending 3 full months working on something before getting a change? Spending 3 full months working on something, only to have it shot down. --Tryptofish (talk) 01:29, 9 May 2024 (UTC)[reply]

I don't think there's any need for that. If we get a "no consensus" on some details, we can always attempt to push through a final proposal that mostly represents communitty consensus; otherwise, giving more opportunities for bikeshedding and nay-saying is absolutely counterproductive. theleekycauldron (talk • she/her) 01:33, 9 May 2024 (UTC)[reply]

That sounds to me like "famous last words". I'm speaking from experience, but if you want to relearn it for yourself de novo, go right ahead. (Rolls eyes at the thought of "attempt to push through".) --Tryptofish (talk) 01:41, 9 May 2024 (UTC)[reply]

I meant via a third RfC, the thing that's probably gonna fail that is for some reason being suggested. theleekycauldron (talk • she/her) 02:53, 9 May 2024 (UTC)[reply]

@Tryptofish The proof that the community is disconent with the status quo came with the approval of proposal 16. Mach61 01:35, 9 May 2024 (UTC)[reply]

That's part of it: a desire for something new. But the other part is whether there is desire for something specific that is new. Don't underestimate the hurdles to the latter. --Tryptofish (talk) 01:41, 9 May 2024 (UTC)[reply]

Why would we need another RFC after this RFC? This is the RFC to figure out the details that were not determined in the last RFC. I don't see a need for a third RFC. You can't get any broader consensus than something like RFA2024, why make everyone re-state what they just stated here? As the close of the last RFC said, "further consensus should be sought on which, if any, is to be adopted," and that's what we're doing here. Levivich (talk) 02:52, 9 May 2024 (UTC)[reply]

The summary of consensus from the first RfC says 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 current survey doesn't provide a way to evaluate "if any" procedure should be adopted. If the phase 2 discussion is modified to accommodate disagreement, then I don't feel another discussion is required. In its current form, though, a discussion on a consolidated proposal for the administrator recall process would be needed to determine consensus. isaacl (talk) 03:07, 9 May 2024 (UTC)[reply]

The way to evaluate "if any" procedure should be adopted is to evaluate each proposed procedure and see if any is adopted. Or to put it more clearly, the question isn't "will there be a recall procedure," the question is "what will the recall procedure be, exactly?" "Will there be a recall procedure" was answered in Phase I (yes), and Phase II is to answer "what will the recall procedure be, exactly?" There is not a need for a Phase III that asks to confirm Phases I and II. Instead, Phase III should be the trial of the procedure decided in Phase II. Levivich (talk) 03:14, 9 May 2024 (UTC)[reply]

@Joe Roe: as closer in case they want to weigh in on what they meant (if they remember). 03:23, 9 May 2024 (UTC) Sincerely, Dilettante 03:23, 9 May 2024 (UTC)[reply]

I meant that there is no consensus for a any of the proposed recall procedures, then obviously we won't have a specific recall procedure to adopt. That would be a very disappointing outcome since there is a clear consensus that we should have some sort of procedure, but I don't believe that in a consensus-based decision making process one discussion can restrict the outcome of another (i.e. force one of the offered options to be adopted; in other words, consensus can change). I didn't mean there there should be a Phase 3/confirmation RfC and I strongly disagree that one is necessary. We are already hurtling fast down the road of bureaucracy-over-consensus with these multi-stage RfCs and we don't need any more pressure on the pedal. The proposal was also to "allow the community to initiate recall RfAs", not "trial a way for the community to initiate recall RfAs". So although CCC again means that we can decide later to change or drop anything we agree here, there's no consensus for a specific time-limited trial as yet. – Joe (talk) 07:52, 9 May 2024 (UTC)[reply]

I agree there shouldn't be a phase 3 before proceeding. I think approval of the overall procedure needs to happen as part of phase 2. The way the discussion is currently structured, everyone can put forward their viewpoints on how to implement specific parts of the process. Users generally aren't going to try to obstruct progress on individual aspects, as that wouldn't be working collaboratively towards a consensus view. Thus I feel it would be a good idea to allow for disagreement to be expressed on the overall process. Sometimes putting the parts together doesn't result in a process that a consensus of users can agree with. isaacl (talk) 03:24, 9 May 2024 (UTC)[reply]

Say we have a vote and decide to buy balloons but we don't agree on exactly how many or what size or color because those questions weren't asked as part of the vote on whether to buy balloons, and although people discussed it, there was no clear consensus answer. So, we have a second round of voting on the number, size, and color of the balloons.

Are you saying that in this second round of voting, we should also vote on whether to buy balloons at all, because some people would rather not buy balloons at all than buy balloons of the number/size/color that is chosen? Because it seems to me that the one thing that shouldn't be at issue in the second round is whether to buy balloons at all, because that was decided in the first round.

Or are you saying that after voting on number, size, and color, there should also be a vote on approving the combination of number+size+color? Because that seems like unnecessary duplication.

Or am I misunderstanding entirely? Levivich (talk) 03:44, 9 May 2024 (UTC)[reply]

I believe you understand that we differ on how agreement should be obtained on whether proposal has consensus support. Your analogy assumes that each aspect of the proposal is independent of the others, and a consensus view can be obtained by combining together the result of individual discussions on each part. I believe that there are interested parties who aren't raising objections on individual aspects, as they are letting those with strong opinions reach agreement on what they feel is the best approach for each, and are waiting to see the overall proposal so they can think about it as a whole, including the interactions between them. This is a common approach in the real world: allow the strongest supporters of a new initiative to work out what they feel to be the best proposal, and then consider it. This gives those who favour a new approach space to work out details without constantly having to defend the overall goals and objective, but still allows for consideration by all sides afterwards. isaacl (talk) 05:13, 9 May 2024 (UTC)[reply]

I believe that there are interested parties who aren't raising objections on individual aspects, as they are letting those with strong opinions reach agreement Then those interested parties should raise the objections on the current phase, conditionally or otherwise. This proposal is not in a vacuum, and each section already has interactions with other sections currently. There are multiple supporting editors who reference other sections in their discussions, I see no reason why the same cannot be said for editors who have concerns.

Speaking more concretely, I am happy with adding additional questions to Phase 2 if necessary. Do you have an example question of what you want to ask? Soni (talk) 05:42, 9 May 2024 (UTC)[reply]

Each section is structured as supporting options A, B, C, and so forth. Thus there is no option for someone who doesn't support any of the suggested approaches. As you may recall from other discussions, I agree with allowing implementation details be worked out by consensus agreement with those who are implementing a process. However the details around initiating a recall discussion have been the key reason for objections for many years now. I think it's reasonable to have a discussion on the complete proposal once it has been shaped by the individual discussions.

I appreciate there are different discussion styles, and some think all discussion should take place simultaneously, rather than giving space to proponents of a given proposal to work out details before that proposal is discussed by all. I understand why, but personally I feel it provides incentive for interested editors to be more obstructionist, rather than collaborative, and thus makes these discussions more confrontational than necessary. isaacl (talk) 06:00, 9 May 2024 (UTC)[reply]

Well, sorry to roll out the cliches, but this isn't a vote, it's consensus-building, and for once that's a meaningful difference: a vote implies some sort of procedural structure and the possibility of binding decisions, while consensus-building by definition needs to allow for the possibility that people can change their minds. Following your analogy, we might find that the only balloons on sale right now are giant puke-green ones with Donald Trump's face on it, so we decide that actually, we'd rather not have any. – Joe (talk) 08:08, 9 May 2024 (UTC)[reply]

Courtesy ping @Soni:. I think this can be handled in phase 2 if we add a question and ping everyone. I think it's cleaner if we do a phase 3, because there's no self-referential elements (A concrete proposal instead of a skeleton with numbers being determined simultaneously - lots of conditional votes possible if we poll now.) Despite that I want to poll now partly due to bureaucracy concerns, and partly because I'm not convinced based on the overall tone of this discussion that this is going to have an unclear result.Tazerdadog (talk) 04:06, 9 May 2024 (UTC)[reply]

As a separate point, I am trying to help manage the structure and reduce chaos on this process, but I do not claim Ownership here. If there are additional questions that multiple of us agree on, any of us can/should add them. I am happy with other editors stepping in as needed. Soni (talk) 05:16, 9 May 2024 (UTC)[reply]

This is the precise 'bureaucracy for the sake of bureaucracy' this proposal was intended to avoid. We have obtained general consensus for a recall multiple times in the past (including 16), general consensus for this broader structure in Phase I (16C), and an open discussion just to let people hash out the "process" of this !vote and letting individual proposals be discussed before !voting starts. It reminds me of an adage I've heard offwiki... "If something doesn't go your way, just start another RFC until consensus changes."

@Tazerdadog I am happy to see additional questions and pings to Phase 2 if enough editors think this is necessary. I personally do not think we need to "accommodate for disagreement" at every hurdle of the process, else we'll be asking "Is this a good idea" at every possible junction hereafter. But I'm also quite unclear what this additional question would be. Could you mock up an example question? Soni (talk) 05:08, 9 May 2024 (UTC)[reply]

@Soni:

Something like this perhaps:

Should administrator recall be implemented using this process?

A: Support - Administrator recall should be implemented at the conclusion of this RFC. The other sections of this RFC give the specific rules and details for a recall.
B: Oppose - Administrators should not be recalled using this process.
C: Follow-up RFC required - A follow-up RFC is required on this. The exact details chosen will strongly affect whether I can support recalling admins using this process.

Definitely interested in other opinions about this - feel free to wordsmith this pretty aggressively. If we add this question we need to list this discussion on WP:CENT directly, to ensure that we get the broadest possible participation. Tazerdadog (talk) 05:57, 9 May 2024 (UTC)[reply]

I still believe this question is redundant and has been asked already. But I am also okay if others want to ask this, so feel free to send it as is. I have made a short pass on the wording in situ, re-edit or reformat as you need. Soni (talk) 06:03, 9 May 2024 (UTC)[reply]

Please define "this process". Levivich (talk) 06:05, 9 May 2024 (UTC)[reply]

"this process" = Compel an administrator to file a RRFA to retain their administrator status by gathering signatures on a petition. The number of users required to trigger a RRFA, timeframe to gather signatures, threshold for success, and other smaller details are being established in their sections of this RFC. Tazerdadog (talk) 06:38, 9 May 2024 (UTC)[reply]

How is that a different question than the question asked in Phase I? Levivich (talk) 15:33, 9 May 2024 (UTC)[reply]

That sounds like a rerun of Phase I. There is already a consensus that we want a recall procedure, assuming the details can be worked out. – Joe (talk) 08:01, 9 May 2024 (UTC)[reply]

Joe, I've reread your close a zillion times (that's an exact number), and while I see a "rough consensus" for reconfirmations initiated by the community, I'm not seeing you finding a consensus for recall petitions, as such. If this part of Phase 2 is going to be conducted with some sort of recall petitions as an inevitable part of the process, that seems to me to go beyond what you found in your close. --Tryptofish (talk) 00:42, 10 May 2024 (UTC)[reply]

"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" - petition isn't the only possible initiation procedure, it's just the only specific proposal so far because "Proposal 16c was well-supported and should be a starting point for these discussions." Levivich (talk) 02:03, 10 May 2024 (UTC)[reply]

This is basically what happened. Through Phase I, the main non-petition specific idea I could see was a "Consensus via ANI/similar". That had been rejected in 16D, so I was not keen to add ideas just for the sake of variety. During Phase 2's open discussion, it wasn't re-recommended, and no more non-petition ideas were discussed.

If someone has proposals to initiate RRFAs that do not involve petitions, they should be welcome to add them. A similar case has already been made for the non rolling initiation procedures; not all of the remaining questions would apply to them as well. Soni (talk) 02:53, 10 May 2024 (UTC)[reply]

@Soni: Others can of course disagree, but as the person who closed the discussion (which nobody has challenged yet), I've said multiple times that there was not a consensus for your proposal 16c, even in the broad strokes. I'm worried that your heavy presence in structuring this follow-up RfC has given undue emphasis to your own idea, with others just invited to "work out the details". I think it would be a good idea if you stepped back and let less involved parties (theleekycauldron, maybe?) manage the process of building consensus, which may still depart significantly from your proposal, or even reject the idea of RRFA after all. – Joe (talk) 07:59, 9 May 2024 (UTC)[reply]

I think it would be a good idea if you stepped back and let less involved parties (theleekycauldron, maybe?) manage the process of building consensus Sounds good to me. I may have understood your "starting point for the discussions" comment a bit different than you intended, hence the 'Open discussion' sectioning phrased as it was.

That said, I will say that I've kept requesting other editors to define this structure from the start. The current page structure was adapted from leeky's original design, I asked for opinions on modular vs wholesale up/down vote, we've integrated Giraffer and Mach's proposals from Open discussion, and I've kept asking others to add additional options/alter the page as they want. Consensus can change, but the current !vote structure is me trying to best summarise all the ideas people suggested in Open Discussion.

I'm completely happy to take another step back if others prefer, but I just wanted to highlight that this is still opinions from many editors being added; I just had been doing the final polish. Soni (talk) 08:19, 9 May 2024 (UTC)[reply]

Soni wanted the chance to direct how this proposal was going to be structured – I think that they've done a fantastic job getting it this far, and I agree with their reading of the close that 16c being a "starting point" does kind of lend itself to the setup we've seen so far. I'm happy to take over managing structure from here – I think we have a real chance at getting this past the finish line, if we clear the roadblocks. theleekycauldron (talk • she/her) 21:17, 9 May 2024 (UTC)[reply]

I'm glad that I raised this issue, because the discussion here reveals a lot of things that haven't really been thought through. As noted, Joe Roe's close says in part: 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. There is a clear meaning to the words "if any": that it is at least possible that none of the "specific proposals" will get consensus to be adopted. Therefore, whatever is done in Phase II must include an option not to do the specific thing being proposed at all. And, as also noted above, the questions have all been formulated along the lines of "which of these options will be adopted?", without the option of "none of the above". That's a big problem! One cannot just wish it away, or ignore it.

And I agree also with the observation that editors who disagree with having such a recall process at all have, for the most part, been staying out of the way so that proponents can put together their best proposal. That's a good-faith thing to do. But it shouldn't be met with a bad-faith assertion that, well, that's your fault, because you should have been raising your objections all along. Maybe editors should have done that, or maybe they shouldn't, but if they didn't, that's not permission for saying that it was preordained in Phase I that anything that gets a local consensus during the Phase II brainstorming is going to become policy – even if that brainstorming was constructed in such a way as to lock out the view that the recall process as a whole might no longer have consensus, once the community sees the moving parts: you can choose which option, but you cannot choose "none of the above".

Admin recall proposals have been made for years. And never has the brainstorming process been equated with the process of establishing as policy. There has always, previously, been a formal RfC about whether or not to adopt the proposed process, after the proposal has been formalized. --Tryptofish (talk) 20:51, 9 May 2024 (UTC)[reply]

Note: if, in fact, the decision has been made here that whatever pieces of the discussions above get individual consensus are going to become policy – that means that all administrators will find themselves subject to them. I've put this notification at AN: [1]. --Tryptofish (talk) 21:04, 9 May 2024 (UTC)[reply]

I'm concerned that your reading of Joe's close is inaccurate. He says that there is consensus to implement some kind of administrator recall, and that phase II should consider specific proposals on which to adopt. If we choose to adopt one of them, that's the one we go with. If we end up choosing none of them, then fine, we can have some other discussion in which we figure out if we want to choose something at all. But that's not a necessary thing because we already settled that question. Soni is right; this is needless bureaucracy. theleekycauldron (talk • she/her) 21:15, 9 May 2024 (UTC)[reply]

I'm just going by the wording as it is written. What happens if the discussion here yields "no consensus" on multiple key parts of the process? --Tryptofish (talk) 21:50, 9 May 2024 (UTC)[reply]

Then we've failed to follow through on our mandate, and the admin-recall process is incomplete and can't be used. Someone who thinks that they can put together a workable proposal that can pass would be welcome to use phase II as a starting place. What seems to be the question here is "what happens if every key question yields consensus?" and I will strongly oppose "have a new RfC to give the discussion one more point of failure". If phase II is a success, the onus will be on any subsequent RfCs to kill admin recall, not re-ratify it. theleekycauldron (talk • she/her) 21:57, 9 May 2024 (UTC)[reply]

If we're considering specific proposals to adopt here, then "not this proposal" needs to be an explicit option (at least under "initiation procedure"). I'm fully on board with a recall process along these lines, but I worry we're heading toward a procedural nightmare when phase II is closed and someone asks "what happens next?" Extraordinary Writ (talk) 21:59, 9 May 2024 (UTC)[reply]

The final closer of the discussion as a whole will let us know if there are any outstanding questions that need to be answered or what our next steps are – there's procedure for this, we're not going to get left in limbo. That's what I'm doing here, make sure that we're working towards concrete, achievable goals. theleekycauldron (talk • she/her) 22:09, 9 May 2024 (UTC)[reply]

With multiple editors, not just me, asking for "not this" options, that is not really, with all due respect, what you are doing here. You are simultaneously acting as facilitator and as a partisan who is trying to shut down anyone who disagrees with you. --Tryptofish (talk) 22:14, 9 May 2024 (UTC)[reply]

In what ways do you feel that I'm shutting down people who disagree with me based on my personal opinions? If your complaint is that I'm not letting people relitigate phase I questions, yeah, that's fair. I don't particularly see a problem with that, but I guess that's valid. If your complaint is that I'm using any capacity as facilitator to try and force a specific consensus, I'd be interested to know what you're seeing and how I can improve on that. Please feel free to leave any feedback on my talk page. theleekycauldron (talk • she/her) 22:48, 9 May 2024 (UTC)[reply]

Done. --Tryptofish (talk) 00:35, 10 May 2024 (UTC)[reply]

I agree that the result from phase 1 is that there is consensus support for the community having the ability to compel an administrator to make a re-request for adminship. Supporters of this viewpoint may have had different rationales; their collective support is what matters. Thus I do not feel it's necessary to re-visit a phase 1 question of whether or not the concept has consensus support. But I also feel the summary of consensus indicates that, as Joe Roe has stated, that the phase 1 result doesn't force one of the offered options [in phase 2] to be adopted. Just because the concept has support doesn't mean that any implementation of that concept has support, as some (though not all) of the implementation points under discussion have been sticking points in the past for adopting a recall process. I don't think another full RfC discussion is needed if a consensus is reached on the individual aspects of the recall process, but I think it would be good to have a checkpoint: describe the complete proposed process in one passage, and allow interested parties to affirm that the overall process is one they can support. As different users may have different dealbreakers, it is possible for each part to have consensus support, while the process as a whole does not. It's probably unlikely, but I feel the process will have a more solid basis behind it with a checkpoint. isaacl (talk) 02:09, 10 May 2024 (UTC)[reply]

How will this affect RfA candidacies?

Editors here seem to me to be a bit too confident that this proposed recall process will address the overall concern of RfA2024: that we should find more ways to get qualified editors to become administrators, and remove unnecessary obstacles. I know that one of the arguments that gets made for why a community-based recall process will make RfA easier (because I used to make this argument, myself) is that, if RfA !voters know that the community can recall an admin, then they will be less likely to oppose. But I don't know if that is true or not. On the other hand, I think an argument can be made that qualified candidates might decide that no one in their right mind would want to become an admin if that means being subject to the kind of recall process contemplated here, as soon as they make a tough call. Even if the process might eventually "acquit" them, they would still have to defend themselves. I think that could greatly reduce the number of new RfA candidates.

So – how would editors who support this proposal make the case for need in that regard? --Tryptofish (talk) 21:13, 9 May 2024 (UTC)[reply]

I think this is a reasonable concern that may prove to be true in the long run, but now that we're past the broad-strokes discussions of phase I, we should be focusing on the community mandate we have to create and implement an admin recall procedure of some kind. theleekycauldron (talk • she/her) 21:48, 9 May 2024 (UTC)[reply]

So you agree that it's a potentially reasonable concern. But are you saying that editors who are concerned about it now are not entitled to a rationale for why we should go ahead anyway? --Tryptofish (talk) 21:53, 9 May 2024 (UTC)[reply]

What we need is an RfC to decide whether or not we need an RfC to decide whether or not to implement the results of this RfC that's a follow-up to a previous RfC. Sincerely, Dilettante 21:55, 9 May 2024 (UTC)[reply]

Lots of things are potentially reasonable concerns. That's why we had phase I, to aggregate and discuss those concerns. This idea has consensus now, and it will require consensus to kill the abstract. Demanding that every editor have a satisfactory explanation before we go forward is not how Wikipedia process works. theleekycauldron (talk • she/her) 22:01, 9 May 2024 (UTC)[reply]

If there's a significant dry-spell following the passage of some desysop procedure, we can scrap it and agree the process did the opposite of the intended effect. CCC. At worst, we've lost 3-4 months where 1 or 2 more users could have used the mop. Sincerely, Dilettante 21:52, 9 May 2024 (UTC)[reply]

How is that different than a trial implementation? And what if we don't just have a dry spell at RfA, but a slew of drama in recall petitions? These aren't idle questions. Just look at what happened with another, less controversial proposal, here: WT:RFA#Feedback on the "new RFA process". --Tryptofish (talk) 21:57, 9 May 2024 (UTC)[reply]

It's different because it's de facto permanent. A trial is for x months, and then we need a discussion to renew it. This is for an indefinite length of time (assuming it passes), unless we hold an RfC that determines otherwise.

If we have a slew of improper petitions, I'll be first in line to scrap the process. Sincerely, Dilettante 22:01, 9 May 2024 (UTC)[reply]

The alternative to doing something is doing nothing, and we know where doing nothing goes.—S Marshall T/C 21:55, 9 May 2024 (UTC)[reply]

If the problem that we must do something about is not enough active administrators, it confuses me how you seem to be arguing that what we must do is a process whose only outcome can be to reduce the number of administrators (both directly and indirectly by discouraging adminship through greater bureaucracy). While something can be better than nothing, it can also be worse. Or maybe you have something else in mind as the problem for which doing nothing would be inadequate? —David Eppstein (talk) 07:47, 10 May 2024 (UTC)[reply]

The reason we're not electing enough sysops is this: before I give someone the power to unilaterally control my edits or ban me, I need to be bloody sure I trust them. So I tend to support less and oppose more. If we had a way to reverse a recruitment error then I would need less trust. So passing RfA would be easier.—S Marshall T/C 07:42, 11 May 2024 (UTC)[reply]

@S Marshall: we have effective ways to reverse recruitment errors: Wikipedia:Former administrators/reason/for cause. – wbm1058 (talk) 16:13, 11 May 2024 (UTC)[reply]

No we don't. Before Arbcom will accept a case, the delinquent sysop has to get dragged to AN/I and fail to utter the Humble Apology of Automatic Sysop Exoneration. Under that system, an idiot with a mop can keep it forever if they choose.—S Marshall T/C 17:03, 11 May 2024 (UTC)[reply]

None of the former administrators listed on the page I linked to above kept their mops forever. What I hear you essentially saying is that we have too many administrators; there are active administrators who should be desysopped but have not been because that's too hard to do currently, in other words, the Arbitration Committee sets the bar for acceptable admin conduct too low. The bar for acceptable conduct needs to be raised higher; this will unleash a new wave of overdue desysoppings. Then down the line, some will complain that so-and-so was unfairly desysopped and call for a new "desysop review" procedure, because the community rushed to judgement rather than give the matter the careful consideration that the Arbitration Committee would have. – wbm1058 (talk) 18:16, 11 May 2024 (UTC)[reply]

Yes, that's likely. Some decisions are bad, because we're humans; so we need to be able to re-think and reverse them. Which is the whole point...—S Marshall T/C 18:27, 11 May 2024 (UTC)[reply]

I don't think it's really hard to grasp the concept that people want a method for removing admins that doesn't rely on admins removing other admins, even if the admins doing the removal are elected for this purpose. In other words, admins should be directly accountable to non-admins, not just to or through other admins. Levivich (talk) 18:29, 11 May 2024 (UTC)[reply]

The regular method(s) of requesting administrative privileges will be available to anyone who failed a re-request. Whether or not a re-request process is enacted, there will be future discussions on how administrative privileges are granted and removed, because there always are. isaacl (talk) 21:39, 11 May 2024 (UTC)[reply]

As I read more comments, it increasingly seems to me that the question of whether a recall procedure will decrease the number of admins, because fewer candidates will find it attractive to run an RfA, or increase the number, because RfA !voters will feel less reluctant to support, knowing there's a recall procedure, is something we will find out only after the proposal might be implemented, and we see what happens. But I have some suggestions for those editors who are concerned that the proposed recall process will cause harm. Don't assume that there will ever be an RfC on whether or not the community will adopt this recall proposal. I'm seeing a lot of pushback to my suggestion that it should happen, and I think it's fairly likely that all of the discussions above will be closed with a consensus to adopt the arithmetic mean of the options offered, and that will be that. So instead, comment in the #Initiation procedure section, above, that you are in favor of ArbCom accepting the role via the existing WP:RFAR process, instead of having petitions. That may be your last opportunity. --Tryptofish (talk) 22:30, 11 May 2024 (UTC)[reply]

Solely regarding a consensus result using an arithmetic mean: I don't think that's likely. Generally Wikipedia users consider that to be the evaluator of consensus imposing their own viewpoint on the discussion. (Yes, there are times when users will let that by in the interest of being conciliatory, but I don't see evidence that will happen here.) isaacl (talk) 23:22, 11 May 2024 (UTC)[reply]

About that (the arithmetic mean), I agree with you that it would be absolutely contrary to WP:CONSENSUS, and I said that to indicate something that I would see as a bad result. Personally, my perception is that a significant number of the proposals have comments more-or-less evenly distributed over the A–E (or whatever the letters are) spectrum, and I'm not seeing anyone doing the work that it will take to get editors to agree on where the balance of sentiment resides, and I think that such discussions are going to be very difficult to close in a valid way. --Tryptofish (talk) 23:29, 11 May 2024 (UTC)[reply]

You said it was fairly likely; personally, I don't think so. It's only been six days; plenty of time for people to consider and consolidate their views. isaacl (talk) 00:34, 12 May 2024 (UTC)[reply]

Re: the question of whether a recall procedure will decrease the number of admins, because fewer candidates will find it attractive to run an RfA, or increase the number, because RfA !voters will feel less reluctant to support, knowing there's a recall procedure, is something we will find out only after the proposal might be implemented, and we see what happens. The recall procedure will decrease the number of admins, because that's all it can do. The only question is whether the recall procedure causes a small, insignificant decrease, or a larger decrease. It's sure to raise the drama level several more notches; drama surrounding admins is not healthy for RfA. – wbm1058 (talk) 00:42, 12 May 2024 (UTC)[reply]

It's an open question in my mind whether, in the first year under the recall procedure, we see more RfAs or more recalls. – wbm1058 (talk) 00:48, 12 May 2024 (UTC)[reply]

I know that one of the arguments that gets made for why a community-based recall process will make RfA easier (because I used to make this argument, myself) is that, if RfA !voters know that the community can recall an admin, then they will be less likely to oppose. But I don't know if that is true or not – No one knows if it's really true or not until we try it. We have to try something[s], because the present system is not working well (in multiple ways). The bane of adminship reform for over a decade has been community "the sky is falling" fear-mongering about what some effect might be, based on precisely the same kind of reasonable but highly subjective guessing as those in favor of various changes. The only way to be certain is to actually try things, and keep and improve upon those that work and undo those that make things worse. PS: For what it's wroth, Tryptofish, if this RRFA stuff (in addition to the rest of the RfA overhaul, especially the diff requirement for accusations) gets set up properly, it actually gives me at least a faint incentive to run for RfA for the first time since I was a noob. (That said, I would have to think of something adminstrative I actually want to take on, and my to-do list is already over-long). PPS: It is not possible for RRFA to result in "adminship is no big deal" actually becoming true again (it can't because discretionary sanctions, now folded into WP:CTOP procedures, provide a "Judge Dredd" operating mode for any admin who wants it, whereby they can punitively issue blocks, topic-bans, and so on, based on their own individual personal judgment not any form of consensus, even among admins). But that doesn't means RRFA has no potential to make adminship less of a big deal. — SMcCandlish ☏ ¢ 😼 02:26, 23 May 2024 (UTC); rev'd. 02:39, 23 May 2024 (UTC)[reply]

In a sense, we agree that nobody knows (until it's tried) whether the first part of what I said is true. But in a sense, that was part of my point: that we don't really know whether there is any merit to the argument that if we have a recall procedure, there will be fewer opposes. But what I intended the more important part of my comment to be is that there is, in my opinion, good reason to believe already that a badly designed recall procedure will make a lot of potential RfA candidates decide that it isn't worth the trouble. Obviously, you've just given me an n=1 anecdote of one person who would actually be more likely to enter a candidacy. But I still am very concerned that the risks of "admin abuse" in the form of admins being abused will do sufficient harm that We have to try something[s] is not true: we don't have to. You believe that the present system is not working well, such that the present system of ArbCom handling it needs to be supplemented by a new system that will handle the cases ArbCom has been failing to address. I disagree. I'm not seeing ArbCom failing to desysop the admins that have been brought before them, and I'm not seeing problem admins going around with nobody taking them to ArbCom (things that were much different about a decade ago). If anything, community sentiment has been that ArbCom might have become too efficient at removing admins, which doesn't strike me as a reason to create even more ways to remove admins. --Tryptofish (talk) 21:32, 23 May 2024 (UTC)[reply]

we don't really know whether there is any merit to the argument that if we have a recall procedure, there will be fewer opposes. There is merit to the argument, it's that we've seen it before - Wikipedia:Wikipedia Signpost/2012-10-22/Special report. There is no guarantee this results in fewer opposes, and you are fair to oppose recall. I just do not necessarily agree with your rest of premise. We have receipts of it causing less strife over time. We're just trying our best to emulate enough things so enWiki gets the same results. Soni (talk) 02:11, 24 May 2024 (UTC)[reply]

That depends on the German and English Wikipedia communities having identical cultures. --Tryptofish (talk) 21:36, 24 May 2024 (UTC)[reply]

They don't need to be identical. They just need to be similar enough in practice that the effects are of the same sign (not necessarily even the same magnitude). --N Y Kevin 02:10, 29 May 2024 (UTC)[reply]

That's a fair point, although if the magnitude here were a lot smaller, there would come a point of diminishing returns. --Tryptofish (talk) 22:28, 29 May 2024 (UTC)[reply]

Frequency

I'm a little concerned about those working in areas where they inevitably make a lot of enemies. Very long complext discussion, so I apologize if I'm just not seeing this, but has someone proposed how frequently such a petition can be started? What I'm primarily concerned with is a petition failing, and someone opening a new one the next day/week/month. I kind of feel like once a year is sufficient? Valereee (talk) 17:59, 10 May 2024 (UTC)[reply]

@Valereee this is addressed in the section Eligibility to RRFA Mach61 18:12, 10 May 2024 (UTC)[reply]

Thank you, stupid of me not to see that! Valereee (talk) 20:10, 10 May 2024 (UTC)[reply]

I will say that this is effectively also involving #Initiation procedure. Some proposals have 'non-rolling' petitions (need to be explicitly started and pass/fail), while others are rolling (so cannot have a "petition failed" as such). The section Mach mentioned is still probably best suited to handle these concerns, both for petition frequency and RRFA frequency. Soni (talk) 20:21, 10 May 2024 (UTC)[reply]

It's also important to remember that this is yet another of the things that is not a suicide pact. If some clown keeps repeatedly going after the same admin, on a bogus basis and for personal animus reasons, always failing to get any traction on their desysop demands, the community will notice and probably respond after not very long by imposing a one-way interaction ban, indef, or other remedy. — SMcCandlish ☏ ¢ 😼 02:43, 23 May 2024 (UTC)[reply]

Unpopular but correct actions

I've seen it mentioned a few times that admins sometimes make "unpopular but correct actions" and that recall will affect this. Can someone explain this concept? Since policy is set by global consensus, it seems that any action that is in line with consensus, that is "correct," would also be popular. What is a hypothetical example of a correct (in line with consensus) but unpopular action? Thanks, Levivich (talk) 20:56, 26 May 2024 (UTC)[reply]

In some contentious topic areas nearly every admin action is unpopular with some set of editors, 'unpopular' doesn't have to mean unpopular with every single individual. Also there are many 'in line with policy' ideas that are deeply unpopular with vocal groups. -- LCU ActivelyDisinterested «@» °∆t° 21:19, 26 May 2024 (UTC)[reply]

To my mind, an "unpopular" action means an action that is unpopular with most people. Like if something is supported by 60% of the people, it's popular, even if 40% of people don't like it. If the numbers were reversed, then it would be unpopular. Is that different than how others understand the word?

In other words, if a decision is unpopular (opposed by the majority), then it's also incorrect (not in line with consensus). Which means it's impossible for an admin to make an "unpopular but correct" action, the phrase is an oxymoron. Levivich (talk) 12:16, 27 May 2024 (UTC)[reply]

Your definition isn't the one being used. -- LCU ActivelyDisinterested «@» °∆t° 12:33, 27 May 2024 (UTC)[reply]

Thanks for explaining that to me. Admin actions that are unpopular with some but popular with most would not result in admin recall. Admin actions that are unpopular with most would not be actions we (or most of us) would want admins to take. Levivich (talk) 12:40, 27 May 2024 (UTC)[reply]

I agree with the latter. -- LCU ActivelyDisinterested «@» °∆t° 13:31, 27 May 2024 (UTC)[reply]

Another way to think about it might be "correct, but likely to get some editors upset". Such actions are what we want admins to feel comfortable doing. --Tryptofish (talk) 21:37, 27 May 2024 (UTC)[reply]

You've inserted a definition of "unpopular" that amounts to begging the question. The reference is actually to a decision that gets you a shoal of signatures on your recall petition. Which can be unpopular with that activist minority, whilst still being correct. Stifle (talk) 08:58, 5 June 2024 (UTC)[reply]

The key issue is that consensus and popularity are measured imprecisely on English Wikipedia, with decisions being made by a self-selected group of people who happen to show up at the right time. Witness how a guideline can be approved by consensus, yet not followed in later discussions, as the group of participants changes, and English Wikipedia's "consensus can change" tradition makes it tricky to override the latest consensus view. I think it's a reasonable consideration that admins may worry that opponents of their actions will be more motivated to participate in (or more easily learn about) a re-request for adminship, in spite of the actions having consensus support from a different set of users. isaacl (talk) 17:10, 27 May 2024 (UTC)[reply]

Some decisions may be correct but could upset a vocal, well-organised group. Fear of a group organising a recall petition could stop people being bold, where needed. We need to do the right things for the project and not have fear of accusations of hate speech etc hanging over us. Secretlondon (talk) 12:27, 30 May 2024 (UTC)[reply]

In addition to the observations above, the kind of action that immediately comes to my mind is doing anything to challenge the Unblockables. The defining feature of that group is that they are "popular" amongst other editors with a lot of social capital, or just with the editing body in general, but objectively a detriment to the project as a whole. Blocking them can be correct even though it is not supported by consensus, because that consensus does not and cannot take into account the editors that have been alienated from the project by their actions. – Joe (talk) 09:26, 5 June 2024 (UTC)[reply]

Related discussion

Related discussion is at Wikipedia talk:Requests for adminship/2024 review#Administrator recall, phase II. In particular, anyone closing discussions here should please see that, too. --Tryptofish (talk) 21:51, 11 July 2024 (UTC)[reply]

Open discussion

This section was open from 5 May to 8 May to help narrow down the scope of Phase 2. Soni (talk) 13:35, 8 May 2024 (UTC)[reply]

This section is intended to help narrow us down in scope first. After a few days, we'll vote for specific proposals.

Tweaks to 16C

Per the close, 16C is a good starting point to this process. What changes to the current wording would be sufficiently good? Soni (talk) 15:06, 2 May 2024 (UTC)[reply]

The linked page should probably be WP:Administrator reconfirmations, rather than Admin reconfirmation. I would change the discretionary range from 55–66 to 55–65%, and clarify whether a no consensus close means the tools are kept or removed (also maybe whether Support/Oppose should be retitled to Keep/Remove). Giraffer (talk) 09:11, 5 May 2024 (UTC)[reply]
I do want to point out that there's a difference between "unsuccessful" and "consensus against": plenty of RfAs fall under the discretionary threshold for a pass but certainly stay within "no consensus" territory. 60% support on a normal RfA is a "no consensus" autofail. theleekycauldron (talk • she/her) 09:24, 5 May 2024 (UTC)[reply]
If we're following RfA logic, the idea would be to have to earn the tools, albeit with a lower threshold for success (therefore no consensus = no consensus to grant = remove). The alternative is to really treat this as a confirmation, and have the status quo be keeping the tools, with a no consensus outcome meaning there is insufficient support to remove the tools. Giraffer (talk) 10:20, 5 May 2024 (UTC)[reply]
The latter is the much safer option. If an admin is elected under controversial circumstances, a 5% flip in the electorate shouldn't be enough to take the tools away – that's probably less than random variation in any given RfA period. If the community wants to take someone's tools away, it should have a clear reason why and a clear consensus to endorse it. Otherwise, every AE admin gets a clip in the knees. theleekycauldron (talk • she/her) 10:45, 5 May 2024 (UTC)[reply]

Part of me wants to say that if we've selected a total idiot we probably deserve what we get; however, even those who have turned out to be manipulating the system for their own ends have not been entirely atrocious with the mop. While i understand S Marshall's concern, i think that any such that we make admins will find themselves before the Arbs before they'd be eligible for this RRfA process (which would surely be a depeniculation rather than a defenestration?). Happy days, ~ Lindsay^Hello 10:16, 5 May 2024 (UTC)[reply]

The proposal does not remove any of the currently available methods to get rid of bad sysops. We sometimes have RfAs that pass with well over 50 opposers; without a "wait one year" these opposers could immediately start a recall election. If you want to add an "immediate" clause, I suggest to put the threshold for something like that not below 500. —Kusma (talk) 10:41, 5 May 2024 (UTC)[reply]
I think 500 is a bit extreme. I think RRfAs should focus on admin conduct/conduct since the candidate became an admin, so those hypothetical 50 opposers shouldn't be allowed to simply repeat their RfA oppose arguments to start an RRfA or even vote in an RRfA. But that's just my opinion and would have to be formally codified. Toadspike (talk) 12:19, 5 May 2024 (UTC)[reply]
In my view, policing the reasons why people are allowed to ask for a recall election is both difficult and unhelpful. The one year wait is a good solution: after a year, opposers will see whether their concerns are reflected in the admin's actual work. —Kusma (talk) 12:32, 5 May 2024 (UTC)[reply]

If they're a total idiot, arbcom is already intended as a last resort (which would mean after RRfA has failed). Sincerely, Dilettante 17:05, 5 May 2024 (UTC)[reply]
+1 We (meaning "the community without ArbCom intervention") currently can't defenestrate idiots within a year via a recall process. In other words, not allowing early RRFAs doesn't make anything worse.
Spitballing: what if we say something like "people who opposed an admin at an RfA/RRfA/RfB cannot sign a recall petition within a year"? House Blaster (talk · he/him) 19:19, 5 May 2024 (UTC)[reply]

I favor the original blanket prohibition on recall petitions in the first year because if someone saw a candidate they disliked seeming likely to succeed, but they lacked a rationale to sway the vote, they would have an incentive to vote neutral over oppose to retain the ability to initiate a petition as soon as a mistake or contentious decision is spotted. BluePenguin18 🐧 ( 💬 ) 23:29, 6 May 2024 (UTC)[reply]
The big question that was raised during 16c's discussion stage was "What threshold can trigger an RRFA". I had used "25 editors in 1 month OR 50 editors in 1 year" as a yardstick from dewiki. What would be a reasonable number that doesn't also make RRFAs impossible to hit? Soni (talk) 11:07, 5 May 2024 (UTC)[reply]
- I think these are good starting points for discussion. My only issue with the actual numbers advanced, is that they appear (correct me if I'm wrong) to be drawn from the DE status quo. The DE equivalent of Extended Confirmed has only about 1/3 the number of editors as en.wiki. As a result, the numbers associated with the proposed implementation of this reform advances a far more easy-to-initiate process than currently exists at DE, removing an important guardrail against abuse. Since the supported proposal is to adopt a community recall “based on DE” it should not be significantly easier than the process DE uses. I suggest the thresholds to initiate a recall, therefore, be increased slightly to more closely reflect the proportional numbers required at DE (e.g. 35 and 75; though, even those numbers make this an easier threshold than exists at DE, proportionally). Chetsford (talk) 12:22, 5 May 2024 (UTC)[reply]
- On a different subject to my previous comment, I'd support eliminating the "Sword of Damocles" provision. The proposal has two petitioning periods, the latter of which (12 months) essentially allows any single editor to unilaterally dangle a Sword of Damocles over an Admin’s head for a year by simply opening a petition page. Aside from how absolutely miserable this sounds for Admins, the unintended consequence of this proposal is that we’ll likely find Admins soon issuing Indefinite blocks against editors with ever increasing frequency to avoid this from happening (not nefariously, of course, but I suspect we’ll see some Pavlovian conditioning occur). For this reason, I suggest we only allow for the 30-day petitioning period and eliminate the longer, 12-month petitioning period. Chetsford (talk) 12:27, 5 May 2024 (UTC)[reply]
  I agree with your assesment here, and I'd prefer we stick with the 30-day period only. Draken Bowser (talk) 13:43, 5 May 2024 (UTC)[reply]
- I don't read German, but it seems that de:Wikipedia:Adminwiederwahl/Intro has listed 50 users within six months since it was created in 2009. isaacl (talk) 19:27, 5 May 2024 (UTC)[reply]
  You are right. During the discussions, I believe @ToBeFree had linked User:ToBeFree/recall as well. I believe I'd misread dewiki criteria while writing 16C, but that should not matter as much as the more relevant "What threshold do we want here?" Soni (talk) 19:33, 5 May 2024 (UTC)[reply]
  ~ ToBeFree (talk) 20:51, 5 May 2024 (UTC)[reply]
We should start the 30 day countdown after the next logged action. As point 3 is currently written, an Admin who is on holiday for a few weeks might find themselves ousted without ever knowing they were being recalled in the first place. Some very minor wordsmithing could (a) require the Admin be notified they’re being recalled, (b) start the 30 day countdown from the point it’s confirmed the Admin is actually online. Chetsford (talk) 12:18, 5 May 2024 (UTC)[reply]
So the current wording is intended to cover this edge case, but perhaps it's too subtle. Point 3 is phrased as Otherwise a bureaucrat can remove their admin rights instead of "will remove", with the expectation that crats will use this discretion in cases like holidays. This would also cover some other edge cases we haven't considered yet.

I personally think more leeway on "When can crats remove bits" but none on "Do they need to RRFA?" is quite better and simpler than try to handle every edgecase from the initial get-go. Soni (talk) 13:26, 5 May 2024 (UTC)[reply]
How about "enough editors that, if all of them had opposed during the RfA, it would have fallen below the discretionary range"? * Pppery * _{it has begun...} 15:28, 5 May 2024 (UTC)[reply]
@Pppery: I feel like that would be unfair to older admins who passed when we had significantly fewer editors, and they therefore passed with less supporters but the same rough level of consensus. QuicoleJR (talk) 16:12, 5 May 2024 (UTC)[reply]
It's not unfair at all. It should be easier to recall older admins. * Pppery * _{it has begun...} 16:35, 5 May 2024 (UTC)[reply]
Why? Should a good admin be able to be subjected to a stressful recall vote by a few butthurt editors simply because of their long tenure? The requirement should be uniform across all admins, since RFA totals are not representative of admin quality. QuicoleJR (talk) 17:00, 5 May 2024 (UTC)[reply]
Because we already know that the community trusts more recently elected admins because of their RfAs. We know nothing about how much community trust ancient admins have in the present day, so it should be easier to ensure they continue to have the same level of trust as more recently-selected ones. * Pppery * _{it has begun...} 17:17, 5 May 2024 (UTC)[reply]
I feel like if an RRFA petition could not hit the threshold, that would be a pretty good indicator that the community doesn't want them desysoped. QuicoleJR (talk) 17:25, 5 May 2024 (UTC)[reply]

Although we would have to decide what to do with old RfAs with no clear support/oppose numbers, people like BradPatrick who never RfAed at all, and cases like RexxS where crats passed below the discretionary range so technically zero or one people would be enough to meet my threshold. Probably all of these can be resolved by specifying a minimum number in addition. * Pppery * _{it has begun...} 16:37, 5 May 2024 (UTC)[reply]

I think that makes it unnecessarily complicated. Why should the numerical outcome of the RfA suddenly become important for all eternity?

Also, this is not very future proof in case RfA changes drastically. —Kusma (talk) 16:51, 5 May 2024 (UTC)[reply]

I've mostly skipped over RFAs that were already trending towards 250-2 blowouts, even if I thought the candidate would make a wonderful admin. Because I was under the impression that my !vote would not make any difference whatsoever. I don't think we should retroactively change the meaning of sitting out an RFA. Suffusion of Yellow (talk) 18:34, 5 May 2024 (UTC)[reply]

Discussions are a sampling of the consensus view at a given time and are dependent on context. I don't think it's a good idea to try to combine the outcomes of two distinct discussions that are separated by a significant period of time. isaacl (talk) 18:48, 5 May 2024 (UTC)[reply]

96 recall votes required for me? Or would votes by previous supporters count twice when now asking for a recall? ~ ToBeFree (talk) 20:57, 5 May 2024 (UTC)[reply]
Any previous supporters would, in my hypothetical which is clearly not getting consensus, be removed from the support tally and added to the oppose tally. * Pppery * _{it has begun...} 21:35, 5 May 2024 (UTC)[reply]
I think something like your proposal could be made more radical and then become an interesting concept that goes beyond the scope of the present discussion: what if we never close RfAs, but instead re-evaluate them once per month? People could continue to add supports and opposes, and whenever some threshold is crossed (in either direction), the community is alerted to this and a new consensus could form. —Kusma (talk) 09:59, 6 May 2024 (UTC)[reply]
This is the ideal type of system in my view: a rolling endorsement system. I press a button that says I endorse X for admin. At any time I can un-press that button. Endorsing would require meeting suffrage requirements and once an editor fails to meet suffrage requirements (like goes inactive), none of their endorsements count. When X gets over 250 (or whatever) endorsements, X gets the bit. Fall below 250 endorsements and X loses the bit. Automatically, no arbs or crats required. So in order to become or remain admins, editors have to be endorsed by some minimum number of editors who meet suffrage requirements. People can discuss and persuade others to endorse/unendorse if they want, people can still campaign for endorsements and answer questions if they want to, or people can just edit normally and one day wake up to find they're an admin (unless they opt out). The endorsements can be public or private depending on what the community wants (there are pros and cons to both). No 7 day public evaluation, nobody has to explain why they do or do not endorse, admin hopefuls just either have the votes or they don't, and you don't even need securepoll. This would require the WMF coding the endorsement system if we wanted it to be automatic, or private, but it could also be done by just signing/unsigning a subpage (crats would still be required). Levivich (talk) 16:04, 6 May 2024 (UTC)[reply]
This sounds horrible. We would have admins lose the bit just because some random editor who endorsed them happened to go inactive. That is not something we want. QuicoleJR (talk) 16:15, 6 May 2024 (UTC)[reply]
Also, most admins probably don't want to be in a permanent state of convincing people to continue their support. RFA is stressful enough, we do not need to make it permanent for every user on the site. QuicoleJR (talk) 16:16, 6 May 2024 (UTC)[reply]

I agree with QuicoleJR that I don't think English Wikipedia is well served by having administrators evaluated publicly and thus concerned about having to attract new supporters. You've previously stated how no organization evaluates its staff in public for anyone to comment; a continuously ongoing voting system is also not something done for staff evaluation. isaacl (talk) 16:42, 6 May 2024 (UTC)[reply]
Comment 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. This is an overestimate of what a RRFA petiton would get insofar as not every editor adding a statement wants a desysop, but its a big underestimate in that the amount of effort it takes to write a statement is much higher than what it takes to add a simple vote. Mach61 16:26, 5 May 2024 (UTC)[reply]
also there's a disincentive to add redundant preliminary statements Mach61 16:27, 5 May 2024 (UTC)[reply]

That's a very good observation. Based on that, it seems like at least 50 in 30 days (and a relatively higher number on one year, if the one year period is even used at all) would not be an unreasonable threshold. Chetsford (talk) 19:39, 5 May 2024 (UTC)[reply]
What happens to the petition at the end of one year if there aren't 50 signers? Is the admin forever immune to recall? Or can a new recall be immediately started, and the same people sign it again? Neither solution seems ideal. Suffusion of Yellow (talk) 18:29, 5 May 2024 (UTC)[reply]
As written, it's a rolling window: within the last 1 year. isaacl (talk) 18:33, 5 May 2024 (UTC)[reply]
In that case, do people get to "bump" their signatures to a later timestamp? (Also not ideal.) Suffusion of Yellow (talk) 18:39, 5 May 2024 (UTC)[reply]
Since the idea is to determine if over a given period of time there is a concern about the trustworthiness of an admin, I think it's reasonable for people to re-affirm that they continue to be concerned. isaacl (talk) 18:42, 5 May 2024 (UTC)[reply]

I would imagine one would only need to re-affirm their concerns after the year is expired on their signature. Easily accomplished by re-signing once the prior had fallen off. microbiologyMarcus ^{[petri dish·growths]} 16:42, 6 May 2024 (UTC)[reply]
Are signers of the petition allowed to give their reasons on the petition page, or it just a straight signature and nothing else? If anything beyond a simple signature is allowed, I can see this turning into a List of reasons why this admin sucks that would rival some off-wiki attack sites. Not to mention the inevitable drama. Suffusion of Yellow (talk) 18:59, 5 May 2024 (UTC)[reply]
This does happen at dewiki, and it does occasionally lead to the administrative removal of (parts of) the explanations given for recall votes. It does additionally lead to "I would support" vote lists on the talk page of many reconfirmation pages. ~ ToBeFree (talk) 21:06, 5 May 2024 (UTC)[reply]

I do not think a discussion ever makes sense on an RRFA petition. Any cross-questioning only leads to a lot more strife than necessary. I'm not sure if that extends to "no reasonings" or "just a statement". I personally think "Just signatures" approach is much more preferable than risk the RRFA request page becoming an "attack page".

That said, it might be good to consider creative solutions to allow "Airing concerns" in a reasonable manner. Only signatures allowed, with editors expected to discuss concerns on User talk and AN? Allowing a single link with signatures, or in edit summaries? I do not expect "Reasoning+Signatures" to remain cordial without heavy moderation, but a side solution may work? Soni (talk) 11:39, 6 May 2024 (UTC)[reply]
There should probably be a procedural safeguard against mass-nominations using this process. For example, you can't do an end run around consensus and have 50 people who think admin activity should be stricter recall all our less active admins. A limit of ~5 concurrent recall requests per extended confirmed user, and/or a rule that every recall be specific to the admin being recalled feels appropriate. Tazerdadog (talk) 04:48, 6 May 2024 (UTC)[reply]
I support the first of those two rules, but the second one seems too vague and unenforceable. QuicoleJR (talk) 16:21, 6 May 2024 (UTC)[reply]

Yup. Suffusion of Yellow (talk) 18:48, 6 May 2024 (UTC)[reply]
We should think about the case where we have parallel arbcom proceedings and an admin recall now. I'd suggest that unless there's a really good reason not to, the arbcom case should go first. If arbcom goes first and declines to desysop, and the community desysops via a recall, that's a check on arbcom and an indicator that no really, they did lose the trust of the community." If the admin goes and passes their recall, and then arbcom desysops, the hope is that arbcom knew something we didn't (e.g. private evidence), otherwise this feels like arbcom overruling the community, which ... isn't great. Tazerdadog (talk) 04:48, 6 May 2024 (UTC)[reply]
Fully agree! The recall petition can accumulate signatures during the ArbCom proceedings, but the actual re-election should occur after ArbCom renders a verdict. Beyond your point about parallel procedures creating conflicting rulings, an ArbCom decision to not desysop could nonetheless produce information cited during a subsequent re-election considered by the wider community. BluePenguin18 🐧 ( 💬 ) 00:28, 7 May 2024 (UTC)[reply]
I'm thinking about the "within 30 days" deadline for admins to open their RRFA. Could a procedure make sense where, after 30 days, their sysop bit is removed, but they can ask to get it back within a certain time (6 months, a year), provided that they then immediately start an RRFA? A bit similar to ArbCom cases being suspended. --rchard2scout (talk) 07:58, 6 May 2024 (UTC)[reply]
Proposal: I'm a firm believer that the 16C idea is good and that the numbers just need to be tweaked. So:
- An RRFA petition needs 40 signatures in 10 days to succeed
  - Rationales are allowed on petition, but are unnecessary. Replies to other petitioners are strictly prohibited, though a "general discussion" section for the petition should probably exist
- If a petition fails to activate a RRFA, that admin cannot be subject to another petition for at first six months, and from then on a year.
- Anyone who supports a petition, even if they retract their support, is barred from supporting or starting another petition against that specific admin for two years. There is no restriction on voting in multiple RRFAs for the same person
- Any admin (uninvolved with the user in question and admin the petition is against) may unilateraly topic ban/page block disruptive users from starting or supporting positions.
Mach61 14:37, 6 May 2024 (UTC)[reply]
I appreciate the proposed conditions seem intended to ensure there are significant concerns about an administrator's actions before a time-limited petition is initiated, by providing disincentives for starting a failed petition. I'm uneasy, though, that the disincentive for supporting a failed petition is too strong, thus preventing the process from proceeding in practice. isaacl (talk) 16:05, 6 May 2024 (UTC)[reply]

Might like to extend that to a full 14 days and drop the re-support timeframe to 6 months or 1 year (no change for re-nominating), but I support the overall proposal. QuicoleJR (talk) 16:19, 6 May 2024 (UTC)[reply]
Noting for clarity that this reply is talking about isaacl's proposal. QuicoleJR (talk) 16:27, 6 May 2024 (UTC)[reply]
Perhaps you mean Mach61's proposal? isaacl (talk) 16:32, 6 May 2024 (UTC)[reply]
Yes, misread the signatures. Thank you. QuicoleJR (talk) 17:18, 6 May 2024 (UTC)[reply]
If I were to tweak this, I'd want to scale the required number of signatories by the size of the user communities; i.e if enwiki has N times as many EC editors as dewiki, then we should require N times as many signatories. But overall, I'd say that the fact that this has been working on dewiki means we shouldn't try to bikeshed the details, and I'm happy to supress my desire to tweak this aspect if it encourages others to supress their tweaking tendencies. If 25 disgruntled users manage to railroad an admin into an RRFA and that admin can't scrape up a 55% majority plus a sympathetic crat chat, then I'm not too worried about the railroading. RoySmith (talk) 14:56, 6 May 2024 (UTC)[reply]

I think I'd be in favor of just X signatures within 30 days, and if it doesn't hit that after 30 days, it's closed, and there is some cooling off period (maybe another 30 days) before someone can initiate another petition. This will eliminate the petition pages being an ongoing "Sword of Damocles" or as I'd call it, a "hate log." I think there should be a discrete beginning, and ending, for any recall petition, and not have it just be a thing that rolls on forever, because I don't think people will want to volunteer for RFA if that comes with your very own "hate log" in perpetuity. Levivich (talk) 19:12, 6 May 2024 (UTC)[reply]

@Chetsford made a similar point above, and I agree with you both. Whereas this one-month format for recall petitions supports decisive action outside ArbCom procedures, a full year of deliberations on an editor's alleged wrongdoings is surely better served with our dedicated panel for arbitration. BluePenguin18 🐧 ( 💬 ) 00:37, 7 May 2024 (UTC)[reply]

Other RFA2024 proposals

How would an RRFA interact with admin elections or another proposal that passed? Soni (talk) 15:06, 2 May 2024 (UTC)[reply]

I think the most interesting edge case I can think of is an admin who chooses to avoid a recall petition by successfully getting re-elected as an administrator privately. is there a strong desire to change that? theleekycauldron (talk • she/her) 10:47, 5 May 2024 (UTC)[reply]

I'm not sure what re-elected "privately" means here. If you mean Admin elections (via Proposal 13), then I am in favour of it being equally acceptable to other ways of gaining adminship. 16C, as written, currently allows for any ways of gaining adminship (RFA/Admin elections) to count for "Cannot be recalled for 12 months" Soni (talk) 10:55, 5 May 2024 (UTC)[reply]

The designated RfA monitors should definitely cover RRfAs. House Blaster (talk · he/him) 19:19, 5 May 2024 (UTC)[reply]

Implementation details

Are there any implementation details an RRFA process should consider Soni (talk) 02:48, 3 May 2024 (UTC)[reply]

Should admins be alerted by to the existence of a reconfirmation subpage by a talk page message so they can decide whether to watch it? Should reconfirmation pages be created for all existing admins immediately, or only when need arises? Also, it should probably be clarified that people may strike their signatures on the request for reconfirmation subpage at any time. —Kusma (talk) 15:42, 2 May 2024 (UTC)[reply]

There should probably be a category of all admin reconfirmation subpages, populated by a template at the top of the page that explains rules and process. —Kusma (talk) 09:42, 5 May 2024 (UTC)[reply]

I had a few ideas:

Are we sure we want the 50 editors/1 year clause? It has the risk of turning into a list of grievances against administrators who work in contentious areas. I think it's better if we stick with one month; obvious cases can be handled through this, but more sustained issues (the kind of things that build up over a year) can go through ArbCom.
Who can strike signatures, clerk, and close the petition? (I would presume only crats for all three.)
Clarify that it should be 30 days/1 year from the opening, not the most recent signature, otherwise petitions risk turning into permathreads.
I would make clear what support/oppose would mean in an RRFA, and whether they should be renamed.

I drafted an example of what these kinds of changes, alongside a few others, could look like in my sandbox. If that's too much change at once, I'm happy to propose it as an alternative when the proposal period opens. Giraffer (talk) 10:11, 5 May 2024 (UTC)[reply]

I think you could make solid arguments against both the 25/month and the 50/year. The former is hotheaded ANI filers, the latter is a buildup of petty grievances. How do we prevent the exigencies of both? theleekycauldron (talk • she/her) 10:52, 5 May 2024 (UTC)[reply]

Raising the number of signatures needed is really the only way to do that. As for the month vs year, I'd still argue that a month with a high threshold is better, because set high enough, the threshold would force the RRFA to be triggered only by a sharp loss of trust. Getting 25 or more people to agree in a month that a user should be desysopped seems pretty difficult. I struggle to see what kind of scenarios would mean that a user should be desysopped under the 50/year clause; all the recent desysops I can think of have been triggered by a single incident, which would fall into the 25/month category. Giraffer (talk) 12:01, 5 May 2024 (UTC)[reply]

I think part of the point here is to allow more desysops in situations that do not rise to Arbcom level. An admin who regularly makes low-profile questionable AfD closes could easily pick up a handful of recall votes per AfD, from different people each time. Perhaps the admin will stop closing contentious AfDs when they have 40 recall voters. Whether that is good or bad depends on the merits of each of these closes. (The provision does not have to be actually used to have an effect). —Kusma (talk) 12:47, 5 May 2024 (UTC)[reply]

Thank you for your proposal, Giraffer. I have two issues:

1. A no consensus outcome would lead to tool removal. Nearly everywhere else on Wikipedia, no consensus means retain the status quo. Now, I have no idea what a "no consensus" close could possibly look like at RRfA, but I feel like it should logically follow the same policy elsewhere on enwiki, which is no consensus = keep the tools.

2. Point 5 is confusingly worded. More importantly, if a "a failed desysop motion at ArbCom" basically gives immunity to RRfAs, this would change the behavior of ArbCom in unintended ways. I think the two processes should be kept separate.

Beyond just this proposal, immunity clauses leave many open questions. Does the first, successful RfA give immunity? What if a new, serious situation arises – could a well-reasoned petition to the 'crats be used to override the immunity period? If we give immunity to the recall process, wouldn't potentially troublesome admins be emboldened to continue controversial behavior? Toadspike (talk) 12:29, 5 May 2024 (UTC)[reply]

The no consensus outcome can be changed to mean the tools are kept. Re point 2, that was an attempt to prevent double jeopardy, where ArbCom declines to desysop an admin over an incident but the community does so anyway. If that's a messy place to go to, I can just remove the clause.

It's worth noting that ArbCom will still have the power to desysop individuals, so anything ineligible for this process can still go through them. The immunity clauses are to prevent flip-flopping over a user's permissions (e.g. someone who disagrees with an RRFA close just filing another one). Being immune to this process shouldn't reduce admin accountability, but remove one way in which an admin can be held accountable, making it essentially the same as how desysops would work now. Giraffer (talk) 09:40, 6 May 2024 (UTC)[reply]

I'd actually prefer the threshold even lower at "preponderance of community sentiment" - crat discretionary zone between 45 and 55% support. This would split the baby on cases where there's no consensus to either maintain the status quo, or default to not having the advanced permission. Tazerdadog (talk) 19:25, 7 May 2024 (UTC)[reply]

@Tazerdadog If the discretionary zone is between 45 and 55, where'd you put the "auto-pass"? Soni (talk) 23:01, 7 May 2024 (UTC)[reply]

@Soni: That would mean an admin would pass their recall without the need for a crat chat at 55% support. The middle of the discretionary range is set at 50% (i.e. where there's no numerical evidence on whether a majority of the community wish to keep the administrator), and a 10% band for bureucrat discretion feels reasonable and in line with previous discretionary ranges. Tazerdadog (talk) 00:07, 8 May 2024 (UTC)[reply]

Does an administrator become INVOLVED with respect to a User who adds their name to the petition to remove? What are the implications of that for administration of the Project? Can a User become immune from all administration? Can a User become a target of other administrators? -- Alanscottwalker (talk) 11:59, 5 May 2024 (UTC)[reply]
Sounds like WP:AVOIDBLOCK: If I start a recall against every admin, I'll never get blocked! Bwahahaha! Toadspike (talk) 12:32, 5 May 2024 (UTC)[reply]
Well, it would not need to be every just admins active or very active in enforcement (or even fewer, just the ones active in your area). Alanscottwalker (talk) 12:47, 5 May 2024 (UTC)[reply]

Admins do not become INVOLVED if someone Opposes them in an RFA. I do not see why RRFAs should be any different Soni (talk) 13:07, 5 May 2024 (UTC)[reply]
Perhaps because a candidate for admin can't be INVOLVED, those conditions can only arise during adminship? Alanscottwalker (talk) 13:57, 5 May 2024 (UTC)[reply]

If I open an ANI thread against admin XYZ, one could reasonably say they're involved with respect to me. If I merely comment on an ANI thread started by someone else, would they be INVOLVEd with respect to me? and if so, for how long?

I don't know the answer to my questions, but I suspect that a recall petition would work similarly. Sincerely, Dilettante 21:18, 5 May 2024 (UTC)[reply]
This may be too far afield for a matter as limited as implementation details, and I don't expect it will be warmly received anyway, but I'd just like to note that, while requiring EC on petitions is a good safety valve, I (a) know there are sock farms that control multiple EC accounts, (b) have recently been made aware of the significant sums of money involved in some paid editing (five figures in one recent case of which I'm personally aware), and (c) know some of these farms would probably like to kneecap Admins active in certain areas.
In my ideal version of this proposal, a recall petition - once reaching the required signatory threshold - would be subject to a CU audit as a final step before start of recall. The CU would have the authority to strike the signatures of any "possible" socks. (Full SPI will still be required prior to blocking.) CU without the more robust investigation of an SPI is not onerous to get around, so I don’t purport that this will solve the risk I describe. It will, however, mitigate it at no cost. While this is not something DE feels necessary to do, I’d just keep in mind that the stakes at DE are a lot lower than at EN. Chetsford (talk) 19:47, 5 May 2024 (UTC)[reply]
+1 Sincerely, Dilettante 20:44, 5 May 2024 (UTC)[reply]

This is a good idea. I'm ignoring the swipe at dewiki near the end, we don't want to start that fight. Toadspike (talk) 09:37, 6 May 2024 (UTC)[reply]
Not intended to be a dig, and I apologize if it came off that way. It's just an observation of the reality that the pecuniary incentives to abusively manipulate EN are, in many cases, significantly higher than those at DE, which is merely a function of traffic and reach versus any measure of relative quality or value. Chetsford (talk) 10:24, 7 May 2024 (UTC)[reply]

The notice of RfA instructions mandate listings at MediaWiki:Watchlist-messages and Template:Centralized discussion, which is how I find out about every election. While I recognize that immediately listing recall petitions here would result in bloat, emerging support for a higher threshold than dewiki necessitates a way to learn about worthwhile recall petitions to build such support. I would support listing recall petitions at these two locations if they reach 50% of the month-based threshold and removing them if the petitions do not succeed within that first month. BluePenguin18 🐧 ( 💬 ) 00:09, 7 May 2024 (UTC)[reply]

Process

In a few days, the open discussion section will be closed for more specific votable proposals (probably 7 days or so?). Is there a preferred structure for that? Soni (talk) 15:06, 2 May 2024 (UTC)[reply]

~~My current plan is for "Open discussion" section to be "closed" after 7 days, and then anyone can add a new proposal. A mockup of that structure is at User:Soni/sandbox3.~~ Soni (talk) 13:17, 5 May 2024 (UTC)[reply]

There are quite a few open questions that could be asked, based on the last couple days. I now favour a more modular structure, and have mocked one up at User:Soni/sandbox4.

This is based on the initial format by Theleekycauldron, and then simplified and added options from Mach61 and @Giraffer's proposals. Please feel free to edit the options for clarity and correctness. Soni (talk) 23:35, 6 May 2024 (UTC)[reply]

Big fan of the modular format, seems like the best way of implementing a close to the effect of "16C is good but needs refinement" Mach61 12:35, 7 May 2024 (UTC)[reply]

Proposals for other RRFA mechanisms

I want to clarify that while I saw a decent amount of support for 16c, and that's why I suggested it as a starting point for this discussion, it didn't gain broad consensus in the first phase. So while tweaking the details of 16c and going with that is certainly an option, it's not the only option. Now that we know the community wants some sort of RRFA, there might be new ideas for how it could be triggered, and I think people should feel free to propose and discuss them here. I also don't see any reason why there can't be more than one triggering mechanism, if multiple proposals find consensus. – Joe (talk) 13:00, 5 May 2024 (UTC)[reply]

Voter eligibility

So only users with Extended Confirmed (30 days + 500 edits) can cast a vote to initiate the RRFA process poll, but then anyone can vote in the actual RRFA? Am I the only one seeing the mismatch in account eligibility between the two steps? OhanaUnited^{Talk page} 14:09, 6 May 2024 (UTC)[reply]

I think that voter eligibility should match RFA when the RRFA actually begins, which I believe would now require voters to be extended confirmed. QuicoleJR (talk) 14:38, 6 May 2024 (UTC)[reply]

General Comments

I'll be absolutely stunned if this process ever gets used. Plus marks though for creating unneeded bureaucracy that will never be used though. Very creative! --Hammersoft (talk) 19:34, 5 May 2024 (UTC)[reply]
Successfully used, ending in a desysop? Perhaps you're right. But I am certain that some of these petitions will be started, if we go with such a system. The below discussion has convinced me that this may not be a good thing, but not having a path to a community desysop at all seems wrong too. Toadspike (talk) 09:34, 6 May 2024 (UTC)[reply]

Prepare to be absolutely stunned. Levivich (talk) 16:10, 6 May 2024 (UTC)[reply]

Hatting off-topic discussion, sorry for the inconvenience. QuicoleJR (talk) 16:38, 6 May 2024 (UTC)[reply]

@Levivich: What do you mean by that? QuicoleJR (talk) 16:23, 6 May 2024 (UTC)[reply]
The probability of this process getting used is 100%. Levivich (talk) 16:24, 6 May 2024 (UTC)[reply]
Are you saying that you plan on using it, or that the chance of it being used or just extremely high in general? QuicoleJR (talk) 16:29, 6 May 2024 (UTC)[reply]
Why are you trying to bait me? Cut it out. Levivich (talk) 16:30, 6 May 2024 (UTC)[reply]
I'm not, I'm just confused by what you said. QuicoleJR (talk) 16:31, 6 May 2024 (UTC)[reply]
If I wanted to announce my intention to start a recall petition, that would be a weird thing to do here, and inappropriate for this discussion. I'm saying it's obvious that the reason there is consensus for admin recall is because people want to recall some admins. Who the admins are or who will start the process doesn't matter. Whether there will actually be a successful recall remains to be seen. But the process will absolutely be used, because people voted for it. Levivich (talk) 16:36, 6 May 2024 (UTC)[reply]

Allow me to clarify; yes, successfully used to desysop. --Hammersoft (talk) 16:29, 6 May 2024 (UTC)[reply]
Ah, that's quite different. I'd put it at 50/50 whether it results in any desysops, it's too hard to estimate given we don't know the details of the system yet. Levivich (talk) 16:32, 6 May 2024 (UTC)[reply]
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. You have got to be kidding me. If you can't drum up enough support to initiate the process in a month, it just stays open forever until you do get enough support? You do know that admins are human beings and maybe might get a little discouraged if there is a page just permanently open, encouraging people to agree that they suck? I'd much rather be dragged before ArbCom than be subject to that level of ongoing attacks. Just Step Sideways ^{from this world ..... today} 20:43, 5 May 2024 (UTC)[reply]
I hope it would get deleted if no-one comments for a year, but the chance of that happening for any active admin is nil. Sincerely, Dilettante 20:50, 5 May 2024 (UTC)[reply]

It's 6 months, not a year, after which each individual comment gets automatically removed. The recall pages at dewiki are permanently open (after the initial year of protection), and they're often used as a place for (negative) feedback (and positive feedback on its talk pages) even if there is no current hope of an actual recall happening. ~ ToBeFree (talk) 21:12, 5 May 2024 (UTC)[reply]
That sounds horrible for the admins, and not like something we want here. QuicoleJR (talk) 21:34, 5 May 2024 (UTC)[reply]

@ToBeFree; it very clearly says a year, not 6 months. @Just Step Sideways; who cares that admins are human beings? The German Wikipedia certainly didn't care, and when they started their de-admin process they lost something like 30% of their admin corps. That's a good thing, right? --Hammersoft (talk) 21:45, 5 May 2024 (UTC)[reply]
I believe ToBeFree was referring to the relevant section from de:Wikipedia:Adminwiederwahl/Intro, Die Wiederwahl kommt zustande, wenn 25 stimmberechtigte Benutzer innerhalb eines Monats oder 50 stimmberechtigte Benutzer innerhalb von sechs Monaten den Antrag unterstützen., which translation tools tell me says "six months". However that's just the rolling window size, which governs when the oldest comments are removed. It does seem to me that as ToBeFree says, the pages are up permanently to collect comments. isaacl (talk) 22:16, 5 May 2024 (UTC)[reply]

@Hammersoft In phase one someone stated the German system was mostly meant to deal with inactive admins. Enwiki's existing inactive admin policy has certainly removed more than 30% of admins over time. Mach61 22:31, 5 May 2024 (UTC)[reply]
No. I am not referring to inactive admins on de.wikipedia. I am referring to their admin recall process which gutted their admin corps. --Hammersoft (talk) 00:21, 6 May 2024 (UTC)[reply]
@Hammersoft What I meant was that, if (I could be wrong) dewiki did not previously have an inactive admins policy, and this system was how they implemented that, a 30% reduction in accounts with the sysop flag is entirely reasonable. Mach61 14:45, 6 May 2024 (UTC)[reply]
Sure. Could be. I don't know. I do know they implemented a de-admin for cause process independent of inactivity, and as a result they gutted their admin corps. When their admins faced the de-admin process, a significant portion of them just quit rather than deal with it. As I noted above, I seriously doubt this process will ever be used to actually desysop someone. But, I do think it will cause a significant portion of admins to simply give up and quit. That's something that's being lost in this process; there's a lot of cattle manure that admins have to deal with. Adding this to the steaming pile isn't going to help. Admins are volunteers. Volunteering to put up with this crap isn't something many admins will want to do. This, in a day and age of declining admins with no hope in sight of reversing the trend. But, if this project wants to shoot itself in both feet, who am I to stand in the way? This whole process has got a nice steamroller going. Maybe the silver lining is that when it's done destroying the admin corps, the project will have to face the reality of a project without anywhere near enough admins. Great stuff! --Hammersoft (talk) 15:43, 6 May 2024 (UTC)[reply]
I'm old enough in wiki-years to have been here for WP:CDARFC. I really cannot see much likelihood of anything getting consensus, once it gets boiled down to actionable specifics. Editors are going to have to come up with clear evidence that any new proposal will fix something that ArbCom is failing to handle – and that it won't create admin roadkill. --Tryptofish (talk) 00:32, 6 May 2024 (UTC)[reply]
If no individual proposal is able to get consensus, what happens? The community already gained consensus to have something, so I'm not sure what we would do if nobody can agree on what the something is. QuicoleJR (talk) 16:41, 6 May 2024 (UTC)[reply]
WP:DESYSOP2019 had a similar outcome in that !voters agreed on the overall principle of recall but not the specifics ... and nothing happened. Sincerely, Dilettante 16:50, 6 May 2024 (UTC)[reply]
Yeah, this is essentially what happens every single time we try to have this conversation, going back a lot further than 2019. I used to strongly support the concept of community-based removal of admins, but it seems every time we discuss it, the solutions get worse than the last round. I finally found myself convinced that ArbCom should just keep doing it. The way to make sure they do it right is to elect people witht a history of making difficult decisions and holding others to account. Just Step Sideways ^{from this world ..... today} 19:16, 6 May 2024 (UTC)[reply]
The community may have (in Phase 1) had some sort of consensus to do some sort of "something", but to go from "something" to a specific proposal requires a further consensus in favor of that specific proposal, which is a lot more difficult than just supporting some general principle. If no individual proposal can get community consensus, then we stick with the status quo. --Tryptofish (talk) 19:42, 6 May 2024 (UTC)[reply]

Initiation procedure

Survey (Initiation procedure)

Discussion (Initiation procedure)

Rolling

Survey (rolling)

Discussion (rolling)

Reconfirmation threshold

Survey (reconfirmation threshold)

Discussion (reconfirmation threshold)

Eligibility to RRFA

Survey (Eligibility to RRFA)

Discussion (Eligibility to RRFA)

Recall Petition Suffrage

Survey (Recall Petition Suffrage)

Discussion (Recall Petition Suffrage)

Striking/Removing signatures

Survey (Striking/Removing signatures)

Discussion (Striking/Removing signatures)

Desysop after Recall petition

Survey (Desysop after Recall petition)

Discussion (Desysop after Recall petition)

Recall petition discussion

Survey (Recall petition discussion)

Discussion (Recall petition discussion)

Reconfirmation by admin elections

Survey (Reconfirmation by admin elections)

Discussion (Reconfirmation by admin elections)

Reconfirmation threshold for admin elections

Survey (reconfirmation threshold for admin elections)

Discussion (reconfirmation threshold for admin elections)

Notifications for petitions

Survey (notifications for petitions)

Discussion (notifications for petitions)

Expired signatures on initiation petitions

Survey (Expired signatures on initiation petitions)

Discussion (Expired signatures on initiation petitions)

Initiator time limit

Survey (Initiator time limit)

Discussion (Initiator time limit)

General Discussion

Confirming Extended Confirmed as Voter Requirement

Dispense with the questions section for an RRfA

Delete RRfA petition after conclusion?

Making the case for need

How will this affect RfA candidacies?

Frequency

Unpopular but correct actions

Related discussion

Open discussion

Tweaks to 16C

Other RFA2024 proposals

Implementation details

Process

Proposals for other RRFA mechanisms

Voter eligibility

General Comments

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.