Wikipedia:Administrator recall/Reworkshop

This is a page to propose and refine changes to rework Wikipedia:Administrator recall. You can discuss the changes here, but this page is more akin to the idea lab – this is not a voting page. After the reworkshop closes, the proposals will be voted on at an RfC. theleekycauldron (talk • she/her) 00:50, 8 November 2024 (UTC)

This page is divided into subsections centered around potential RfC questions. The collapsed sections at the bottom contain either questions that were determined to not address the root causes of toxicity or questions rendered superfluous by discussion and RfCs elsewhere. If you have a decently fleshed-out draft for an RfC question (meaning you have an idea of the wording and at least a couple options), you are welcome to add the question to this page. If the idea is still gestating, you're encouraged to post it on the talk page for feedback. Sincerely, Dilettante 00:41, 24 November 2024 (UTC)

General process

Independent of the results of the other questions, should administrator recall?

• Option 1: Continue as a petition, with or without modifications (details below)
• Option 2: Be replaced with a consensus-based process (details to be determined in a future discussion)
• Option 3: Be discontinued entirely.

Per below. Sincerely, Dilettante 00:26, 21 November 2024 (UTC)

again, this inherently gives advantage to options 2 and 3 because the modifications to option 1 haven't been made yet. It'd be asking based on blind trust – people should have the opportunity to fix the current process before dumping it or starting over. theleekycauldron (talk • she/her) 03:11, 21 November 2024 (UTC)

I agree with this. I think "Should recall continue" will probably be asked in the future. I do not think it should be now, because it's putting the cart before the horse. We've seen kneejerk reactions meliorate over time as we get more info (See time period RFC). Allowing the modifications to happen without a sword of "Just remove the entire process" is important imo Soni (talk) 05:08, 23 November 2024 (UTC)

• I mean, if it's going to be a consensus-based process, why not just go straight to RRfA? Why have two separate steps at all? If we're going to have a "consensus-based process" as an option, I feel like we have to have "straight to RRfA" as an option, too, since logically that is the consensus-based process - that is, I suggest "Option 4: Recalls take place as a single consensus-base process that merges the current petition and RRfA, and results in immediate de-adminship if closed successfully" (or unsuccessfully, I guess; combining RRfA and the petition into one step makes that language confusing because success / failure mean opposite things for each.) --Aquillion (talk) 17:10, 21 November 2024 (UTC)

  If combined we should not use "success" or "failure" but something like "immediate de-adminship if the re-RFA is withdrawn or does not reach the reconfirmation threshold." Thryduulf (talk) 18:32, 21 November 2024 (UTC)

• Should we merge Options 1 and 2, and add a subquestion along the lines of

  If consensus is found for recall to exist, should the discussion prior to the RRfA take the form of?

  A petition (details determined below)

  A consensus-based process (details to be determined in a future discussion)

• The way I see it is that the pro-recall camp is unfairly split into two groups while the anti-recall group is not. Alternatively, we could require all !voters to rank the three options, instead of merely indicating support for one. Sincerely, Dilettante 18:45, 21 November 2024 (UTC)
• I think the idea of recall is a very good one and I think the entire process we've gone through on this has been valuable and there are a lot of lessons that can be taken out of it. At this point, however, we have an extremely complex process that we're trying to build on top of an even more complex process. The best of our policies are elegant and simple. I support would suggest either Option 3 for now so we can start over from scratch and incorporate the lessons learned from this short trial, or, an Option 4 which would be suspension of the process pending election of a drafting committee of three editors to prepare a short and simple recall proposal for the community's consideration. Chetsford (talk) 21:06, 22 November 2024 (UTC); edited 21:57, 22 November 2024 (UTC)

  @Chetsford this is not an RFC, it is a workshop to develop a future RFC. Supporting or opposing an option is not relevant here. Thryduulf (talk) 21:39, 22 November 2024 (UTC)

  Yes, that's correct. I've edited my word choice for sake of clarification of intent among those whom it confused. Chetsford (talk) 21:57, 22 November 2024 (UTC)

These options represent a false dichotomy trichotomy: either either recall has a petition, or is replaced by a consensus-based process -- which falsely implies the petition process is not a consensus-based process (it is) -- or be discontinued entirely -- which should be an entirely separate question.

The question of whether to have a petition at all, prior to an RRFA, is one question.

The question of whether to have a recall process at all, is a separate question.

Both questions are fine to ask, but not lumped together like this, and the first question shouldn't frame it as "petition or consensus-based" but rather as "petition or no petition".

BTW IMO the obvious answer is going to be "petition" until and unless someone proposes an alternative gatekeeping method for RRFAs. And I predict the chances of recall being scrapped entirely is zero, now that we've had hundreds of people participating in it. Levivich (talk) 21:21, 23 November 2024 (UTC)

Moved from Wikipedia:Administrator recall/Reworkshop § Opening a petition

I also agree. —Alalch E. 23:39, 13 November 2024 (UTC)

+1, c:User:Alexis_Jazz explains the pitfalls of such a system implemented in practice at Commons Mach61 03:25, 14 November 2024 (UTC)

To clarify my comment after it was moved here from another thread: I "agree" (relative to what I was replying to in the original context) that Option 2 is a non-helpful option that shouldn't be included in the RfC. —Alalch E. 11:22, 23 November 2024 (UTC)

Also RfA is a consensus-based process and RRfA is the main part of administrator recall, while the petition is a prelude, so administrator recall is already a consensus-based process. Option 2 is really not worth adding to the RfC. —Alalch E. 12:35, 23 November 2024 (UTC)

+3. Regards, Goldsztajn (talk) 23:01, 23 November 2024 (UTC)

I don't think that three-option question idea is a good idea, because it's asking people whether we should keep recall whether or not we reform it. theleekycauldron (talk • she/her) 09:29, 16 November 2024 (UTC)

Why is asking people whether we should keep recall a bad thing? Thryduulf (talk) 12:03, 16 November 2024 (UTC)

It seems a bit soon...I doubt we'd be asking it if we hadn't had two petitions within days of it becoming policy, but that could represent pent-up demand. I don't object to it in theory, and if we don't create these RfCs for another five months, I'd say it would be worth asking. But right now people are freaking out a little. Valereee (talk) 15:06, 16 November 2024 (UTC)

I agree with Valeree. But, if we end up proposing reforms here that would all but eliminate recalls, in that case it would be better just to ask the real question. RevelationDirect (talk) 23:45, 22 November 2024 (UTC)

+2 ("freaking out"). I would suggest we have a (minimum) 12 month moritorium on any questions that propose deprecating RECALL. Go through this process of "reworking", (hopefully) reach a final consensus on amendments and then (possibly, if still a sizeable demand) have a straight up/down vote for retention/deprecation. Regards, --Goldsztajn (talk) 23:06, 23 November 2024 (UTC)

Rethinking my previous response...asking if it should go away altogether, and deciding that in this huge sprawling mess of an RfC...this just begs someone to come along and say, "You effectively hid this complete overturning of previous consensus within a gigantic sprawling RfC that was presented as being supposed to fix what was wrong with the process. We need this question to be asked as a yes/no in a dedicated widely-advertised RfC." I do not think we should ask this question as part of this RfC. Valereee (talk) 16:50, 24 November 2024 (UTC)

• I think the whole “petition” step should be dropped and the recall process should go straight to RRFA. It’s confusing, needlessly bureaucratic, has no precedent anywhere else, and largely assumes ordinary users lack both the common sense and good faith not to open a recall vexatiously. The only “gatekeeping” should be “don’t use as a first (or even second) resort” and “opening a recall is restricted to long-term users in good standing” (or a more formal definition thereof). Dronebogus (talk) 12:42, 25 November 2024 (UTC)

  @Dronebogus: So then how would a RRFA be initiated? By a single person? Hey man im josh (talk) 14:03, 25 November 2024 (UTC)

  How else? Dronebogus (talk) 14:57, 25 November 2024 (UTC)

  Well...by a group of some size large enough to prevent vexatious initiations of RRfA? Valereee (talk) 15:10, 25 November 2024 (UTC)

  Someone has to initiate that too. Who initiates the initiation process? You could extend this ad absurdum. Dronebogus (talk) 15:12, 25 November 2024 (UTC)

  I get your point, but I'm thinking about how many people -- some with thousands of edits -- come up with silly questions at RfA for no apparent reason other than that we tell them everyone's allowed up to two. I've literally seen people who, when it was pointed out to them that their question has already been answered, respond with, "Oh, I'll try to come up with another question to ask." Like literally finding out they can ask up to two questions makes them start trying to come up with something.

  I mean, I guess we could try directly initiating RRfA...but what if my job just got crazy, or I'm travelling, or I just had a baby, or I'm studying for the bar? I feel like the admin in question needs to be able to schedule it within reason. Do we need a new form, or would the complainant just create Wikipedia:Requests for adminship/Valereee 2 as a blank page that I'd have a month or whatever to officially open? Do we allow questions/supports/opposes/discussion there while I'm trying to come up with nominators, etc.? Valereee (talk) 16:16, 25 November 2024 (UTC)

  Respectfully I think you’re just making up excuses like people at RfA come up with silly questions. The only extraordinary decision-making system we have on Enwiki is ArbCom, and that’s for cases where the problem is exceptionally complex, intractable, and extremely contentious. “Admin1 is abusing their tools as per exhibit A” is not any of those except maybe the last one. We don’t need a novel system to deal with it. Dronebogus (talk) 16:15, 27 November 2024 (UTC)

  I'm sorry that you find the reasonable things that a person would have to consider to be excuses, but these are legitimate points that someone contemplating a run would have to actually consider. As someone who stood and has nominated several people, it's entirely relevant and my and their schedules have been a key point of when to execute the RfAs. Hey man im josh (talk) 16:29, 27 November 2024 (UTC)

  @Dronebogus, I object to the accusation that I'm "making up excuses". Starting off with "Respectfully" does not make that unsupported accusation okay. I'll note that I was actually trying to find a way to see things from your point of view. Valereee (talk) 16:46, 27 November 2024 (UTC)

Option 2 overlaps with Option 3 in § Opposition: Option 3: An opposition signature section should exist. The net of support minus oppose signatures must meet the required number for the petition to pass. (e.g. 1 oppose signature cancels out 1 support signature), i.e. the straw poll concept. It is a proposal to replace the petition with more of a consensus-based process, specifying how, and it therefore not only overlaps but also conflicts with "details to be determined in a future discussion".—Alalch E. 14:26, 26 November 2024 (UTC)

I know this isn't the place to iron out exact details, but I'm not sure I understand even generally how this would work.

Would it be like this?:

• 10:00 AM: 49 For / 25 Against (Net +24)
• 10:01 AM: 50 For / 25 Against (Net +25, it passes and goes to RRFA)
• 10:02 AM: 50 For/ 26 Against (Net +24, but it was already over at 10:01 so this !vote was after the buzzer)

Or would it the buzzer go off after 30 days and we'd look at the spread then? Does an RRFA even happen in this scenario since the real discussion is on the petition so that settles it one place?

Maybe this is all super obvious to others more familiar with admin process, I dunno. RevelationDirect (talk) 00:13, 27 November 2024 (UTC)

*It doesn't work except as a simple petition, it just doesn't, so option A. Easy to implement: put it on a talk page or other subpage of a trusted and active editor who will simply erase anything except signatures, having agreed to do that. You can delete anything on your user pages, you know, and can't be gainsaid.

I mean, you could ask the editor undergoing a petition to initiate reconfirmation (better word than 'recall') if she'd prefer that. She will. Because that is the polite, kind, and efficient way to do it.. Let's be polite, kind, and efficient.

Sure, some editors will go to the editor recall page anyway and opinionate and argue on the merits and argue on the process and argue whether pigs have wings or whatever they want. There would lots of words on the talk page, and drama galore.

There are a couple-few ways to handle that (none quick or easy, but effective), which I can describe if asked. Herostratus (talk) 03:15, 29 November 2024 (UTC)

• We shouldn't put up a vague "consensus-based process (details to be determined in a future discussion)" option. It's not just "details" that are unspecified – the entire thing is unspecified. Those in favor should determine an actual proposal in this workshop. It would be a failure for a workshop like this to put up an option which, if adopted, would require yet another round of re-re-workshop and RfC. Adumbrativus (talk) 22:20, 30 November 2024 (UTC)

  Though personally I don't see anything inherently wrong with having two questions as laid out by Levivich – (1) is there support for a recall process; and (2) do you support a recall process of petition + RfA process, or RfA process only – I'm sensitive to concerns that without indications of a change in consensus from last year's phase 1 discussions, asking for yet another consensus for a recall process is likely to be an inefficient use of community discussion time.

  If there is going to be just one question, then I think it should offer a choice between concrete formats (and commenters can list all of those which they support), and a "restart discussions for another format" option for those who want something else entirely. Most likely, options other than petition + RfA process, or RfA process only aren't going to be as well fleshed out, but it needs to be more than "something consensus-based". isaacl (talk) 23:10, 30 November 2024 (UTC)

Opening a petition

Question 1: Under what circumstances may a petition be opened?

• Option 1: At any time (no change)
• Option 2: Following the closure and archival of either a thread at either one of the administrator noticeboards, or at WP:AARV, concerning the administrator's conduct
• Option 3: Following advance notice to the admin via their talk page
• Option 4: Recall should take place through a non-petition process

This has come up at a few places, including Wikipedia:Requests for comment/Shorten recall petition period. Sincerely, Dilettante 16:47, 8 November 2024 (UTC)

Added option 3. We should probably consider timeframes other than 1 week for 3 and 4 (e.g. 24/48 hours/5 days), maybe ask something like should there be a delay and get people to specify what their preferred one is? Thryduulf (talk) 18:45, 8 November 2024 (UTC)

Splitting into three. IMO five days and one week are similar enough that we risk vote-splitting/the spoiler effect. Same goes for 48 and 24 hours. I couldn't find a way to split into only two while keeping it clear and making immediately following closure an option. Sincerely, Dilettante 21:48, 8 November 2024 (UTC)

I've done copyediting to hopefully make things clearer. I thought about combining questions 2 and 3, but like you I couldn't make it work. Is it worth asking whether the admin should be allowed (but explicitly not required) to waive any delay? Thryduulf (talk) 22:28, 8 November 2024 (UTC)

I feel like WP:NOTBUREAU should and WP:IAR should support this without an RFC. However, I cite IAR much more than most editors, so take my word with a grain of salt. Sincerely, Dilettante 22:46, 8 November 2024 (UTC)

About question 1, the policy says at the top that you should attempt other methods of dispute resolution before a recall petition is initiated, that means that option 1 'At any time' is currently not '(no change)'. Granted it doesn't say when, and following the chain of links recall is now listed as the first option after pure discussion fails, but it's on that vein that I criticized the fact that the petition to recall Fastily was started with an ANI ongoing. – 2804:F1...E3:5F9B (::/32) (talk) 16:12, 9 November 2024 (UTC)

Maybe I said too many unrelated words, so here is fewer:

- Option 1 of Question 1 is not what current policy says (not 'no change'), current policy says to attempt other methods of dispute resolution first.

Do you disagree? – 2804:F1...E3:5F9B (::/32) (talk) 19:51, 9 November 2024 (UTC)

Current policy says other dispute resolution methods should be tried first (and a reasonable interpretation is that the "in most cases" of the preceding sentence also applies). Even if dispute resolution is attempted first there is no current requirement to wait for it to be closed or archived before a petition is begun. This seeks to change that "should, in most cases" to a "must, in all cases", so I think describing option 1 as correct. Thryduulf (talk) 01:13, 10 November 2024 (UTC)

Adding a variant for Option 2, and an option for ditching this entire clunky and unhelpful petition process. ⇒SWATJester ^{Shoot Blues, Tell VileRat!} 05:33, 9 November 2024 (UTC)

@Swatjester: I agree with Dilettante; abolishing recall should be considered after we attempt to fix it. theleekycauldron (talk • she/her) 23:29, 9 November 2024 (UTC)

At which point it will surely be argued in the best of faith "well why didn't you try and abolish it when there was a re-workshopping." And all the wailing and gnashing of teeth about having to do yet *another* RFC on an issue that's siphoned far too much energy and time from far too many people on the project already.⇒SWATJester ^{Shoot Blues, Tell VileRat!} 23:35, 9 November 2024 (UTC)

I've changed the language to "Recall should take place through a non-petition process". If you want to abolish the policy, that should probably happen in a different proposal. theleekycauldron (talk • she/her) 00:06, 10 November 2024 (UTC)

Not helpful.

There were already two RFCs where you could have !voted against it. This seems like forum shopping. Sincerely, Dilettante 17:15, 9 November 2024 (UTC) Kind of ridiculous to make an accusation of forum shopping when you've clearly already noted that I didn't do so at either prior discussion. This seems like a failure to assume good faith. ⇒SWATJester Shoot Blues, Tell VileRat! 23:25, 9 November 2024 (UTC) You're right; an accusation would be ridiculous. Thankfully, when I said "seems like", I only meant there are similarities between one person bringing up a discussion repeatedly at different venues and someone bringing up a discussion at a new venue despite it having taken place previously. Sincerely, Dilettante 00:47, 10 November 2024 (UTC)

I've added an option here to increase the red tape to a more suitable level. I'm finding unclear the wording of 2a and 2b, which read to me as indicating a petition can be opened just because an admin's conduct was discussed at a noticeboard, irrespective of whether there was any proposal to initiate a recall or any consensus against the admin's actions (this might very well be the intent, which I disagree with).

This does add a "petition to petition" step, to characterise it uncharitably. The reasoning is that a noticeboard proposal can gauge interest and support before the full process kicks in, and assess the perceived suitability of a recall petition before just anyone who sees the thread can just open one with no prerequisites. If we retain the 25 signatories requirement, that will usually be a higher raw number to clear than a noticeboard discussion. Folly Mox (talk) 14:57, 13 November 2024 (UTC)

Option 2c is now effectively a consensus to petition to RRFA. That's the kind of red tape I think literally nobody would want, unless the goal is to maximise drama over anything else. If the community really disapproves of the current system to that extent, just cut one middleman, and make it a consensus to RRFA direct. Even that is still better than what your option will end up being

For this reason, I think we're better off workshopping Option 2c or removing it entirely Soni (talk) 17:44, 13 November 2024 (UTC)

On the contrary, I think the lack of barriers to initiating a petition maximises the drama, and I added the option containing precisely the amount of red tape I wanted, but I presume my position is in the minority. Folly Mox (talk) 20:41, 13 November 2024 (UTC)

Should we spell out potential non-petition processes and list them as options, 4a, 4b, etc? My view is that option 4 should be asked at a later date, but if we're asking it now, it certainly shouldn't be so vague and probably shouldn't be tacked on to a largely separate question. Sincerely, Dilettante 18:03, 13 November 2024 (UTC)

Option 4 I think would be best asked as a very broad question at the start of the RFC along the lines of:

Should administrator recall?

• Option 1: Continue as a petition, with or without modifications (details below)
• Option 2: Be replaced with a consensus-based process (details to be determined in a future discussion)
• Option 3: Be discontinued entirely.

As for option 2c, I agree that consensus to hold a petition to hold a re-RFA is too many layers of process. Either it should be Petition → ReRFA or Consensus → ReRFA. Thryduulf (talk) 18:50, 13 November 2024 (UTC)

Moved to Wikipedia:Administrator recall/Reworkshop § General process

I think red tapes serve a very substantive purpose, to allow admins to change their ways if they should, a bit of WP:ROPE for admins. Kenneth Kho (talk) 20:55, 22 November 2024 (UTC)

I've removed option 2c and replaced 2 with 2b. theleekycauldron (talk • she/her) 07:55, 16 November 2024 (UTC)

• Clarifying question: Would option 2 be the equivalent of "clear evidence of attempts to resolve the dispute" that is used as a criterion for Arbcom cases? Risker (talk) 03:38, 20 November 2024 (UTC)

  Assuming you are referring to "Following the closure and archival of either a thread at either one of the administrator noticeboards, or at WP:AARV, concerning the administrator's conduct" then I'd say it's similar to that but not quite the same. As currently worded the requirement would be that the admin's conduct in general must have been discussed at the noticeboard(s), not necessarily the specific dispute(s) and not necessarily with the intent of resolving. We may wish to consider something closer arbcom's wording, but I think the first difference (general conduct vs a specific dispute) is worth keeping. Thryduulf (talk) 03:50, 20 November 2024 (UTC)

• Striking Option 4. If it really needs to be asked, it needs to be asked in its own question. Sincerely, Dilettante 21:17, 20 November 2024 (UTC)

Sigh. And here we go again. Dilettante, if you insist on striking it, can you please go ahead then and ask it in its own question instead? Thryduulf's version of "Should administrator recall..." from 13 November a couple of lines up would suffice, and seems to have some support for being asked (myself, Thryduulf, Alalch, and Mach61 if I'm reading that correctly, with Valereee not objecting). ⇒SWATJester ^{Shoot Blues, Tell VileRat!} 23:46, 20 November 2024 (UTC)

Done. However, I maintain that this is unnecessary since there have been three other RfCs for one to oppose the petition based system, including one where I proposed a consensus-based alternative. Sincerely, Dilettante 00:26, 21 November 2024 (UTC)

Time delay

Question 2: If closure or archival of a discussion is required to start a petition, should there be a minimum amount of time between that action and starting a petition?

• Option 1: No (no change)
• Option 2: Yes, 24 hours
• Option 3: Yes, 48 hours
• Option 4: Yes, 1 week

Question 3: If advance notice is required on the admin's talk page before starting a petition, how long must that notice be?

• Option 1: 24 hours
• Option 2: 48 hours
• Option 3: 1 week

Moving questions 2 and 3 down here. theleekycauldron (talk • she/her) 00:03, 10 November 2024 (UTC)

I don't think merging questions 2 and 3 was helpful - no delay between an "advanced notification" and opening a thread doesn't make sense, but it is a very valid to have no delay following closure/archiving of a noticeboard thread. Thryduulf (talk) 01:29, 10 November 2024 (UTC)

Per my above comment I've split the two questions as we need to have an option for no delay after a thread closure but that does not make sense for an advance notice independent of a discussion thread. Thryduulf (talk) 15:05, 13 November 2024 (UTC)

