Jump to content

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

Add links
From Wikipedia, the free encyclopedia
< Wikipedia:Requests for adminship‎ | 2024 review‎ | Phase II

This is an old revision of this page, as edited by Fanfanboy (talk | contribs) at 15:17, 9 May 2024 (→‎Survey (Desysop after Recall petition): Changing vote). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

Status as of 09:46 (UTC), Thursday, 15 August 2024 (update time)

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:

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

Initiation procedure

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. Petitions can be opened but are not rolling
  • 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
  • Something else (specify...)

Note - The word "request" was replaced with petition for consistency with rest of the page.

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]
  • B and E currently, 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]
  • 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]
  • 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]
  • 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 C or D. 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. Neutral on E.-Gadfium (talk) 23:25, 8 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]
  • 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]

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]

Reconfirmation threshold

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)

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]

Eligibility to RRFA

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
  • Something else (specify...)

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

Survey (Eligibility to RRFA)

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]

Recall Petition Suffrage

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
  • Something else (specify...)

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

Survey (Recall Petition Suffrage)

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]

Striking/Removing signatures

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
  • 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)

  • A and C neutral B 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]
  • 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. Chetsford (talk) 17:11, 8 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]

Discussion (Striking/Removing signatures)

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

Desysop after Recall petition

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).
  • 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 > D Fanfanboy (talk) 16:06, 8 May 2024 (UTC)[reply]
  • A.—S Marshall T/C 16:38, 8 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]
  • 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]
  • 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]

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]

Recall petition discussion

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)

Discussion (Recall petition discussion)

Finer points

If there's any implementation details not already covered by the previous sections, please add them here.

Reconfirmation by admin elections

Can an admin stand for reconfirmation via Administrator Elections?

Survey (Reconfirmation by admin elections)

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]

Reconfirmation threshold for admin elections

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)


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]

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]

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]

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

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, ~ LindsayHello 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"? HouseBlaster (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. HouseBlaster (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? OhanaUnitedTalk 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]
  • 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]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Requests_for_adminship/2024_review/Phase_II/Administrator_recall&oldid=1223047697"