• I think a week between closing and start of the recall action is a good idea, and allows everyone to cool down after what would no doubt be a heated dispute. There is no emergency here (that's what Arbcom is for). Another week isn't going to blow up the Wiki. Risker (talk) 03:43, 20 November 2024 (UTC)

  Why don’t we add an option of 72 hours on there? Although if the administrator is obviously on a vacation or a break (provided that the break is of a reasonable time); the petition shouldn’t be started until X amount of time after said break is over. Hurricane Clyde 🌀^{my talk page!} 23:14, 20 November 2024 (UTC)

  Throughout these discussions there's been some suggestions to slow things down to avoid hastiness and others to speed things up to avoid unecessary stress for the recalled admin. I don't know where that golden middle is at, but just noting that tension. RevelationDirect (talk) 17:34, 25 November 2024 (UTC)

Simplifying the original question:

Question 1: May a petition be initiated for any reason?

• Option 1: For any reason (no change)
• Option 2: Only if the administrator is alleged to misused the administrative tools or has failed to behave in a respectful, civil manner
• Option 3: Only if the administrator is alleged to misused the administrative tools or has failed to behave in a respectful, civil manner and a discussion has closed or archived at WP:AARV or one of the administrator noticeboards?

I believe that this revised question gets to the core question is if a petition can be opened for any reason or only for specific reasons. --Enos733 (talk) 16:26, 22 November 2024 (UTC)

Its useful a question to ask, but not the same question as above. The core of your question is about why a petition may be initiated, while the original question is procedural about what prior discussions and/or notifications must occur prior to opening a petition. Thryduulf (talk) 16:45, 22 November 2024 (UTC)

Option 1 is not the status quo for it to be marked as "no change". WP:RECALL says: Any extended confirmed editor may start a petition for an administrator to make a re-request for adminship if they believe that the administrator has lost the trust of the community. That's not "any reason". The reason is clearly stated. —Alalch E. 11:27, 23 November 2024 (UTC)

As the person who wrote that, I think your interpretation is incorrect. That's one possible reason to initiate it. One many also initiate it if they believe the administrator should not have the trust of the community, may or may not have the trust of the community, or is otherwise seriously concerned that non-arbcom processes have failed to handle tool misuse. Sincerely, Dilettante 16:59, 23 November 2024 (UTC)

• I've tweaked question 2 to use "discussion" rather than "thread" as I think that's clearer. Thryduulf (talk) 20:37, 24 November 2024 (UTC)

Number of editors

How many signing editors are required to trigger a reconfirmation RfA?

• Option A: 10 editors
• Option B: 25 editors (no change)
• Option C: 50 editors
• Option D: 100 editors
• Something else (specify)

Struck out options
The following discussion has been closed. Please do not modify it.
Option 3: 10 editors who are uninvolved with the admin. Involved editors may comment on the petition but not formally sign them. * Option 3: An equal number to the amount that supported the editor's most recent RfA? Option 4: An equal number to the total amount that participated in the editor's most recent RfA? Option 6: 100 editors OR an equal number to the total amount that participated in the editor’s most recent RfA or administrator election; whichever is higher.

I will say: one of the hazards of these first two is that I'd probably support changing to 50 editors/2 weeks, but would rather 25 editors/1 week to 25 editors/2 weeks or 50 editors/1 week. So in that way, they're not really independent. theleekycauldron (talk • she/her) 00:50, 8 November 2024 (UTC)

Option 1 (the status quo) is okay IMO. Miniapolis 22:17, 8 November 2024 (UTC)

This is not an RFC or the place to express opinions about which option you prefer. We're just drafting the RFC. Thryduulf (talk) 22:35, 8 November 2024 (UTC)

Maybe combine this with the time question, like it was in the original proposal? HouseBlaster (talk • he/they) 03:29, 9 November 2024 (UTC)

Adding two additional options on the premise that the bar for desysopping someone this way should require more attention than their original sysopping got.⇒SWATJester ^{Shoot Blues, Tell VileRat!} 05:28, 9 November 2024 (UTC)

Clearly involved here as a 2007-era admin, but options 3 and 4 are going to be much easier to obtain for RfAs prior to current watchlist notice (which might be an intended feature?), and the recent admin election produced off-the-scale voter numbers compared with the RfA process but with reduced individual scrutiny. Espresso Addict (talk) 15:15, 9 November 2024 (UTC)

Indeed. Assume that I (passed RFA in 2005 with 57 support, 2 oppose, 1 neutral) and Queen of Hearts (passed AELECT this month with 389 supportm 105 oppose, 122 neutral) did the exact same thing. Is it reflective of the seriousness of that thing that I can be recalled with 57 or 60 signatories but QoH would need 389 or 616 signatories? Say we did different things, the petition against me attracts 70 signatories, QoH's attracts 200 signatories in the same time period. That indicates that more of the community have a problem with QOH's actions than with mine, but I am the only one facing recall. Note: This is purely hypothetical, I'm explicitly not accusing QoH of having done anything.

Unless this is somehow normalised to reflect the average number of supporters or participants around the time the admin gained the tools (and I don't know how you can do that with elected admins until we've had several elections) this simply wouldn't scale. Thryduulf (talk) 01:01, 10 November 2024 (UTC)

I'm not sure entirely the best answer here, but to answer the question, yes -- I believe that users who were sysopped with a certain level of consensus should require an at least equal degree of consensus to be desysopped; as a result, by extension yes, I think the required consensus to desysop shouldn't be equal among administrators, but should be reflective of the relative difference in their initial support. The question that a petition is trying to resolve is not whether admin X is more trustworthy than admin Y; the question is whether the consensus for editor X to be an admin has shifted from what it used to be. So yes, in practice, I think someone who was sysopped from a consensus of 389 supports should have a higher bar for desysopping than someone who passed with only 57 supports (or to use myself as an example, I think it's absolutely fair that it be 4x harder to desysop QoH than it would be to desysop me). ⇒SWATJester ^{Shoot Blues, Tell VileRat!} 04:47, 10 November 2024 (UTC)

Ok... I sort of feel the fact that I've adminned on and off for 17 years now without generating significant drama should count in my favour? Espresso Addict (talk) 07:16, 10 November 2024 (UTC)

This also does bias in favor of the EFA candidates; it only took one election to produce more WP:RFX300 candidates than two decades of RfA. theleekycauldron (talk • she/her) 07:44, 10 November 2024 (UTC)

Yes, I am also in favour of just skipping Options 3 and 4. Both seem to be pretty fringe and we're trying to avoid presenting too many options this workshop phase. Soni (talk) 08:54, 10 November 2024 (UTC)

The question that a petition is trying to resolve is not whether admin X is more trustworthy than admin Y; the question is whether the consensus for editor X to be an admin has shifted from what it used to be. I thought the question recall was asking was: "Should the admin have to demonstrate that there is still consensus for them to be an administrator?" which is independent of the raw number of supporters/participants in their RFA. Note that per User:NoSeptember/RfA voting records#2005 and earlier my June 2005 RFA which had 60 !votes was the 10th most attended RFA ever at the time and came less than a month after Bishonen became the first person to receive over 100 participants in their RFA. User:NoSeptember/Zzyzx11 50 vote list notes that in May 2005 there were only 14 RFAs with more than 50 participants, Wikipedia:Requests for adminship/Little Mountain 5 in April 2014 was the last completed RFA to receive fewer than 100 participants. There has not been a successful request for adminship with fewer than 100 supporters since April 2020. Does Significa liberdade passing RFA with 84% of 205 participants supporting in 2024 really indicate stronger support for their adminship than Bishonen passing with 98% of 114 participants in 2005? Thryduulf (talk) 15:12, 10 November 2024 (UTC)

Yes, it indicates exactly that. A consensus of 172 (or 205) people indicates stronger support than a consensus of 111 or 114 people. In order to know whether a consensus has shifted you have to evaluate that against where it stood in the first place. ⇒SWATJester ^{Shoot Blues, Tell VileRat!} 01:08, 20 November 2024 (UTC)

Getting over 100 supports in an era when 80 participants total is the norm and nobody has ever been more supported in the history of the project, is much stronger support than getting 170 supports in an era when 200 supports are not uncommon. I don't think you are listening to anybody else. Thryduulf (talk) 01:56, 20 November 2024 (UTC)

Striking options 3 and 4 per discussion. theleekycauldron (talk • she/her) 07:54, 16 November 2024 (UTC)

I don't see any consensus for striking. Unstriking per my comment below, and I'm going to ask for now the *third* time for individuals to stop arbitrarily striking options they disagree with. This should be for the voters to decide. Nobody is harmed by there being 4 options instead of 2. ⇒SWATJester ^{Shoot Blues, Tell VileRat!} 01:04, 20 November 2024 (UTC)

I see nobody other than you thinking those options are useful. I encourage re-striking to avoid wasting the community time and energy on options that have no chance of passing but reduce the chances of getting consensus. Inclusion is not harmless. Thryduulf (talk) 01:59, 20 November 2024 (UTC)

As theleekycauldron says, this should be decided after the duration is determined. The count can be greater if the duration is longer. Zero^talk 12:28, 10 November 2024 (UTC)

I also find this question not to be useful in general. —Alalch E. 12:24, 16 November 2024 (UTC)

I think that's where a number of us disagree. Quite a few people, at least from what I've seen, do believe the threshold should be raised, which means it's a useful conversation worth having. Hey man im josh (talk) 18:45, 20 November 2024 (UTC)

• Looking at this, I wonder why we aren't looking for 100 signatures. I realize that this is modeled after other projects, but no other project has a community as large and active as English Wikipedia. Proportionally, we should have a much higher number of signatures required than a project that has 5000 monthly editors. It's pretty clear that it only takes one or two missteps by an admin to be able to round up 25 people who are unhappy. Risker (talk) 00:37, 20 November 2024 (UTC)

  I know, 25 in 30 days is kind of low. When you have 100K+ edits, it's not hard for someone to cherry pick a few edits and piece a case together. And then when the recall is "successful", voters at RfA see that and it makes them a little preconditioned towards opposing. ~WikiOriginal-9~ (talk) 00:54, 20 November 2024 (UTC)

  I'd note that my suggested Option 3 and Option 4 would in the vast majority of cases equate to that 100+ signatures requirement, or more. As such, I'm unstriking them. Let the people vote on it. Insufficient participation is part of the reason we got into this shitshow of a mess in the first place. ⇒SWATJester ^{Shoot Blues, Tell VileRat!} 01:00, 20 November 2024 (UTC)

  Swatjester, how about changing that to a hard number like 100? I mean....there are tons of admins who had less than 20 people commenting on their RFA. They shouldn't be subject to that kind of jeopardy. Risker (talk) 02:15, 20 November 2024 (UTC)

  I still think there's value in having an option that directly represents overcoming the consensus that supported adminship in the first place; and I don't think there's harm in having a variety of options for the community to choose from. But in the interest of compromise I'll *self* strike options 3 and 4 for now and add Risker's suggestion as option 5. ⇒SWATJester ^{Shoot Blues, Tell VileRat!} 02:54, 20 November 2024 (UTC)

  I understand where you're coming from, Swatjester. At the same time, consensus can change. In a different sphere, we wouldn't close another type of "discussion" using the previous result simply because there weren't the same number of people participating. Risker (talk) 03:15, 20 November 2024 (UTC)

  I think if there are 100 editors who will register their concerns within a tight timeframe, then the scenario is one that an arbitration case request can cover. For the administrator recall process to be effective, it has to address some shortcoming of the arbitration route. isaacl (talk) 20:28, 20 November 2024 (UTC)

  You're hitting on exactly the structural flaw with the recall process: in order for it to be effective, as you say, it has to provide something that arbitration doesn't, which presumes there was a shortcoming of the rarely-used arbitration route to begin with. But nobody's approaching it that way, that I can tell at least. ⇒SWATJester ^{Shoot Blues, Tell VileRat!} 20:56, 20 November 2024 (UTC)

  100 signatures is pretty close to the amount of oppose votes required for a RRfA to fail. Given that a RRfA is extremely well-advertised, while a recall petition isn't, and furthermore that the recall petition should be a thresholding (showing that a RRfA is reasonable, rather than that it will certainly fail), asking for the same amount of signatures is way too much. Chaotic Enby (talk · contribs) 13:02, 22 November 2024 (UTC)

I get that this discussion is to frame options rather than to make final decisions, but it's striking that all of the alternatives are higher than the status quo and there's no proposal to, say, lower to 10 editors. If the three options are 25, 50, and a 100, fifty might seem like the moderate one but that's only because of the framing here.

If the 2nd petition had reached an RFFA, I'm not sure how I would have voted but neither one seemed frivolous to me. What problem is raising the petition threshold meant to fix? RevelationDirect (talk) 11:36, 20 November 2024 (UTC)

No one has proposed 10 as an option from what I'm aware of because it's pretty clear that that threshold is far too low to be reasonable. Hey man im josh (talk) 18:40, 20 November 2024 (UTC)

I'm not sure if it's "pretty clear" that the threshold is far too low, but I do agree with the sentiment that it should probably not be reduced further. The threshold felt just right to me, but we're already going to actual discussion territory now. Probably just easier to note that not enough people significantly want 10 (or a lower number) and that's sufficient to not include the option Soni (talk) 19:18, 20 November 2024 (UTC)

I think we need to be aware of Anchoring effect. I'd certainly vote that it shouldn't be lowered, as both petitions so far reached their threshhold within days, but when we provide numbers, and one end of the range is the status quo, we're leading people to the conclusion that the number is in some way an extreme and should be moved in the opposite direction, and possibly should move toward the apparent center. So 25-50-100 directs people to 50. Valereee (talk) 13:34, 21 November 2024 (UTC)

I agree that we'd need equivalent numbers on the lower side to avoid the anchoring effect. To keep nice round numbers, maybe 10-15-25-50-100? Chaotic Enby (talk · contribs) 12:59, 22 November 2024 (UTC)

It's striking because it's a handful of admins trying to make the bar to recall fellow admins higher. ~~ Jessintime (talk) 19:23, 20 November 2024 (UTC)

What's striking is the assumptions of bad faith when admins want to participate in the discussion and actually have an opinion on the matter. Hey man im josh (talk) 19:46, 20 November 2024 (UTC)

We're all friends here. Let's try to reframe this... RevelationDirect (talk) 20:51, 20 November 2024 (UTC)

Let's try again: it's striking because a handful of editors are trying trying to make the bar to recall fellow admins higher in good faith because they sincerely believe the current process is so easy that it's counterproductive. (Glad to reword further to fairly capture that viewpoint.) There's nothing wrong with that perspective or suggesting changes based on that perspective, but that is a source of controversy that at least some editors, myself included, respectfully disagree with. - RevelationDirect (talk) 21:02, 20 November 2024 (UTC)

As someone who joined this conversation not knowing that recalls being out of control was an assumed perspective, this page is a little jarring because good faith suggestions to make the process easier through process improvements are intermingled with good faith suggestions to make the process harder by discouraging it to be used at all.

I'm not going to suggest that any of these proposals shouldn't be considered. But I think it makes sense to create two overarching sections to this reworkshop: "process cleanup" and "raising the bar", or some better labels, to distinguish between those related goals. RevelationDirect (talk) 21:22, 20 November 2024 (UTC)

What about this? Let’s set the limit as one half of the total number of editors who participated in the last RFA (or one-half of the total number of people who voted in their administrator election); OR, at least 50 signatures; whichever is higher. Hurricane Clyde 🌀^{my talk page!} 23:05, 20 November 2024 (UTC)

But why? Why would anything like option 6 even be useful?

As option 6 is written now: 250 participated at mine, so I'd need 125. Risker would need 100, because fewer than 150 participated, which wasn't unusual in 2008. How is it useful -- or remotely fair -- to require more for me than for Risker? And if we're including the recently elected admins, 659 participated, so half that is 329, more than for me and Risker put together, and frankly would end up at WP:300, that's how unusual that number would be. What could possibly be the value in making this so complicated and also unfair? Valereee (talk) 13:26, 21 November 2024 (UTC)

I’ll strike it out. I didn’t realize there were that many. Hurricane Clyde 🌀^{my talk page!} 13:33, 21 November 2024 (UTC)

Besides @Valereee, I’m now more interested in @Aquillion‘s proposal. Hurricane Clyde 🌀^{my talk page!} 13:35, 21 November 2024 (UTC)

Although maybe raise it to 20 or 25 instead of ten. Hurricane Clyde 🌀^{my talk page!} 13:36, 21 November 2024 (UTC)

You've got it right, RevelationDirect. When I look at the parallel processes from other Wikipedias, the first thing that strikes me is that the numbers we're talking about for enwiki aren't very far from what they are in these other projects. Okay, but...we have 38,000 monthly active editors. The next closest is 6,000 (French and German). The French system is radically different from this one (it requires 6 independent "contestations" in a given period to trigger recall), and the German system has three possible routes, the most urgent of which involves administrator input only. On the majority of projects with an admin recall process, there's not an Arbcom with the authority to remove adminship, so there is no alternative path to removing an administrator. I keep coming back to there being more than 6 times the number of active editors on English Wikipedia than the next closest Wikipedia with a similar process, and looking at the numbers there and wondering why we'd think that 25 editors (which matches the German "general concern" type de-admin process) is suitable for our masively larger community. I'll note that almost every other project has built-in "delay" points in their processes; in several cases they are explicitly to permit the subject admin to respond, or to give thought to whether or not to proceed direct to a re-RFA.

And there's another point. The RFA process varies pretty widely, too. On most projects, they never had the concept of !vote - they were always clear that it really is a vote, and that only support or oppose are options. Discussion isn't permitted at all on some of those projects, and on others only a brief comment with one vote (nobody gets to comment on others' votes). Most do not allow questions for candidates, either. So...our process to get the bits in the first place is much more complicated. I have asked friends from other projects about their RFAs, and they generally found them to be only a tiny bit stressful, and often only looked at them once or twice a day.

I agree that there is a real benefit to having a community-based process for de-adminship. But it needs to go hand-in-hand with the ability to retain current administrators and develop new ones, and to ensure that there are sufficient administrators to carry out the admin tasks that we have. So yes, I do think that the bar should be comparable on our project to other projects; that means it should be probably 5 times higher in supporting a de-adminship than we see in other projects, so anywhere from 50 to 150 depending on the comparator. Seriously, any admin who's worked in a controversial area can probably name the first 25 people who'd sign up to have them desysopped. Risker (talk) 00:19, 21 November 2024 (UTC)

I'm inclined to agree that we should at least consider options that emphasize the idea that starting a RRfA should not be hard and that the sole standard ought to be "is this non-frivolous?" With that in mind, a proposal: Only 10 signatures are needed, but they must be from editors that are WP:UNINVOLVED with regards to the admin in question, held to the highest possible standard of uninvolvement; in this case, unlike others, even interactions in a purely administrative capacity are considered to constitute involvement. The person creating the petition is not required to be uninvolved but if they're not then ofc they can't sign. This answers the main objection above (that any admin will accumulate enemies just by admin-ing), while emphasizing the fact that the petition stage is not meant to be a big deal or a difficult threshold for any remotely serious recall attempt, and that the fixation on it or attempts to add additional red tape to it are therefore misguided. (I see that this has been discussed and rejected below, but I think that lowering the overall threshold resolves most objections - a rogue admin could in theory try to abuse their power to render people unable to sign by starting conflicts with them, but with such a low threshold it feels like they would just be WP:ROPEing themselves by making their corruption more obvious, since with a 10-person threshold stopping a valid recall attempt in the petition stage is no longer viable. I think that an admin who attempted that would find their actions rapidly creating more opposition to them than they could deal with.) --Aquillion (talk) 05:06, 21 November 2024 (UTC)

One question to @Aquillion: would there be any other requirement for a signature? other than no involvement? Hurricane Clyde 🌀^{my talk page!} 06:34, 21 November 2024 (UTC)

That being; would there be any other requirement that an editor must meet in order to post a signature. Hurricane Clyde 🌀^{my talk page!} 06:35, 21 November 2024 (UTC)

I wasn't thinking of any, but we could always workshop some. One advantage to a lower standard is that we can combine it with more strict requirements. --Aquillion (talk) 17:06, 21 November 2024 (UTC)

I’d be open to that proposal. Not sure whether or not it should be ten signatures or maybe a slightly higher number (like say fifteen or twenty). Hurricane Clyde 🌀^{my talk page!} 17:12, 21 November 2024 (UTC)

But I think there should be a provision in there that stipulates that any confrontation during the petition stage (on the part of the admin) should not constitute “involvement” (on the part of the signer); in other words, solving the hangman rope problem. Hurricane Clyde 🌀^{my talk page!} 17:14, 21 November 2024 (UTC)

Yes, if we require signatories to be uninvolved with the admin it needs to be specified that this means they were uninvolved at the timestamp of their signature. A signature doesn't become invalid due to the signature or you subsequently become involved in something elsewhere on the project. Thryduulf (talk) 18:34, 21 November 2024 (UTC)

• Option 7: 10 EC editors within one year of a successful RfA or election; thereafter, a number of EC editors equal to TBD% of all EC editors at the time the petition is initiated (today that would be 73 if 0.1% or 146 if 0.2%).
  The intent here is to establish a "probationary" period -- within one year of a successful RfA it remains relatively easy to recall an Admin so that issues that become quickly apparent can be immediately rectified. Thereafter, a moderate degree of difficulty is introduced as deterrence against gaming or the accumulation of complex, long-term grudges. (And no, this does not mitigate the potential that a bad actor will "lay low" for a year and then go insane, or any number of other exotic scenarios.) Chetsford (talk) 20:19, 22 November 2024 (UTC)

  Umm no. Let’s do a round number that goes up after a while. Like increasing it to 15, 20, 25, etc. Hurricane Clyde 🌀^{my talk page!} 20:25, 22 November 2024 (UTC)

  But I agree that they need to be EC. They should also be uninvolved as well in order to sign (but not necessarily start) a petition. Hurricane Clyde 🌀^{my talk page!} 20:26, 22 November 2024 (UTC)

  Will ping @Chetsford so that they can read it. Hurricane Clyde 🌀^{my talk page!} 20:27, 22 November 2024 (UTC)

  But the probationary period idea is a very good idea. Hurricane Clyde 🌀^{my talk page!} 20:29, 22 November 2024 (UTC)

  That's fine, too. I'm not sure I'd support increasing the threshold every single year (i.e. 10, 20, 40, 80, etc.) as that introduces a level of complexity that, itself, might be a deterrent to petitioners. But I'd be fine with a simple, two-level system (i.e. 10 in the first year, 100 after the first year or whatever [I'm not suggesting those specific numbers, just putting them as placeholders]). Chetsford (talk) 20:30, 22 November 2024 (UTC)

  I also wasn’t suggesting doubling the numbers either. Maybe increase by a further 10 or 25 editors each year up to a certain cap (like say 50 or 100). Hurricane Clyde 🌀^{my talk page!} 20:32, 22 November 2024 (UTC)

Struck the uninvolved editors option. Adding the requirement that signatories or some of them be uninvolved was discussed in more depth and was rejected as a question earlier on this very page, due to problematic implications regarding questionable incentives, see § Requisite support of uninvolved editors; ping S Marshall—Alalch E. 11:32, 23 November 2024 (UTC)

• Risker's comments about numbers address the reality. It was obviously not intended that Arbcom's mandate be traded for a version of ANI with a potential for personal vendettas to influence recalls or for groups to organize "witch hunts" against administrators perceived as overly authoritative or policing. The danger is in voting with or without reasoning and the RfA style of incentive to pile-on. This emphasizes the importance of investigating the possibility of requiring a high threshold of community support for recall actions as one of the main questions to be discussed. It should take into account the differences in scale and the participation culture of users from the German language region, with its different cultural trends in voter turn-out in decision-making (Meinungsbild, RfA etc.) and which are not compatible here. Thus aiming for probably 5 times higher sounds appropriate. Kudpung กุดผึ้ง (talk) 22:19, 23 November 2024 (UTC)

  We should still have some kind of probationary period where it is easier to recall an admin (like say within the first 6 to 12 months); and then increase the threshold progressively. That way; a rogue admin can still be recalled easily early on; but at the same time, avoiding the witch hunt problem. Hurricane Clyde 🌀^{my talk page!} 23:22, 23 November 2024 (UTC)

  Huh, I'm much more worried about long-term admins who lost touch with current community standards. I appreciate your different perspective. RevelationDirect (talk) 20:17, 24 November 2024 (UTC)

  Some editors think that being able to more easily remove an editor's administrative privileges would encourage the community to grant the privileges more freely. (The only way to really know is to try it out, though, which is currently happening.) isaacl (talk) 20:23, 24 November 2024 (UTC)

• Strong preference for option 1. People don't take signing these petitions lightly and 25 experienced editors having significant concerns is a massive red flag where an RRfA would be warranted imo. Clovermoss🍀 (talk) 20:09, 24 November 2024 (UTC)

  @Clovermoss this is not an RFC, it is workshopping a future RFC. Supporting or opposing any individual option is meaningless. Thryduulf (talk) 20:19, 24 November 2024 (UTC)

  I am aware, but that is indeed my perspective and my justification for why. Options were included at the top, afterall. Clovermoss🍀 (talk) 20:20, 24 November 2024 (UTC)

  The options are included at the top because we're workshopping which will appear in the RFC. Your perspective and justification for why you prefer or don't prefer any option are irrelevant here. Thryduulf (talk) 20:35, 24 November 2024 (UTC)

  I think I understand what you mean now. I will keep that in mind for the future. I suppose I see RfCs by their very nature as including these things and that a pre-RFC process would just focus more on that discussion aspect. I really do think our RFC page should be more clear about these things. As it stands, it doesn't explain what a workshop is at all. Clovermoss🍀 (talk) 20:40, 24 November 2024 (UTC)

  The issue here is whether we want to make it easier or harder to initiate a recall election. The petition was intended to provide a hurdle, and 25 signatures is a significant hurdle. Ten might be better. Making it higher defeats the purpose of holding admins accountable. Hawkeye7 (discuss) 20:49, 24 November 2024 (UTC)

  10 editors has been expressed enough times in this discussion that I'm convinced it should appear in the RFC at least. Adding it as an option explicitly. Soni (talk) 21:33, 24 November 2024 (UTC)

  Agreed, it also reduces the anchoring issues mentioned elsewhere. Thryduulf (talk) 01:25, 25 November 2024 (UTC)

  The problem would be on how to make sure that vandals, sockpuppets, and long term abusers, etc. Don’t end up getting an admin recalled for blocking them (like you’re you know supposed to do). So there’s got to be some kind safety net to try to prevent that from happening.

  Because you’re going to have people like for example Andrew5 (an LTA that was globally banned earlier this month), and other bad actors who would use this mechanism for nefarious reasons. That’s why I think we should at least require that the editor be extended confirmed BEFORE signing; maybe even EC-protect the petition page to enforce it, should it be posted as a requirement. Hurricane Clyde 🌀^{my talk page!} 02:18, 25 November 2024 (UTC)

  Extended confirmed status is already a requirement with the current process. isaacl (talk) 04:02, 25 November 2024 (UTC)

  Well it needs to stay that way. They should have to EC to start a petition and they should have to be EC to put their John Hancock on it. That’s my opinion. Hurricane Clyde 🌀^{my talk page!} 04:21, 25 November 2024 (UTC)

  That is the current requirement and there have been no proposals to change that. Thryduulf (talk) 04:58, 25 November 2024 (UTC)

Opposition

Should expressing formal opposition to the petition be allowed, and in what manner?

• Option 1: No change from current process (e.g. not expressly disallowed, but no provision for it exists).
• Option 2: Expressly disallowed
• Option 3: An opposition signature section should exist. The net of support minus oppose signatures must meet the required number for the petition to pass. (e.g. 1 oppose signature cancels out 1 support signature).
• Option 4: An opposition signature section should exist. Opposition may be registered by signature only, with no additional discussion. It has no operative effect on the required number of signatures for the petition to pass.
• Option 4b: (Contingent on a discussion section existing) Opposition may be registered in the discussion section only. It has no operative effect on the number of signatures required for the petition to pass.

I think options 3 and 4 should have the same explanation policy as #Explanation of signatures. Aaron Liu (talk) 18:03, 16 November 2024 (UTC)

That should be implicitly the case for those two already. Whatever gets decided on that explanation of signatures section would be applicable to any opposition signature section too (though not for 4b as that'd be a discussion section, not a signature section). ⇒SWATJester ^{Shoot Blues, Tell VileRat!} 19:51, 16 November 2024 (UTC)

3 just seems to be a run of RRFA without it being RRFA. --Super Goku V (talk) 04:12, 17 November 2024 (UTC)

4b: I think opposition signatures should be allowed, but only in a general discussion area; and it also shouldn’t count against support signatures (eg: the petition can still pass with 25 support signatures even if 50 oppose signatures exist). Hurricane Clyde 🌀^{my talk page!} 22:50, 20 November 2024 (UTC)

Hurricane Clyde, note that this the drafting for an RfC, not an RfC itself, so !voting has no meaning. The point is to discuss which options should be listed, not which options we like. Sincerely, Dilettante 23:01, 20 November 2024 (UTC)

Either way @Dilettante, there should (in my opinion), be some kind of mechanism for an editor (other than the admin in question) to express their opposition in some way. But I don’t think it should have a direct bearing on the results of the petition. In other words; any opposition signatures would be treated as neutral; rather than canceling out a signature. Hurricane Clyde 🌀^{my talk page!} 23:12, 20 November 2024 (UTC)

Then why just summarize the option? All you're doing is clogging an overlong page. Sincerely, Dilettante 23:14, 20 November 2024 (UTC)

I feel like 3 would be best here. Expressing opposition should definitely be allowed, since it's necessary to come to a consensus. Option 3 would let people discuss it most easily. Even though allowing opposition is going to make this process more chaotic, the main reason why we had that discussion about proposals for changing RfA a few months ago was because the RfA process caused a lot of stress for the candidates, and the current recall system's setup only exacerbates that, since essentially, the only consensus that can be reached is that an admin should be desysoped. A certain number of signatures alone shouldn't be enough to recall an admin, since if only support can be taken into account, it inaccurately depicts the opinion of the community. That Tired Tarantula^Burrow 00:51, 21 November 2024 (UTC)

@That Tired Tarantula please see @Dilettante's comment directly above, This is not an RFC. Expressing support or opposition to an option is meaningless. Thryduulf (talk) 01:19, 21 November 2024 (UTC)

Okay. Sorry, I didn't notice. Yep, I should've paid more attention. I'll strike my comment. That Tired Tarantula^Burrow 01:38, 21 November 2024 (UTC)

• If we allow opposition in the petition stage, what exactly is the purpose of separating out the RRfA into a separate stage? At that point we're basically running two RFCs on the same topic - what is the benefit of doing that? My understanding is that the sole purpose of the petition stage is to serve as a quick and lightweight process to filter out utterly, completely frivolous recall requests. Adding more weight and red tape to it goes against that. The "heavy" part of a recall, where actual in-depth arguments are made and serious decisions occur, is the RRfA itself. (And beyond that, my concern is that those suggestions are nonsensical but that it's hard to immediately spot how bizarrely nonsensical they are without an in-depth big-picture understanding of the process and what this would mean for it. I'm opposed to asking questions like that, since they tend to turn into trainwrecks.) --Aquillion (talk) 04:47, 21 November 2024 (UTC)

  I think we can see at this point that getting 25 signatures means the RRFA is unlikely to pass and/or a lot people will retire rather than go through it. You absolutely should be able to oppose a petition starting from first principles anyway - Wikipedia operates by consensus, not votes-for-any-and-no-reason. FOARP (talk) 20:32, 21 November 2024 (UTC)

But the entire purpose of a petition, as I understand it, is to serve as a bar to prevent a single disgruntled editor from starting an RRfA (which is the "real" recall); people didn't want the adversarial, high-tension situation of a recall to be something that could be invoked just by anyone calling for it, so the cursory step of ensuring that there's multiple people who want this was included before the "real" recall began. The petition is not intended to measure consensus - the "consensus-evaluation" step is the RRfA. If you allow opposes in the petition, you're turning it into an RFC on whether the person should remain an admin, and in that case, why is it still separate from the RRfA? Why not just merge the RRfA and petition into one step? What would be the benefit of evaluating the community's consensus twice in a row? (And my broader concern is that the absurdity of doing this isn't obvious unless someone understands how the entire system works, which could lead to confusion in an RFC; I'm concerned people could say "oh, yeah, consensus is good, sure" without understanding that this would result in a system that effectively just does the same process twice for no clear reason.) --Aquillion (talk) 03:58, 26 November 2024 (UTC)

Exactly: if the petition becomes the !vote, then we have a system where just one person can start the !vote, which undermines the entire point of the petition. If we don't want just one person to be able to start a consensus-based !vote about whether to desysop an admin (and we don't, because those discussions are expensive in multiple ways), then we must have a non-!vote gatekeeping method of some sort. Like a petition. Levivich (talk) 07:51, 26 November 2024 (UTC)

It’s getting frustrating that people seem to gloss over this point. Aaron Liu (talk) 13:34, 26 November 2024 (UTC)

• @Aaron Liu: What is "formal opposition"? Can we get rid of this unclear term?—Alalch E. 11:34, 23 November 2024 (UTC)

  For example, does option 2 mean that given that a discussion section exists, it is expressly disallowed to format your comment as follows: *'''Oppose''' .... I don't think that this should be an option, it's too trivial. There's no need for that to be in the RfC. The thing is with the people who see the petition stage as a vote and want for their vote to count; it isn't about mere formatting of comments. Further, Option 4b is the same as Option 1.

  This question is in substance the following question:
  Should the petition be replaced with a straw poll about whether to require the admin to make a re-request for adminship or stand as a candidate in an administrator election if they want to remain an admin?

  • Yes, and there must be n more supporters than there are opposers, n to be determined in § Number of editors
    (Also an implied option: Yes, and a simple majority is required)
  • No

  —Alalch E. 11:47, 23 November 2024 (UTC)

  i did not create this question lol
  But, here's my understanding: "formal opposition" simply means "formal opposition". It's opposition that is explicitly allowed with a provision in the Recall policy. It is whatever Recall defines it as (and if it doesn't, i.e. option 1 or 2 passes, it simply doesn't exist). Aaron Liu (talk) 19:13, 23 November 2024 (UTC)

  Oh right, you didn't create it. Anyways, I get what "opposition" means, but there's no precise meaning to the "formal" part. There's no need to have an RfC about something allowed staying allowed, and it's impossible to disallow comments that disagree with the recall initiative (the only question is where the recall discussion will be held and whether it will be watched by monitors). Whether someone formats their comment as a boldfaced "oppose" is a matter of personal style. This is really a question about turning the petition into a straw poll or a very similar format, as I've explained above. —Alalch E. 11:36, 24 November 2024 (UTC)

  There's no need to have an RfC about something allowed staying allowed

  Not sure what this means. Your "no" option would mean the same thing.
  I get what you mean by option 2 being hard to implement under the proposed everyone's-a-monitor system, but your choices do not accommodate option 3. Aaron Liu (talk) 16:22, 24 November 2024 (UTC)

  The question is "Should expressing formal opposition to the petition be allowed, and in what manner?" Questions should always contain a comprehensible proposal for a change. Allowing opposition is not a proposed change. Saying that editors should consider allowing opposition implies that opposition is disallowed, and that is incorrect and potentially misleading. The options themselves do not describe a change, except Option 4 (meant to say 3 here). Option 3 (meant to say 4 here) is a discussion section titled "Opposition"/"Oppose" or similar—in effect, another discussion section if a discussion section is left, and the functionally equivalent replacement for the discussion section if the discussion section is removed. That is the topic of § Recall discussion and should be decided via that question, which directly addresses the issue. Option 4 (read: 3) is the only option that describes a change and the change is converting the petition to a straw poll. Therefore the question should be whether to replace the petition stage with a straw poll. (note: When writing this comment originally, I mixed up option 3 and option 4—14:18, 26 November 2024 (UTC)) —Alalch E. 03:32, 26 November 2024 (UTC)

  All of the options except one are changes, though. I’m not sure what you mean. (And I’m sure you see the specialized difference from the discussion section. Most options precisely want to avoid opposition being placed in the discussion section.) Aaron Liu (talk) 13:37, 26 November 2024 (UTC)

  I’m not sure what you mean. Option 1 = 4b = no change. Option 2 = if seen as a style rule on how not to format your comment, it is trivial and functionally not a change (people will still express opposition); if construed as a ban on the expression of certain opinions, it is an impossible outcome (editors can not be prohibited from voicing their opinion against the recall initiative if there is a recall discussion). Option 4 = no, I don't see the specialized difference; just a duplicate discussion section if a discussion section is kept and the retitled discussion section if the discussion section is removed via the other question. Option 3 = turn the petition into a straw poll. —Alalch E. 14:09, 26 November 2024 (UTC)

  I get your point as applying to 4b now. I think maybe it would prohibit opposition replying in the petition section.
  2 does not say it's just formatting. Enforcement is up to enforcement. It would bar all opposition.
  4 creates a special section for just opposition discussions, so that other things can be in discussion. Enforcement of option 2 also applies here. Aaron Liu (talk) 14:26, 26 November 2024 (UTC)

  All opposition or any opposition can not be barred. Let's say there is a discussion section like we've seen in the two petitions. In that discussion section editors will voice opinions. Among those opinions will be the opinion that the given recall initiative is inappropriate and that the admin should not be required to undergo RRfA. Prohibiting this expression of opinion on the merits is granite-hard-impossible. If there's no discussion section, this same opinion will be voiced in the other official recall discussion location. If there no recall discussion based on the recall discussion question, this opinion will be voiced outside of the officially sanctioned recall discussion. —Alalch E. 14:45, 26 November 2024 (UTC)

  Then it still keeps the opposition in a separate page and has less toxicity on the petition page. Plus, these are arguments for the RfC, not the workshop. You haven’t shown that option 2 will result in no change. Aaron Liu (talk) 15:44, 26 November 2024 (UTC)

  But whether opposition will be expressed on a separate page is not addressed by this question. Let's say the recall discussion retains the form of the discussion section on the petition page and option 2 wins in the RfC: Opposition will still be expressed on the petition page, in the discussion section. Now let's say the recall discussion is moved to the talk page and option 2 wins in the RfC: Opposition will be expressed on the talk page. That depends on the location of the recall discussion. The only difference that option 2 can produce is formatting comments in a such a way that opposition is not expressed as resembling a !vote a-la WP:AFDFORMAT. —Alalch E. 16:02, 26 November 2024 (UTC)

Recall discussion

Where should the recall discussion during the petition be held? (WP:MONITOR will still apply to the recall discussion if it is held outside of the petition page.)

• Option 1: On the petition page (no change)
• Option 2: On the petition talk page
• Option 3: Somewhere else (specify)
• Option 4: No recall discussion. (Discussion of the admin conduct topics related to the petition can not be held on the petition page—no discussion section. Nor can such discussion be held on the petition talk page, which remains open only for procedural and technical matters. Such discussion elsewhere is not prohibited, but where it occurs it will not be the officially sanctioned recall discussion and so WP:MONITOR will not apply to it.)

Word limits

Whose comments at a petition should be subject to a word limit? (Choose 1 or more)

• Option 1: Nobody (current)
• Option 2: The filer
• Option 3: The administrator
• Option 4: Other participants

Old question—02:27, 25 November 2024 (UTC)
The following discussion has been closed. Please do not modify it.
Should there be a word limit? (See Wikipedia:Village pump (idea lab) § Workshopping the RfC) Option 1: Yes—the same for all participants Option 2: Yes—the same for all participants, extended for the petition initiator and administrator Option 3: Yes—the same for all participants, extended for the administrator, but the petition initiator's petition statement can be edited by other signatories to provide additional evidence Option 4: Yes—the same for all participants except for the administrator. No limit for the administrator. Option 5: Yes—something else Option 6: No (no change)

For a "something else" option, we could replace the petition initiator's extended word limit by a "petition statement", started by the initiator but which other signatories can edit, for instance to provide additional evidence. This could both limit the first mover advantage and allow for new evidence while still limiting conversation. Chaotic Enby (talk · contribs) 11:52, 8 November 2024 (UTC)

@Chaotic Enby: Added. Should we add "each within their respective word limit" at the end of Option 3?—Alalch E. 00:33, 9 November 2024 (UTC)

If it is a single statement being edited, it might be complicated to measure individual word limits. It could probably be best to have a global word limit for the petition statement (of course, larger that for the individual signatories, as it is making the case for the petition as a whole). Chaotic Enby (talk · contribs) 03:20, 9 November 2024 (UTC)

Adding an option for limits generally for everyone but the recall target. If you have 25, 50, or more petitioners each doing 100, 500, or more words on one side, then it ought to be fair for the recall target to defend themselves equally to that total on the other side. Whether a wordy, voluminous defense is a good idea for an admin facing recall in actual practice is a decision they'll have to make for themselves. ⇒SWATJester ^{Shoot Blues, Tell VileRat!} 05:52, 9 November 2024 (UTC)

@Chaotic Enby, Alalch E., and Swatjester: who grants extensions to word limits? The monitors, I assume? theleekycauldron (talk • she/her) 11:40, 20 November 2024 (UTC)

Yes, monitors. —Alalch E. 11:45, 20 November 2024 (UTC)

Presumably the monitors, yes. In theory a system like at WP:AE could work, (that version: They may not exceed 500 words and 20 diffs, except by permission of a reviewing administrator. Administrators may remove or shorten noncompliant statements. Disruptive contributions may result in blocks.) but in fairness that system doesn't do a good job of enforcing the limits at AE either. ⇒SWATJester ^{Shoot Blues, Tell VileRat!} 19:09, 20 November 2024 (UTC)

And there's no point in figuring out who gets an extended word limit if we're not putting hard number on it yet. Feels like we could get this down to 3 options. theleekycauldron (talk • she/her) 11:41, 20 November 2024 (UTC)

I agree, probably 3. And the idea of an "editable" petition statement offered by Chaotic Enby (..."petition statement", started by the initiator but which other signatories can edit, for instance to provide additional evidence.) seems like a separate thing. —Alalch E. 11:47, 20 November 2024 (UTC)

How about reworking it to something like:

Whose comments at a petition should be subject to a word limit? (Choose 1 or more)

• Option 1: Nobody (current)
• Option 2: The filer
• Option 3: The administrator
• Option 4: Other participants

We can ask separate questions about what the word limit(s) should be, and what should and should not be covered by the limit as a separate question. 11:49, 20 November 2024 (UTC) Thryduulf (talk) 11:49, 20 November 2024 (UTC)

I like that a lot better :) theleekycauldron (talk • she/her) 11:53, 20 November 2024 (UTC)

But it can't be word limit for the administrator and not the participants. —Alalch E. 11:55, 20 November 2024 (UTC)

change "other participants" to "all participants", then? theleekycauldron (talk • she/her) 11:55, 20 November 2024 (UTC)

It can only be all except filer+admin, all except admin, and all. Other combinations don't make sense (e.g. none except admin, all except filer, etc.) —Alalch E. 11:59, 20 November 2024 (UTC)

Oh, right, should go the other way. I would say this, and include "all except filer" as well. theleekycauldron (talk • she/her) 12:02, 20 November 2024 (UTC)

There shouldn't be an "all except" or other combination options as that gets complicated quickly. Choosing one or more options from a menu like this is simple and unambiguous. Theoretically possible options not getting chosen doesn't matter in this format. Thryduulf (talk) 12:15, 20 November 2024 (UTC)

@Thryduulf: The offered outcomes attainable through the combination of options need to make sense. The combinations must be acceptable, that's the thing. By "Choose 1 or more" in your suggested simplification it's easy to imagine a scenario where a nonsensical combination of options has consensus. It turns out that only four core outcomes make sense: word limit for all, word limit for all but not for the admin, word limit for all but not for the admin and not for the initiator, and word limit for none. So that is what the RfC should offer with respect to the question of "word limits yes/no and for whom"; it's the same number of options but eliminates aberrant scenarios. —Alalch E. 22:48, 22 November 2024 (UTC)

I disagree that there are options which are unacceptable or which do not make sense. There are options which I would not choose, and obviously options which you would not choose (which are not necessarily the same options) but that is a very different thing. Thryduulf (talk) 23:26, 22 November 2024 (UTC)

I can't support any RfC question which offers the option to impose a word limit on the filer and not on the participants (arbitrary and nonsensical), a word limit on the administrator and not on the filer (unfair), and other such unserious options. @Theleekycauldron: Do you have any more thoughts on this? —Alalch E. 11:55, 23 November 2024 (UTC)

Just because you can't support an option doesn't mean it is "unserious" or that other people must not be allowed to choose that option. Thryduulf (talk) 13:02, 23 November 2024 (UTC)

It's unserious because it is not clear enough in representing the potential resultant decisions in the RfC. Editor Bob !votes: "Option 2: An ArbCom case request has a word limit, and so should the petition, but there's no need to limit the admin". Bob is silent on the "other participants", for whatever reason (doesn't give it thought, does not understand what it refers to, thinks that signatures don't need a word limit because they're just signatures, etc.). And ... ? Bob has chosen "The filer's comments are subject to a word limit, but not the administrator's and not the participants'". Bob later realizes that he effectively gave support to an option which he did not intend to support. He is totally against the petition starter starting out with a 500-word statement, followed by a 1500-word statement by the second signatory. —Alalch E. 13:44, 23 November 2024 (UTC)

We have to assume that people are competent enough to only support options they support. It may be that they want the petition starter and admin to be restricted but not signatories. You don't get to impose your views over what is "serious" onto others. Thryduulf (talk) 13:49, 23 November 2024 (UTC)

We can't assume that participants in the RfC have a full picture of the process in their head and that they are familiar with all of the moving parts. In a many-part RfC such as this every added "choose 1 or more" question presupposes progressively more that participants will comprehend each option individually and how it interacts with other options in order to project an attainable resultant decision of the RfC. —Alalch E. 13:55, 23 November 2024 (UTC)

That's why we have responsibility to ensure the RFC is well structured and the questions are well phrased, but that does not extend to declaring that we know best. I simply don't comprehend how "choose who should have word limits" can be misunderstood or misconstrued, or why a consensus that filers and/or admins should have a word limit but not other participants would somehow be unconscionable (other than you not liking it). Thryduulf (talk) 14:00, 23 November 2024 (UTC)

We should start with "should there be word limits". Let's change the question to "should there be word limits (simple yes/no)", and if the consensus is that there should be, a next phase can determine
- if any group/s should be exempt (any being totally exempt is actually a bit of an extraordinary prospect that I don't feel is likely to materialize in any form ...)
- what the general word limit words/diffs numbers are (presumably 500/50)
- whether any groups need extended word limits to begin with (presumably 1000/100). —Alalch E. 14:21, 23 November 2024 (UTC)

So you're proposing to ask three questions in three rounds (word limits yes/no; who should have standard, who should have extended; what should the limits be), rather than two questions in two rounds (who should have word limits (choose all that apply); what should the limits be for each group). I think that is overcomplicating things when we can answer the first two of those questions very simply by offering nobody as an option for who should have them. Thryduulf (talk) 15:44, 23 November 2024 (UTC)

No. I think there's agreement that word limits will be fully worked out in phases. Up to this point, two phases have been discussed, the second phase being about the number of words and diffs. I'm still suggesting that questions about the word limits be asked in two phases. The first phase would be the simple yes/no question. The second phase would be eventual exemptions (depends on the yes/no but does not depend on anything else), general counts (same; works independently of the exemptions), extended counts (additionally depends on exemptions and counts, but it can probably be worked in in the same phase). So, equally two phases as before. —Alalch E. 17:25, 23 November 2024 (UTC)

@Alalch E. and Thryduulf: I think you both make good points. Alalch E., you're right that RfC options don't normally propose every conceivable possibility, only the most plausible ones. (Missed options can always be added later.) But I think in the end, Thryduulf's presentation is still the simplest, and adding complexity to try and avoid absurd results might well be tempting fate. There'll be people at the RfC to make sure participants are understanding the questions and actually matching their responses to their values. theleekycauldron (talk • she/her) 11:46, 24 November 2024 (UTC)

Thanks for summing it up. I've replaced the question with Thryduulf's.—Alalch E. 02:27, 25 November 2024 (UTC)

Changing "other participants" to "all participants" wouldn't allow for the filer and/or the administrator having no word limit but other participants having one. I agree choosing option 4 alone would be odd, but it wouldn't be impossible. Setting a word limit for the admin but not the filer or vice versa is a combination that makes sense, even if they aren't ones I'd choose. Thryduulf (talk) 12:01, 20 November 2024 (UTC)

Closing a petition

Question 1: Should a petition that reaches the threshold number of signatures be closed before the end of the 30 days? (Choose one or more.)

• Option 1: No, it should remain open for the full 30 days.
• Option 2: Yes, as soon as the threshold number of signatures is reached.
• Option 3: Yes, at a delayed time (e.g. 12/24/48 hours) after the threshold number of signatures is reached (specify what time).
• Option 4: Yes, when the subject of the petition agrees to start an RRfA or stand in an admin election.
• Option 5: Yes, when the subject of the petition starts an RRfA or nominates themselves in an admin election.
• Option 6: Yes, when the subject of the petition resigns as an administrator.
• Option 7: Yes, When the subject of the petition asks for it to be closed.

Question 2: Who can close a petition that reaches the threshold number of signatures?

• Option 1: Anyone
• Option 2: Anyone eligible to sign the petition
• Option 3: An administrator
• Option 4: A bureaucrat

Note that if Question 1 option 1 gains consensus this question is moot and responses will be ignored. Support for an option implies support for later options.

Question 3: Must a person closing the petition be? (choose one or more)

• Option 1: Uninvolved with respect to the administrator
• Option 2: Uninvolved with respect to the petition
• Option 3: An experienced closer of discussions
• Option 4: None of the above

I've split withdrawing into it's own question below. Thryduulf (talk) 11:31, 8 November 2024 (UTC)

The formulation of this question conflates closures under success, fail, and withdrawal conditions all in one. These should all be split out separately, e.g. "When should a petition be closed as successful", "When should a petition be closed as unsuccessful", and "When should a petition be allowed to be withdrawn". Additionally, there might be value in specifying alternative early close conditions (if the subject is desysopped; if the subject is banned from the project; if the petition was filed out of process; etc.)⇒SWATJester ^{Shoot Blues, Tell VileRat!} 06:11, 9 November 2024 (UTC)

• I oppose option #2 and #3. I believe if someone wants to let the discussion run its course, they should be able to do so. I think it could potentially be beneficial to see just how many signatures someone gets when they're deciding whether it's worth committing to an RfA or simply giving up the tools altogether. Hey man im josh (talk) 19:40, 12 November 2024 (UTC)

  Keep in mind this is an RfC drafting and opposing an option is irrelevant unless you think it's so unlikely to gain consensus as to not warrant being on the RfC. Sincerely, Dilettante 20:18, 12 November 2024 (UTC)

• Added resignation to options 4 and 5 Sincerely, Dilettante 20:16, 12 November 2024 (UTC)
  • Split into own option. theleekycauldron (talk • she/her) 07:27, 16 November 2024 (UTC)

    @Thryduulf: currently, options 2 and 4–7 are all in policy, and option 1 relates to another question. Do you think it's worth it to propose option 3 as an up/down? Don't see the point in relitigating the other points. theleekycauldron (talk • she/her) 07:42, 16 November 2024 (UTC)

    Given the current wording (which is only options 2 and 6) was just added boldly after it was realised when Graham87's petition reached 25 signatures that there was no mention at all of closing at all, and there have been multiple people commenting (I forget where) that it should be left open beyond the point it reaches 25 signatures, I do think this is a valuable question to ask. I don't understand why you removed the resignations from 4 and 5 though? Thryduulf (talk) 11:58, 16 November 2024 (UTC)

    I moved it to a new option, and I don't think 2, 4, 5, and 6 are controversial enough that they need RfC ratification. The informal discussion is enough, I don't see a serious challenge to it (and we can have one if there is one). theleekycauldron (talk • she/her) 10:03, 17 November 2024 (UTC)

    If you want to make a yes/no "Should a petition be kept open for a certain amount of time after it reaches 25?", that makes sense, but a complicated 7-question proposal is something I think we should to keep to a minimum. theleekycauldron (talk • she/her) 10:04, 17 November 2024 (UTC)

    I understand the desire to keep the RFC as simple as possible, but I disagree that a simple "Should a petition be kept open for a certain amount of time after it reaches 25?" is sufficient to answer the questions that need answering. Option 1 can be removed by rephrasing the question to something like "When should a petition that is not withdrawn be closed?" and I'm not sure "something else" is needed, but all the others seem like viable options that could gain consensus. Thryduulf (talk) 11:06, 17 November 2024 (UTC)

    I'm sorry, I'm not understanding. Why do those points need to gain formal consensus? They're uncontroversial enough that they were implemented informally without complaint. theleekycauldron (talk • she/her) 11:12, 17 November 2024 (UTC)

    Well I wont be the only one who didn't notice the change until after it was boldly implemented without notice (look at the number of people who have left comments elsewhere about how it should be left open), and I haven't complained about it outside of this workshop because this workshop exists - it seems very silly to demand a discussion about something that is going to be discussed in the RFC. In short I don't think it is as uncontroversial as you do. Thryduulf (talk) 11:25, 17 November 2024 (UTC)

    Indeed @Hey man im josh has just commented at BN that they don't think the petitions should be "pre-emptively closed" and that "there isn't a consensus to do so". We do need to ask this question at the RFC. Thryduulf (talk) 15:56, 18 November 2024 (UTC)

    Please do correct me if I'm wrong, but I recall this being discussed regarding Graham87's recall discussion. It was let to go beyond the 25 signatures and was eventually closed because of comments by Graham. RfA sucks, and if the petition gains enough signatures to show that an RfA isn't worth the effort, I believe that's an option that those being recalled should be allowed to consider. I don't necessarily see a benefit to immediately closing at 25 signatures if that's not what the person of focus wants. Hey man im josh (talk) 16:01, 18 November 2024 (UTC)

• This has been recently discussed and resolved at Wikipedia_talk:Administrator_recall/Archive_2#Early_closure. As this section seems fairly non contentious, it might be better to let WP:RECALL stand as is instead of bundling closure in Reworkshop again. Soni (talk) 08:37, 16 November 2024 (UTC)

  That's a shame I missed that. I made very clear my opinion on the matter that I'm against it when I mistakenly thought Graham87's recall discussion was closed inappropriately (again, I screwed up reopening that because I thought Graham87 had not been involved in the discussion about whether it should be closed). Hey man im josh (talk) 16:02, 18 November 2024 (UTC)

  Yeah the Graham closure discussion is what prompted this ask. I remember someone posted a link in the BN discussion to it as well. Soni (talk) 16:42, 18 November 2024 (UTC)

  I appreciate that and I respect that I may be in the minority, but I do believe there are relevant reasons to at least hold a longer discussion than what was initially had before the text was added (~26 hours from Thryduulf starting the discussion to the text being added. Hey man im josh (talk) 17:24, 18 November 2024 (UTC)

• I've rephrased the question to make it clear that it only applies to petitions that reach the threshold number of signatures, removed the option about withdrawing (as no longer relevant), added language about admin elections and added an option for when the admin asks for it to be closed. Thryduulf (talk) 17:05, 18 November 2024 (UTC)
  • I've also added questions 2 and 3 (this format seems simpler than combining all the options, wordsmithing is more than welcome). Who can close the petition seems to be controversial (see BN etc). This leaves open whether the administrator can close a post-threshold petition themselves, but the implication is that if closers are required to be crats and/or uninvolved then the answer is no. Thryduulf (talk) 17:20, 18 November 2024 (UTC)

    I feel like Q3 is delving too much into the depths of this again, and can probably be just combined with Q2. There's too many options that are not very functionally different from each other. Soni (talk) 06:41, 19 November 2024 (UTC)

    I agree this may not need to be codified. Valereee (talk) 12:05, 19 November 2024 (UTC)

    I don't see how you can combine Q2 and Q3 without getting complicated, repetitive options? Which options do you think are functionally too similar? They all seem usefully distinct to me. Thryduulf (talk) 12:24, 19 November 2024 (UTC)

    I was thinking just leave Q2 and Q3 off altogether. If there's no strong feeling that closing a petition requires whatever permissions or experience, why even ask? I've seen no more than people asking if it's okay (along with one saying there was consensus in an RfC that only bureaucrats could close a petition, but I couldn't find that in the RfCs.) And while it's always best if someone uninvolved closes things, meh. That's always true, why do we need to codify it here specifically unless/until it becomes a problem? Fewer questions is better. Valereee (talk) 12:43, 19 November 2024 (UTC)

    absolutely leave Q2 and Q3 off. Not a current serious issue with the recall process, and not a question that can't be solved without a full RfC. theleekycauldron (talk • she/her) 11:33, 20 November 2024 (UTC)

    It may or may not require a full RFC (although that would certainly be beneficial) they are questions that need an answer before there is a dispute about them. Thryduulf (talk) 11:41, 20 November 2024 (UTC)

    I'm going to disagree that all possible questions need an answer before there is a dispute. A dispute is the signal we need to get a question answered. A question is just a question, and we really don't need to preemptively answer all possible questions. Too many questions is exhausting, for one thing. Valereee (talk) 13:43, 21 November 2024 (UTC)

    Why is actively avoiding answering important questions in a calm, low-stress, low-stakes environment and waiting for a potentially acrimonious and drama-laden dispute to happen and trying to solve it when emotions are running high a good thing for Wikipedia? Thryduulf (talk) 14:20, 21 November 2024 (UTC)

    Because too many questions wears people out, because I think this one can probably be answered by, "Well, the first two were closed by non-admins and no one really objected", and because opening an RfC on a question implies there's already a dispute, which I don't think there is. And I'll disagree that it's even an important question; what major concern people have expressed does this address? Valereee (talk) 16:19, 21 November 2024 (UTC)

    I agree with Valereee that there hasn't been a major concern expressed about who can perform what is currently a ministerial act. As much as we'd like those interested in commenting to respond to all the questions that have been raised in this reworkshop, the reality is that many people lost interest in participating during phase 2 (and the lengthy time it took for someone to volunteer to evaluate the result further dissipated momentum). In my view, if we want to keep more people engaged, some questions will have to be postponed to another discussion (or re-evaluated after more experience with the process has been gained). isaacl (talk) 19:04, 21 November 2024 (UTC)

• Seven options for Q1 seems a bit excessive. I think just make it a straight yes or no. voorts (talk/contributions) 02:38, 21 November 2024 (UTC)

  A straight yes or no question here would be counterproductive, given that the various options have been the subject of much discussion and debate (unless it is split into a yes/no, and then an "if yes, which of these" which is just adding complexity for no benefit). I agree 7 is a lot though, but at least the first 6 are needed and 7 is needed too unless that gets spun off into a separate question. Thryduulf (talk) 02:44, 21 November 2024 (UTC)

  So... seven is too many, but we need the first six and probably the seventh? theleekycauldron (talk • she/her) 12:13, 22 November 2024 (UTC)

  7 choices is a lot, but as it's 'choose one or more' I think that's okay? I do think all of these probably are needed. Valereee (talk) 13:50, 22 November 2024 (UTC)

  I said 7 is a lot, not that 7 is too many. There is a very big difference. Thryduulf (talk) 14:04, 22 November 2024 (UTC)

Administrator inactivity

The petition can be started only if the admin has edited or made logged actions in the last 30 days.

• Yes
• Yes, but not 30 days (specify how many)
• No

The petition can not be started if it is known that the admin will be unavailable at the time the petition starts and/or for significant proportions of 60 days counting from then.

• Yes
• Yes, but not 60 days (specify how many)
• No

The 30 day timer to start the RRfA only starts when the admin becomes aware that the petition threshold has been reached.

• Yes (hypothetically no change due to bureaucrat discretion)
• No

Old question
The following discussion has been closed. Please do not modify it.
Should it be possible to raise a petition against an administrator who is currently inactive? Option 1: Yes Option 2: Yes, but if successful, the reconfirmation RfA is postponed until the administrator returns, with the tools being temporarily removed in the meantime Option 3: Yes, but only if a reasonable person could argue they have lost the trust of the community for reasons other than inactivity Option 4: Only if the administrator's inactivity could reasonably be ascribed to criticism at a central forum Option 5: No

Feel free to rework wording. Espresso Addict (talk) 08:03, 11 November 2024 (UTC)

I have a feeling that option 2 will complicate the current desysops by inactivity duration. What if the admin is inactive longer than the current inactivity period allowed? Will the petition be required, since now the inactive admin basically have to RfA anyway? – robertsky (talk) 09:47, 11 November 2024 (UTC)

I wondered myself how these would interact; my take is that under Option 2, an inactive administrator who had a successful petition against them in absentia would have their tools removed temporarily by the bureaucrats, and if the inactivity endured long enough to result in tool removal for inactivity, that would then count as removal "under a cloud". I suppose there's then a question of whether, if they subsequently returned to activity and desired to return to admin duties, they would have to run a reconfirmation RfA (with a lowered threshold, I think?) or a normal one.

As background, this is partly in response to a thread I read somewhere (this recall procedure is being discussed in so many places at the moment I can't recall where I saw it, sorry) where someone (I think it was WhatamIdoing?) brought up the problem of people trying to circumvent our current strong consensus on admin inactivity by bringing five petitions per month against the least-active ones. Espresso Addict (talk) 10:01, 11 November 2024 (UTC)

You might be thinking of Wikipedia talk:Administrator recall/Archive 1#One per year. WhatamIdoing (talk) 00:22, 14 November 2024 (UTC)

Indeed, WhatamIdoing, That was it, thanks! Espresso Addict (talk) 00:30, 14 November 2024 (UTC)

Added Option 3 but it needs serious wordsmithing, and is perhaps to vague to even make it to the final RfC. However, I can think of at least one user whom this applies to, and it's what I would !vote for, so I think it should be an option. Sincerely, Dilettante 20:34, 11 November 2024 (UTC)

Dilettante What I'm wondering is, does it matter whether or not they retain the community's trust as an administrator if they are completely inactive? Espresso Addict (talk) 22:01, 11 November 2024 (UTC)

If this admin logs in once or twice a year, I'd argue it does matter. Either way, we're getting too much into specifics for an RfC drafting. Sincerely, Dilettante 22:18, 11 November 2024 (UTC)

There is currently no guidance for when a petition can be brought, which to me is a good thing. The point is that recalls occur when the community loses trust in an administrator (that is it). I believe if we want to go down this road of specifying what is meant by "losing trust in the community," then we should have an explicit RfC question asking whether the community should develop criteria which needs to be met before a petition can be initiated. --Enos733 (talk) 22:57, 11 November 2024 (UTC)

There is some instructional guidance on this. The second paragraph of WP:ADMINACCT says: Administrators who ... have lost the trust or confidence of the community may be sanctioned or have their administrator rights removed by the Arbitration Committee [and now also by the community]. In the past, this has happened or been suggested for the following actions: [list of historically occurring types of admin misconduct]. This provides instruction on when it is reasonable to think that the admin might have lost the trust of the community based on historical precedent (and the list is practically exhaustive, even if it does not intend to be, due to how generalized the descriptions are). WP:RECALL connects to this when it says Any extended confirmed editor may start a petition for an administrator to make a re-request for adminship if they believe that the administrator has lost the trust of the community. "X may do Y if Z" may even be understood to suggest that X may not do Y unless Z ... but at the very least: If the editor does not believe that the administrator has lost the trust of the community, that editor should not start the petition; at the very least it's inadvisable. —Alalch E. 04:15, 12 November 2024 (UTC)

Thank you for this. I do now think that if we want to add inactivity as a reason for a recall, it should be discussed and added to the list at WP:ADMINACCT. That said, I still think if we want to go down this road, we should still want to add a question of whether an editor needs a specific reason to start a petition. Right now, the page is silent. - Enos733 (talk) 04:41, 12 November 2024 (UTC)

I suppose inactivity could fall under "Failure to communicate" if someone reasonably asks for an explanation of an admin action performed prior to going on a wikibreak, and the inactive admin fails to provide one because they are not checking their talk page/linked e-mail. Espresso Addict (talk) 13:15, 12 November 2024 (UTC)

That depends when the question came in relation to the Wikibreak, why the admin is taking a break and whether they are able to check their talk page/email.

For example if I take an admin action on Thursday morning then take a wikibreak starting Friday afternoon. I should have responded a query sent Friday morning, but one asked on Saturday is a different matter. In some cases it's reasonable to expect admins to pay attention to their talk page/Wikipedia email while on a break, in other cases it isn't. In January this year I was on a cruise for a week, I had no internet access of any kind for most of that time and did not have access to my Wikipedia email or my admin account for the entire time I was away (on my phone I only use my alt account; my Wikipedia-related emails go to a dedicated email account that I do not log onto from my phone). Unless and until we require admins to be available 365 days a year, going on a break is not prima facie evidence of a failure to communicate. Thryduulf (talk) 00:19, 13 November 2024 (UTC)

• I don't want to say no... because if you deserve to be desysopped you deserve to be, but this feels akin to a backdoor to de-adminship if someone is not available to defend themselves. Hey man im josh (talk) 19:34, 12 November 2024 (UTC)
• Seems like a solution in search of a problem. We de-sysop inactive admins all the time. WP:ADMINACCT: Administrators are expected to respond promptly and civilly to queries about their Wikipedia-related conduct and administrative actions, especially during community discussions on noticeboards or during Arbitration Committee proceedings Hawkeye7 (discuss) 20:06, 13 November 2024 (UTC)

I don't think anyone's going to be able to usefully engage with this one in an RfC until "inactive" is clearly defined. -- asilvering (talk) 04:17, 14 November 2024 (UTC)

Asilvering No edits or logged actions for at least 5 days but less than a year? Espresso Addict (talk) 15:14, 14 November 2024 (UTC)

I think this is too specific and in the weeds for a recall workshop right now. While I'm not necessarily opposed to the idea of fine-tuning the reasons for doing recall, the guidance we have as of now is not completely broken yet.

I think there's parts of recall that are much more in need of work currently. I would much rather this RFC focus on those, and we fine-tune the rest in a few months if the need exists Soni (talk) 15:46, 14 November 2024 (UTC)

@Espresso Addict: I think this would be a good one to make an up/down vote on a single proposal, if we air it. theleekycauldron (talk • she/her) 07:47, 16 November 2024 (UTC)

Indeed, something simple would be good. However, I don't see how, in a simple question, to distinguish between, say, (1) admin EA does something moderately reprehensible, has a critical ANI thread in response and flounces vowing never to edit Wikipedia before the thread concludes; (2) admin EA performs run-of-the-mill admin work that no-one objects to and then takes an extended wikibreak for health reasons. Espresso Addict (talk) 13:49, 16 November 2024 (UTC)

Can we assume that people take this kind of thing into consideration? Valereee (talk) 20:23, 16 November 2024 (UTC)

• I don't believe that this should be an option, or part of the recall process at all. We have an existing policy and process for desysopping inactive admins, with explicit requirements that differ greatly from what would be required here. It already has consensus. We should not be encouraging back-door ways to do an end-around of that consensus, and the option to do so should not even be on the (RFC) ballot.⇒SWATJester ^{Shoot Blues, Tell VileRat!} 20:00, 16 November 2024 (UTC)

  Not disagreeing, but the current guidelines don't seem to rule it out. Espresso Addict (talk) 20:11, 16 November 2024 (UTC)

  The question here is whether this should be on the RFC. If it is significantly likely that exactly one option will receive overwhelming support then there is no point in putting it to the RFC, it should just be implemented. If there is no chance of a consensus it should also not be in the RFC without, at minimum, further workshopping. I agree with @Asilvering when they say I don't think anyone's going to be able to usefully engage with this one in an RfC until "inactive" is clearly defined. which also precludes there being an overwhelming consensus. Phrase the question something like:

  How recently must an administrator have been active before a petition may be initiated against them?

  Question 1:

  • Option 1: Within the last 3 days
  • Option 2: Within the last 7 days
  • Option 3: within the last 14 days
  • Option 4: Within the last month
  • Option 5: No limit.

  Question 2:

  If an administrator is inactive (based on the definition used in question 1) when a petition against them is certified, when should the timer to initiate a re-RFA begin?

  • Option 1: When the petition is closed
  • Option 2: 30 days after the petition was initiated
  • Option 3: When they return to activity

  This doesn't though answer the question about whether we should have this at all. I don't think we should be initiating petitions against inactive administrators: either it can wait until they return or are desysopped for inactivity, or it needs to go to arbcom. However I can see the utility in defining what inactivity means in this context, so I'm weakly in favour of asking a question like something like my reformulation (not necessarily verbatim) or and weakly against the original formulation. Thryduulf (talk) 20:38, 16 November 2024 (UTC)

  If everyone here agrees that we should not be initiating petitions against inactive administrators in their absence, then I'd be happy just to amend the guidelines to say so, but that's not my read of what they currently state. Espresso Addict (talk) 20:52, 16 November 2024 (UTC)

  I agree there is no current prohibition on starting petitions against inactive administrators, I think there should be but not without an explicit definition of "inactive". Thryduulf (talk) 21:00, 16 November 2024 (UTC)

  I wasn't involved in the discussions from which this recall process arose (the perils of being periodically inactive) but if it would be acceptable to come up with a definition of inactivity and then add it to the guidelines that would certainly save an RfC question. Espresso Addict (talk) 21:05, 16 November 2024 (UTC)

  Please see edit.—Alalch E. 04:25, 17 November 2024 (UTC)

  I don't think the concern is about administrators one month away from meeting the inactivity requirement, but administrators who aren't editing so they wouldn't be present to make a re-request for adminship. isaacl (talk) 05:35, 17 November 2024 (UTC)

  I agree that Alach's edit is functionally pointless. A petition started a month before an admin becomes totally inactive is not one opened in the spirit of petitions and could be disruptive. Thryduulf (talk) 11:10, 17 November 2024 (UTC)

  I guess it's a helpful edge case edit, but unless I'm reading it wrong, it only addresses cases where an admin has reached the point of a pending desysopping notification. It doesn't address the main concern, which is that anywhere prior to that point, a petition can be used to back-door around the inactivity requirements that currently exist as policy. We already have an explicit definition of "inactive" -- Has made neither edits nor administrative actions for at least a 12-month period, or Has made fewer than 100 edits over a 60-month period. If neither applies then the administrator is definitionally *not* inactive per policy. Allowing any group of 25 editors at one place and one time to override the broad community consensus that set that policy is literally what WP:CONLEVEL say we *cannot* do. Maybe the way to approach that is a footnote after "loss of trust by the community" clarifying that inactivity short of the desysopping requirement does not alone constitute such a loss of trust. ⇒SWATJester ^{Shoot Blues, Tell VileRat!} 09:03, 17 November 2024 (UTC)

I think we should propose just this as an up/down vote:

• An petition cannot be opened against an administrator who has no edits or logged actions in the past 30 days.

I think this the simplest proposal that can pass, which reduces confusion at the eventual RfC. I think shorter durations than 30 days are a bad idea because they're too easily gamed (recall flu). In edge cases where an admin genuinely needs extra time to open an RRfA, the bureaucrats can always extend that 30-day timer to open an RRfA at their discretion. theleekycauldron (talk • she/her) 11:05, 17 November 2024 (UTC)

Avoiding gaming isn't a concern - either they make an edit (at which point those wanting to start a petition have at least 3 days to do so) or they don't and they eventually get desysopped for inactivity. If they don't want to wait then AN/I and/or arbcom are still routes that are available. An admin who is not editing is not doing the things that (some in) the community don't want them to be doing. If we really want to make it hard to game, then count edits on any WMF project.

Personally I think a month is far too long and won't be supporting options longer than 7 days. It is important that recall is as fair as possible to the subject, and that means making sure they are aware there is a petition against them and they have the opportunity to respond to it. Crat discretion is on the order of a few days, not for cases where an admin returns after a break only to find there was a petition against them that played out from start to finish while they were on an extended break away from the project. Thryduulf (talk) 11:21, 17 November 2024 (UTC)

Inactivity desysops take a year at least, which isn't close to being an option here, so it doesn't make sense to say that either they're editing or they get inactivity desysopped. If avoiding a recall petition just means making one comment at an ANI thread to fulfill ADMINACCT and then going dark for a few days, so that by the time there's actually enough steam to open a petition you're "inactive", then that's a pretty clear escape from accountability. theleekycauldron (talk • she/her) 11:29, 17 November 2024 (UTC)

If there "isn't enough steam" to open a petition then the issue is not serious enough to recall an administrator over. Thryduulf (talk) 11:39, 17 November 2024 (UTC)

My option "Only if the administrator's inactivity could reasonably be ascribed to criticism at a central forum" was intended to address "recall flu". Espresso Addict (talk) 16:24, 17 November 2024 (UTC)

How about this: A petition can be started and can pass irrespective of activity, but the period during which the admin needs to start the RRfA starts counting from the admin's first sign of activity made after the petition's close. —Alalch E. 14:20, 17 November 2024 (UTC)

That's certainly an option that makes sense. Espresso Addict (talk) 16:24, 17 November 2024 (UTC)

This is the exact use-case because of which the RRFA part of this process currently has crat discretion (even when 25 signature count on petitions does not). Even if we do not explicitly specify anything here, any reasonable crat can understand this kind of case. If an admin makes no edits for 30 days after petition close, crats can already choose to just wait a few more days and/or until they actually return. Soni (talk) 19:54, 17 November 2024 (UTC)

Can they though? My understanding based on all the discussions I've read is that crat discretion is based around a few days to account for personal circumstances, admin election scheduling and similar, not months. If we want the crats to have the discretion to start the 30 day clock whenever they think appropriate based on admin inactivity we need to be explicit about it, otherwise there will be vocal complaints about why they haven't been desysopped yet starting exactly 30 days after the 25th signature, even if the admin in question is not aware the petition has started. It's why I suggested (somewhere, I can't remember where) that the 30 days should only ever start from either the admin's explicit acknowledgement of the result or from the time of their first edit after they were formally informed on their talk page if they are actively editing without officially acknowledging. Ultimately my view is that admins subject to a recall petition must know a petition has started and also must know when it has been certified (if it has) and both require them to be either actively editing or to officially acknowledge it some other way. Anything else is unfair. Thryduulf (talk) 22:52, 17 November 2024 (UTC)

Bureaucrats are reasonable people, and admins who are active are expected to monitor their talk pages for messages to meet accountability requirements. I'm not concerned about trying to codify every variation of an admin who suddenly becomes inactive in the middle of the process. Based on the particulars of the case, the bureaucrats can determine what would be a fair way to proceed. isaacl (talk) 23:04, 17 November 2024 (UTC)

What happens if, for whatever reason, an admin makes it known (or someone else makes it known) they're unable to respond to a petition once it has begun for real life reasons? For example, a major health reason (emergency or otherwise), vacation plans or some other reason which really means they won't be able to edit Wikipedia for some extended period of time. Perhaps since it has already been started, the petition should be allowed to run its course. What should happen next? Should the countdown to the RRFA start as soon as the petition reaches the required threshold? Should it just be left up to bureaucrats to decide? I'm not taking about someone who just stops editing in the hopes of avoiding an RRFA, but some who's kind of claiming hardship and actually asking for a postponement. -- Marchjuly (talk) 00:39, 18 November 2024 (UTC)

There are two critical points in time, the first when the petition starts and the second when it ends. For fairness both should happen when the admin is active. The first is a very easily controlled point in time, because the person starting the petition chooses exactly when to start it. It is very easy to determine whether the given admin is active now or not: Have they made edits or logged actions within the last n days? Yes - they are active and the petition can start, no - they are inactive and starting the petition needs to wait.

The other critical time is more complicated. While it is known that the petition will not end later than 30 days after it starts, that's not relevant to re-RFAs (because a petition that expires without 25 signatures doesn't trigger one). The Re-RFA clock currently starts once the 25th eligible signatory saves their edit. It is unknowable to everyone other than the person who is the 25th signatory when that will be (and the earliest they can possibly know is when they see the 24th signature, they also cannot be sure they are the 25th until they save their edit without an edit conflict). If it happens when the admin is active they have 30 days to initiate a re-RFA or resign. If it happens when the admin has been inactive for a fortnight, they have 16 days. If it happens when the admin is on a two-month wikibreak trekking through the Amazon or nursing their dying grandmother then they have negative time and end up desysopped. Which is why I say that it needs to be explicit that the 30 day timer needs to only start once the admin is aware of it - when that is, and how strict to be about the 30 days is where crat discretion comes in. Crat discretion is not about ignoring rules or saying that "when the community explicitly said X they actually mean Y". Requiring the admin be active at the start also allows them to communicate (to the community or privately to one or more crats) any periods they know they will be inactive. e.g. if a petition starts on the first of a month and the admin says I'm going to be away for five weeks from the 7th, they are not avoiding their responsibilities by not starting a re-RFA within 30 days of the poll closing on the 9th.

I also think the fears of recall flu are overstated. If a petition is started it is because at least one person feels they should be acting as an administrator. An inactive admin is not acting as an administrator. If they become active again after a short time then the petition can just be started then. If they become active again after a long time then either there are still problems and the petition can be started then based on both sets of problems, or there aren't any problems and they don't need to be recalled.

Someone deliberately timing their activity so as to avoid a recall petition is both engaging in a lot of effort and someone who should be desysopped by arbcom for intentionally avoiding scrutiny of their actions. Thryduulf (talk) 02:08, 18 November 2024 (UTC)

@Thryduulf: Would what you posted it the last paragraph of your post also apply to petitions which seem to have been deliberately timed to begin when the administrator in question is unlikely going to be able to respond in a timely matter? Should such petitions be scrutinized? I've mentioned there's no vetting process for petitions at WP:RECALL and am not advocating here that there should be one. How should a petition that's started after an administrator has clearly made it known on their user talk page that they're going to be away until a particular date be treated? You seem to be saying that it should be allowed to continue, but the 30-day countdown for an RRFA to take place shouldn't start until after the admin returns. Is that a correct understanding of what you posted? -- Marchjuly (talk) 02:53, 18 November 2024 (UTC)

I hadn't thought about that scenario but it is plausible. For example IIRC there is one (possibly former, I can't remember who it is) functionary who is almost never active in March due to March Madness and I vaguely recall someone whose work means/meant they contribute(d) in a circa 6 months on, 6 months off pattern. A petition targetting them timed to start right as their absent period starts when they have been currently active but will not be around to respond could be seen as disruptive, especially if the petition starter knows the admin's schedule. How to handle that is indeed currently undefined, but one possible option would be for someone (a crat? to close it without prejudice to an outcome of a future petition, setting the timer before a new petition can be initiated to however long it is until they are expected back (or just pausing it until that point?). Any sanction against the petition starter would be something for ANI to handle (off the top of my head, a ban from starting petitions in general, just from starting one against that admin, or an interaction ban with that admin are things that might be considered).

If, for whatever reason and under whatever circumstances, a petition reaches 25 signatures the 30-day timer should not begin until it is reasonable to presume they are aware of the outcome (that could be an official acknowledgement, a return to active editing, or some other means - determination would be at crat discretion). If they are active that will be very quickly (both Graham87 and Fastily commented within 24 hours that they were aware) if they are inactive it will be longer. Thryduulf (talk) 05:50, 18 November 2024 (UTC)

I think the particulars of each case, and how much information is known about them, is going to vary and will affect what's most fair. Thus I don't think the process should try to plan to cover every contingency. I feel the community trusts bureaucrats to be fair, and bureaucrats take that responsibility in earnest. isaacl (talk) 03:00, 18 November 2024 (UTC)

This isn't an attempt to cover every contingency, it's a combination of a requirement for a known circumstance (whether the administrator is active now is always known) for the start and setting the basis around which crat discretion works for the latter part. Crat discretion is best thought of as fuzzy limits around a starting point. My point is to set the starting point to something that is fair to the admin (30 days from when they become aware of the petition outcome rather than 30 days from when it ends) rather than asking the crats to stretch the limits of their discretion beyond what is reasonable (few people are going to complain about 33 days when that's when admin election nominations open, many people are going to complain about 50 days to start a re-RFA regardless of why it's 50 days). Thryduulf (talk) 05:31, 18 November 2024 (UTC)

I was responding to Marchjuly, who was asking questions about several different hypothetical scenarios. I don't think the process should go into that fine detail. I appreciate that you and I may have different ideas on the degree of detail. I think I would ask if the bureaucrats would be willing to take a more active role in communicating with the admin during the process so any potential reasons for absence could be made known. This could dovetail with making a bureaucrat responsible for verifying that a petition has reached the target threshold. Through conversation, the bureaucrats could keep track of the admin's current level of awareness and availability. (Completely unforeseen circumstances could always arise, of course.) isaacl (talk) 05:58, 18 November 2024 (UTC)

'crats and the admin communicating during all stages would not be a bad thing, as long as we don't (implicitly) require admins to divulge information they do not wish to share. It's fine for the community to know only that the admin will be unavailable for a given period of time without knowing any more details. As long as the admin isn't trying to avoid accountability (visible by e.g. active editing on other projects) the process should be paused. The goal is to be as fair as possible to both the admin and the community.

As far as detail goes I think you might getting the wrong impression about how detailed I am proposing:

• If the admin has been active within the last n days, start at any time unless it is known that they will be unavailable at the time the petition starts and/or for significant proportions of the next ~60 days.
  • If the matter can wait until they return, wait.
  • If the matter cannot wait until they return, go to arbcom.
  • If it appears they are trying to avoid responsibility, go to arbcom.
• If 25 signatures are reached, do not start the 30 day timer until the admin is aware the threshold has been reached.
  • If it appears they are trying to avoid responsibility, go to arbcom.

Thryduulf (talk) 15:03, 18 November 2024 (UTC)

Please rest assured, I understood the level of detail you are proposing. We're not that far apart; I just think it's better to leave more flexibility in the operational procedure rather than codifying details in a policy which is harder to change. On a separate note, I don't think having the bureaucrats open an arbitration case request is desirable. There's no additional information to be uncovered about the scenario by the arbitration committee. isaacl (talk) 17:46, 18 November 2024 (UTC)

I agree that we shouldn't codify too many details, but we do need to codify some and those that we do codify should be the starting point around which discretion is exercised which they are not currently.

Why would the crats be opening an arbitration case? It would be for who started/supported/want to start a petition (i.e. those who have serious concerns about the admin) to initiate a case request. The point of doing so is that arbcom are the only ones who can desysop outside this process. If what the admin is (alleged) to have done is so serious that it cannot wait until they return from inactivity (or wait until they are desysopped for inactivity) then arbcom are the ones who can deal with it. Thryduulf (talk) 18:05, 18 November 2024 (UTC)

Yes, I agree that bureaucrats shouldn't be opening a case. Your list says "go to arbcom", but that shouldn't be part of the recall policy. I don't think the severity of the raised concerns should play a role in the outcome of the recall petition, as at the point, the concerns have not gotten a full airing. isaacl (talk) 19:23, 18 November 2024 (UTC)

I was intending the subbullets to be guidance/commentary rather than instructions but I can see how that wasn't at all obvious. Thryduulf (talk) 20:39, 18 November 2024 (UTC)

The community trusting bureaucrats is about whether they will desysop at a particular point in time in a particular sequence of events. But the awareness concerns from lack of administrator's recent activity seem to primarily relate to whether a petition can even be started, and if started when it could not have been validly started, should it be summarily dismissed. In the following scenario, the current text of WP:RECALL is unchanged: Someone closes the petition on day 3 after 10 signatures saying "this petition isn't appropriate and/or reasonable and/or fair because the admin has not edited after being notified about the petition or has not edited in the last 8 days, closing", and someone else reverts saying "rv, nothing about that in WP:RECALL, doesn't prevent a petition". This scenario doesn't involve bureaucrats; it's too early for them. —Alalch E. 09:52, 18 November 2024 (UTC)

It doesn't have to be too early for bureaucrats. It's desirable for someone to check if the petition is eligible to be started (in terms of when and by whom), and so it's also a good time to start conversations with the admin to make sure they are aware of the process and know what to expect procedurally and in what time frame. As the bureaucrats are trusted to make fair decisions about assigning administrative privileges, they are good choices to engage with the admin from the onset, and thus it's suitable for them to check if the starting criteria for the petition have been met. isaacl (talk) 17:55, 18 November 2024 (UTC)

I don't think this needs to be asked as a question, because we don't have a problem with people trying to recall inactive admins, and I doubt we ever will. If it becomes an issue, then the question can be asked. Levivich (talk) 21:30, 23 November 2024 (UTC)

Agreed, let's focus on the things the are currently problems first, and discuss the things that may become future problems later (preferably not until they arise). Ajpolino (talk) 13:54, 24 November 2024 (UTC)

Discussing problems only after they arise is an absolutely terrible way to deal with things, unless the goal is maximum drama. Thryduulf (talk) 14:42, 24 November 2024 (UTC)

Well, maybe it's not a good question for this iteration of the RfC, as while it may be important, it isn't urgent, and we have many issues that are urgent now. We've got (currently) 13 proposed questions, some of which are actually more than one question and all of which have several answer options. I suspect we're already going to end up with daunting walls of text. Future RfCs can focus on the "what if X happens" issues. Maybe move this to a "For future consideration" section? Valereee (talk) 15:52, 24 November 2024 (UTC)

No consensus at Re-RFA

In the event that a Re-RFA ends in the discretionary range and the crats find either no consensus among the community, or there is no consensus among the crats, what should be the outcome?

• Option 1: The administrator should retain adminship (i.e. there needs to be a consensus to remove the tools)
• Option 2: The administrator should not retain adminship (i.e. there needs to be a consensus to retain to tools)

This is presently undefined and (currently) is a real possibility in Graham 87's re-RFA. Leaving it undefined seems unfair on the crats. Thryduulf (talk) 03:20, 19 November 2024 (UTC)

I thought there is current a lower than usual threshold of 60% for re-RFA per (WP:RRfA)? Also see above Wikipedia:Administrator_recall/Reworkshop#Percentage_threshold_to_pass.

I think if it fell into the discretionary 50-60% threshhold, then it is, as the name suggests, discretionary, though I could very well see that in such a tight case, the crats may err on the side of caution, since I'd say at the end of the day, we want the community to have confidence in admins, so I'm not sure if an edge-of-the teeth majority would pass that. Arguably if say it's 59% I could see the "discretion" part being in favor, but say it's at 51%, then maybe that's more of a no. We just ultimately need a line, which for now was drawn at 60% with a bit of potential leeway between 50-60%, which makes sense I'd say. Raladic (talk) 04:08, 19 November 2024 (UTC)

I think "Option 1" because most of the XfDs (except FFD and RfD perhaps) seem to default to "keep" or "maintain the status quo" in the case of a "no consensus" close per WP:NOCONSENSUS, don't they? I don't know what happens in the case of an RFC, but perhaps its the same. I guess it could be argued that since an RFA is seeking community consensus about one becoming an admin than the onus falls upon those seeking to become an admin to establish a consensus in their favor; however, a recalled admin is still an admin even though enough people have signed a petition stating the community should reevaluate their status. It seems to me that an RRFA (at least one resulting from a recall petition) is less a case of an admin voluntarily seeking reconfirmation and more of a case of some seeking the desyoping of the admin. In that case, it seems to me that onus should switch onto those seeking desyop to establish a community consensus in their favor. If they fail to do so, then perhaps, in principle, the default should be for the administrator to retain their tools, absent any specific consensus not to do so among bureaucrats. -- Marchjuly (talk) 04:26, 19 November 2024 (UTC), post edited -- 05:06, 19 November 2024 (UTC)

I think it since this is technically the (re)-granting of permissions, the side of caution should be the default, just as admins exercise more caution when granting some request at WP:PERM would err more on the side of not granting them if it's borderline.

Especially since it is ultimately about granting one of the highest level of set of permissions, so I think given the already lowered threshold of 60%, admins at Re-RFA should reach close to that to have a reasonable level of confidence of the community to hold the mop. Raladic (talk) 04:52, 19 November 2024 (UTC)

@Raladic, @Marchjuly as a reminder this is not the place to support, oppose or advocate for or against either option, this is just workshopping the questions to ask in the forthcoming RFC. Thryduulf (talk) 04:56, 19 November 2024 (UTC)

Fair, I just figured I'd comemnt since you pointed out the urgency with regards to the ongoing Re-RFA from Graham, since this Reworkshop will probably be longer than that.. Raladic (talk) 04:59, 19 November 2024 (UTC)

My apologies: Hopefully I tweaked my post so that it's now acceptable. If not, I don't mind striking it out. Besides what theleekycauldron posted below seems to imply that this kind of matter has already been as "Option 2". -- Marchjuly (talk) 05:06, 19 November 2024 (UTC)

If "no consensus" defaulted to "retain", consensus would be required to desysop, which was an option that was explicitly rejected in phase II. Voorts's close made it quite clear that consensus is required for the admin to retain their tools. theleekycauldron (talk • she/her) 04:59, 19 November 2024 (UTC)

Not quite, that close states (based on the options) that the "community should show it has continued faith" [by way of a majority, due to the 50% threshold] for the admin to retain their tools (anything going to a crat chat has a majority, unless it finishes at exactly 50%) requiring a supermajority consensus to desysop was rejected. What happens when there isn't consensus is undefined. Thryduulf (talk) 05:15, 19 November 2024 (UTC)

Even if you ignore the numbers completely, the question is "does the community have continued faith in the admin" has three possible answers - yes, no and no consensus. The first two are easy, the third has to default one way or the other, and there are three equally arguable options: "the status quo prevails" (adminship is retained), "there is no consensus the community has continued faith" (desysop), "there is no consensus that community does not have continued faith" (adminship is retained). This is not the place to argue which of these should happen, nor to argue which can be inferred from a discussion which did not consider there being no consensus. Thryduulf (talk) 05:21, 19 November 2024 (UTC)

I'm sorry, but I think that unnecessarily splits hairs on the exact language. Either consensus is required to desysop (in which case "no consensus" defaults to retain), or consensus is required to retain (in which case "no consensus" defaults to desysop). There's simply no other choices, and I think the intention of the community on which they wanted to choose is eminently clear. The process calls for a reconfirmation RfA; if there's no consensus, there's no consensus to reconfirm. But if you insist, voorts closed that question, and I think a clarification of that close would be enough to clear this up. If "no consensus" is somehow an edge case nobody thought of, sure, let's clarify it with another question. If not, can we please not sink editor-hours into this. theleekycauldron (talk • she/her) 06:40, 19 November 2024 (UTC)

I agree with leek, but I don't think this is related to my close. The process that was created is a re-RfA. Failing a re-RfA means you lose the tools. If the 'crats find no consensus to retain, then the admin loses the bit. The normal language of consensus to promote etc. is a bit of a red herring IMO. voorts (talk/contributions) 15:28, 19 November 2024 (UTC)

• I think this is a good question to ask, and the way in which votes have evolved in the current reconfirmation RfA suggests that it is likely that such events will often end within the discretionary range. I am sure that the bureaucrats would welcome guidance on how to proceed in this eventuality. Given how many editor hours the highly active admins who have been recalled so far have "sunk" into this project, I think we can afford to sink a few more into making sure all aspects of the process have been fine-tuned, and then on demonstrating that they have community support. Espresso Addict (talk) 22:08, 19 November 2024 (UTC)
• The current process is to run the RfA process but with lower thresholds. The RfA process determines if there is consensus establishing that the community trusts the candidate to hold administrative privileges. The bureaucrats can either determine that there is consensus in the community for the candidate to have administrative privileges, or there isn't. How that decision is worded in terms of recall doesn't affect that determination. isaacl (talk) 23:30, 19 November 2024 (UTC)
• theleekycauldron uniltarry closed this with the summary {{tpqZDoes not urgently need to be resolved. Anyone who really wants to can informally survey at WT:RECALL.theleekycauldron (talk • she/her) 11:27, 20 November 2024 (UTC)}}. I very strongly disagree with that - this needs to be resolved before the next re-RFA and something as critical as whether the RFA succeeds or fails needs to be handled formally. Thryduulf (talk) 11:37, 20 November 2024 (UTC)

  I think you are creating ambiguity where none exists. voorts (talk/contributions) 13:34, 20 November 2024 (UTC)

  As I've explained multiple times, the ambiguity is real. Thryduulf (talk) 13:36, 20 November 2024 (UTC)

  I think option 2 should apply; in the event of no consensus, the default option should be to desysop. Hurricane Clyde 🌀^{my talk page!} 22:56, 20 November 2024 (UTC)

  But since this isn’t an RFC; (didn’t know at the time) I’d say the options there are pretty solid. Seems like a simple yes no question to me. Hurricane Clyde 🌀^{my talk page!} 02:23, 21 November 2024 (UTC)

• Re-reading my close, I think the community's consensus was pretty clear that there was a desire for admins at RRfA to show that they still had the trust of the community, such that at least a majority of !voters support the admin retaining their tools. Consensus can change, of course, but if this question is added to the follow-up RfC, then it should be made clear that option B is currently the consensus. voorts (talk/contributions) 02:31, 21 November 2024 (UTC)

  Everywhere else, no consensus means no change to the status quo. Hawkeye7 (discuss) 23:06, 22 November 2024 (UTC)

  In my view, there are two outcomes to an RRfA: pass or fail. "No consensus" isn't an outcome; when the 'crats use the phrase "no consensus to promote" at a regular RfA, they mean "this person failed their RfA". voorts (talk/contributions) 23:24, 22 November 2024 (UTC)

  If that was what they meant by "no consensus to promote" they would say that. The fact they explicitly distinguish between "no consensus to promote" and "consensus against promotion" means they are different things, as indeed they are everywhere else on Wikipedia. Thryduulf (talk) 23:29, 22 November 2024 (UTC)

  That's a difference without a difference, it's not per se about promotion, there is either trust or there is not. Regards, Goldsztajn (talk) 21:26, 23 November 2024 (UTC)

• Question unnecessary. At RfA there must be consensus to promote amongst editors, if no clear consensus for or against emerges, then bureaucrats must determine if there is consensus to promote. In all cases, it is a consensus to promote. If there is no consensus that an admin retains trust, then by definition they do not have the trust of community. Regards, --Goldsztajn (talk) 21:24, 23 November 2024 (UTC)

  I agree the question is unnecessary because the answer is uncontroversial: it's either there is consensus to promote (or, in the case of RRFA, retain), or no consensus to promote/retain. The idea of having consensus to desysop (e.g., must have >50% or >60% oppose) was already proposed and rejected this year. Levivich (talk) 21:29, 23 November 2024 (UTC)

  Whether no consensus defaults to the status quo or not was not even brought up, let alone discussed before it became a possibility in Graham87's RFA and since it has been discussed multiple people have said that it is obvious that no consensus defaults to the status quo (retaining adminship) and a similar number of people have said it is obvious that no consensus defaults to loss of adminship. They can't both be right, so it must not actually be obvious after all. Thryduulf (talk) 22:56, 23 November 2024 (UTC)

  It's about outcome (trust) not process (promotion); application of general rule is never universal (think self-defence). Regards, Goldsztajn (talk) 23:43, 23 November 2024 (UTC)

  If it were clear then everybody would have the same opinion, but they don't. This question absolutely needs to be asked before it becomes a source of drama. Thryduulf (talk) 01:14, 24 November 2024 (UTC)

  The problem is created by the way the question has been framed in terms of process; that's what is creating the confusion because "promotion" is a process. But the point of recall is to test trust. Therefore, if there is an insistence on asking a question it should be framed in relation to trust; this provides a much clearer demarcation and avoids conflation with process. Eg:

  1. If bureacrats conclude that a RRFA has no consensus, this indicates that an admin has not retained the trust of the community.

  2. If bureacrats conclude that a RRFA has no consensus, this indicates that an admin has retained the trust of the community.

  Regards, Goldsztajn (talk) 11:24, 24 November 2024 (UTC)

  I'd be tempted to phrase option 2 something like "...an admin has not lost the trust..." but it is a good formulation overall. Thryduulf (talk) 12:47, 24 November 2024 (UTC)

  Not lost would be a lower threshold to keep than retained - if phrased in the form of two questions, the same word should be used. My preference is for trust retained/not retained, ie a higher threshold to keep. Regards, Goldsztajn (talk) 08:14, 25 November 2024 (UTC)

  I think the first formulation is still the clearest, honestly. theleekycauldron (talk • she/her) 08:31, 25 November 2024 (UTC)

Withdrawn petitions and subsequent petitions

How soon after a withdrawn petition may a new petition be initiated against the same administrator?

• Option 1: No limit
• Option 2: 1 month
• Option 3: 3 months
• Option 4: 6 months
• Option 5: 12 months

This is currently undefined but should be. I don't know if it needs an RFC or just a normal discussion, but this is a good place to decide that and to workshop the question if it does need an RFC. My initial thoughts are that we want to discourage frivolously opening and then withdrawing petitions but equally we don't want petitions being opened and then withdrawn to prevent an administrator being subject to recall by gaming the system. Thryduulf (talk) 13:34, 20 November 2024 (UTC)

Six months. theleekycauldron (talk • she/her) 13:52, 20 November 2024 (UTC)

Eh? Why? The page you linked to makes no mention of withdrawing (a withdrawn petition is not a failed petition) so doesn't provide any context or explanation for your answer, which itself doesn't answer the question I asked here. Thryduulf (talk) 13:58, 20 November 2024 (UTC)

I think it depends. If it’s the same person petitioning; it should be three months; if it’s someone else petitioning, there shouldn’t be a limit. Hurricane Clyde 🌀^{my talk page!} 22:57, 20 November 2024 (UTC)

I'm kind of wondering whether a withdrawn petition should mean that person cannot start another petition to recall the same admin, period. If you're going to start a petition, you need to have thought it through. If a few months or even years go by and you really think a petition needs to be started, you ought to be able to find one other person who agrees with you enough that they're willing to start that petition. And honestly if someone withdraws more than one petition, they need to lose their ability to start petitions. Valereee (talk) 14:10, 24 November 2024 (UTC)

I'd allow a very short grace period with no penalty so that someone who completely cocks up some template formatting or something like that can withdraw it to fix it, something on the order of 5-15 minutes maximum, but beyond that this seems like a good idea. I'm unsure whether the grace period needs to be codified or it can just be an IAR thing?

Thinking more though, I'm wondering whether this needs to be specifically codified? if someone is repeatedly starting and withdrawing petitions then they can be given a topic ban from starting petitions and/or an iban with the admin they are targetting. Thryduulf (talk) 14:38, 24 November 2024 (UTC)

Personally I think leave it as a judgement call, codify if it turns out we need to. I would even accept, "I was just so pissed off, but I went for a walk and cooled off" as a reason to just pretend it never happened. But withdrawing because several days in, no one else had signed and you were getting pilloried in the discussion section? Nope, you cannot file against that admin again. And if you do that twice, you lose the privilege. Valereee (talk) 14:52, 24 November 2024 (UTC)

Yes. Different reasons for withdrawal were mentioned in the other discussion. If the page would be eligible for G7 speedy deletion at the time of withdrawal (even if not deleted) then it shouldn't count for anything. If there was commentary on the merits of the rationale from other editors then it should count. If it's unclear maybe just get a consensus of uninvolved EC editors at WT:RECALL? This would necessitate maintaining a list of withdrawn petitions that count somewhere, WP:CARP seems the obvious place. Thryduulf (talk) 18:38, 24 November 2024 (UTC)

I think this is one of the situations we can wait to see how big a problem it is before codifying specific rules. There are existing methods to handle editors who use processes inappropriately. (Regarding finding another person to start a petition, well, technically if you go looking for one, that's canvassing. If you happen to be in a conversation with someone who raises the possibility, then sure, you could discuss it.) isaacl (talk) 20:08, 24 November 2024 (UTC)

Withdrawn petitions are failed petitions. A petition is started, the last remaining valid signature is withdrawn, petition fails. If someone does this to game, that will be a bad-faith action, meaning that that is not a withdrawn petition but an invalid petition with no effect, as if it had never existed. —Alalch E. 12:57, 23 November 2024 (UTC)

At the talk page discussion that Leeky started in parallel with this one, I don't believe anyone else has said that withdrawn petitions are automatically failed petitions. Thryduulf (talk) 13:05, 23 November 2024 (UTC)

Waiving the 12-month immunity period for new petitions after a successful RRFA

Should admins be able to voluntarily waive the 12-month immunity period on new petitions after a successful RRFA?

• Option 1: Yes, at any time
• Option 2: Yes, during RRFAs
• Option 3: Yes, if the RRFA falls within the discretionary range (50-60%)
• Option 4: No (no change)

Should there be circumstances in which the 12-month immunity period after successful RRFAs is involuntarily waived?

• Option 1: Yes, if the RRFA succeeds in the discretionary range (50-60%)
• Option 2: Yes, at bureaucratic discretion if the RRFA succeeds in the discretionary range (50-60%)
• Option 3: No (no change)

If a waiver is allowed, should new petitions be required to include at least one instance of behaviour/edits/actions taken after the RRFA?

• Option 1: Yes
• Option 2: No

Bringing this over here from the talk page. At the first RRFA, 41 different opposers either directly mentioned the 12-month immunity period on new petitions after a successful RRFA as a reason to oppose or cited Levivich's highly influential oppose which did. If this immunity period could be waived voluntarily, then admins at RRFA would have a mechanism to try and win those participants over if they're not clearly going to pass. This would be helpful for those admins that fall into an area similar to Graham87, where there are both obvious positives to their adminship but also serious problems with their actions and community trust that a voluntary pledge to improve is insufficient. I also threw in the second question because it was suggested at the RRFA by Closed Limelike Curves, and I think it's something interesting to consider, where finishing in the discretionary range might result in less future leeway because of reduced trust than a clear pass. -- Patar knight - ^chat/_{contributions} 07:22, 25 November 2024 (UTC)

Administrators can still voluntarily choose to follow their own recall process, setting their own more permissive conditions. For example, if someone they respect asks them to re-affirm that the community trusts them to hold administrative privileges, they can do so. Special rules don't have to be set as admins can choose on their initiative to undergo the RfA process again. isaacl (talk) 17:20, 25 November 2024 (UTC)

They actually cannot, since if they wanted to have a recall process that included a binding waiver of the 12-month immunity period and are 100% willing to follow through, WP:RECALL does not allow it and voluntary recall processes are not binding. Obviously, WP:IAR can be invoked, but if that's going to be the case, we can just add a some sentences (max 3, depending on what the answers to the questions are) to clarify the process. That wouldn't be rules creep.

I fail to see the relevance of your hypothetical, since it doesn't address the immunity period at all. Just because an admin wants to waive the immunity period during their RRFA does not mean that they want to immediately start another future RRFA. The waiver is an attempt to win over !votes of those who would accept their continued adminship iff there was a quick and convenient enforcement mechanism that isn't ANI or ARBCOM. -- Patar knight - ^chat/_{contributions} 07:22, 26 November 2024 (UTC)

The recall process doesn't prohibit an administrator from going through the request for adminship process whenever they choose. Anyone can create a petition at any time and people can sign it as an opinion poll, and the administrator can choose to respect its outcome. If the administrator is 100% willing to follow through, then having a personal voluntary recall process is sufficient.

Regarding gaining support from the community in the request for adminship process by making pledges to follow personal restrictions: I feel that's something the community should consider holistically for the administrators policy. It should decide if the benefits of managing a system of personal restrictions is worth its cost. There is a reasonable argument that the baseline level of trust expected from administrators shouldn't require any personal restrictions beyond the relevant common guidance for administrators. I appreciate though that some may feel there are ways to manage a system of personal restrictions that allow more people to take on administrative tasks. isaacl (talk) 19:32, 26 November 2024 (UTC)

I've been advocating for recall for five years now, and I used to ask "the recall question" at RFAs. Back then, people told me that it was pointless, because some candidates would say that they'll add themselves to voluntary recall, and then not do it. And that's exactly what happened. I stopped asking "the recall question" and became more resolute in my support for involuntary recall. So I for one have little faith in the voluntary recall process, even as an abstract idea.

That said, I think it's worth asking at the next RFC about allowing admins-under-recall to waive the 12-month immunity. The waiver would be voluntary, but once invoked, it can be enforced, by the community and 'crats, who can simply allow another recall within 12 months for an admin who previously waived the immunity during a prior recall. So it would be an enforceable waiver. Such an immunity waiver may have swayed my or others' votes at that recent RRFA; it's worth discussing and potentially adopting. Levivich (talk) 19:45, 26 November 2024 (UTC)

I think a system of personal restrictions should be discussed as part of modifying the administrators policy, rather than the recall process. If personal pledges are to become enforceable, the community should examine the effects holistically. New admin candidates, for example, may pledge to waive any recall immuity respite period, to avoid certain topic areas, to only use their administrative privileges to perform a specific set of tasks, or some other restriction. isaacl (talk) 20:01, 26 November 2024 (UTC)

We already have an enforcement mechanism for broken RFA pledges: recall. Levivich (talk) 20:07, 26 November 2024 (UTC)

For conciseness, I elided "enforceable through immediate removal of administrative privileges due to a breach of the pledge". isaacl (talk) 20:22, 26 November 2024 (UTC)

Anything not related to recall would be outside the scope of the proposed RFC, and as Levivich says, can be resolved by recall if serious enough. -- Patar knight - ^chat/_{contributions} 20:35, 26 November 2024 (UTC)

Anyone can create a petition at any time is objectively not true for the process this RFC is meant to address, since RECALL explicitly says The petition may not be created within twelve months of the administrator's last successful...re-request for adminship, or within twelve months of the administrator being elected an administrator or elected to the Arbitration Committee. If a petition fails, another petition to recall the same administrator may not be started for six months from the date the last one was closed. (emphasis added).

I did include Option 1 to Q1 which expands it to outside RRFAs, though again only for the 12-month post-RRFA period. Perhaps there should be a question about voluntary waivers of all immunity periods, but the post-RRFA situation is the most salient now, since it might be the make or break for admins in the process.

I think at Graham's RRFA, there was a community desire for problematic, but net positive admins to be bound by an enforceable mechanism. Many opposers (and even the candidate) viewed the pledge as technically worthless, while many supporters were satisfied with the pledge as de facto binding, citing the likelihood of ANI/ARBCOM sanctions if violated, though that might not be a given looking the high number of admins supporting at the RRFA).

It shouldn't be difficult to maintain a small subsection, or subpage if needed, at RECALL that lists immunity waivers. Assuming that waivers aren't opened up beyond RRFA candidates, RRFAs are well attended, so they are unlikely to be missed. If necessary, require the monitor or a bureaucrat to update the list. -- Patar knight - ^chat/_{contributions} 20:33, 26 November 2024 (UTC)

The recall process lays out requirements to compel an admin to make a re-request for adminship. Admins can, however, do whatever they want to decide if they will voluntarily make a new request. There's no way to force an admin to continue to be an administrator, just because fewer than 12 months have passed since they first were granted administrative privileges, for example. isaacl (talk) 23:20, 26 November 2024 (UTC)

Again, recall petitions and (R)RFAs are different processes. Being willing to waive a 12-month immunity period if your RRFA succeeds to try and win supporters is not the same as starting an RRFA yourself. No one here is also trying to force admins who don't want the bit to stay on as administrators, so I fail to see the relevance. -- Patar knight - ^chat/_{contributions} 23:46, 26 November 2024 (UTC)

You said it wasn't true that anyone can create a petition at any time. If an admin is implementing their own voluntary recall process, though, they can say I will respect the result of a recall petition created at any time, even within 12 months of my previous RfA. The recall process doesn't bar a voluntary petition being created, and the admin following the results voluntarily. isaacl (talk) 23:56, 26 November 2024 (UTC)

While the WP:RECALL process does not impact the ability of admins to engage in any entirely voluntary, non-binding recall process, as written they absolutely do bar an admin from voluntary allowing the creation of binding RECALL petitions during the various immunity periods. -- Patar knight - ^chat/_{contributions} 02:55, 27 November 2024 (UTC)

As I stated, for the situation you specified with admins 100% willing to follow through, a voluntary recall petition is sufficient. isaacl (talk) 03:43, 27 November 2024 (UTC)

What I said initially was ...since if they wanted to have a recall process that included a binding waiver of the 12-month immunity period and are 100% willing to follow through.... This is plainly referring to a scenario where an admin wants to voluntarily waive the immunity period and potentially submit themselves to the binding recall petition process. -- Patar knight - ^chat/_{contributions} 03:54, 27 November 2024 (UTC)

Yes, that's what I understood. Since they're 100% willing to submit to the result of a recall petition, I'm not worried about whether or not it is voluntary. isaacl (talk) 03:57, 27 November 2024 (UTC)

Under the current phrasing at WP:RECALL, how do you propose, without invoking WP:IAR, that the following recall plans work within 12 months of the admin passing an RRFA after a successful recall petition:

• The binding recall procedure at WP:RECALL can be used against myself at anytime, including within 12-months after I pass an RRFA; and,
• If I pass this RRFA, I will allow anyone to start to petition using the WP:RECALL process despite the 12-month immunity period after successful RRFAs?

-- Patar knight - ^chat/_{contributions} 23:04, 27 November 2024 (UTC)

I'm sorry, I'm not sure I understand your question. Since Wikipedia isn't a bureaucracy, admins can say my voluntary recall process is like the one described on the administrator recall page, but with these differences. (The most uncontroversial approach would be to use the regular request for adminship thresholds. Although some editors think the lower thresholds should be available for voluntary re-requests, I'm not sure if this view has community consensus.) isaacl (talk) 23:27, 27 November 2024 (UTC)

I'll rephrase: If an admin who has just survived an RRFA has one of the two recall plans above, can the WP:RECALL process be used within 12 months?

In your example, "these differences" is a euphemism for "with differences that will make it completely unenforceable and make it be seen as useless in the eyes of a significant portion of RRFA" participants who will then oppose the RRFA". There are obviously very meaningful differences between something that is binding and something that is not. -- Patar knight - ^chat/_{contributions} 05:14, 28 November 2024 (UTC)

As discussed, the new recall process has a specified respite period before another petition can be started to compel the admin to make a re-request. However since the period is for the benefit of the admin, no one really has any standing to object to the admin unconditionally waiving it. They would be voluntarily submitting to follow the result of the petition. isaacl (talk) 08:40, 28 November 2024 (UTC)

I'm not contradicting what you're saying. But not all protections are waivable simply through being for the benefit of the subject. A construction worker has a right to a safe workplace, can't waive the right to be protected by a protective headgear (mirrored by the employer's obligation to the worker to provide them with the headgear), which is at the same time the worker's obligation to wear the headgear (mirrored by the employer's right to impose and monitor safety protocols and shield himself from liabilities). A naive observer could say: "Why should the employer care? If the worker gets killed through their sole culpability in not following safety protocols (negligently took the helmet off at the wrong time), it's not the employer's fault". While on some level correct, this would clearly be the wrong operating principle, because it's clearly in everyone's best interest that helmets be worn; obviously, the employer does care. It could be that editors believe that it's everyone's best interest that administrators can not, in general, waive the protection in the form of the respite period, but that maybe, only in exceptional circumstances, they can. —Alalch E. 11:15, 28 November 2024 (UTC)

As I commented somewhere previously, I do not support allowing administrators to waive this right because I believe this will just encourage some editors in Re-RFAs to bully administrators into "voluntarily" giving up the right. (Re-)RFA is already toxic enough without making it more so. An admin who passes RFA either was not doing anything wrong, has stopped doing wrong things, or the community trusts them to stop doing wrong things. In the first case they shouldn't have been at Re-RFA in the first place so we don't want to enable more incorrect uses of the process by removing the immunity. In the second case, there will be no need for a second petition (because they are not doing bad things) unless they restart, in which case ArbCom would the most suitable venue regardless of whether they are eligible for another petition or not. In the third case, either they do stop and everything is now good (so no petition needed) or they don't stop, in which case they need to be taken to arbcom not subject to another petition. If a petition/re-RFA was launched for any other reason then that is the abuse of process and should not be encouraged. Thryduulf (talk) 11:41, 28 November 2024 (UTC)

I considered that editors may object to avoid setting a precedent. But ultimately, English Wikipedia's tradition of not being bureaucratic about doing what the community wants means that if the admin wants to voluntarily submit to a petition, and the community wants to create one, then by English Wikipedia's consensus-based bottom-up decision-making traditions, it should proceed.

I am concerned about pressure being asserted to get admins and admin candidates to make increasingly stringent pledges, which is why I said earlier that I think a holistic discussion of the consequences of personal restrictions should be held on how this should be described in the administrators policy. isaacl (talk) 17:44, 28 November 2024 (UTC)

If this is the case, then we should just add a sentence to WP:RECALL saying that admins can waive the immunity period at their discretion instead of making it seem like there is no way to do so if there de facto is. -- Patar knight - ^chat/_{contributions} 14:32, 28 November 2024 (UTC)

Alternatives to RRFA

One of the goals of Recall is to put removal of adminship into the community's hands - but I do wonder if the community is necessarily best placed to do so all of the time. We do regularly see the community whipped up into a frenzy over contentious topics that cooler heads can sort. Now, I can imagine the scenario that a petition is quickly filled of a single contentious issue - and yes, and RRfA is a good way to get the full community consensus on the administrator. However, I wonder if we could put in a slower alternative, to allow cooler heads to consider the options? My gut feeling suggests that the administrator should either submit an RRfA or Request an Arbitration Case to review their actions. It's not like WP:ARC is a more pleasant process, but it may be more appropriate in certain scenarios. Worm^TT(talk) 13:11, 2 December 2024 (UTC)

So basically you're suggesting that after a petition reaches the threshold the admin would have three options - resign, stand for Re-RFA/admin election, and request an arbitration case? If so then presumably the 30 day timescale would apply to initiating request for arbitration rather than the case starting as that is not something the admin is in control of. Would the committee be mandated to open a case? Can the community mandate that? If the committee is not required to open a case, what happens if they decline the request? Is that the end of the matter or do they then have to choose between resignation and re-RFA/admin election? I'm not necessarily opposed to the idea but these questions need answers before we can put it to an RFC. Thryduulf (talk) 13:42, 2 December 2024 (UTC)

Firstly, yes, I would be expecting the timescale to be up to initiating the request, not starting the case.

Speaking from experience, if the community is willing to say that they do not have confidence in an administrator, the committee responds to that - and the petition is pretty strong evidence of that. Every committee I have sat on has had a lower bar for opening an admin conduct case than other cases - so I would suggest that the concern of a mandated case is moot. If the committee turns down the case - well, there's an argument there that the decline is the committee's decision on the matter.

That said, I'm biased, I've sat on the committee on and off for years. I know what I'd do if I was on the committee, and what I'd encourage committee members to do. I would be interested in hearing other views. Worm^TT(talk) 13:50, 2 December 2024 (UTC)

Defunct sections

Petition length

Does not currently need to be discussed. theleekycauldron (talk • she/her) 23:53, 9 November 2024 (UTC)

Note that an RfC is currently ongoing on this topic. In case further discussion is needed, how long should a petition be? Option A: 30 days (no change) Option B: 14 days Option C: 7 days Option D: Whatever the outcome of the RfC says. Something else (specify) We shouldn't be debating this in multiple places while an RfC is up. If this must exist, adding an option to use the results of the RfC. ⇒SWATJester Shoot Blues, Tell VileRat! 05:34, 9 November 2024 (UTC) As I'm interpreting it, if that RFC finds a consensus, we won't include this as part of the reworkshop RFC. Sincerely, Dilettante 17:21, 9 November 2024 (UTC)

Requisite support of uninvolved editors

Doesn't look like this one is gonna make it to air. theleekycauldron (talk • she/her) 07:40, 16 November 2024 (UTC)

Of the signatories, how many must have been uninvolved with any dispute in which the admin concerned acted in their capacity as an administrator within the last 1/2/3/x (separate question) months? (See Wikipedia:Village pump (idea lab) § Workshopping the RfC) Option 1: five other than the initiator, and their signatures are a latch—they must be collected first and the petition is only then unlocked for everyone else, and if one of the five withdraws their signature, it only subtracts a signature, but can't lock the petition up. Option 2: X editors (specify details) Option 3: zero (no rule dealing with uninvolved signatories; no change) Option 1 is the specific formulation of this requirement that was come up with after some brainstorming at VPI. There are certain complications if the "latch mechanism" isn't used, involving what happens if an uninvolved signatory withdraws their signature (Option 1 solves that).—Alalch E. 11:38, 8 November 2024 (UTC) Option 1 would minimize axe-grinding. Miniapolis 22:19, 8 November 2024 (UTC) I can see there being ambiguity as to the definitions of "uninvolved" and "dispute" here, but more importantly I don't really see how a filer is supposed to identify those people even if it wasn't ambiguous. ⇒SWATJester Shoot Blues, Tell VileRat! 05:24, 9 November 2024 (UTC) If this is going to be proposed, it should be a standard "I think X should be implemented, support or oppose?" RfC. But this would be wildly difficult for a monitor to enforce. theleekycauldron (talk • she/her) 05:58, 9 November 2024 (UTC) Pinging Thryduulf to comment on the practical side of enforcing Option 1. I think that uninvolved signatories could sign a pledge that they are aware of the requirement, that they have seriously looked into the possibility that they might have been involved in a dispute of said sort the in the stated period, and determined that they were not, and that they are aware of the consequences of signing as an uninvolved signatory while not in reality being uninvolved (and that consequence could be an automatic ban from the recall process in general, once discovered, or something else). —Alalch E. 23:09, 9 November 2024 (UTC) I think a statement at the top of the page saying something like: "By being one of the first five people to sign this petition you are asserting that you have not been involved, in any capacity, with the dispute(s) listed by the filer, or with any other matter within the last [3 months] in which the subject of this petition acted in an administrative capacity. Assertions shown to be incorrect will result in your being prohibited from contributing to any petition in which you are not the subject for twelve months and/or further sanction" but wordsmithed. Thryduulf (talk) 00:23, 10 November 2024 (UTC) I agree with that. But also, maybe it would not be a bad idea to make this into an awareness template like a CT alert and require that they put it on their talk page (meaning they've signed the statement) prior to signing the petition. This will increase the likelihood that they've actually read it, and also the likelihood that they care about the process. —Alalch E. 00:54, 10 November 2024 (UTC) Something is needed, but this allows involved people to start petitions with only the risk that their signatures will be discounted if their involvement is discovered later. If it doesn't prevent the petition from being opened to everyone, their purpose has been achieved. Not sure about this: maybe after five signatures appear, the named admin should have a brief chance to challenge their uninvolvement. Zerotalk 12:39, 10 November 2024 (UTC) The problems with this idea are (1) that it will make sysops who block or sanction people prolifically harder to recall, and (2) that it gives the sysop an incentive to impose sanctions on people who dislike them.—S Marshall T/C 07:49, 11 November 2024 (UTC) I'm going to go ahead and say that I feel this option should not be on the menu at RFC. It's well-intentioned but the behaviours it incentivises are very undesirable indeed.—S Marshall T/C 11:53, 12 November 2024 (UTC)

Discussion section

For the "should there be a discussion section: yes/no/else" part see § Recall discussion (consumes this question). For the "should lengthy threaded discussion should be disallowed" part see § Lengthy threaded discussion (split out).—Alalch E. 22:40, 15 November 2024 (UTC)

Should there be a discussion section on the recall page? (See related RfC.) Option 1: Yes (no change) Option 1b: Yes, but lengthy threaded discussion should be discouraged. Option 2: No Something else (specify) Adding Option 1b: needs wordsmithing, as I don't know exactly how to draft it, but the point is to enable people to explain themselves briefly without pages of screen real-estate going to lengthy threaded discussions that inevitably devolve and go off-topic, and are hard to follow. This is not such a problem if the discussion happens on a different page; but if it happens on the recall page proper, then it can have the effect of making it too difficult to read and follow. See, e.g. on Graham87's recall, the lengthy aside into high school blocking practices unrelated to Graham. In terms of screen real-estate, the discussion session is roughly 7 times longer than the entire list of supports, including the lengthy first one. ⇒SWATJester Shoot Blues, Tell VileRat! 06:02, 9 November 2024 (UTC) I think that the issue that 1b addresses is better treated using word limits. See § Word limits. —Alalch E. 01:42, 10 November 2024 (UTC) Word limits are one possibility but I'm not sure it's the best one. Word limits have their own problems (particularly with presenting complex evidence) and if extensions are allowed, that creates overhead as well. What I'm trying to get at with 1b is to stop multiple back-and-forth edits that will inevitably devolve off topic (possibly before hitting a word limit if those are set generously). It's the number and frequency of the responses that's the problem I'm trying to tackle, not their size. Again, I am not certain about the way to wordsmith exactly what to call this: it's not quite a paragraph limit, it's not quite a number-of-edits limit, it's not quite a "number of indents" limit -- it's more along the line of limiting the amounts of responses and rebuttals from an initial discussion point (possibly no more than 1 layer deep, I'd suggest, but I'm trying to not be prescriptive about that). ⇒SWATJester Shoot Blues, Tell VileRat! 04:33, 10 November 2024 (UTC) "Discouraged" is effectively the same as "permitted". Either it is enforced or it isn't. Zerotalk 12:41, 10 November 2024 (UTC) How about "lengthy threaded discussion should be discouraged" --> "lengthy threaded discussions should be moved to the talk page"? But we'd then need to identify monitors. Espresso Addict (talk) 07:46, 11 November 2024 (UTC) WP:RECALL already states that the discussion is subject to WP:MONITOR, so "lengthy threaded discussions should be moved to the talk page" is not a change from the status quo. —Alalch E. 06:21, 12 November 2024 (UTC) Disallowed would work. Espresso Addict's version would work if there are monitors in the end result. ⇒SWATJester Shoot Blues, Tell VileRat! 22:10, 11 November 2024 (UTC)

Discussion elsewhere

If the vote is to disallow discussion on the recall page, it presumably means there will be no officially sanctioned discussion. If someone wants to propose moving discussion away from the recall page, that's a separate thing. theleekycauldron (talk • she/her) 23:55, 9 November 2024 (UTC)

Given that there is no discussion section on the recall page (see the previous section), where should the discussion concerning the petition be carried out? Option 1: on the recall page's talk page Option 2: on some specific page other than the recall page's talk page (specify) Option 3: on an unspecified page or pages other than the recall page's talk page Option 4: It does not need to be specified where.  Note: Refactored the question, see permalink for the previous version, which the below comments primarily attach to.—Alalch E. 00:48, 9 November 2024 (UTC) @Alalch E.: 2, 3, and 4 don't seem to me to be in the scope of this RfC. We can't restrict what topics can come up on user talk pages. We can control whether it's discussed on the petition page or its talk. theleekycauldron (talk • she/her) 10:29, 8 November 2024 (UTC) These options follow from what was discussed in Wikipedia:Village pump (idea lab) § Avoiding a long month of drama, for example: There would be no restriction on clarification being sought on user talk pages .... While we can't restrict what topics are created on user pages, if it becomes customary to hold discussions on this topic on user talk pages, and there is no central place to discuss, any such user talk threads should be exempt from WP:OWNTALK, and it is possible that the RfA monitor function should extend even there. (Currently, the discussion section comments are subject to monitoring: Any signature or comment may be struck based on the same criteria used during requests for adminship.) —Alalch E. 10:37, 8 November 2024 (UTC) So we can control more. And for example, use of the petition talk page can be prevented. If the petition talk page is the place for discussion, the RfA monitor function which currently exists on the petition page should be extended to that page. This could be another RfC question. —Alalch E. 10:49, 8 November 2024 (UTC) I don't think we can really prohibit the discussion beyond the petition and its talk page. Moving the discussion of the petition on the talk page allows for a slower-paced discussion, where not every signatory is compelled to add a comment, while still allowing for a centralized discussion which could be useful to bring up additional evidence. On the other hand, if we want by design to not have a centralized discussion to avoid a RfA-like pressure, we can prohibit the discussion on both the petition page and its talk page, while leaving other places (like user talk threads) subject to their usual rules. Chaotic Enby (talk · contribs) 11:50, 8 November 2024 (UTC) Yes, we can prohibit discussion on both the petition page and its talk page, and if we by doing so inevitably cause the discussion to migrate to another place or places, we might want to also have, for example, word limits and the monitoring function preserved in all those places. —Alalch E. 12:03, 8 November 2024 (UTC) This seems like CREEP to me. If we prohibit a discussion section, people will soon figure out what works best. Even at the Graham87 petition, people were willing to discuss it on the talk page, on my talk page, and on Graham87's talk page, based on the focus and sensitivity of the discussion. Sincerely, Dilettante 16:42, 8 November 2024 (UTC) I disagree. This needs to be explored because many people have said that they thought that the petition would be a simple gathering of signatures without the discussion, and that the lively forum format, as what happened with the Graham87 petition, is completely different from how they imaged the petition stage would work. It can not be assumed that these editors simply thought that the same thing should be replicated onto the talk page. Chaotic Enby believes that this would allow for a slower-paced discussion; I would say that it *might*. And the only distinction being the pace becoming maybe somewhat slower, is far from the original mental picture of many people: Signature collection with no discussion. —Alalch E. 17:06, 8 November 2024 (UTC) If we specify a preferred venue (with the exception of 3, since that's decentralized), everyone will congregate there and we'll have just shifted the forumstyle conversation to a new location. Option 7 won't pass an RFC. Sincerely, Dilettante 17:20, 8 November 2024 (UTC) If nothing is specified, that means that the petition talk page has been set as the new norm and the RfC needs to be transparent about that, because the distinction is highly speculative and comes down to a technicality. It's possible to specify a plurality of pages, i.e. a decentralized discussion: Statements with rationales underlying the signatures go on respective signatories' user talk page and responses also there, and every such page containing such topical discussion matter is subject to RfA-style monitoring. And let's say the admin comes on your talk to defend from an allegation and you remove their comment and leave yours per WP:OWNTALK. Shouldn't be allowed. Messages of moral support and praise can go on the admin's talk page. Objections to the process and various generalized protestations can go on the talk page of the page describing the process. These are possibilities, and things that can be controlled. —Alalch E. 17:43, 8 November 2024 (UTC) For now, I'm gonna strikethrough a few of these, since we should be keeping this RfC as tight as possible and discussion seems to be leaning against including them. Feel free to keep to discussing, though. theleekycauldron (talk • she/her) 21:28, 8 November 2024 (UTC) Added 5a—Alalch E. 00:26, 9 November 2024 (UTC)

Monitors

See § Moderated discussion not on the recall page—Alalch E. 00:33, 10 November 2024 (UTC)

Currently: Any signature or comment may be struck based on the same criteria used during requests for adminship. This pertains to the discussion on the recall page. But provided that there is no discussion section on the petition page, should WP:MONITOR continue to apply to the discussion concerning the petition? Option 1: Yes—WP:MONITOR applies to the page dedicated to the discussion concerning the petition (e.g. the the recall page's talk page) Option 2: Yes—WP:MONITOR applies to any page where such discussion matter is found Option 3: No Don't think this is necessary. If there's no discussion section, there's no need for monitoring. We can't do anything about discussion in other places other than close it as off-topic. theleekycauldron (talk • she/her) 05:55, 9 November 2024 (UTC) This is a necessary question. The discussion is getting moved from the recall page to another page or pages. That discussion has the same need for monitoring. Things that monitors do can be done in the places which this discussion is getting moved to, as long as it's some specified place or a single obvious place like the talk page. This may include monitoring word limits, which the following question is about. At VPI, both monitoring and word limits were discussed in the context of the recall page's talk page. —Alalch E. 06:39, 9 November 2024 (UTC) If there's an officially sanctioned place for discussion, it's monitored. Otherwise, it isn't. I'm not sure what needs changing here. theleekycauldron (talk • she/her) 23:56, 9 November 2024 (UTC)

Moderated discussion not on the recall page

See § Recall discussion—Alalch E. 22:40, 15 November 2024 (UTC)

Provided that there is no discussion on the recall petition page (see § Discussion section), dubbed "recall proper" for the purposes of this question, should the current provision in WP:RECALL stating that WP:MONITOR applies to recall proper (Any editor may comment in a discussion section on the recall petition page. Any signature or comment may be struck based on the same criteria used during requests for adminship), be extended to apply to another page, and that page designated as the officially sanctioned place for discussion? Subsidiary question: If the recall page's talk page (dubbed "recall talk" for the purposes of this question) is not the officially sanctioned place for discussion, should its use be restricted as follows: The recall petition page's talk page is reserved only for any technical and procedural issues relating to signature gathering, with everything else considered off-topic—no discussion on the merits of the admin conduct issue there. Option 1: Yes—Recall talk is the officially sanctioned place for discussion, and WP:MONITOR applies also there. Option 2: Yes—A specific page/s other than recall talk is/are the officially sanctioned place/s for discussion (specify), and WP:MONITOR applies also there. Use of recall talk is restricted as stated. Option 3: No—There is no officially sanctioned place for discussion (WP:MONITOR only applies to recall proper). Option 4: No—There is no officially sanctioned place for discussion (WP:MONITOR only applies to recall proper). Additionally: Use of recall talk is restricted as stated. This follows from the discussions at Wikipedia:Village pump (idea lab)#Avoiding a long month of drama. For example, Chaotic Enby said: Moving the discussion to a less prominent place behind the petition, plus a word limit as Thryduulf suggested, would definitely limit the "pre-RRFA RFA" stuff. It was suggested (by Thryduulf) that extending the monitor function to another page is something that will need to [be] actively decided.—Alalch E. 00:39, 10 November 2024 (UTC) @Thryduulf: Is any of WP:RECALL currently covered by MONITOR? I assume RRfAs are by default, but I don't see a discussion applying it to the petition process. theleekycauldron (talk • she/her) 07:12, 11 November 2024 (UTC) Now you mention it, I don't see it at either WP:RECALL or WP:MONITOR. I guess that makes sense as it was assumed that there would not be extensive discussion on petition pages and thus there wouldn't be a need for it. We should ask a question about it. Thryduulf (talk) 12:50, 11 November 2024 (UTC) I quoted the part of WP:RECALL that says that WP:MONITOR applies to the recall petition page, both the signatures and the comments. Theleekycauldron wondered if this extant provision was included as a result of a specific discussion to include it (that's how I understood her question).—Alalch E. 14:32, 11 November 2024 (UTC) The word "monitor" does not appear at Wikipedia:Administrator recall, but I see now it's phrased as Any signature or comment may be struck based on the same criteria used during requests for adminship. with the link going to WP:MONITOR. I was not involved in the discussions that led to RECALL being enacted so can't say how we arrived at the current wording. Thryduulf (talk) 15:36, 11 November 2024 (UTC) Gotcha. So then what's the question here, Alalch E.? "Any signature or comment" would apply to wherever we hold the official discussion and the petition. Unless we wanna not have MONITOR apply... theleekycauldron (talk • she/her) 05:02, 12 November 2024 (UTC) It would not apply. Any signature or comment would only apply to the recall petition page: Any editor may comment in a discussion section on the recall petition page. Any signature or comment may be struck based on the same criteria used during requests for adminship. "signature" is something that only appears on the recall petition page. "Comment" is clearly a comment made in the discussion section on the recall petition page, not a comment concerning the petition elsewhere. If the official discussion is held not on the recall petition page, but elsewhere, it would need to be stated that MONITOR applies to that other page. —Alalch E. 05:10, 12 November 2024 (UTC) So are you saying if we changed it so that it reads: "Any editor may comment in a discussion section on the recall petition talk page. Any signature or comment may be struck based on the same criteria used during requests for adminship.", it wouldn't apply? I don't agree. I think monitor applies to the discussion section of the petition, wherever that discussion section happens to be. theleekycauldron (talk • she/her) 05:15, 12 November 2024 (UTC) We could really just stipulate this in the RfC: Where should the recall discussion be held? (WP:MONITOR will still apply to the discussion if it is held outside of the petition page.) On the petition page (no change) On the petition talk page Somewhere else No discussion section theleekycauldron (talk • she/her) 05:18, 12 November 2024 (UTC) Actually, more relevantly, to continue on my above reply: If the result of the discussion section question is to remove the discussion section, WP:MONITOR would only apply to signatures, and would not apply to any comment anywhere, i.e. there would not be a moderated discussion. The question is ultimately: Do editors want to replace a moderated discussion about recalling an admin (currently, a moderated discussion is indicated, but we're not seeing it in practice, and the lack of understanding of the process is making it hard for a monitor to operate) with an unmoderated discussion (more of the same, i.e. more of the wild growth discussion that people have been surprised to see result from the new process). I think that the way you have reformulated the question is good and it also consumes the discussion section question. The only thing which I would suggest is clarifying that "no discussion section" also means that the recall talk page is not the place for the recall discussion (under that option, it would be the place for technical and procedural issues and not a place to talk about the admin conduct dispute). More of the same, using different words: If option 4 is accepted as stated ("No discussion section"), most people will either understand it to mean that the same type of discussion that they've seen can be held on the talk page or understand it to mean that the process will not be accompanied with the sort of discussion they've seen until now (many will fail to recognize the implication that removing the discussion section does not prohibit this discussion, i.e. that there will still be such a discussion, just elsewhere). The term "discussion section" does not relate to the talk page, and can only be understood as the discussion section of a page which has some other content, and a section of it is for discussion (whereas discussion is the purpose of an entire talk page); as the talk page is the single obvious place for discussion in the absence of a discussion at the project proper page that option would therefore mean: "There should be unmoderated discussion on the talk page".—Alalch E. 05:53, 12 November 2024 (UTC) Therefore, option 4 should be "No recall discussion. Discussion of the admin conduct topics related to the petition and whether the admin should be recalled can not be held on the recall page or its talk page (which remains open only for procedural and technical matters). Such discussion elsewhere is neither prohibited nor officially sanctioned; where it occurs it is not subject to WP:MONITOR." —Alalch E. 06:17, 12 November 2024 (UTC)

Withdrawing a petition

This has largely been settled through precedent that a petition may only be withdrawn if the initiator is the only signatory. It also doesn't seem like one of the main sources of toxicity for the process. How withdrawal effects the six month timer is still unclear, but this question doesn't seek to address that either way. Sincerely, Dilettante 17:05, 16 November 2024 (UTC)

Should the filer be permitted to withdraw a petition? (Choose one or more). Option 1: No Option 2: Yes, but only if there are no other signatures on the petition. Option 3: Yes, but only if there are fewer than a certain number of signatures (specify). Option 4: Yes, but only if it has not yet been certified. Option 5: Yes, but only within a specific period of time (e.g. 24/48 hours) (specify). Option 6: Yes, at any time. Thryduulf, what does certification mean in this context? If I've been following this process as closely as anyone and don't know, I guarantee the average RFC voter won't. Sincerely, Dilettante 16:49, 8 November 2024 (UTC) It means it's reached the threshold of signatures (currently 25) required to force a resignation or re-RFA. If there is a better term, please use it. Thryduulf (talk) 18:30, 8 November 2024 (UTC) That sounds like the best term to me."Yes, but only if there is no quorum" could work, but that implies this is a vote (or even a !vote), rather than just headcounting. Sincerely, Dilettante 21:32, 8 November 2024 (UTC) Do we actually need option 4? Would people supporting it not just choose option 3 and specify 25? Or is keeping it as is clearer? Thryduulf (talk) 22:33, 8 November 2024 (UTC) I think it should be kept to make it an explicit option. To balance out how wordy that makes it, option 6 has a snowball's chance in hell of passing so I'll strike that. Sincerely, Dilettante 22:48, 8 November 2024 (UTC)

Simultaneous petition limit

There is no specified reason for this to be part of the RfC.

How many petitions can be open at once? Option 1: Unlimited (no change) Option 2: 2 petitions Option 3: 5 petitions Something else (specify) This question is obviously likely to be influenced by the others: if a petition is likely to only be open for a week, 2 at a time is probably plenty. If it's likely to be more like a month, we would probably want more like 10-12. Given a user may be a signatory on up to five concurrent petitions, it'd make no sense to set the number of active petitions lower unless this RFC is trying to directly override the consensus previously established. I'ved added an option for five petitions for that reason. Sincerely, Dilettante 16:39, 8 November 2024 (UTC) I'm not sure what problem this is meant to solve with the current recall process? theleekycauldron (talk • she/her) 21:31, 8 November 2024 (UTC) Pinging Animal lover 666 since they added this. Sincerely, Dilettante 21:36, 8 November 2024 (UTC) The user who created this, User:Animal lover 666, has since edited, but has not commented here. If you'd like to comment, please uncollapse this section. Sincerely, Dilettante 17:06, 12 November 2024 (UTC)

Can an administrator voluntarily opt into a RRFA?

per discussion, I don't think this is really within the scope of the upcoming RfC. Let's get involuntary recall working before we talk about voluntary reconfirmation. theleekycauldron (talk • she/her) 23:58, 9 November 2024 (UTC)

Do we want to clarify if an administrator can voluntarily go through the RRFA process? Option 1: Yes Option 2: No This question comes up in two places - first if an administrator decides to go through the RRFA process before the petition reaches the required numbered of signatures. The second place is to allow administrators who voluntarily wish to go through a reconfirmation of administrative privileges (the RRFA process has a lower threshold to retain the privileges). --Enos733 (talk) 17:34, 8 November 2024 (UTC) This partially intersects with Options 4 and 5 of § Closing a petition. I think it should be distilled into only addressing the "second place". —Alalch E. 18:12, 8 November 2024 (UTC) If we decide to specify this, we'll need to include whether an RRfA when there is no petition resets the 1 year timer. Sincerely, Dilettante 21:34, 8 November 2024 (UTC) We're already asking whether admins can short-circuit the petition process and just jump straight to RRfA in another question. If the remaining question is whether admins can RRfA whenever, I don't think that's relevant to fixing the recall process. theleekycauldron (talk • she/her) 06:04, 9 November 2024 (UTC) I believe the entire procedure is important to the recall process (including who can use the process). Also, the question raised by Dilettante should be addressed if we do allow voluntary recalls. - Enos733 (talk) 20:54, 9 November 2024 (UTC) The entire procedure is important, but I don't think this is a question that this RfC needs to answer. We should address this when it comes up, because otherwise I'm worried about cluttering up this RfC. theleekycauldron (talk • she/her) 20:57, 9 November 2024 (UTC)

Grandfather clause

Merged with question 1. Sincerely, Dilettante 20:36, 11 November 2024 (UTC)

May petitions be started when the bulk of the evidence stems from prior the creation of the admin recall procedure? See Wikipedia_talk:Administrator_recall/Archive_1#Grandfather_clause?. I'm not convinced this needs to be part of the RFC, but pinging Robertsky Sincerely, Dilettante 22:56, 8 November 2024 (UTC) @Dilettante thanks for the ping. I think this can be rolled into question 1 as an option. – robertsky (talk) 01:25, 9 November 2024 (UTC) @Dilettante Upon reading the question you pose here, I think you are doing my original text dirty. My emphasis is that if you want to open a petition, do it after a new ANI conversation as the option or possibility of recall wasn't present before. I would have no problem with you opening a petition about Graham87 after his recent use of User block with a new ANI thread or opening one outright that goes along the lines, 'hey guys, look at <this recent activity>. I don't think this is working out despite past issues raised here and assurances given at <link to past discussions>, can we get a petition open?' – robertsky (talk) 06:11, 9 November 2024 (UTC) Robertsky, if you'd like, you can rewrite the question or merge it; I don't see a way to merge it while preserving the nuance of what you're saying, and don't want to misinterpret you. This is an open workshop after all. Sincerely, Dilettante 17:14, 9 November 2024 (UTC) @Dilettante it is already present as options in question 1, option 2/2b/3. – robertsky (talk) 17:44, 9 November 2024 (UTC)

Resigning before a petition is certified

Per my comment below, I don't think this is within the scope of this RfC. Constraining bureaucrat discretion as to what constitutes "under a cloud" is an incredibly thorny question to make one question of many in a large RfC, and not one directly related to how recall works. theleekycauldron (talk • she/her) 07:46, 16 November 2024 (UTC)

Question 1: If an administrator who is the subject of a recall petition resigns their adminship before it gathers enough signatures to require a re-RFA, should that administrator be permitted to regain the tools by request at Wikipedia:Bureaucrats' noticeboard? Option 1: No Option 2: Yes, but only if there are fewer than a certain number of signatures (specify) Option 3: Yes, with some other restriction (specify) Option 4: Yes, with no restrictions If a requirement to give advanced notice is enacted in #Opening a petition, it seems logical to me that whatever is decided here should apply equally to an admin who resigns during the period between notice being given and the petition starting. I don't think we need to specifically ask a question about this? Thryduulf (talk) 06:04, 11 November 2024 (UTC) Question 2: Should bureaucrats have discretion when implementing the rules established in question 1? Option 1: No Option 2: Yes Question 3: If an administrator as described above stands again at RFA or in an admin election, which thresholds should apply? Option 1: Standard thresholds, as if they were applying for adminship for the first time Option 2: Lower thresholds, as if it were a re-RFA/election following a successful petition These scenarios do not seem to be covered at present. Thryduulf (talk) 21:43, 10 November 2024 (UTC) Questions 1 and 2 are currently "it's up to the bureaucrats what constitutes 'under a cloud'", which I think is a good enough answer. There's no set protocol for what happens when an admin resigns when there's questions about them at ANI, at ARCA, wherever. It depends on specifics. I don't think this RfC should foresee and tangle with really thorny questions of admin policy that are only tangential to the recall process, it muddies the water. theleekycauldron (talk • she/her) 07:10, 11 November 2024 (UTC) And if an admin resigns during a petition, they would be eligible to run an RRfA within the next 30 days. If the 'crats won't resysop after that, they would no longer be eligible and would have to run a normal RfA. theleekycauldron (talk • she/her) 07:13, 11 November 2024 (UTC) I don't think Question 1 and 2 should be worded the way they are; I'd reword more along the lines of "Does resigning adminship while this petition is active (but before it has been certified) constitute resigning "under a cloud" for the purposes of subsequently regaining tools?" We should be more explicit about what we're stating here, rather than leaving it up to the bureaucrats who are supposed to be interpreting the will of the community, not substituting their own judgment. It should be a binary yes/no -- either the community is categorically saying it is, or categorically saying it isn't. Question 2 is inherently answered by either a "Yes" or "no" answer to a rewritten question 1 if we're using the phrase "under a cloud" specifically. ⇒SWATJester Shoot Blues, Tell VileRat! 22:16, 11 November 2024 (UTC)

Notification templates

Per discussion :) theleekycauldron (talk • she/her) 07:53, 16 November 2024 (UTC)

There seem to be two templates to be used when starting a petition ({{Admin recall notice}} and {{Admin recall notice/AN}}), but there are no corresponding templates to use when closing a petition according to the question I asked at WT:RECALL#Discussion. So, I going to ask why here in this workshop. Personally, I think it would be better to have some community agreed upon wording that could be used every time a petition is closed instead of leaving things up to the person closing the petition; not only for the sake of consistency, but also to avoid any misunderstandings. My apologies if I've posted this in the wrong place or using the format. I guess the question would be: Should there be boilerplate closing templates for notifying administrators who are the subject of a recall petition that it has been closed and for notifying AN that a petition has been closed? Option 1: Yes for both. Option 2: Yes, but only for notifying the administrator in question. Option 3: Yes, but only for notifying AN. Option 4: No for both. -- Marchjuly (talk) 07:18, 16 November 2024 (UTC) @Marchjuly: I think this would be better discussed at Wikipedia talk:Administrator recall and implemented informally. theleekycauldron (talk • she/her) 07:24, 16 November 2024 (UTC) That's fine theleekycauldron. Do I use repost what I posted here there and then delete it from here? Should I strike it all out and use {{Moved discussion to}}? -- Marchjuly (talk) 07:51, 16 November 2024 (UTC) @Marchjuly: I think just start a new thread, I'll hat this one. theleekycauldron (talk • she/her) 07:52, 16 November 2024 (UTC) Truly, if you just ask someone to create that template, they probably will. theleekycauldron (talk • she/her) 07:53, 16 November 2024 (UTC)

Close language

Being handled elsewhere :) theleekycauldron (talk • she/her) 11:27, 20 November 2024 (UTC)

So far, I've seen "successful petition" refer to a petition that forces an admin to undergo an RRFA, but "successful RRFA" refer to an RRFA which does not result in a desysop. The differing outcomes (one being bad for the admin and another being good) are confusing, not helped by the fact that the first R of RRFA is not recall nor reconfirmation, but just "re-". I've had to remind myself multiple times which outcomes refer to what -- maybe we could be more specific with how we describe them? I am not good enough with words to work out how, though. Giraffer (talk) 10:00, 19 November 2024 (UTC) This is being discussed at Wikipedia talk:Administrator recall#Concerns about the word "successful" where it has been agreed that using "successful" for the petition is not appropriate. We appear to be coalescing on "reached the threshold"/"threshold reached" for petitions that reach the required number of signatures to require resignation or a re-RFA. Discussion about how to refer to the outcome of a re-RFA has been more limited but not everybody agrees "successful" is inappropriate for that context. Your comments in that discussion would be welcome. Thryduulf (talk) 12:31, 19 November 2024 (UTC) Oh! Thanks for the link, Thryduulf. Giraffer (talk) 19:23, 19 November 2024 (UTC)

Handling of deleted content

Seeing a lot of nervousness about this question. If someone wants to workshop a single proposal on talk, we can reintroduce that. theleekycauldron (talk • she/her) 11:31, 20 November 2024 (UTC)

How should evidence involving deleted content that is only visible to administrators be handled? Option 1: It is acceptable for a non-administrator to highlight perceived problems with deleted content without checking it Option 2: An uninvolved administrator should be asked to verify evidence brought that relates to deleted content Option 3: An administrator should be asked to temporarily undelete relevant deleted content Option 4: An administrator should be asked to temporarily undelete relevant deleted content provided the evidence is not eligible for revision delete under any criterion except RD6 See comments passim in the currently open petition regarding Fastily. Espresso Addict (talk) 22:57, 12 November 2024 (UTC) Added Option 4 but it probably needs wordsmithing. It spells out the IAR exceptions to Option 3. Sincerely, Dilettante 18:12, 13 November 2024 (UTC) For the record, the inactive admin I cryptically refer to above has posted an oversighted BLP violation. It's worth noting here that if option 3 passes, there is an argument to be made that the content should be unsuppressed, which I'd obviously oppose. Sincerely, Dilettante 18:18, 13 November 2024 (UTC) @Dilettante if you see someone sharing content that has been oversighted, please inform the oversight team and/or arbitration committee as soon as possible. Thryduulf (talk) 18:54, 13 November 2024 (UTC) An administrator should not even be able to share oversighted/suppressed content, surely that requires higher permissions. Espresso Addict (talk) 19:03, 13 November 2024 (UTC) Thanks for the input, but the content is, for now, hidden to non-OSers. My point is that a petition should not be based on content that should not be unrevdelled or unsupressed, but we should be able to open petitions based on deleted pages. Sincerely, Dilettante 20:47, 13 November 2024 (UTC) I don't see how we can work around this problem. Material is deleted for good reasons, and undeletion is inappropriate. Furthermore Ignore all rules is limited to actions for "improving or maintaining Wikipedia". This would not count. Hawkeye7 (discuss) 20:01, 13 November 2024 (UTC) Unproblematic deleted material is usually temporarily undeleted for Deletion review. I don't follow ArbCom cases often but perhaps someone could comment on how this issue is handled there. Espresso Addict (talk) 20:07, 13 November 2024 (UTC) Yeah, there is a difference between things deleted for e.g. non-notability and things deleted for being e.g. OTT personal attacks. The former can be undeleted temporarily, the latter can't. Ultimately non-admins just have to trust admins about what something that has been deleted is. Similarly for things that have been oversighted, non-OSers have to trust OSers that something actually is genuinely non-public information. Thryduulf (talk) 20:55, 13 November 2024 (UTC) Indeed. I'd remove Option 4 because one has to trust that the neutral admin will only restore appropriately harmless material and deny copyvio, attack pages and the like. Espresso Addict (talk) 21:16, 13 November 2024 (UTC) I added it specifically so we make those exceptions explicit, and don't have people at an RfC or later down the road questioning why the letter of the law doesn't match the spirit. If you think that won't be an issue though, feel free to strike it. Sincerely, Dilettante 21:19, 13 November 2024 (UTC) We could footnote something for clarity. Espresso Addict (talk) 21:23, 13 November 2024 (UTC) I think we could just stick with the same rules we use for RfA? We usually trust uninvolved admins to summarize/explain what's in deleted content. theleekycauldron (talk • she/her) 07:48, 16 November 2024 (UTC) I'm very concerned that what happened in Fastily's petition was not rational. Espresso Addict (talk) 13:51, 16 November 2024 (UTC) If the concerns are related to information that isn't publicly available, then the recall process can't handle it. An arbitration case request will have to be opened. isaacl (talk) 06:03, 17 November 2024 (UTC) The successful recall petition against Fastily says otherwise. Espresso Addict (talk) 16:26, 17 November 2024 (UTC) The recall petition met the target threshold without revealing any private information, as far as I know. I don't think information that can only be seen privately should be made public just because someone started a petition. If examining the private information is deemed necessary, then an arbitration case request has to be opened. isaacl (talk) 19:24, 17 November 2024 (UTC)

Lengthy threaded discussion

Not seeing a clear definition here. theleekycauldron (talk • she/her) 11:35, 20 November 2024 (UTC)

In a recall discussion, should lengthy threaded discussion be disallowed? Yes No It's hard to answer this without a definition of "lengthy". Are we forbidding anything beyond "comment, reply, original commenter's response"? Or do we mean "nothing absurd"? If it's more toward the latter end of that spectrum, then standard talk page guidelines and bludgeoning enforcement can probably address this. Also, "recall discussion" should be clarified because it could in theory refer to the petition, RRfA, or both. Thebiguglyalien (talk) 21:19, 19 November 2024 (UTC) The intended meaning of "recall discussion" is the discussion that is currently held under the "Discussion" heading of the recall page, but it might be moved elsewhere or it might not exist as a discrete thing, depending on the #Recall discusion question's outcome. As to the definition of "lengthy", the original proposer of including this question should explain that. This question was spun off from #Discussion section. —Alalch E. 02:20, 20 November 2024 (UTC)

Explanation of signatures

The RfC looks like it'll have a clear outcome so this doesn't need to be asked again

Should editors be allowed to have additional text accompanying a signature? (See related RfC.) Option 1: Yes (no change) Option 2: No, signatures only Option 3: Only a very brief, optional explanation; further discussion goes in the respective section Something else (specify) I don't think this is needed - there is an open RFC elsewhere about whether things other than signatures are allowed, if anything is then the word limits section below will deal with how long it can be. If things other than signatures are allowed by that RFC but we want to restrict what it can be (other than by length) then that should be a separate, focused question. Thryduulf (talk) 13:14, 20 November 2024 (UTC)

Percentage threshold to pass

Everybody agrees that raising the percentage to 75% is not a proposal which needs to be made. Simple majority was also proposed but that is already within the discretionary range ("between 50 and 60% support"), and the distinction is not addressing anything that appears to be in need of getting addressed.

What percentage should a candidate receive at a reconfirmation RFA in order to pass? Option 1: Keep at the current 60% Option 2: Raise to the normal 75% Like many others, I expected that old (quite justified) admin actions unrelated to the immediate concerns would be used as grudges against long-termers and would artifically lower their percentages. We only have one reconfirmation discussion so far but that doesn't seem to be happening, at least explicitly, and many "Support" votes seem to at least partially be in opposition to the recall process generally. Assuming those trends hold, I don't know if 50% + 1 and a crat chat really reflects community support. (Also, a side effect of this change would be that editors needing time to restore community trust would not feel prodded into reconfirmation right away.) What do you think? - RevelationDirect (talk) 02:52, 19 November 2024 (UTC) I am unsure what the rationale was behind prodding in reconfirmation right away. However 75% is ridiculously high. It gives opposers three votes to supporters one. 50% is good enough for real world elections. Hawkeye7 (discuss) 04:05, 19 November 2024 (UTC) That being the real world threshold is actually a really good point! That raises the related question of what the new admin threshold should be. (Either way, I would support having the same cutoff.) RevelationDirect (talk) 11:47, 19 November 2024 (UTC) In the interest of skipping bike-shedding, I would prefer not having this question in the reworkshop as well. We have 15 possible sections, and a number of those need to be cut to not make this process yet another "Very few editors follow along what's happening" and "Nobody knows how the sections affect other sections". In this case, I do not see many people think the threshold is too high, and people in fact lean towards RRFA already being too hard on admins. So this seems to go in the opposite direction, with a clear potential for harm but no clear benefit. Soni (talk) 21:26, 19 November 2024 (UTC) If there is not an emerging consensus to standardize to one threshold to become an admin, I have no objection. If this workshop only allows proposals that make recalls less likekly to pass, I would have an objection though. (Given the lack of replies so far, the former seems likely.) RevelationDirect (talk) 22:58, 19 November 2024 (UTC) I think this would be extremely unlikely to pass, so I don't think this should be one of the core questions that gets asked. theleekycauldron (talk • she/her) 11:36, 20 November 2024 (UTC) You probably have a lot better sense of where the community is than I do and maybe there is mostly interest in tightening the process to ensure that the recall process is only rarely invoked. If that's the route parts of this page are taking, I have no objection to archiving this proposal because I don't want to waste time. What's important here is transparency. Proposals meant to make recalls stricter should explicitly be presented as such, rather than comingled with generic technical improvements. That would also make the goals of discussions here much clearer. RevelationDirect (talk) 15:31, 20 November 2024 (UTC) 50% per Hawkeye7. We require sysoping to have widespread support (ergo the 75% threshold). Similarly, de-sysoping should have widespread support (and neither 25%+1 nor 40%+1 is reasonably "widespread" support; 50% at least indicates half the community has lost faith). Chetsford (talk) 20:57, 22 November 2024 (UTC) I wonder if the 75% for sysop was set so high becaue there wasn't a recall process at that time. RevelationDirect (talk) 23:51, 22 November 2024 (UTC)

Minimum time before petition following resysopping at BN

Pretty broad agreement here and on talk that this doesn't need to be in this RfC. theleekycauldron (talk • she/her) 11:29, 24 November 2024 (UTC)

If a former administrator's tools are restored following a request at Wikipedia:Bureaucrats' noticeboard, should there be a minimum length of time before a recall petition may be initiated against them? Option 1: No (current) Option 2: Yes, 1 month Option 3: Yes, 3 months Option 4: Yes, 6 months Option 5: Yes, 12 months (the same as following a Re-RFA) Note that administrators who resign to avoid scrutiny of their actions are not eligible to regain the tools in this manner. Thryduulf (talk) 17:44, 10 November 2024 (UTC) So for the 12 month option, for example, an admin who resigned once a year before going on a two week vacation and then asked for the tools back when they returned could never be recalled? Why would that even be considered? I don't get it. They wouldn't even need to be doing it on purpose for that effect, it just doesn't makesense that it could have that effect. Similar for the other time periods although that might require more definite, and obvious, gaming. 46.31.205.228 (talk) 19:10, 20 November 2024 (UTC) This is not the place to argue for or against any of the options (this is not the RFC, but a workshop for it), but any administrator may be taken to ANI or arbcom at any time. While in theory an admin could resign and regain the tools annually, nobody has ever done that. As noted at List of resysopped users, Dennis Brown and Boing! said Zebedee (the latter now retired) are the only two users who have had sysop rights restored the record 5 times after resigning, and in both cases those restorations span more than 5 years. Thryduulf (talk) 19:25, 20 November 2024 (UTC) I see lots of people arguing against including options (or whole sets of options) so I'm thinking that actually maybe yes, this is the place to argue that? Is there a reason that you think someone who has temporarily resigned their tools and got them back again should then be immune to recall (for some period of time)? I don't understand the logic. 46.31.205.228 (talk) 19:44, 20 November 2024 (UTC) There is a difference between arguing for and against including options on the RFC and arguing for and against those options. You need to explain why people should not be given the option to choose 12 months rather than why you don't think they should choose 12 months. As for me, I think there should be some period of time in which they are immune because they were by definition not under a cloud at the time they resigned the tools (or were deysopped for inactivity) and they need to be given a chance to demonstrate whether any problems with their actions as an admin from before they handed in the tools still exist now they have them back. Thryduulf (talk) 21:03, 20 November 2024 (UTC) because they were by definition not under a cloud at the time they resigned the tools - that's not true at all, since we don't currently have a system to determine whether someone is under a cloud; currently, the only concrete way to be "under a cloud" that I'm aware of is for ArbCom to declare it (which made sense until now because that was the only way to involuntarily lose the bit.) That is to say - every admin who resigned the bit without an active ArbCom case against them, until today, was presumed to not be under a cloud, because they weren't at any real risk of losing the bit. But now that that's no longer true, we would need B-crats or someone else to examine their history and determine whether they were under a cloud when they resigned (ie. likely to face a successful recall), and we need some way for people to go "no, wait, stop, that person was under a cloud and / or successfully evaded scrutiny at the time by resigning the bit." If you don't want RECALL itself to serve as that mechanism (which would require no protection-period), you need to combine this proposal with how, exactly, you intend to determine whether or not someone resigned under a cloud under the new system; and how an editor could raise the issue of "hey, wait, that person was under a cloud / evaded scrutiny for this thing by resigning" in order to prevent them from regaining the bit or to get it removed if it was mistakenly restored to them. --Aquillion (talk) 17:17, 21 November 2024 (UTC) This already happens - see WP:RESYSOP points 3 and 4. While an arbcom declaration is the only way an editor can be guaranteed to be "under a cloud" it is also applied if someone resigned attempting to avoid scrutiny and/or sanctions in any other way. If they were then the 'crats will not restore the permissions. Thryduulf (talk) 18:40, 21 November 2024 (UTC) I am not seeing this as being the same as an RFA. Wikipedia:Administrators#Restoration of admin tools: If there were serious questions about the appropriateness of the former admin's status as an administrator at the time of resignation or removal, the request will be referred to WP:RFA. In doubtful cases, re-granting of the tools will be deferred until a broader community discussion takes place and is closed. An RRFA petition could reasonably be considered a broader community discussion. Hawkeye7 (discuss) 21:30, 20 November 2024 (UTC) @Hawkeye7 I'm confused about who you are replying to here, but if you comment is regarding the note next to option 5 (which I've just corrected to say "following a Re-RFA" not "following an RFA") then the comment is only saying that the duration of immunity would be the same as that following a re-RFA. Thryduulf (talk) 21:51, 20 November 2024 (UTC) Maybe a month at most. Hurricane Clyde 🌀my talk page! 23:03, 20 November 2024 (UTC) I’d propose adding an option of 14 days after resysopping. Hurricane Clyde 🌀my talk page! 23:07, 20 November 2024 (UTC) I don't think 14 days is anywhere close to long enough to determine whether an admin has ongoing issues or not. If others think that's a time period that could get consensus it can be added but we don't want too many options as that reduces the chances of any one of them getting consensus and can discourage participation. Thryduulf (talk) 01:12, 21 November 2024 (UTC) The duration following an RFA and an RRFA is currently the same: within twelve months of the administrator's last successful request for adminship, request for bureaucratship, or re-request for adminship Hawkeye7 (discuss) 23:19, 20 November 2024 (UTC) Yeah, true, but I'm still confused about how either relates to your previous comment. Thryduulf (talk) 01:13, 21 November 2024 (UTC) This brings up an old question: Is an admin still an admin when he gives up his bit temporarily? In my own head, I'm still an admin because I passed RFA, the community has granted me access to the tools and access hasn't been removed for cause. I just locked up the mop and bucket, but I can access them in a day. To me, an admin that has previously given up his tools could still have a petition against them for as long as they are eligible to get the tools back. There is no mechanism for voluntarily and permanently surrendering the bit, so surrender is not protection against process and is always considered temporary until they pass inactivity thresholds, and Crats have "spoken" on the issue. So long as you can waltz into WP:BN and get the bit back, you are an admin. This means (to me) that you can't game the system by resigning the bit at any time. I would also say that WP:ADMINACCT applies to me when I temporarily resign the bit. Others may see it differently, and there isn't a consensus on this that I'm aware of. The unanswered question is, what makes an admin an admin? The bit itself, or the authority to have access to the bit, as granted by the community? I would argue that the consent of the community does, not the technical flipping from 0 to 1 of the sysop bit. We need a consensus on this issue, and it will answer many other questions. Dennis Brown - 2¢ 01:02, 21 November 2024 (UTC) An afterthought: "Adminship" is a status of the person, not a status of the +sysop bit. Dennis Brown - 2¢ 01:15, 21 November 2024 (UTC) (edit conflict) For the purposes of recall, an editor without the admin bits is not an administrator. They cannot be recalled because they are not using admin tools and so they cannot, by definition, be misusing them. If there are issues with their other conduct then use a different process because all recall can do is take away the bits they don't have. Thryduulf (talk) 01:16, 21 November 2024 (UTC) My point is, we may want to define what an admin is more clearly. I think this is going to get more and more tangled with exceptions and gaming until we finally say that adminship is the status of a person, not the status of a bit. Adminship should be more clearly defined as "access to the bit", not just the bit being active. That IS what adminship really is, after all, we just don't clarify that in policy. We blindly look only at the +sysop flag instead of the person, which is why we have these issues. Again, a little bigger than this one discussion, but many discussions like this would be moot if we tackled the definition problem first. Recalls are for past misuse of the tools, so current bit status is irrelevant. Dennis Brown - 2¢ 01:38, 21 November 2024 (UTC) Recalls are for past misuse of the tools no, recalls are for ongoing misuse of tools. If someone doesn't have the tools they can't misuse them. If they ask for them back and then misuse them, that is the time to recall them. If recall was for past issues then someone who misused the tools 15 years ago but has been an exemplary admin since could be recalled for those ancient sins, which is very clearly completely contrary to the good of the project. Thryduulf (talk) 02:07, 21 November 2024 (UTC) I understand what you are saying, I'm trying to point out the fatal flaws in the current perspective. And it is (recent) past, not future, although policy for recall allows mistakes from 20 years ago, or if someone just doesn't like their mustache, as no rationale is required. That is why I say that while the current system only looks at the BIT, that is the problem. Maybe I'm not explaining it well enough, but my point is that until we start treating "being an admin" as more than just when the bit is active, you are going to have issues and gaming potential. I still maintain that while policy doesn't state this explicitly, an admin is an admin even when he surrenders the bit, so long as he has the authority to request it back and reasonably be guaranteed that he will get it back. To put it in WPO terms, a cop without a gun is still a cop. We need to treat admin as much, and maybe develop a mechanism whereby admin can PERMANENTLY surrender the admin bit, but more importantly, we should expect admins to be fully accountable even when they temporarily give up the bit. The bit is only the tools, the authority comes from the community, the accountability should be the same for any period where they have the bit or can regain the bit with just a simple request. Dennis Brown - 2¢ 02:30, 21 November 2024 (UTC) I understand what you are saying but fundamentally disagree with you, both that this is how it currently is (which is relevant to what we are discussing here) and that it is how it should be. The cop analogy is flawed because the gun is not a fundamental part of being a cop - they can do their job without it (and indeed having a gun is the exception in many parts of the world), but an admin cannot do the job of an administrator without the admin tools. Thryduulf (talk) 02:37, 21 November 2024 (UTC) Then is WP:adminacct in effect while the bit is surrendered? If I tell you, and you know that I gave up the bit but I'm going to reclaim it later, is there any level of behavioral expectation above that of an ordinary editor? Dennis Brown - 2¢ 03:37, 21 November 2024 (UTC) I will bow out at this point, I don't want to distract, although it's always interesting debating with you. I just feel like this patchwork of modifications isn't necessary if we look at adminship as it really is, about the person, not the flipping of a bit. To me, that is a much more accountable way to view it. Dennis Brown - 2¢ 03:44, 21 November 2024 (UTC) (edit conflict) Given WP:ADMINACCT starts Administrators are accountable for their actions involving administrator tools it obviously does not apply. If you want to take a broader view, everything there that does not relate to things only admins can do is actually just what we can and do expect of every editor (respond promptly and civilly to queries about your actions, follow policy, don't attack people off site, etc), even if we don't explicitly say so. In terms of arbitrator committee, the only difference is that they can't remove the admin tools from someone who doesn't have them. Thryduulf (talk) 03:45, 21 November 2024 (UTC) My understanding is that if the bit was surrendered under a cloud, you have to go through RFA to get it back. Normally this only comes up at ArbCom (since until now they were the only ones who could take it away), but I think we could make a reasonable policy that if someone surrenders the bit while there's an active petition or RRfA about them open (and the petition isn't egregiously frivolous), or it's obvious that a non-frivolous petition was about to be started, then they're considered to have resigned under a cloud and have to go through RFA. The one complication is that B-crats would have to enforce this somehow - either there would need to be a way to inform them "hey, that person resigned under a cloud", or the B-crat handling the resignation would need to do a quick check for open / recent discussions surrounding the admin, note if there were any that have any serious chance of leading to a successful recall, and inform the admin "hey, based on this open discussion, you're resigning under a cloud and won't be able to regain the tools without a RFA, sure you want to go through with it?" (And note it down if they agree.) --Aquillion (talk) 05:19, 21 November 2024 (UTC) On reflection, I also think that the sharply negative reaction to this proposal shows that it has no real chance of passing, so I'd suggest discarding it and, if it's extremely important to you, trying to think of an alternative way to accomplish what it's aimed at. This RFC is already going to be massive and we should avoid cluttering it with suggestions that are such obvious nonstarters. --Aquillion (talk) 17:19, 21 November 2024 (UTC) +1, this issue is purely speculative, not one of the top issues that need resolving with recall, and we already have enough top issues that need resolving (e.g., number of signatures, petition length, discussion rules) to fill up an RFC. Levivich (talk) 21:32, 23 November 2024 (UTC) +2, unnecessary. No clear problem are we trying to solve. Regards, Goldsztajn (talk) 22:42, 23 November 2024 (UTC)

Provisions for bad-faith nominations

Pretty clear consensus against running. theleekycauldron (talk • she/her) 11:38, 24 November 2024 (UTC)

The current text of WP:RECALL doesn't cover this; while I think that it is common sense, numerous people on the talk page raised hypotheticals of blatant bad-faith nominations, and, when told that that would "obviously" get sanctioned, pointed out that nothing on RECALL says so. There's no harm in adding a paragraph defining what makes a good faith nomination and noting that ones made in bad faith or which otherwise abuse the process may result in sanctions against the person raising it. In particular, I'd define a bad-faith or disruptive nominations as those whose sole purpose was plainly to harass the the target, which clearly had no reasonable chance of passing; plainly spurious nominations made for retaliatory purposes; nominations that are clearly unrelated to the conduct of the admin in question; or the repeated creation of nominations that egregiously fail RECALL's standards. It might also be worth mentioning that the past behavior of the person making the nomination may come under scrutiny (as at ANI), although the forum for such scrutiny would not be on the petition but on ANI or the like. Again, I think that this is how things would work already, but since people have repeatedly raised concerns about it not being spelled out, there's no real harm in spelling it out. --Aquillion (talk) 17:00, 21 November 2024 (UTC) For specific questions, something like: Should WP:RECALL unambiguously warn that those making bad-faith or disruptive nominations may face sanctions? Should RECALL define bad-faith or disruptive nominations as nominations which had no reasonable chance of passing and whose sole purpose was plainly to harass the the target; plainly spurious nominations made for retaliatory purposes; nominations that are clearly unrelated to the conduct of the admin in question; or the repeated creation of nominations that egregiously fail RECALL's standards or words to that effect? Should RECALL note that the past behavior of the nominator may come under scrutiny at other venues, such as ANI? Something along those lines. --Aquillion (talk) 17:03, 21 November 2024 (UTC) I think this is a good question to ask and your first and third bullets are good as is. Bullet 2 though I think needs a bit of tweaking - it's important that we don't set the words exactly in stone so they can be tweaked if needed. Perhaps instead of proposing wording we should ask something like "Should RECALL define bad-faith disruptive nominations as including the following: Nominations that have no reasonable chance of passing. Nominations whose clear purpose is to harass the target. Nominations made for retaliatory purposes. Nominations that are clearly unrelated to the conduct of the administrator in question." We should allow people to pick all the ones they think should be included so opposition to one doesn't prevent consensus for any. Repeated bad nominations should either be merged into the third bullet ("...the past behaviour of the nomination, including repeated creation of petitions that do not meet the standards or requirements, may come under scrutiny..." or a separate top-level bullet along the lines of: "Should RECALL explicitly note that repeatedly creating petitions that do not meet the standards may result in sanctions for the nominator?". Thryduulf (talk) 18:29, 21 November 2024 (UTC) Since this doesn't affect the operating process, I don't think an RfC is needed for it. The text can be proposed and discussed on the talk page for the recall process. isaacl (talk) 18:49, 21 November 2024 (UTC) Please see edit. —Alalch E. 15:06, 22 November 2024 (UTC) @Alalch E. Where did you propose that edit? The text added is quite verbose. OXYLYPSE (talk) 15:12, 22 November 2024 (UTC) Nowhere. Trim it down to your liking please. —Alalch E. 15:13, 22 November 2024 (UTC) This proposal appears to be contested by User:Hawkeye7 due to a worry that "bad-faith petition" as a conception is against WP:AGF.—Alalch E. 20:11, 22 November 2024 (UTC) I think that this is sufficiently obvious that it does not need to be said. Only really bad behaviors, such as harassment and patent trolling, should figure into the decision on whether to shut the petition down in the first place, and already from the fact that these behaviors are really bad, it is clear that the petition should be closed. The only important point to note is that wanting, attempting, or performing such a close means going against the petition starter in a serious way. The only way to properly close a petition as a "bad-faith petition" is having evidence that the petition starter is deliberately trying to hurt Wikipedia. It centers on the petition starter and requires evidence in the form of diffs and links. There's no drive-by closing of petitions as "disruptive" etc. All in all, better to leave out as a question and see how things go in this regard in vivo. —Alalch E. 20:30, 22 November 2024 (UTC) I agree. We already have provisions about bad faith editing. I do not think we need to add specific language here. - Enos733 (talk) 17:26, 23 November 2024 (UTC) Me too. Levivich (talk) 21:36, 23 November 2024 (UTC) We should just handle this without an RfC if it comes up. Sincerely, Dilettante 18:07, 23 November 2024 (UTC) Superfluous, we have more than enough necessary tools to deal with vexatious acts. Regards, --Goldsztajn (talk) 20:57, 23 November 2024 (UTC)

3-strike system?

Looks like there's significant opposition to running this one. theleekycauldron (talk • she/her) 08:29, 25 November 2024 (UTC)

What if we paired the petitions with a 3-strike system against admins. The idea behind it is a petition is opened for supposed admin mis-conduct. If it gets the requisite number of signatures, a strike is issued against the admin, publicly documented somewhere. Strikes are not permanent and eventually expire after some time (6 months maybe?). Once a petition concludes it cannot be re-opened for conduct that predates the petition's filing. It must only reference conduct after the start of the previous petition. If an admin accrues three strikes, they are sent to RRFA. This should make it less easy to simply oust admins because they made an unpopular action at the time, still hold them accountable if they repeatedly perform problematic actions, and allows the opportunity for the admin in question to make a course correction in the midst of a controversy.—CYBERPOWER (Around) 13:57, 24 November 2024 (UTC) This effectively requires three petitions to meet the threshhold within a six month period before an admin would have to RRfA, and starts the clock fresh each time so that the second petition could only include behavior since the beginning of the first petition and the third petition could only include behavior since the beginning of the second. It requires three times the work from the community. And it would be easy to game...if you get a second petition, stop editing until the first expires, and the third can never happen. Valereee (talk) 17:16, 24 November 2024 (UTC) The strikes can be longer than 6 months. I just threw an arbitrary number out there. If they endure long enough, they wouldn't be as easy to game. —CYBERPOWER (Around) 18:44, 24 November 2024 (UTC) But however long. After the second petition starts, stop doing anything remotely questionable until the first expires. Et voila, the third can never happen. Valereee (talk) 19:25, 24 November 2024 (UTC) This would in essence exempt all current admins from receiving more than one strike for past patterns of undesired behaviour. It also treats all concerns as being equal in magnitude. I appreciate the idea of trying to demonstrate there are ongoing issues, rather than a one-time occurrence. But I think the relative severity of the acts in question needs to be taken into account. isaacl (talk) 20:01, 24 November 2024 (UTC) This should make it less easy to simply oust admins because they made an unpopular action When has this ever happened in the history of Wikipedia? Maybe a long time ago, but in the six years I've been here, I've never seen a cabal of disgruntled editors sink anybody's RFA, or get anybody desysoped by Arbcom, and certainly it hasn't happened with recall. This is not a problem that needs solving, I think it's entirely imaginary. Levivich (talk) 20:04, 24 November 2024 (UTC) In heated agreement with Valereee, Isaacl and Levivich. Regards, --Goldsztajn (talk) 20:35, 24 November 2024 (UTC) Well then, never mind. I thought it was at least worth bringing up. :-)—CYBERPOWER (Message) 20:57, 24 November 2024 (UTC) It's worth discussing if there are any other ideas on how to establish the presence of significant concerns that warrant a closer examination. There have been a lot of ideas over the years (including on this page). So far, nothing other than a petition process has gotten enough support to implement, but maybe something else might gain favour now. isaacl (talk) 22:34, 24 November 2024 (UTC)

Which tag for WP:RECALL?

Worthy question better asked after the coming RfC has concluded.—Alalch E. 14:38, 26 November 2024 (UTC)

Should the page WP:RECALL be tagged: {{policy}} {{procedural policy}} {{guideline}} {{supplement}} {{information page}} Nothing Something else It is no longer tagged {{procedural policy}} following Wikipedia:Administrators' noticeboard#Is WP:RECALL a policy?; probably should be asked at a full RFC, whenever that happens. Levivich (talk) 18:54, 22 November 2024 (UTC) I think it's probably better to ask this after all the RFCs conclude and the page is stable. Thryduulf (talk) 21:53, 22 November 2024 (UTC) Maybe we should start another page to plan the RfC after the next RfC. Levivich (talk) 18:06, 23 November 2024 (UTC) If we create a page, people come up with questions to ask that don't need asking since they try to preempt issues that'll never happen or can be resolved in the course of normal editing (see the closed subsections here, for example). A man staring at a hammer will start looking for nails. Sincerely, Dilettante Sincerely, Dilettante 18:11, 23 November 2024 (UTC) Agreed. theleekycauldron (talk • she/her) 11:37, 24 November 2024 (UTC)

Nominations at Re-RFA

The prevailing opinion is that it's better not to add this question to the RfC.—Alalch E. 23:42, 29 November 2024 (UTC)

How many nominators besides the admin subject to petition should be allowed? 0 1 2 3 No formal limit (status quo; same as RfA) Should nominations be allowed at Re-RFA like they are at RFA? Now that Graham87's is closed this feels like something worth discussing. ~~ Jessintime (talk) 14:47, 20 November 2024 (UTC) The status quo is clearly that they are allowed. What would be the reason to disallow them - what problem would it solve and/or what other benefits would it bring? Thryduulf (talk) 15:05, 20 November 2024 (UTC) For lack of better phrasing, I think it should be up to the admin in question to explain why they should retain their tools, not their buddies. Of course would-be nominators could still do so in the support section. (Also quite frankly I think running an RRFA exactly like an RFA can cause confusion.) ~~ Jessintime (talk) 15:10, 20 November 2024 (UTC) The page currently says A RRfA follows the same process as a request for adminship, but with lower thresholds for passing so RRFAs and RFAs being similar is by design. RRFA candidates will have to make the case for themselves in the questions regardless and people who feel strongly enough to be a nominator would probably post an extended support at the start of the RFA anyway, which is mostly the same except in terms of location. Graham was floating the idea of 10 co-noms, which might be getting into the territory of appearing like admins are circling the wagons, so perhaps the question could be about a numerical cap on co-noms with 0 as an option if you want to proceed with this. -- Patar knight - chat/contributions 16:03, 20 November 2024 (UTC) Now I understand the motivation I could see myself supporting a cap on the number of nominators, although I'm not sure I'd go as low as 0 presenting it as an option would make sense. Thryduulf (talk) 16:17, 20 November 2024 (UTC) I’d say maybe cap it at 2 or 3 co-noms. If it were up to me. Hurricane Clyde 🌀my talk page! 23:00, 20 November 2024 (UTC) There is no limit on the number of co-nominators at RFA. Hawkeye7 (discuss) 23:26, 20 November 2024 (UTC) True, and there is no argument that there is no current limit for re-RFA either, but that doesn't mean we can't introduce one here if there is consensus to do so. Thryduulf (talk) 01:05, 21 November 2024 (UTC) There's no upside to more than 3 nominators at RfA; I've seen comments too many noms if there were more than three. And at RRfA I could see multiple admin noms being considered problematic by some !voters, especially those who've commented about circling wagons and thin blue lines, etc. I think we can leave it to a judgement call by the admin in question. Valereee (talk) 14:23, 25 November 2024 (UTC) Heck even with three noms sometimes people think it's overkill. However, I think in some rare circumstances, it could actually make sense to have more. But as Valereee says, we should be able to trust the person running to determine what's best and what gives them the best chances. Hey man im josh (talk) 14:25, 25 November 2024 (UTC) Rephrased question based on discussion. I believe that this isn't a major issue, in part because the Graham87 RRfA has shown that more noms isn't necessarily intimidating to opposers, so I do oppose asking this. Sincerely, Dilettante 22:12, 29 November 2024 (UTC) I agree that this doesn't appear to be a major issue that needs resolving and thus needn't be asked in the next RFC. Levivich (talk) 22:16, 29 November 2024 (UTC) I'm not going to say this is something that will never be needed (one example is anecdote not evidence), and if it is then it will probably need RFC-level consensus to implement. However, I agree that it does not appear to be needed now so isn't a high priority for this RFC. Thryduulf (talk) 23:15, 29 November 2024 (UTC)