Wikipedia:Requests for comment/Recall petition signature threshold and length

RFC: Admin recall petition signature threshold & length

Question 1: How many signatures should be required to close an administrator recall petition as successful?

Question 2: How long should administrator recall petitions be left open before being automatically closed as unsuccessful?

Currently the threshold is 25 signatures over 30 days. For the sake of the closer, please pick only natural numbers.

"Successful" is the language used at WP:RECALL to signify that the admin the petition is about will need to request their tools back from the community at RFA or the admin elections. "Unsuccessful" is hereby defined, for the purpose of this RfC, as "admin retains tools". GreenLipstickLesbian💌🧸 08:29, 30 December 2025 (UTC)

Survey (Admin recall)

Please answer one or both questions. GreenLipstickLesbian💌🧸 08:29, 30 December 2025 (UTC)

• 40 signatures in 1 week. These two numbers should be related (more time = more sigs), so I can't say this is the ideal pair. I don't care exactly how many signatures we land on, just that the number should be slightly higher than it currently is due to 1. the size of the enwiki community, about 10x that of dewiki, and 2. the way the community approaches these petitions thus far. I do feel very strongly that petitions should be much shorter, ideally a week, at most two. As they are, they do not serve as a running tally of disparate incidents (as they do on dewiki), instead focusing mainly on a single trigger incident, so the current time frame is too long. Toadspike [Talk] 09:01, 30 December 2025 (UTC)

  Looks like the original close of the recall check-in RfC has been overturned. As my !vote was premised on that close, it bears clarifying. Shortening the timeframe could greatly improve the discourse at recall petitions. It would limit the superfluous objections to the petition or process itself in the discussion section and produce a faster result for the subject, and save vast sums of community time. This clarity is sorely needed. (An alternative solution would be to abolish discussion entirely, which I would also support.) Requiring more signatures, the change with the most supports in the check-in, wouldn't solve any of these problems. Toadspike [Talk] 00:34, 1 January 2026 (UTC)

• 25 signatures over 30 days. Per Wikipedia:Administrator recall/Lists#Closed, of the 9 successful petitions, the petition length by days was: 10, 11, 1, 0, 0, 0, 20, 0, 1, for an average of 4.8 days. 14 day petitions would have resulted in one successful petition becoming unsuccessful (Night Gyr), reduction to 7 days would have resulted in a further two unsuccessful (Graham87, Fastily). Some predictive modelling could interpret signature quantity increase (based on exponential/momentum of signing) to estimate how it would effect successful petitions. My guestimate is that on it's own it might not effect much with a 30 day petition, but alongside a reduction to 14 days would probably also reverse the result of two 10/11 day petitions at minimum (if sig increase >30-40% to >33-35). I'm left thinking the proposal is trying to break something that's working as intended, or fix something without knowing how it's broken, given there are no signs of damage. CNC (talk) 10:10, 30 December 2025 (UTC)

  On the note of successful petitions, I'd highlight that when the cases are not clear cut, the community has successfully self moderated. For Necrothesp, the petition was quickly withdrawn, while there were several ambiguous cases that did not proceed to recall, like Pbsouthwood. Soni (talk) 14:12, 31 December 2025 (UTC)

• There's apparently/allegedly consensus to increase the number of signatures and shorten the threshold, which is a ... surprising outcome of that RfC, so I'd go with 30 signatures over 28 days. The alternative to recall is Arbcom, and if someone asked Arbcom to take a sysop abuse case, then 30 good faith Wikipedians co-signing the petition virtually guarantees that Arbcom would take the case. My position remains that 30 good faith Wikipedians is an extraordinarily high threshold just to begin the process of discussing someone's suitability for adminship. The 28 days is to allow time for people to discuss, interrogate, and challenge the claims the petitioners are making. I advocate that it should be mandatory for the petition to remain open for a minimum period, so that petitioners have sufficient time to withdraw their !votes after reflecting on the discussion. The fashion for closing recall petitions as soon as they hit the minimum threshold is helpfully meant -- it's intended to minimise the pain for the target admin -- but it should not continue. For the reasons I've given I strongly oppose any increase above 30 signatures and any drastic shortening of the recall period below 28 days.—S Marshall T/C 10:39, 30 December 2025 (UTC)

  Now that the Dr Vulpes' close has (rightly) been rescinded, I no longer feel any deference towards it so I'll revert to 25 signatures in 30 days which is the status quo.—S Marshall T/C 11:45, 31 December 2025 (UTC)

• 25 signatures over 30 days. It's working. The worst possible outcome in case these numbers are unfair to good admins is a subsequent unnecessary but fair RfA or admin election and a year of peace. ~ ToBeFree (talk) 10:40, 30 December 2025 (UTC)
• No support for shortening timeframe, ambivalent regarding increase by small number (eg 5). Regards, --Goldsztajn (talk) 10:47, 30 December 2025 (UTC)
• Light hand on signatures, significant cut to time frame - 25 signatures is already sufficient to identify that there is a problem here. however, a bad petition sitting in limbo for a full month is not ideal. if I had to throw a dart, I'd throw it at 30 signatures/14 days, but there's flexibility in both numbers there. Tazerdadog (talk) 11:42, 30 December 2025 (UTC)
• 25 signatures over 30 days per CommunityNotesContributor's analysis of the closed petitions. Some1 (talk) 11:47, 30 December 2025 (UTC)
• 25 signatures, 30 days. For the sake of clarity, oppose any other change whatsoever. As for rationale, per CNC's analysis above, and I quote S Marshall's comment below, which says it better than I can: The recall process has been a huge success and the best thing that's happened on Wikipedia for years. It's had no miscarriages. Everyone who got desysopped via recall should have been desysopped. The only person who shouldn't have been desysopped, wasn't. Sysop behaviour has substantially improved now that there are consequences that aren't gated behind Arbcom's hopelessly obscure, obfuscated, and snail-paced process. Also, support 1-year moratorium on recall reform RFCs, let's show this dead horse some mercy. Levivich (talk) 11:53, 30 December 2025 (UTC)

  +1 Recall is working as intended. I also don't think we should be bound by the consensus from a "check-in" discussion. You can't call something a check-in and then convert it to a binding RfC. voorts (talk/contributions) 13:33, 30 December 2025 (UTC)

  I'm not sure there even was a consensus there. Everyone who !voted for "no changes" didn't go down the list and start opposing everything else. ~WikiOriginal-9~ (talk) 14:30, 30 December 2025 (UTC)

  It does look misclosed to me too.—S Marshall T/C 15:11, 30 December 2025 (UTC)

  It's questionable in hindsight as there was overall clearer consensus for no change. The "consensus within" for certain subjects is plausible, ie the bartenderesque part, but this this microcosm doesn't necessarily reflect broader consensus either. Kind of similar to local consensus vs sitewide consensus, which doesn't make it wrong, only that it won't inherently stand up to sitewide scrutiny when under a microscope. CNC (talk) 16:11, 30 December 2025 (UTC)

• 25 signatures, 30 days Recalls shouldn't only be for slam dunk cases. If it takes 30 days to start a discussion, it takes 30 days. And remember, this is to start the discussion, NOT to remove the bits. SarekOfVulcan (talk) 13:46, 30 December 2025 (UTC)
• Q1: 25 signatures; Q2: 21 days: Broadly this process appears to be working ok in capturing and actioning concerns. Shortening the time that someone finds themselves under the process seems fair. (That said, whatever the time limit, anyone reaching that point one or two sigs short of recall would surely feel themselves placed in an awkward position regarding confidence in ongoing admin activity.) AllyD (talk) 14:41, 30 December 2025 (UTC)
• 25 signatures, 30 days. As others have said, the process is working and each successful recall attempt was warranted. The experience to date has shown it does take some time for the ball to get rolling, so shortening it or raising the signature count significantly could neuter the process. Jessintime (talk) 15:35, 30 December 2025 (UTC)
• 25 Sigs, 30 days - Per others, the process is working, and I don't think anyone has made a good case for changing it outside the desire to simply change it. Rambling Rambler (talk) 15:38, 30 December 2025 (UTC)
• 25 signatures over 30 days Recall is working as intended. The close for the check-in was deeply flawed, as every vote for "Option A" should've counted as a vote against all the other options, meaning that the net support for every proposed change should've been negative, and any discussion where 50% says "keep the status quo" should've been closed as "No consensus for change". I'm afraid that this RfC is as flawed as the last one, as we have two open-ended options with infinite possibilities, which leads to an impossible bartender close process. It should be two separate !votes with a finite number of options each. --Ahecht (TALK
  PAGE) 16:30, 30 December 2025 (UTC)

  Respectfully, while it's true that there are technically infinite options, nobody here is a kindergardener, I don't think I need to hold their hand. While I could be wrong, I think we can trust the community not to confine themselves to reasonable suggestions, and I think our fellow editors to accept that the closer will have to round the exact numbers up or down, iff there is, in fact, conensus for a change. (The closer is going to have to bartend, but that's unfortunately unavoidable in RfCs of this type, given that we haven't yet instituted RCV - and while I registered my objections to the framing of the previous RfC as soon as it opened, at least we did get an affirmation that the community broadly supports the existence of recall, possibly with some tweaking. ) GreenLipstickLesbian💌🧸 21:47, 30 December 2025 (UTC)

  On the Internet, nobody knows you're a kindergardener. 😀 Anomie⚔ 21:54, 30 December 2025 (UTC)

• 50 signatures over 2 weeks: To say "it's working" discounts a lot of factors. The threshold, from the start, has always been problematic, and it's clear, based on the previous discussion, there is desire for a change. If someone truly deserves to be recalled, what difference will changing from 25 to 50 make? Hey man im josh (talk) 16:41, 30 December 2025 (UTC)

  What factors does it discount? What is your evidence that the threshold has been problematic? If changing from 25 to 50 will make no difference, why should we change it? Levivich (talk) 17:18, 30 December 2025 (UTC)

  Well... because maybe sometimes editors are honestly confused, or acting on impulse, or not quite understanding the situation, or possibly even just following the crowd?

  m:Community Wishlist Survey 2019/Editing/Keep the lightweight text editor was a petition some years ago for a technical change. It got more than 50 support votes in just five days, and it was preceded by a separate discussion that got more than 50 votes in just three days. Obviously, it's very important and the community is unified, right?

  However, the petition was to:

  1. Turn on some blue-gray buttons
  2. Next year.

  and what most the voters wanted was:

  1. To fix a different menu
  2. Right now.

  I have a hard time believing that any community (including this one) is immune to this sort of response. Processes should be built to account for ordinary human limitations (e.g., misunderstanding the facts or blaming the wrong person). WhatamIdoing (talk) 23:03, 30 December 2025 (UTC)

  Given how contested the more controversial recall petitions have been, I doubt there is substantial reason to believe that similar blind unanimity that occurred on meta will occur here. Katzrockso (talk) 23:09, 30 December 2025 (UTC)

• 25 signatures, 30 days - All the evidence we have points towards this working as intended. Especially with two trying to get the bit back and roundly rejected by the community. Also looking at the recent check in, it seems clear the votes were not really counted in the best way. The clear majority said no change/status quo, but they were not counted as oppose change, and as such reached in my opinion an incorrect conclusion. Judging by the discussions on the closer page I was not alone.[1] PackMecEng (talk) 17:25, 30 December 2025 (UTC)
• With all due respect I think this RfC was premature. It is very difficult to find a workable process consensus from an open-ended RfC. The recall checkin I see as an attempt to gather all possible views, and so needed to be open-ended. Any followups should have been subject to extensive workshopping. I imagine it's a little late to call a halt to this, so I will note that I support any increase in the number of signatures, with a tentative preference for 50. We modelled this process off of the de.wiki process, but our community is far larger. As long as the suffrage requirement is not in any way limited beyond XC, I am willing to bet that any active admin will accumulate 25 signatures at a recall petition. That said, I'm increasingly less convinced that a petition is the correct first step for a recall. The intent behind the process was for bit retention to be determined via RRFA, with a petition process intended to filter out frivolous requests. Raising the signature threshold may help address the discomfort some admins have with recall being used to enforce activity standards higher than mandated at WP:INACTIVITY, but it will increase the risk of desysopping-by-petition. I would like to see us more toward a process with a higher evidentiary requirement but a lower numerical requirement. I also strongly oppose any moratorium on discussion. This is a new process. I support its continued existence but there are kinks to be ironed out. Vanamonde93 (talk) 17:55, 30 December 2025 (UTC)
• 40 signatures, one week One week is historically been the RfA period, it makes sense to use it. And I'm with those who feel there should be a meaningful bar. If proponents can't gather the fifty signatures in a week, then perhaps the situation doesn't call for de-admining.--Wehwalt (talk) 19:17, 30 December 2025 (UTC)

  It's like a political recall. You don't have to get a majority of the voters on board, just enough to bring it to the rest of the voters - and 50 votes would be a very large percentage of most RFAs. We don't need enough signatures to overturn the RFA before even starting it, that would kind of defeat the second part of the process. SarekOfVulcan (talk) 19:57, 30 December 2025 (UTC)

  I find it quite ironic that there is a suggestion that recall will inevitably result in a desysop (or is indeed already in effect a desysop) and this is why it so urgently needs reform, but then now the suggestion to increase the thresholds to guarantee that any recall is a desysop. Katzrockso (talk) 05:23, 31 December 2025 (UTC)

• 25 signatures over 30 days. There has been no substantial reason presented to change anything from the status quo.Katzrockso (talk) 19:49, 30 December 2025 (UTC)
• 30 signatures over 30 days or status quo. There is no need to change the length of a petition and one week is not enough time for proper discussion to take place. fanfanboy (block_talk) 22:20, 30 December 2025 (UTC)
• 25 signatures over 30 days. One of the complaints about the process I've seen is that the petition does not seem to lead to RRFAs. This change would exacerbate that purported issue. As with the previous mega-RfC, the proposed changes tinker with a few parameters, but I haven't seen much evidence that these tweaks will actually address the opposition to the process (and could make issues worse, as this one might). CMD (talk) 22:35, 30 December 2025 (UTC)

  "...petition does not seem to lead to RRFAs. This change would exacerbate that purported issue." Right. 40/50+ signatures over a week seems like it'll turn this admin recall petition process into an RfA-like desysop process. Some1 (talk) 23:57, 30 December 2025 (UTC)

• 40 or 50 signatures over 7 days. First, I want to say that I think the way this discussion has been constructed is unlikely to yield a valid outcome, because it has gone straight to being a poll, in which editors are stating their preferred numbers and potentially digging in, while bypassing a workshop where the ideas could be thoughtfully examined first. Right now (admittedly it is early) the discussion looks headed towards contradicting the consensus of the previous discussion that was closed merely a few days ago. My suggestion, close this as yielding two results: that a significant number of editors want to retain the status quo without changing anything, and some sort of consensus alternative to the status quo – then, have a follow-up RfC, which asks editors to choose between the status quo and the proposed alternative.
  Anyway, I think we should seek a result that is neither "quick and efficient" nor "slow and burdensome", in favor of something that is reasonable. In the previous discussion, there was a consensus that having a recall that fails to reach success can be unfair to the administrator, because if the outcome is that they have not done anything worthy of recall, why should the petition be left hanging there for 30 days? That is unreasonable, and the intention of making it easy to, eventually, accumulate enough signatures is not a valid reason to do it that way. Traditional RfA is for 7 days. AELECT is for 7 days. And our experience with recall, so far, indicates that it is very unlikely to need more than 7 days to obtain enough signatures for a petition that will be successful. It should be 7 days.
  I'm not sure whether it should be 40 or 50 signatures, and I'm OK with either number. Here's what we know from our experience so far: we typically get 25 signatures for a successful petition in about one day. Making a simple-minded extrapolation leads to expecting 50 signatures in two days. However, it's reasonable to expect that there will be some trailing off, after the initial rush, so it might take more than two days. But it won't be difficult or burdensome to get that many in 7 days. Having a threshold that gets met in about one day may serve a desire to be "quick and efficient", but it is unreasonable. Petitions often open and close in the time between when many editors log out, and when they log in the next day. That's not getting a balanced input from the community. And there's no valid need to do it that fast. We need to have confidence that the result of a recall is reached in a thoughtful manner, with representative input from across the community. And we can be confident that 40 or 50 signatures in 7 days is realistic for successful petitions, based on our experience so far. --Tryptofish (talk) 23:36, 30 December 2025 (UTC)

  If we shortened it to 7 days Graham, Fastily, and Night Gyr would not of had their petitions pass. Do you think that would of been the correct outcome? PackMecEng (talk) 23:45, 30 December 2025 (UTC)

  There's no right or wrong answer to your question. It's in the eye of the beholder. I went back and looked at the list of all past petitions, and most successful ones, as I said above, reached the threshold in about one day, so it can be argued that these three were the more controversial cases. --Tryptofish (talk) 23:52, 30 December 2025 (UTC)

  There's no right or wrong answer to your question. It's in the eye of the beholder. What do your eyes behold? You were pretty up to date on those, and all, petitions from what I can tell. PackMecEng (talk) 23:59, 30 December 2025 (UTC)

  Thank you for being so interested in my opinion, but I'm more interested in improving the process than in getting my "preferred" outcome in a petition. My eyes behold an opportunity to make the process better, in terms of being more thoughtful. So there's no need for you to keep asking me about this. --Tryptofish (talk) 00:08, 31 December 2025 (UTC)

  I see, that's to bad. Because it is always interesting to look at the consequences of changes. Those three retaining their admin bits would be the consequence if we drastically changed the current process in the way you are suggesting. I am not a fan of keeping things the way they are just because that is the way we have always done it, but large changes like this usually have to be backed up by some kind of data or similar logic past vibes. I do not quite see how comparing it to a completely different process, RFA, is useful in this situation. It is a completely different process with the ONLY similarity being it has to do with the admin bit. So perhaps you could expand on why you think that is an appropriate comparison? Because the other point to that is most are fairly unhappy with the RFA process as well, for similar reasons to what you expressed here as being helpful to the recall process. PackMecEng (talk) 00:17, 31 December 2025 (UTC)

  If you made it 40 in 7 days, then I'll tell you what will happen. Editors will start pre-recall petition discussions on talk pages, so as to hash out a well-written case and gather support before the actual petition gets published. So when the petition does get listed, there will be a prompt flurry of 40 supports based on a discussion the target sysop might not even have been invited to.

  IOW this idea won't do what you think it will do because of the game theory of it.—S Marshall T/C 00:27, 31 December 2025 (UTC)

  Come to think of it, that can happen under the status quo, or with any combination of signature and day numbers. You're right that this would be unacceptable. We should forbid it, in any case. --Tryptofish (talk) 00:32, 31 December 2025 (UTC)

  Why should it be forbidden? No one is forcing anyone else to sign the petition. Some1 (talk) 00:36, 31 December 2025 (UTC)

  This is really a separate issue to discuss. Which provides evidence for why I feel there needed to be a workshop before starting this RfC. --Tryptofish (talk) 00:40, 31 December 2025 (UTC)

  If you ban it on-wiki then you'll move it off-wiki. You want these decisions to be made on Wikipediocracy? Because this is how you get governance by Wikipediocracy.—S Marshall T/C 11:47, 31 December 2025 (UTC)

  What would work is an explicit requirement to discuss the specific issue(s) with the subject admin first, either on their talk page or elsewhere if there is an explicit link to the discussion on their talk page and allowing sufficient time for the subject administrator to respond in that discussion if they choose to. But As Tryptofish correctly states, this is a different issue to the one this RFC is about. Thryduulf (talk) 18:55, 31 December 2025 (UTC)

  I'm going to put forth a thought experiment that I encourage editors here to try. Imagine a recall-like system for determining site-bans for any editor (not just admins). If there are 25 signatures within 30 days, the editor is site-banned. Those who think the site-ban is unjustified can say so, in the comments section, but cannot directly influence the outcome. The "real" discussion is considered to come only when and if the banned editor files an appeal. I suspect that a lot of us would feel uncomfortable with that. Keeping in mind that all editors are real human beings, and that's true of administrators too, one should consider how that thought experiment would affect one's opinion of admin recall. --Tryptofish (talk) 22:30, 31 December 2025 (UTC)

  Of course, any of us could be indefinitely blocked by one editor.—S Marshall T/C 22:35, 31 December 2025 (UTC)

  That's a glib reply. We only give that blocking ability to persons who meet some pretty stringent criteria (which indeed is a big part of the reason for having recall for those who fail to live up to expectations). But the kinds of petitions we are discussing here are open to editors generally, and there can be plenty of signatures from those who lack enough clue to be admins. --Tryptofish (talk) 22:41, 31 December 2025 (UTC)

  It's never happened, though. The abuse you're talking about is 100% hypothetical. You're proposing to wreck a system that manifestly, objectively, in practice has given the right result every time, over a theoretical possibility that's never arisen.—S Marshall T/C 22:49, 31 December 2025 (UTC)

  What are you talking about? Of course it has happened, that editors who don't have much clue, have been among the 25 who have signed petitions. You say that the practice has given the right result every time, and imply that it always will, as if that is objective fact, agreed to by everyone. And you accuse me of trying to wreck it, when I am actually trying to improve it. (My thought experiment is hypothetical, but that's what thought experiments are.) --Tryptofish (talk) 22:54, 31 December 2025 (UTC)

  a system that manifestly, objectively, in practice has given the right result every time . From the way I look at it, the current system has not given the right result every time. I can't prove this objectively, because there is no objective "right" result in all cases. Thryduulf (talk) 23:58, 31 December 2025 (UTC)

  All right. "Glib", from Wiktionary: "Having a ready flow of words but lacking thought or understanding; superficial; shallow; smooth or slippery; artfully persuasive but insincere in nature; snarky or unserious in a disrespectful way." Tryptofish, that's a direct insult. Retract it please.—S Marshall T/C 13:15, 1 January 2026 (UTC)

  I believe you posted this as a reply to the wrong comment. Chaotic Enby (talk · contribs) 13:32, 1 January 2026 (UTC)

  That's OK, I had no difficulty figuring out that S Marshall was replying to me. Instead of my retracting it, I think I'll see if I can find 24 other editors over the course of a month, who will agree with me. --Tryptofish (talk) 23:44, 1 January 2026 (UTC)

  We already have something very similar to that and it's called WP:ANI. Some1 (talk) 23:15, 31 December 2025 (UTC)

  Another glib but incorrect answer. First of all, very few people would argue that ANI is anything other than WP:CESSPIT. But even ANI does not set an automatic threshold at 25 participants, and exclude editors who disagree from that threshold. Given that my thought experiment is intended to encourage editors to think about the effects on real human beings, I find it noteworthy and sad that there are editors here who regard recall as something-that-must-not-ever-be-modified to such an extent as to see it as a battleground. --Tryptofish (talk) 23:23, 31 December 2025 (UTC)

  I mean when most people disagree with you, it's probably you not them. You keep making wild accusations like something-that-must-not-ever-be-modified or and imply that it always will, as if that is objective fact, agreed to by everyone when no one is saying that, its a strawman argument. What people are saying is why would we preemptively change something if we cannot point to anything wrong besides vibes. If/when the process fails then we can take a look at why and address it, but to just make up claims, sans facts, is why you are receiving so much push back and not much in the way of support. PackMecEng (talk) 15:03, 1 January 2026 (UTC)

  Or it could just be that one side is bludgeoning the process for some reason. Anomie⚔ 15:07, 1 January 2026 (UTC)

  Yeah that is how we are on our who knows how many RFC to change it with results like this one. This is looking close to a snow close at this point with a vocal minority wanting change. PackMecEng (talk) 16:19, 1 January 2026 (UTC)

  If it was just a "vocal minority" then there wouldn't have been more editors supporting some sort of change than editors explicitly supporting the status quo (even if you count those supporting both the status quo and some sort of change as only supporting the status quo). In the current discussion, looking only at bolded comments I see roughly 26:20 status quo vs some sort of change, which even if we ignore all the arguments (which we should not do as this is not a vote, and there are more comments supporting the status quo that provide no evidence/rationale than there are ones supporting some sort of change) then that's not close to a consensus let alone a "vocal minority". Thryduulf (talk) 17:08, 1 January 2026 (UTC)

  one side is bludgeoning the process for some reason I think the reason a few admins bludgeon these discussions is because achieving adminship is hugely important to them and they're terrified they're going to lose it. One would hope that ten obviously meritorious recalls and zero frivolous recalls over a year would be enough hard data to convince them that they're not in danger as long as they don't blow off the community's concerns. Levivich (talk) 17:39, 1 January 2026 (UTC)

  ten obviously meritorious recalls we have not seen this. Thryduulf (talk) 17:41, 1 January 2026 (UTC)

  It's not admins I see bludgeoning here. Anomie⚔ 18:55, 1 January 2026 (UTC)

  Shall we count together again? :-) I count your signature 15 times in this thread, I think that's the most. Maybe back off on accusations of bludgeoning, FUD, bad faith, and other misconduct? Levivich (talk) 19:07, 1 January 2026 (UTC)

  Not my fault people keep posting falsehoods and then arguing with me when I point it out. Anomie⚔ 20:26, 1 January 2026 (UTC)

  There was one arguably frivolous recall, where both signatories agreed to retract it. If anything, that's another point in support of editors being reasonable, and of recall successfully self-moderating. Chaotic Enby (talk · contribs) 05:37, 2 January 2026 (UTC)

  imply that it always will [produce the right result], as if that is objective fact, agreed to by everyone when no one is saying that except S Marshall is saying that - You're proposing to wreck a system that manifestly, objectively, in practice has given the right result every time. Claims like this one are the ones that are being made up, sans facts.

  If/when the process fails then we can take a look at why and address it Many (but not all) editors agree the process already has failed at least once, but some editors are refusing to look at any of the reasons why people think that let alone address anything. Thryduulf (talk) 15:53, 1 January 2026 (UTC)

  Many (but not all) editors agree the process already has failed at least once, but some editors are refusing to look at any of the reasons why people think that let alone address anything. From what I can tell they are looking at the reasons and just disagreeing. PackMecEng (talk) 16:17, 1 January 2026 (UTC)

  There is a difference between disagreeing with another editors opinion and refusing to acknowledge that different opinions (can) exist. Statements like S Marshall made (and to be clear they are not the only one) are manifestly, objectively, in practice the latter. Thryduulf (talk) 17:00, 1 January 2026 (UTC)

  Well, that's interesting and worth clarifying. My reasoning is: (1) Sysop tools are a privilege, not a right; (2) You can't be elected to hold those tools unless the community has confidence in you; (3) The purpose of a recall process is to check whether you still enjoy the community's confidence; And (4) If you don't have the community's confidence, your tools should be removed. All of the people who got desysopped via recall either (a) knew they no longer enjoyed the community's confidence because they'd failed the re-RFA, or (b) the community's confidence was in doubt and the sysop wasn't willing to test it in a re-RFA, and therefore they should have been desysopped. Personally I feel that each of these things is exceedingly obvious and I can't imagine which one could be in doubt. And I think that if you accept all of them then my conclusion's inescapable.

  Where was this miscarriage that you say exists? Who lost their tools who deserved to keep them?

  If you choose to answer that, then I hope Levivich doesn't give you a hard time for answering it. Reasoned debate sometimes does mean long back-and-forth discussions and I hope that isn't madly objectionable.—S Marshall T/C 23:02, 1 January 2026 (UTC)

  Before one can determine whether the system produced the right results, we'd have to agree on what all the results were. For example: Has it made admins feel less valued by non-admins? Has it made any potential RFA or AELECT candidates more interested or less interested in becoming admins? Has it emboldened drama-mongers or resulted in anyone threatening to start a recall? Has it encouraged admins to be more polite in their comments? Has it discouraged any admins from making difficult decisions? WhatamIdoing (talk) 23:19, 1 January 2026 (UTC)

  (3) The purpose of a recall process is to check whether you still enjoy the community's confidence. And (4) If you don't have the community's confidence, your tools should be removed. That is indeed the purpose of a recall process and the outcome that should result that should arise from losing the community's confidence. The problem is that the recall process we have doesn't evaluate the community's confidence in an admin: it identifies only whether any 25 extended-confirmed editors have lost confidence in you, or think your adminship should be reconfirmed or dislike you (for any reason) or like adding their names to things or dislike the concept of administrators or think you haven't been active enough for their personal taste or for no reason at all. This is regardless of what anybody who isn't one of those 25 people think - even someone who unquestionably has the confidence of the community could find 25 people within 30 days supporting a petition against them.

  All of the people who got desysopped via recall either (a) knew they no longer enjoyed the community's confidence because they'd failed the re-RFA, or (b) the community's confidence was in doubt and the sysop wasn't willing to test it in a re-RFA, and therefore they should have been desysopped. If recall and RFA were working as intended then this conclusion would follow from the premise, but neither are so it does not - regardless of what I thought of my chances of success I certainly wouldn't want to stand at RFA immediately after having mud thrown at me for a month with no opportunity for anyone to influence what did and did not stick (or was even relevant to anything).

  I don't have time now to find the comment, but a while ago I analysed all the petitions we'd had up to that point (8 or 9 I think) and analysed whether the outcome reflected the consensus of all the discussion on the petition, not just the supporters. I don't remember the specifics but I think it was only about a 60%-70% match.

  However, that it is even possible to have a rational discussion between good faith editors who disagree with the outcome shows that it is unquestionably not objectively producing correct results every time. Thryduulf (talk) 23:42, 1 January 2026 (UTC)

  Who got desysopped who shouldn't have been? Show me.—S Marshall T/C 23:53, 1 January 2026 (UTC)

  If you are asking that question in that manner then you very clearly have not read and understood my comment. I that circumstance I choose not to waste any more of my time by responding further. Thryduulf (talk) 00:02, 2 January 2026 (UTC)

  Me: All the recall decisions so far have been objectively right.

  You: No they haven't, some have been wrong.

  Me: Show me which one was wrong.

  You: Bah, you're not listening and I'm done talking to you.

  Not the greatest piece of reasoned debate ever, perhaps.—S Marshall T/C 01:29, 2 January 2026 (UTC)

  If you think that No they haven't, some have been wrong is an accurate summary of the point I was making in my long comment then you are demonstrating that you are indeed either not listening or not understanding. Thryduulf (talk) 01:35, 2 January 2026 (UTC)

• I'm very sorry for being so stupid. Help me understand you. Do you agree with me that recall has always desysopped the right people, or do you feel there's ever been a miscarriage?—S Marshall T/C 01:54, 2 January 2026 (UTC)

  As explained, by myself and others, it is not possible to say objectively whether there has or has not been a miscarriage because the "right" outcome for each petition is subjective. Per Tryptofish elsewhere in this discussion, whether there has or has not already been a miscarriage is also the wrong question. The correct question is whether the current setup allows for miscarriages to happen, and as I and others have repeatedly explained the answer to that question is unquestionably "yes", for multiple different reasons. As this is just re-explaining things that have already been explained multiple times by multiple people in multiple ways I do not intend to spend more time on this discussion. Thryduulf (talk) 02:04, 2 January 2026 (UTC)

  All decision-making processes, from Wikipedia to the scientific method, from corporate management to courts of law, allow miscarriages to happen. AfD sometimes makes the wrong decision, so we have DRV. RFC sometimes makes the wrong decision, so we have RFC close reviews. Blocking decisions aren't exactly infallible either; a huge proportion of long term, good faith editors have a stupid block in their block log that can't be erased. (An indef block harms someone far more than a desysopping does, and we apply indefs randomly and on whim.) RFA sometimes makes the wrong decision, so we have recall. And as you rightly say, recall will, eventually, make the wrong decision. At that point we'll do the usual and have a huge sprawling discussion in a central place that goes on for too long and generates far too much text, but eventually, after everyone's been heard, produces a fudge of some sort. We don't wreck working systems because they could theoretically miscarry. We only modify systems where there's evidence that they consistently aren't working.—S Marshall T/C 09:35, 2 January 2026 (UTC)

  "who regard recall as something-that-must-not-ever-be-modified" That is not true, for me at least. I'm not opposed to scrapping the entire petition process in favor of a "performance review" system where admins would be required to file for a RRfA/Request to Retain Adminship every, let's say, 24 months, if they wish to retain their administrator privileges. (This would for sure help with admin WP:INACTIVITY, as admins who are inactive would most likely not file RRfAs.) I'm sure that this is a very unpopular idea, and that admins probably prefer petitions over performance reviews (which is completely understandable; again, I'm not opposed to the current petition process and think it's working fine as is). Some1 (talk) 17:43, 1 January 2026 (UTC)

  Even ignoring the issues of capacity for that many re-RFAs, the most recent voluntary reconfirmation RFAs received oppose votes on the grounds that they were wasting the community's time. That is not fair on the administrator concerned and above all else a process for de/readminship must be fair to all parties (this is my overriding goal in all my comments on these discussions, the current system is not fair to subject administrators). There is also no evidence that admin inactivity is a problem that needs a solution. Thryduulf (talk) 17:51, 1 January 2026 (UTC)

  Golly gee whiz, I guess I should be happy that my comment has attracted enough replies to be visible from outer space. Must have touched some nerves. So I'm going to repeat what I've already said, that this RfC has become unproductive, with editors (not all of them, but too many) taking entrenched positions and just arguing with each other with little possibility of agreement in sight. We are going to end up with a plurality that will be misrepresented as a consensus. I think it has become a waste of time to try to improve the recall system in hopes of preventing a future bad outcome. That's because a lot of editors (not all of them, but too many) are entrenched in the illogical (and frankly, idiotic) position that, because we have had a number of recall petitions so far, and none of them has resulted in a generally-accepted case of a bad result, it is therefore unlikely that a bad result could ever happen in the future, and so any proposal to make a change that might ward off a potential bad result in the future is just dealing with an unproven hypothetical, and consequently is going to break a system that is already near-to perfect. (I'm reminded of Ruth Bader Ginsburg's quote about the folly of throwing away one's umbrella because, so far, one hasn't gotten wet.) Maybe in the future, we just won't have any malfunctioning recalls, and it will be OK. Or maybe, we will eventually have a recall that reaches 25 in a month, but there will be a consensus that it was a miscarriage of justice (and maybe the admin will pass a reconfirmation RfA, or maybe the admin will just leave Wikipedia). When (and if) that happens, it will (sadly) be a different environment for having discussions about improving recall. That's unfortunate, but the reality is that those of us who think we can see a trainwreck coming will have to wait until it gets here, before we will be able to have an intelligent conversation about how to prevent it from happening again. Happy New Year, y'all! --Tryptofish (talk) 00:05, 2 January 2026 (UTC)

  We don't wreck working systems because they could theoretically miscarry. We only modify systems where there's evidence that they consistently aren't working. If we are going to accept that argument, then it's only fair to point out that 2-3 of the 9 admins who who have been recalled weren't, at the time of their recall, harming the wiki in any way with their admin tools. -- LWG ^{talk (VOPOV)} 03:13, 4 January 2026 (UTC)

• 25 signatures over 30 days Bad RFC. After spending several hours today reading all 10 past recall petitions and a lot of this discussion, I see no reason to think tweaking numbers will result in better outcomes for the recall process. EDIT: as the close that prompted this RFC has been rescinded this RFC should now also be closed and this issue tabled until clearer workshopping takes place. -- LWG ^{talk (VOPOV)} 03:39, 31 December 2025 (UTC)
• 40 signatures over 7 days – per Tryptofish. This is a reasonable proposal to raise the burden on the petitioners, and at the very least, more adequately reflect the gravity of what is a de facto desysop vote. Yours, &c. RGloucester — ☎ 04:15, 31 December 2025 (UTC)
• 25 signatures in 30 days - The process works. A majority of editors in the previous RFC supported no change to the process. Yet the close redefined many of those comments as "Don't abolish recall", and arrived at a spurious "consensus for change". The closer's talk page has several good faith contributors asking for a re-close. Instead, there is now digging of heels and this parallel RFC that presumes consensus for change. Preserve the status quo please.

Additionally, comments in the last RFC were disregarded unless editors explicitly opposed every single proposal they didn't prefer. Therefore, I'm strongly opposed to any increase in signatures, and opposed to any shortening of time. 25 signatures in 14 days is the only other proposal I'm neutral on. Soni (talk) 05:23, 31 December 2025 (UTC)

• 25/30 — not broken/don’t fix. • a frantic turtle 🐢 06:21, 31 December 2025 (UTC)
• 25 signatures over 30 days. Increasing the number of signatures will only make the petition process even more of a de facto desysop, despite it not being adapted for that purpose and only intended as a stopgap for frivolous petitions. In the previous RfC, more people supported A (no change) than supported proposals to increase the signature requirement/decrease the duration, and the close to that discussion (finding the opposite consensus) was heavily contested.
  I'm open to reforming the RRfA part or replacing it with a different process, but that's a question for another day. Chaotic Enby (talk · contribs) 07:42, 31 December 2025 (UTC)
• 25 signatures in 30 days. I do have qualms about aspects of the Recall/RRFA (e.g. not solely being based on inactivity, ability to waive post-RRFA immunity if successful), but the threshold and duration are fine. It's high enough to weed out non-serious cases but not so high that it would become a double RRFA process. It's also long enough to allow for discussion and disincentive pre-campaigning while not being overly long. -- Patar knight - ^chat/_{contributions} 08:19, 31 December 2025 (UTC)
• 50 signatures, don't really care about the number of days to leave it open for, but there needs to be a 3 day hold from opening the petition before the second and subsequent signatures can be added. A wait time for emotions to cool is appropriate before what is de facto a vote to desysop. Stifle (talk) 09:10, 31 December 2025 (UTC)
• 25 signatures over 30 days. The current process is fine. WP:AINTBROKE applies here. Sugar Tax (talk) 12:05, 31 December 2025 (UTC)
• 25 signatures over 30 days. no big deal. -- SashiRolls ^{🌿 · 🍥} 12:11, 31 December 2025 (UTC)
• Reduce to 7 days. For the petition stage with its 25-signature bar to go on for up to a month, while an actual (R)RfA with dozens and dozens of !votes is wrapped up after only a week, has never made much sense to me. And from the petitions we've had over the past year, it makes even less sense to me, as the bar is usually met within a matter of days and hours. (Not surprisingly, seeing as most petitions come immediately off the back of some WP:AN/ANI fracas.) Seven full rotations of the Earth is sufficient. SuperMarioMan (talk) 12:36, 31 December 2025 (UTC)

• Also, increase signatures to 40 or 50. Given the pile-on effect from WP:AN/ANI, 25 signatures isn't much of a mandate. Also, oppose early close of this RfC simply because there was a backlash about the way the last one was closed. These questions need to be settled one way or the other. SuperMarioMan (talk) 20:39, 31 December 2025 (UTC)

• NaN votes over Infinity days 25/30, the system is working fine as-is. REAL_MOUSE_IRL talk 14:12, 31 December 2025 (UTC)

  0 is a valid natural number, we should just switch to a 0 votes over 0 days RECALL for the lulz :) Sohom (talk) 16:25, 31 December 2025 (UTC)

• 25 signatures over 30 days The existing system is working as intended. – SD0001 (talk) 14:17, 31 December 2025 (UTC)
• Retain current system. Carrite (talk) 16:43, 31 December 2025 (UTC)
• More signatures in less time. I don't have specific figures in mind, but it is clear from all the prior discussions that the current system is not working as intended - if it were we'd have had a mixture of successful and unsuccessful petitions and most of those recalled would have chosen to stand for re-RFA/election. Thryduulf (talk) 18:58, 31 December 2025 (UTC)

  Agree with this. JuxtaposedJacob (talk) | :) | he/him | 21:42, 1 January 2026 (UTC)

• 25 signatures over 30 days As it works, don't fix it. Andrew🐉(talk) 20:47, 31 December 2025 (UTC)
• 100 signatures in 14 days. It seems like most petitions that get to recall easily get 25 signatures in roughly 2 days. by the time a recall petition is brought there's been extensive discussion at ANI, and people are all riled up. I'd like to see the number high enough that people who didn't participate in whatever discussion lead to people getting riled up in the first place are needed to weigh in. I would also like the time frame to be long enough that people move past their initial anger, but not so long that there's an axe hanging over the person's head for an entire month. ~ ONUnicorn^{(Talk|Contribs)}problem solving 20:50, 31 December 2025 (UTC)

  That is pretty far out of left field. Impressive. PackMecEng (talk) 22:04, 31 December 2025 (UTC)

  It's the RRFA that gets the 100 signatures, not the petition! Why is this so hard to figure out? SarekOfVulcan (talk) 23:05, 31 December 2025 (UTC)

  I also think that this should be the process; there should not be a RRFA. If you get 100 signatures in 14 days that should be it. Perhaps a provision that you can try a new RFA in 6 or 12 months. I picked 100 signatures because it's been at least 10 or 11 years since any RFA has passed with less than 100 signatures. Meaning if 100 people sign a recall proposal, that's a pretty clear sign that you would not pass a RFA at that time. ~ ONUnicorn^{(Talk|Contribs)}problem solving 23:29, 31 December 2025 (UTC)

  There have been RFAs that have had more than 100 opposes and still been successful - this is true, so it's not out of the question that a recall petition could garner 100 signatures and a RRFA could be successful, but I find that highly unlikely. ~ ONUnicorn^{(Talk|Contribs)}problem solving 23:33, 31 December 2025 (UTC)

• One signature. I posit that that's no different than what we currently have, between (among other factors) the user who's made no edits in over a year except sign recall petitions and oppose an RRFA, the user who's signed every petition open longer than a day, the user blocked for sockpuppetry, and that there's no provision at all in the design that works against canvassing and meatpuppetry. —Cryptic 23:20, 31 December 2025 (UTC)
• 25 signatures over 30 days The system is working as intended. Changing it now would be a governance failure. →StaniStani 23:27, 31 December 2025 (UTC)
• 35 signatures over 30 days. Recall is largely working well, but +10 signatures wouldn't hurt as a requirement. While the current system is fine, it seems that slightly more people are paying attention to admin recall than expected, so I wouldn't complain about a slightly higher threshold to reflect this reality. Strongly opposed to cutting shorter the time a petition is open; if there's a desire to make the petition process harder, it should be via more signatures, not via artificial deadlines when there's often discussion to be had after a recall is proposed and people can be out or not paying attention. SnowFire (talk) 00:28, 1 January 2026 (UTC)
• 25 signatures over 30 days The process has worked very well, so there is no good reason to change it. It is very interesting that almost all of those here who want to make the process more difficult are admins. Ktrimi991 (talk) 01:41, 1 January 2026 (UTC)
• Support any increase in signatures or decrease in timeframes. I'm concerned about the process's vulnerability to hardcore abuse, gaming ECP subtly is part of the ordinary course of business for some sockfarms. MER-C 12:17, 1 January 2026 (UTC)
• 40 signatures over 7 days (or some movement in that direction). It may be that so far no admin has been subjected to this process wrongly, but that doesn't mean that it won't happen in future. The current procedure effectively allows 30 editors to remove an admin, which seems to me an unreasonably low bar. But really I think the number of signatures or days is not the most important issue here: what I would like to see is for there to be a mechanism for editors to oppose recall petitions, and for the recall not to take effect unless at least a certain proportion of commenters are in favour of the recall. That would be much more effective in preventing abuse of the system than tinkering with the number of signatures or days. Dionysodorus (talk) 13:43, 1 January 2026 (UTC)
• 40 signatures 30 days. The current time frame is adequate enough for a decision to be made but the current signature count is not as high as it should be so increasing it to 40 signatures in 30 days seems a good solution. GothicGolem29 (Talk) 16:23, 1 January 2026 (UTC)
• Oppose any change – 25 signatures over 30 days. Copying reasoning from my "Recall check-in survey" response: When reviewing the recall results so far, the system appears to be working as intended, and I have seen no indication that it will fail to keep working as intended in the future. The current requirements are reasonable for demonstrating adequate concern to require an RRfA. fifteen thousand two hundred twenty four (talk) 17:21, 1 January 2026 (UTC)
• Support Change: to increasing number of supporters (and fine with shortening the time) but increasing the numbers is the only way to make this closer to working. It does not work (and apparently is not meant to work) as a consensus process, yet it seeks to overturn and in reality will regularly overturn consensus. So, one of the remedies for such a ham-handed and ill-fitting vote process is to increase the sample size of the electorate (it is a vote process) to more likely reflect a community consensus. (I'll support any of the natural numbers above that increase the support numbers.) More votes required will also mean more due process. If some don't like the process of arbcom, just remember, it is a feature of those who just want their way in government or administration to dispense with and deny due process. -- Alanscottwalker (talk) 18:03, 1 January 2026 (UTC)
• 10 signatures 30 days  Tewdar  19:39, 1 January 2026 (UTC)
• 40 signatures in 14 days: 30 days is way too long, but 7 days is a little short. Someone could be on vacation for a week, that's a pretty common thing. I feel like deciding on the number of signatures should be less vibes-based, but 25 does seem slightly low. Gnomingstuff (talk) 22:15, 1 January 2026 (UTC)
• 40-50 signatures over 7 days – per Tryptofish. Any admin needing to be recalled can reach that threshold easily, which satisfies the need for recall to begin with. Some have hit 25 in a day. The shorter period is simple because 30 days isn't necessary to get the result, and dragging it on isn't fair to anyone. Dennis Brown - 2¢ 01:19, 2 January 2026 (UTC)
• 25 signatures over 30 days: The status quo is working. If anything increasing the number of signatures would prolong the process as every case we have had so far has reached the threshold on less than 21 days (or resulted in resignation) and all but one have been completed in less than 14 days. Reducing the period would be unfair to regular editors who may not edit daily or may take 2 to 3 weeks off for vacation (the usual length of vacation in most of the industrialised world) or because they are busy. I'd be okay with 50 signatures in 30 days (but no more than 50) but shortening the time frame is a no. Wellington Bay (talk) 03:49, 2 January 2026 (UTC)

• 25 signatures over 30 days. A reasonable time for a petition, enough signatures to ward off vexatious petitions but few enough to move most cases to a RRfA. Hawkeye7 (discuss) 04:08, 2 January 2026 (UTC)
• 25 signatures over 30 days. Partially per Hawkeye7. Requirements for petitions should not be too onerous so that even potentially controversial petitions can be discussed in full, while not being too low to basically make any gripe lose admin bits unless recovered afterwards. Existing requirements are on the low end of the Goldilocks zone. Can be a bit more signatures or a bit less time (e.g. 35/30 or 25/21, not 35/21) but these changes are not going to make a substantial good impact so we can just as well stay where we are. Also, to those who want much stricter requirements: admin bits are privileges not rights, and they basically were rights if you weren't caught in misconduct before. I see proposals like these as a backdoor way of introducing the state before recall. Szmenderowiecki (talk · contribs) 06:04, 2 January 2026 (UTC)
• Doesn't need 30 days - I think we've seen that there are warts with the current process, but just to address time, 30 days for RFCs was to allow time for editors who might have an opposing (or different) view to find the discussion and contribute. In the case of recall, it is neither a discussion, nor does it allow for contrary views to be considered in its closure. Indeed, consensus is nowhere to be found in this petition process. As such a week or 2 should be plenty. If RFA can achieve an outcome in 7 days, surely a recall petition can. --- As for the question of signatures, it's probably immaterial due to the lack of concensus process in the petition model. That said, 25 seems awfully low considering the the petition appears have seemingly become a fait accompli on its own. 100 in 7 days seems the top threshhold (we have a special page for that). So, someplace in between, around 60-ish would seem about right. - jc37 14:07, 2 January 2026 (UTC)

To be clear, I'm opposed to "the status quo", and think that some change is in order. - jc37 14:29, 2 January 2026 (UTC)

• 25 signatures over 30 days. Not convinced that these standards are in any way failing. JoJo Anthrax (talk) 15:53, 2 January 2026 (UTC)
• 25 signatures over 30 days per CNC. In addition, I think it might be best to return to workshopping recall after a couple more recalls have been done since the check-in to me seems to not have a clear consensus on what to do, so we should keep the standards we have now as the status quo. If this option has no consensus or consensus against, my second option is 40 signatures over 14 days since I felt that 25 was sometimes too quickly achieved, and I also don't think its realistic for a petition to languish for 30 days.Gramix13 (talk) 19:57, 2 January 2026 (UTC)
• 40 signatures, 14 days There is a stress on the administrator the entire time a petition is active. --Enos733 (talk) 04:57, 3 January 2026 (UTC)
• 25 sigs, 30 days, or simply raising just the amount of sigs and not the amount of days. It ain't broken, and unless somebody brings out proof that an admin probably should not have been recalled but was because of such a low limit, I will be supporting this. Though if the only way to get consensus is raising the number of sigs, I will be OK with that, but anything shorter than 30 days is too short and may shut out people that are still deciding on whether to recall or not when they get caught by a one or two week limit. ~2025-31733-18 (talk) 10:47, 3 January 2026 (UTC) ( Blocked sockpuppet) voorts (talk/contributions) 18:39, 19 January 2026 (UTC)
• 10 signatures over 14 days. NotAGenious (talk) 13:26, 3 January 2026 (UTC)
• 25 Signatures over 30 days. aka leave the process as is. Very unconvinced by the arguments those wanting to change the process. Looking from afar, all the successful recalls have been well and truly justified. The admins trying to make the recall process harder to the point of impossibility give a real strong Blue wall of silence-vibe I'm afraid. --~2026-64418 (talk) 05:11, 4 January 2026 (UTC)
• 30 signatures over 15 days. With one exception, the current threshold of 25 sigs/30 days has been met within 15 days every time; I'm ambivalent on the 30 signatures and would be okay with the status quo of 25. I also take severe umbrage to the implications that attempts to change this process - which is, for all intents and purposes, the desysop - are intended to "protect bad admins" or some other nonsense. As it sits right now, Recall has essentially become the firing squad; RRfA/re-election merely the hastily-drawn-up tribunal to retroactively justify it. —Jéské Couriano v^_^v ^{threads critiques} 05:26, 4 January 2026 (UTC)

  Or maybe, just maybe, the fact that both admins choosing to run being voted out is evidence that they didn't have community support, instead of being a "hastily-drawn-up tribunal"? Especially since, in the latter case, there was more than a month between the recall petition and the election, so I don't see it as anything close to "hastily". Chaotic Enby (talk · contribs) 06:13, 4 January 2026 (UTC)

• 25-30 sigs, 28-30 days. The purpose of this process should continue to be avoidance frivolous petitions, it isn't supposed to be the discussion of the target. And it seems this has come up over and over again with the same result already? — xaosflux ^Talk 14:09, 4 January 2026 (UTC)

  The purpose of this process should continue to be avoidance frivolous petitions that was clearly the original intent, but there is no consensus that this is either how RECALL currently is being used or that this is what the purpose should be going forwards (some are proposing changes so that is unambiguously used in that way, others are proposing changes so that it does a better/fairer job in the manner it is currently (perceived as) being used in).

  And it seems this has come up over and over again with the same result already? It has come up over and over again, but on none of those occasions (that I can recall) has there been a single answer that has been the clear and unambiguous consensus of the community. Thryduulf (talk) 14:46, 4 January 2026 (UTC)

  Perhaps remove discussion from the petition. You either endorse it, or move along. It isn't supposed to be a drama festival, it is supposed to be a safeguard against wasting time. — xaosflux ^Talk 17:12, 4 January 2026 (UTC)

  I do think this is the smoothest solution we can get. Not having discussion was part of the initial proposal as well, and we would reduce a lot of the heat from petitions while keeping the admin's ability to respond and safeguarding against frivolity. Soni (talk) 19:27, 4 January 2026 (UTC)

  How would that work in practice, though? Which of these is a good idea:

  1. People sign petitions without anyone saying why
  2. People sign petitions and say why but not one is allowed to respond or rebut

  I think this is the reason why "no discussion" didn't gain consensus in the initial round of RFCs: we have to let people say why they're signing, and we have to let people respond to those reasons, otherwise we risk advancing frivolous petitions to the RRFA stage. Yes, the other side of the coin is that the petition discussion becomes the RRFA. I'm not sure there is any way around that. If we have a two-stage system (first stage: filter out the frivolous, second stage: decide on adminship), we pretty much have to allow discussion at both stages. People should be able to make the case that the petition is frivolous, if the point of the petition is to filter out the frivolous. Levivich (talk) 20:19, 4 January 2026 (UTC)

  Allowing discussion at the petition stage is also fairest for the subject administrator - they need to know why people think they've done something desysop-worthy. Several petitions have shown that it is not safe to assume someone signing a petition agrees with the initiator about the reasons. Thryduulf (talk) 21:42, 4 January 2026 (UTC)

  IMO the signing of a petition shouldn't be "I think this person should be desysoped" in the first place, only "I think the community should review this person's adminship". The RRFA should be the place for the review, not the petition; the petition should just be for making sure a reasonable number of people think the reexamination is necessary to avoid frivolous RRFA demands. As things are though, we instead have the petition as an oppose-section-only pre-RRFA to wind people up before the real RRFA. Anomie⚔ 22:14, 4 January 2026 (UTC)

  I disagree - I think signing a petition should mean "I think this person should be desysopped". You have looked at the initiator's rationale, read the evidence presented and read the admin's response (and would have read the evidence presented in support of the admin retaining their status if that were part of the process), you should know whether you think they should be desysopped or not - if you don't know then you shouldn't be supporting (or opposing) the petition. Thryduulf (talk) 00:49, 5 January 2026 (UTC)

  The petition endorsement is just "this petition has merit". Your chance to say if someone SHOULD or SHOULD NOT be desysoped is if a discussion ever opens. — xaosflux ^Talk 00:50, 5 January 2026 (UTC)

  There is no practical difference between endorsing the petition and voting to have someone desysopped.

  Imagine someone saying "This RECALL petition against Xaosflux has some merit, and I plan to support him remaining an admin – assuming he chooses to undergo RFA again, which mostly people don't do. I'm voting to support the petition so that iff he agrees to undergo RFA again, then I'll be able to vote in the RFA to keep things exactly as they are now, which is exactly as they might remain, if people (like me) who support him remaining an admin didn't sign this petition (like I'm doing now)"?

  If I think you should remain an admin, I shouldn't vote to put you on a path whose default outcome – and the outcome in practice for 100% of certified petitions so far – is that you stop being an admin. WhatamIdoing (talk) 02:11, 5 January 2026 (UTC)

  Which is the problem with recall as it currently exists: accusation and one-sided rush to judgement from the start of the petition, rather than deciding there's a case and then actually looking at the situation as the petition setup intended. If we're going to start the judgement immediately, then make it an actual discussion instead of just the oppose section (and skip the pointless separate RRFA). But I think Tryptofish had it right earlier, there are enough people entrenched in "it didn't break yet, therefore it never will" positions that reform is probably doomed until it actually does break. Anomie⚔ 03:53, 5 January 2026 (UTC)

  "it didn't break yet, or even come close, and we'll have to wait until it does before we know how best to improve it" is how I'd phrase it Levivich (talk) 04:38, 5 January 2026 (UTC)

  In a sense, the question behind this entire discussion is whether "we'll have to wait until it does [break] before we know how best to improve it", or whether we can make reasonable judgments about what we can expect, without having to wait for it to happen. Obviously, I'm of the latter opinion, but I also recognize that the emerging consensus is for the former, and those of us who wish it were otherwise might as well get over it. --Tryptofish (talk) 00:52, 6 January 2026 (UTC)

  What is anyone going to "rebut". An "*I endorse this petition. ~~~~", are you going to say, Hey, NO YOU DONT! — xaosflux ^Talk 00:49, 5 January 2026 (UTC)

  I don't think "1. People sign petitions without anyone saying why" is going to help weed out frivolous petitions. Hard to know if it's frivolous or meritorious if you don't know the reasons why. If people said the reasons why, then other people might want to rebut the part that comes after "because" in "I endorse this petition because ..." Levivich (talk) 01:10, 5 January 2026 (UTC)

  I think the options are more complex, including at least these options:

  1. People sign a petition without anyone saying why, which means editors who are both unfamiliar with the admin/the latest kerfuffle and also bad at stalking editors through their contribs (probably) wouldn't sign the petition (unless the OP's a friend of theirs, because that's a thing that happens).
  2. People sign a petition without anyone saying why ...on that page, anyway.
  3. The OP gives a reason, and other people sign the petition without giving their own reasons.
  4. The OP gives a reason, the admin gets a rebuttal section, and other people sign the petition without giving their own reasons.
  5. People sign a petition and say why, and only the admin is allowed to reply.
  6. People sign a petition and say why, and anyone is allowed to reply on that page/its talk page, but there are word limits.
  7. The petition is opened first for discussion, and only later for signing.
  8. The OP is required to give public notice of an intent to begin a petition against a named admin, but the RECALL petition cannot be started for a designated time after this (e.g., 7 days), during which time no discussion is permitted, but the admin has the opportunity to resign "under a cloud".
  9. The whole thing becomes a secret ballot. Editors are directly discouraged from discussing the situation with anyone; instead, potential endorsers are encouraged to look at the admin's actions and contribs, make up their own mind, and not disclose their decision until the petition is over.

  WhatamIdoing (talk) 02:44, 5 January 2026 (UTC)

  I think 8 is pretty close to what I would imagine would be the ideal set of changes. Allows editors to resolve this at the admin's talk, cool down recall further by adding a time before petitions can be endorsed. But also do away with the entire heated discussion and arguing part of petitions.

  I can also see 6 working out, in a "Each person get 100 words, and no rebuttals" kind of way. But I suspect that would be harder to implement than just no discussion Soni (talk) 05:12, 5 January 2026 (UTC)

• 25–30 signatures, 14–30 days. I think the recall process is fundamentally working as intended, and that these particular parameters don't need anything more than incremental adjustment. Instead, I think a change that would make a real positive impact is the one suggested by Stifle and some others: introduce a several-day hold between when a petition is announced/initiated and when it can be signed, to allow time for temperatures to cool and hopefully lead to more thoughtful review of any individual's adminship. ModernDayTrilobite (talk • contribs) 15:11, 8 January 2026 (UTC)
• 25 signatures in 14 days. 30 days is too long in my opinion. OhanaUnited^{Talk page} 16:26, 10 January 2026 (UTC)
• 25 signatures in 30 days. Amenable to minor changes to one or the other (e.g. 25 signatures over 21 days, 30 signatures in 30 days) but without supporting either, oppose changing both or changing either by more. NebY (talk) 12:44, 12 January 2026 (UTC)
• 30 signatures over 14 days. I think the risk of a 30-day petition and the stress are not really worth it. With the size of the English community, 30 signatures should be fairly easy to reach when there is problematic behaviour. —Femke 🐦 (talk) 12:47, 18 January 2026 (UTC)
• 40 signatures over 7 days - Basically per above. This is a terminal vote for an admin and needs to be treated more seriously. FOARP (talk) 14:46, 21 January 2026 (UTC)
• 50 signatures over 7 days. I find the recall process concerning as it resulted in several users who became subjects of admin recall petitions ceasing to edit on Wikipedia after their petitions passed. I think that 25 signatures to actually gain support for a petition to succeed seems like a small number and 30 days is more than enough time for discussions. Hence, I also think the number of signatures to have a petition succeed should be increased and the expiry time of each petition should be shortened. ~SG5536B 09:03, 23 January 2026 (UTC)
• 25/7 or more days. I think 25 signatures is not a bad threshhold. If 25 people told me I should rRfA, I'd do it tomorrow. (And frankly if they were 25 people I generally considered competent, experienced and well-intentioned, I'd just down tools.)

I do think 30 days is a very long time; if the snowball hasn't started rolling in a week, I'm not sure it's going to, but I don't actually have a strong opinion on that part of the question. I'm not concerned that some 30-day petitions took longer than a week to get full support; people will procrastinate when they know they have 30 days to decide whether to sign, whether their support is needed or they can stay above the fray, whatever. Valereee (talk) 10:57, 24 January 2026 (UTC)

• 30-40 in 7, broadly per Tryptofish. For such a serious process as a recall, just 25 required supports feels oddly low, and petitioners being given a month to get those 25 support votes together opens up the possibility of a frivolous petition resulting in a frivolous RfA that wastes the community’s tim (even if that hasn’t happened yet). The Kip ^(contribs) 07:49, 26 January 2026 (UTC)
• 25/30, system works just fine, none of the (correctly certified) recalls have been shown to be in error. NOTBROKEN. Fram (talk) 10:47, 26 January 2026 (UTC)
• '25 signatures in 30 days' I think it allows time for less active Wikipedians to also contribute their opinions. If it stays open for a month, and doesn't get any support then there are no consequences: nothing major is lost. I don't think it wastes the community's time. EasternShah (talk) 12:37, 29 January 2026 (UTC)

Discussion (Admin recall)

• Wikipedia:Requests for comment/Recall check-in has recently been closed with consensus for some change to these parameters, and the traditional questioning of the close process across multiple venues is well underway.[2][3][4] The issue of the number of signatures needed, however, does appear to be one the community needs to discuss, as is the issue of the petition length. So, please, discuss. GreenLipstickLesbian💌🧸 08:29, 30 December 2025 (UTC)

  @GreenLipstickLesbian this feels like a poor explanation for why "multiple seperate RfCs to follow-up on the close of the previous discussion" is correct. In the discussion at the recall talk page there seemed to be agreement a workshop was beneficial, which would have also given time to figure out just which parts of the last RfC has enduring consensus. Best, Barkeep49 (talk) 15:36, 30 December 2025 (UTC)

  I agree that a workshop would have been better at this point. I can see the logic of "this is the simpler question, so let's handle it first", but I don't think this question is quite as simple as it appears. I also agree with some of the people who have already commented, who have said (or implied) that an open-ended question like this is basically the temperature-check RfC again - if we are going to change the timing and signature count in a recall petition, we should probably be choosing from a list of possible options, chosen from a pre-RFC workshop. Certainly, we do need to discuss the number of signatures and petition length. But could we do this as a pre-RFC workshop rather than a set of formal !votes? -- asilvering (talk) 18:36, 30 December 2025 (UTC)

  It's one thing to WP:BEBOLD, but doing this without a prior workshop was a big mistake. In my !vote above, I've made a suggestion about how we might be able to salvage this, but I have a serious fear that this has been constructed in a way that has invited a social network-style pile-on, that will ruin any thoughtful attempt to improve the process. --Tryptofish (talk) 23:41, 30 December 2025 (UTC)

  @Barkeep49 Well, as per Tryptofish Right now (admittedly it is early) the discussion looks headed towards contradicting the consensus of the previous discussion that was closed merely a few days ago. Given that observation, yes, I too am very curious as to why the consensus for a increase in signatures and reduction in length seemingly couldn't even endure a week!

  I also find it interesting, though less surprising, that the community seems to be settling in three distinct categories (long time + larger number of sigs, short time + larger number of sigs, status quo), which is a very small number of options indeed. (No Mickey Mouse !votes yet, thankfully). Ultimately, I do agree that a more measured discussion before jumping into a binding RfC was needed, and made comments indictating such a while ago, but that binding RfC has already happened. This is merely an attempt to figure out what exactly it has bound us to. GreenLipstickLesbian💌🧸 05:18, 31 December 2025 (UTC)

  Given that observation, yes, I too am very curious as to why the consensus for a increase in signatures and reduction in length seemingly couldn't even endure a week! It's a straightforward explanation, that RFC was misclosed and people are re-iterating it as such here. I wish this RFC was started a week or two later, after people had sufficient time to pursue close challenges. Instead, we'll probably see the close challenge while this RFC continues discussing. Soni (talk) 05:33, 31 December 2025 (UTC)

  I can't entirely describe the RfC as misclosed, framed as it was to prompt some apparent consensus for one of a limited range of changes. GreenLipstickLesbian💌🧸 07:17, 31 December 2025 (UTC)

  GLL, you say that you favored "a more measured discussion before jumping into a binding RfC... but that binding RfC has already happened." This RfC didn't just happen spontaneously; you initiated it. And you should, in my opinion, withdraw it now. --Tryptofish (talk) 22:36, 31 December 2025 (UTC)

  @Tryptofish Wikipedia:Requests for comment/Recall check-in was not started by me, but the way it was framed means that, when closed (again!), it will bind the community to one of three responses on questions like "should the signature threshold be increased" and "should petitions be shorter" - consensus for, conensus against, and no consensus. The problem is that there was an incredibly amount of ambiguity in how to answer those questions - to take the main issue people had with the close, how do you count a !vote for A? It is against increasing the signature requirement, are they okay with increasing the signature requirement but don't view it as a necessity, is it a genuine abstain? Given that, "No consensus" is about the best I think anybody's getting, but that form of Schrodinger's consensus is not workable - well, it's workable if you want to play recall politic games (to clarify: I don't think that was Barkeep's intent when starting it), which is also something I'd like to prevent during the next 5 to 8 months while people workshop ideas for actual improvement. Community seems to have had no issues offering their opinions and confining themselves to a reasonable selection of options, however, so again, it's nice to see that happen and I don't actually want to stop it. GreenLipstickLesbian💌🧸 22:58, 31 December 2025 (UTC)

  That is so wrong, on so many levels. It's becoming very clear that the "check-in" isn't going to bind the community to much of anything. Even if there was not consensus for one thing, that does not amount to a consensus that everyone is forbidden to try, later, to formulate something similar but better. And the same is going to be true of this RfC, no matter the outcome. All you are doing is to base this RfC on another discussion close that is no longer in effect, and you are going to make it harder, not easier, for people to workshop further ideas. --Tryptofish (talk) 23:06, 31 December 2025 (UTC)

  Soni may be correct that the previous RfC doesn't reflect consensus. If that's correct this RfC's format - which was setup in a weigh to superweight that point of view - is good because it ensures the community consensus is carried out. If that stance however is one held by a large minority of Wikipedians then this RfC isn't so good. And it seems especially not good that it seems like it was launched because @GreenLipstickLesbian is upset with me about my launching of the previous RfC (Ultimately, I do agree that a more measured discussion before jumping into a binding RfC was needed, and made comments indictating such a while ago, but that binding RfC has already happened.). Ultimately I'm disappointed that both house who feel the status quo is correct and those who think that it needed to change by increasing the number of signatures and decreasing the length of time will walk away from this process feeling they had community consensus. Best, Barkeep49 (talk) 01:30, 1 January 2026 (UTC)

  Upset at you? I'm sorry if you've gotten that impression, Barkeep49, but I'm most certainly not.

  Now, I hope you don't mind, but I've long since learnt that when one party of to a dispute tries to so publically guess at the others emotional state, the conversation has ceased to be productive. Peace, GreenLipstickLesbian💌🧸 20:05, 1 January 2026 (UTC)

  GLL, this entire RfC has degenerated into editors yelling at (or past) one another, and the whole thing has ceased to be productive. --Tryptofish (talk) 23:36, 1 January 2026 (UTC)

  @Barkeep49, Tryptofish, and GreenLipstickLesbian: (no especially strong reason for the ping) A workshopped RfC was created at Wikipedia:Administrator recall/January 2025 request for comment, but no one had the initiative to launch it. It should have been launched, because it was designed well and was ready to go. This was not so long ago, but everyone has forgotten about it. Note that most of the actual workshopping was done on a separate page: Wikipedia:Administrator recall/Reworkshop —Alalch E. 16:51, 9 January 2026 (UTC)

  The RFC workshop was a few months too soon. By the time people ironed out what questions to ask, the questions and options being initially proposed on the workshop were no longer a concern. Most of the reworkshop suggestions were based on the first couple cases of Recall, which saw significant community pushback. The very next Recall assuaged most of those concerns. I liked the reworkshop and January 25 RFC as processes, but it needed to happen much later, after we had an idea where Recall needed changes. Soni (talk) 06:29, 10 January 2026 (UTC)

  That RfC was explicitly framed as a "check-in", so I don't think it's particularly charitable to describe it in this way. -- asilvering (talk) 02:09, 1 January 2026 (UTC)

• The recall process has been a huge success and the best thing that's happened on Wikipedia for years. It's had no miscarriages. Everyone who got desysopped via recall should have been desysopped. The only person who shouldn't have been desysopped, wasn't. Sysop behaviour has substantially improved now that there are consequences that aren't gated behind Arbcom's hopelessly obscure, obfuscated, and snail-paced process. Please, let's not allow it to be sabotaged.—S Marshall T/C 10:47, 30 December 2025 (UTC)
• Given the scope of Wikipedia's geographic diversity, given that English Wikipedia is most likely the home project of the largest group of non-native speakers, given the scope of time zones, I find a suggestion that a recall petition be shortened to a week both unfair and impractical for a project which is voluntary. It privileges participation to those with more time and resources. Regards, --Goldsztajn (talk) 10:55, 30 December 2025 (UTC)

  I share your concern about not privileging people in the "right" time zone, over the rest of the broader community, but that leads me to the opposite conclusion. Our current system says that petitions can stay open for 30 days, but successful ones never do. They often open and close within about a day. That actually prevents a lot of the community from being able to provide input, and it's not like there's a fire that needs to be put out. We should fix the system, so that it continues long enough to have broad participation, something that isn't happening now. --Tryptofish (talk) 23:45, 30 December 2025 (UTC)

  I don't see how one can draw any conclusion from the fact that successful petitions pass in under 30 days; that's more or less a sky is blue statement. My simple point, among others that I agree with here, is that for those who work full-time, or are active carers, or who have difficulty with access (in any form), shortening the length of a petition in a voluntary project privileges those who have the resources to devote to the project (and that generally means older, wealthier people from, globally speaking, relatively privileged social strata). Again and again over the years, admin accountability is an issue that has come up repeatedly - if 25 editors decide I've failed in my job as an admin, well that's now the price of the ticket when I put my hand up for the job. I'm not in favour of making admin accountability more complex, harder and less accessible to all. The proverbial mob has built this strange but wonderous thing, not torn it down. Regards, Goldsztajn (talk) 05:09, 31 December 2025 (UTC)

  But I didn't say that successful petitions pass in under 30 days. I said that they usually pass in a day or two. Seven is less than 30, but greater than 1 or 2. --Tryptofish (talk) 22:44, 31 December 2025 (UTC)

• This should probably be two RFCs. Like the RFC before this, combining questions and options will probably make things difficult for the closer, and will probably create opportunities for wikilawyering. –Novem Linguae (talk) 11:41, 30 December 2025 (UTC)

  I can't think of anyone who's qualified to close this RfC but wouldn't cope with a complex combination question.—S Marshall T/C 11:59, 30 December 2025 (UTC)

  I disagree, simply because these two combinations are strongly interconnected. I might be okay with shorter timeframe or more signatures, but I definitely would not support both. I think there will be many editors in similar buckets. Both options are better presented at once, else we risk breaking a functional system by making two independent tweaks.

  For example, a petition with 25 signatures that runs for 30 days, differs significantly from one with 10 signatures in 7 days and both other permutations (10 signatures/30 days, 25 signatures/7 days). Soni (talk) 12:30, 30 December 2025 (UTC)

• I think I'll just wait for the RFC acting on the "There is consensus for the development of a different petition process" and "There is consensus for changes on how re-RFA works" parts of the close. As I !voted in the earlier RFC, I don't think tweaking these numbers will make much of a difference to the actual flaws in the process. If there's discussion somewhere preparing for that RFC, feel free to ping me. Anomie⚔ 13:41, 30 December 2025 (UTC)

  I'm still waiting for an RfC that actually shows that there is consensus for changing the petition process. Since 50% of the !voters supported the status quo, I have a hard time seeing consensus for a change. --Ahecht (TALK
  PAGE) 16:48, 30 December 2025 (UTC)

  Your 50% guesstimate is wrong, at best it was only 40% and more likely closer to 33%. See my comment below. Anomie⚔ 17:07, 30 December 2025 (UTC)

• So who's gonna be brave and hat this trainwreck so that we can do it again correctly? FIRST: A straight up question: does the system need to be changed, YES or NO. Not 500 people with 500 ideas about how many days and how many signatures. Let's see if there is even any sort of consensus for change. I don't think there is. SECOND: IF and ONLY IF there is a consensus for change, then a question: do we need A. More signatures required; B. Fewer days required; C. More signatures AND fewer days required; THEN and ONLY THEN ... THIRD: a structured, very small, set of proposals based on that result as to how to implement that change. HOWEVER, since one of WP's original sins is the lack of a constitution and the lack of a rational voting system, I'm just talking to myself. Never mind. Carrite (talk) 17:52, 5 January 2026 (UTC)

  Based on the recent check-in RFC, my crystal ball says you'd get around 60%–66% in favor of change in your first discussion, but then the second would fail due to a bunch of people voting "D: No change" or "E: It needs more change than just changing those numbers" while supporters split themselves among A, B, and C. Even if you ignore anyone who votes D, the split between A, B, C, and E would probably prevent a consensus from being found. Anomie⚔ 21:49, 5 January 2026 (UTC)

Further analysis of previous RFC

• I note several people above are claiming that option A should have been read as being consensus for no change, overriding all other !votes. By my count, option A had only 46 supports out of 111 !votes. Also, 12 of those option A supporters indicated support for at least one of B–J; some of the support for A was pretty clearly more along the lines of "I'd be ok with no change" rather than "I oppose any change" as those above are claiming or implying. By that measure, then, I'd say that there was consensus against "no change" with about 60%–66% !voting in favor of some sort of change.
  For comparison, I counted 43 !votes supporting option D; 30 supporting E; 50 supporting one or both of D or E; 37 either directly supporting option G or supporting Mz7's proposal without explicitly mentioning G; and 46 supporting at least one of G, H, or I. I don't know for sure why my counts differ from User:Dr vulpes's, although I'd guess it comes down to different reading of people being "open to" options and other non-bolded reasoning and my counting of 7 supports for Mz7's proposal as implicit support for option G. Feel free to also blame my bias if you want. Anomie⚔ 17:06, 30 December 2025 (UTC)

  I haven't checked your figures but if you take away the 12 who !voted for option A in addition to other options, that still leaves us with 36 pure option A !votes. Those 36 votes are still enough to warrant a no consensus for any of the other options. The second-highest supported option was D with 43 !votes which would have had only 54% support when accounting for the 36 option A !votes. ~WikiOriginal-9~ (talk) 17:51, 30 December 2025 (UTC)

  that still leaves us with 36 pure option A !votes Not even all of those are necessarily opposed to any change. IIRC some seemed closer to "there have been no riots over it yet so it's good enough for me, let's not waste time on it". Those 36 votes are still enough to warrant a no consensus for any of the other options Maybe, maybe not. You'd also have to factor in the people who !voted for D or E but remained silent on G when considering G, for example. And people who'd switch to G over A after J failed, etc. It doesn't seem worth trying to guess at all those factors. Anomie⚔ 18:02, 30 December 2025 (UTC)

  So 46 people opposed D/E that had 50 combined votes, that's as close to NC as it gets. This is why bartender doesn't work in these cases; if an editor voted for changing the process away from a petition, the mechanics, or something different, they aren't necessarily going to be satisfied with changing the requirements to simply "become more difficult" (unless they specifically opposed A which few did). Likewise if voting to abolish or exclude admins, allow support, etc. Bartender only works when there is fundamentally consensus to move away from the status quo, which was not the case (either in net A votes nor vs best proposal), and the proposals are at least similar to some degree. CNC (talk) 17:59, 30 December 2025 (UTC)

  I'm not arguing for a bartender close in the first place, I'm just pointing out that "no-change wins because no individual change got majority support" is fallacious and "no-change wins because someone guessed that it had about 50% support" is flat out wrong. "No consensus in favor of anything specific" seems about right to me, which also doesn't mean "stamp out all future attempts at finding consensus for a change".

  On the plus side, we can probably at least eliminate options K (9 support, 11 explicit oppose), J (11 support, 16 explicit oppose), C (0 support, 10 explicit oppose), and F (0 support, 9 explicit oppose). Anomie⚔ 18:24, 30 December 2025 (UTC)

  Fair enough. FWIW I also think it's worth having this more simplistic RfC, not only to satisfy the desire for exploration, but also to shutdown trying to stab in the dark for a solution. CNC (talk) 18:40, 30 December 2025 (UTC)

• A majority of respondents thought the current system was fine. There was NO mandate for a change because the close was improper. There especially was no mandate for a double change of shortening the length PLUS adding to the signature requirement. This thread, in addition to being horribly structured, is completely out of order. Carrite (talk) 16:41, 31 December 2025 (UTC)

  At most only about 40% did, which is not a majority. And at least a quarter of that 40% were still open to some sort of change despite considering it "fine". Anomie⚔ 16:56, 31 December 2025 (UTC)

  Anomie's analysis here and above is important. Reasonable people may disagree as to whether the checkin has consensus for some change, or no consensus for change. But it's plain incorrect to say a majority opposed any change. Vanamonde93 (talk) 18:30, 31 December 2025 (UTC)

  Maybe a better statement would be there was not a majority for any given change. PackMecEng (talk) 18:52, 31 December 2025 (UTC)

  I think the phrase everyone is looking for is dog's breakfast. Goldsztajn (talk) 22:03, 31 December 2025 (UTC)

  It would be correct to say that 'A' (no change) received a plurality of votes. Some1 (talk) 23:20, 31 December 2025 (UTC)

  It would also be correct to say that the subject of this RFC, namely "increase the signature threshold and/or reduce the time limit", received more votes than A did. Anomie⚔ 00:29, 1 January 2026 (UTC)

It would be correct to say that 'A' (no change) received a plurality of votes. it didn't. Counting only supports and ignoring all preferences, nuances and opposes the numbers were:

Extended content

Category	Count	Editors
Supporting the status quo only	22	CMD, SarekOf Vulcan, xaosflux, Aquillion, ViridianPenguin, A.B., S Marshall, Andrew, AllyD, 115.64.183.57, Spryde, nableezy, Iggy pop goes the weasel, Traumnovelle, Jessintime, ToBeFree, Katzrockso, fifteen thousand two hundred twenty four, Dr. Duh, Mach61, Mztourist, Goldsztajn
Supporting either status quo or change	28	Tewdar, Fram, fanfanboy, Silver seren, Some1, RevelationDirect, Carrite, CNC, 88.97.192.42, Writ Keeper, Gramix13, Caecillisuinhorto-public, Useeight, Horse Eye's Back, Der Wohltemperierte Fuchs, Thebiguglealien, AugusteBlanqui, Alexandermcnabb, RL0919, -bɜ:ʳkənhɪmez, Arcticocean, QuicoleJR, NebY, Patar knight, Levivich, PackMecEng, SnowFire, SuperMarioMan
Support some sort of change only	56	Barkeep49, Tazerdog, Tamzin, Cryptic, Enos733, DoubleGrazing, Number57, BD2412, Seraphimblade, Simonm223, Mz7, SWATJester, Rosguill, Kusma, Wehwalt, Vanamonde93, King of Hearts, Guettarda, Thryduulf, ThadeusOfNazareth, Novem Limguae, Tryptofish, RGloucester, WhatamIdoing, Jeske Couriano, Mox Eden, Alanscottwalker, Donald Albury, Giraffer, Lindsay, Kevin L, Choucas0, FaviFake, FOARP, Rutebega, Passengerpigeon, asilvering, Toadspike, Stifle, NicheSports, Dionysodorus, 2601:540:200:1850:F43C:C448:7974:22BD, Anomie, NotAGenious, Ajpolino, Juxtaposedjacob, JBL, Squawk7700, GothicGolem29, Aaron Liu, Epicgenius, MER-C, Chaotic Enby, rsjaffe, OutsideNormality, Steel1943

Even if you count both the fist two categories as opposed to any change (which would be incorrect, as some explicitly had it as a lower preference to change) then it's 56 in favour of change vs 50 opposed to change. Thryduulf (talk) 17:47, 1 January 2026 (UTC)

If you're using those categories, then sure. If you're comparing the different options (options A - K), then A received the most votes out of those 11 available options. (I should note that I am not saying that since A received a plurality of votes that the consensus is "no change". It's not. The "check-in" RfC should've been closed with consensus against options J, K, F, C, and no consensus for the rest of the options.) See the tables below (data taken from Levivich's table at Wikipedia talk:Requests for comment/Recall check-in).

Extended content

	A	B	C	D	E	F	G	H	I	J	K
Votes	48	20	1	43	31	2	28	19	15	10	8
% out of 109 voters	44.04%	18.35%	0.92%	39.45%	28.44%	1.83%	25.69%	17.43%	13.76%	9.17%	7.34%

Ranked:

A	44.04%	Process is working well, no changes needed
D	39.45%	There should be more signatures needed
E	28.44%	30 days is too long, the petition process should be shorter
G	25.69%	Keep recall, but develop a different process than petition leading to a re-RFA
B	18.35%	There should be some way of enabling support for the admin during the petition phase
H	17.43%	Keep recall, but do some other change to how re-RFA works
I	13.76%	Keep recall, but do some other change to how the petition works
J	9.17%	Recall should be abolished
K	7.34%	Prohibit admins from !voting in RFCs to amend recall
F	1.83%	30 days is too short, the petition process should be longer
C	0.92%	There should be fewer signatures needed

That's out of 109 voters. People were able to support multiple options (my vote apparently counted for both A and D), so the "spoiler effect" doesn't apply here. Some1 (talk) 20:16, 1 January 2026 (UTC)

That's true but irrelevant. The relevant distinction in this context is "people who want some sort of change" vs "people who don't want any sort of change" vs "people who would be happy with either some change or no change". That people were able to support multiple options is also not relevant, because nobody was included in more than one category. No change did not receive either a majority or a plurality of votes as claimed - it was supported by a minority of participants. Thryduulf (talk) 22:06, 1 January 2026 (UTC)

A is definitely a plurality: more than any other option but less than a majority. You don't combine all other options and treat them as one option when determining if there is a plurality; if you did that, there would never be a plurality, because all other options combined would always be the majority in any poll that had three or more options where no single option got the majority. This is some fuzzy math, combining all other options and claiming there is no plurality. In any 3+ option poll, there will always be a plurality: which ever one(s) got the most votes. Levivich (talk) 22:46, 1 January 2026 (UTC)

I'd only be combining all other options if I was attempting to find consensus for a specific change. I wasn't doing that, I was responding to the claim that people wanting no change respresented the plurality of voters - something that is demonstrably false. It's true no option for any specific change received a plurality, but that's irrelevant as nobody has claimed that. Thryduulf (talk) 23:52, 1 January 2026 (UTC)

But A did receive a plurality? Of course, it received less than all other options together, but it received more than any other option individually, which is the definition of a plurality. It didn't received a majority, but that is something else. Chaotic Enby (talk · contribs) 05:46, 2 January 2026 (UTC)

I have already answered this. Thryduulf (talk) 07:52, 2 January 2026 (UTC)

As ToBeFree has noted before, I don't think you would be able to obtain any option besides "people want some sort of change" if you run a survey like this and use your methodology to obtain consensus. Katzrockso (talk) 23:45, 1 January 2026 (UTC)

I'm not sure whether this is a reply to my comment or not, but if it is then I'm not attempting to obtain a consensus for anything specific. The purpose was literally just to demonstrate that there wasn't a consensus or a plurality of voters in favour of on changes. Thryduulf (talk) 23:54, 1 January 2026 (UTC)

I should be in the first category. I supported A. Levivich (talk) 22:41, 1 January 2026 (UTC)

You also supported prohibiting admins from participating - Also support K, after reading others' comments about it. [5] Given that this would be a change from the status quo, you are correctly the category of people supporting the status quo and/or some change to the status quo. Thryduulf (talk) 23:56, 1 January 2026 (UTC)

Please try harder to be accurate when you're describing my vote: Prohibiting admins from voting in RFCs to amend recall, not from participating in recalls. That's not a change to the recall process. When it comes to the recall process, I support the status quo only with none of the proposed changes, as I explained in detail in my vote describing my view that the recall process was working well and that the proposed changes would not improve the process. Levivich (talk) 01:11, 2 January 2026 (UTC)

But it isn't consistent to group all the people supporting any kind of change together. For instance, I also supported K (and am being placed in the latter group), but, if I only had to choose between A and D/E, I would choose A. Grouping all support for a change together is an example of the politician's fallacy. Chaotic Enby (talk · contribs) 05:45, 2 January 2026 (UTC)

if I only had to choose between A and D/E That's a good example, since it turns out that in the recall check-in more people actually did choose D/E than A. But since D and E partially spoilered each other, neither individually had a higher total than A. Anomie⚔ 14:36, 2 January 2026 (UTC)

Again, people were able to vote for multiple options in that RfC, so the "spoiler effect" doesn't apply. No option took away votes from another option in that RfC. Some1 (talk) 15:02, 2 January 2026 (UTC)

You claim that if the check-in had had only a combined D+E option instead of separate D and E options, somehow fewer people would have supported the combined option than supported one or both of the separate options? That does not seem at all like the most likely scenario. Anomie⚔ 16:49, 2 January 2026 (UTC)

No, that's not what I'm claiming at all (if I'm understanding your question correctly). People were able to vote for multiple options in that check-in RfC. My (Support A. Weak support for D) counted as a support for A and D in the table(s). Why would I want my weak support for D to be combined with E votes? There's a reason why I didn't say support E in that RfC (because I didn't support it). Some1 (talk) 17:04, 2 January 2026 (UTC)

If there had been only "S: Petition requirements should be more strict (more signatures and/or shorter timeframe)", no separate "D: There should be more signatures needed" and "E: 30 days is too long, the petition process should be shorter", you would not have supported that option S? Anomie⚔ 17:28, 2 January 2026 (UTC)

My comment at the check-in RfC said "Support A. Weak support for D; the number of signatures could be raised from 25 to 30, but I'm not opposed to keeping it at 25."

To answer your question, no, I wouldn't have supported the hypothetical "option S". I don't think the petition requirements should "be more strict" (which is what hypothetical option S says right before the parenthetical); and I wouldn't want the closer to be confused with a support for an 'and/or' option when only one part of that and/or is, in my case, being weakly supported. Signature threshold and petition length are two separate things, so the check-in RfC at least got something right by making those two separate options that editors could vote for (one or both). Some1 (talk) 18:22, 2 January 2026 (UTC)

Seems to me like you're probably an outlier then. I think most people who voted for D or E would have supported S. But it seems unlikely you'll be convinced to agree, since it goes against how you want the results to be. Anomie⚔ 18:53, 2 January 2026 (UTC)

I don't think we should interpret votes to say things they don't say or imply. That's a reflection of the failure of the RfC question itself. Katzrockso (talk) 22:08, 2 January 2026 (UTC)

I think it's perfectly reasonable to presume that most people supporting (option 1) and most people supporting (option 2) would also support (option 1 or 2, which to be determined in a later discussion). Thryduulf (talk) 01:20, 3 January 2026 (UTC)

Also want to add that, since D and E ranked 2nd and 3rd in terms of support, it's a good thing we're having this "petition signature threshold & length" RfC, because it'll settle any debates about the two. Some1 (talk) 18:32, 2 January 2026 (UTC)

I should be in a category of editors who feel that the check-in, this RfC, and all of these discussions to date have proven to be a waste of time, and it's time to move on, and to try to have a better examination of these issues at a later time, after a lot of cooling down. --Tryptofish (talk) 23:40, 1 January 2026 (UTC)

Meta

There is currently a box at the top of this page that says:

This discussion is very likely to have an "extremely high number of comments" (to quote the relevant bit from WP:RFCBOT) and should not be on this page. Please:

1. Split it off to a separate page, perhaps named Wikipedia:Administrator recall/Petition signature threshold and length.
2. When you split it off, remove the |rfcid= parameter from the template at the top of the page (so the RFC bot can find the new location).

Thanks. WhatamIdoing (talk) 22:40, 30 December 2025 (UTC)

I would object to this in the next couple of days at least. RFCs are much more active in the beginning, and splitting it off to a subpage reduces the number of people who could find it. After a couple days, fine. Until then I'd be inclined to more aggressively archive or split off less active topics, even if they are shorter. Tazerdadog (talk) 00:37, 31 December 2025 (UTC)

@Tazerdadog, the whole point of the Wikipedia:Requests for comment process is that it actively advertises discussions on low-traffic pages. When we split it off, the Wikipedia:Feedback request service bot will issue a new set of invitations to subscribers. The RFC bot will post the new location on Wikipedia:Requests for comment/Wikipedia policies and guidelines and Wikipedia:Requests for comment/Wikipedia proposals. Someone will change the link in WP:CENT to point to the new location. And we will leave a note here, for anyone who has already replied, so they can find the new location. WhatamIdoing (talk) 21:13, 1 January 2026 (UTC)

We should probably have some sort of comment/size limit for a subsection, contingent on the activity decreasing in volume in recent days, so that we can create a subpage of some kind. For example, the subsection "Temp accounts were a stupid idea" last saw a comment on 24 December, and before that one comment, it was 20 December. That section also has 289 comments, including a number of very lengthy comments. I don't see why, for housekeeping purposes, we couldn't create a subpage of that discussion. Katzrockso (talk) 04:36, 31 December 2025 (UTC)

Because I jiggered the archiving settings so it would get archived last night.

Yes, someone should have split that discussion off when it reached ~100 comments. But nobody noticed at the time. We don't have a bot set up to enforce these things. WhatamIdoing (talk) 21:15, 1 January 2026 (UTC)

Rather than a comment size (since lots of small comments don't make as significant an impact than a smaller number of massive WP:Walls of text), is there a good guidance for how large a section should be before we split it off? If we can estimate the average discussion size for say each noticeboard and the average number of discussions within the archiving period, we should be able to calculate some at least mathematically informed limits. Katzrockso (talk) 23:43, 1 January 2026 (UTC)

Rescinded close

Moved from Discussion (Admin recall) for better visibility. CNC (talk) 11:34, 31 December 2025 (UTC)

• Noting that the close of the previous discussion has been rescinded. Chaotic Enby (talk · contribs) 10:42, 31 December 2025 (UTC)
• (edit conflict)The person who closed the discussion that caused this discussion has self-reverted, so now this discussion is about how to implement a decision that we've no longer, strictly speaking, actually made. Although I think it's much too far along to close this one now and the two will have to run in parallel.—S Marshall T/C 10:45, 31 December 2025 (UTC)
• Should this be considered for closing alongside the check-in RfC now the close has been rescinded? I'm inclined to think the two could be wrapped up together here, given this was initiated based on the close of the previous. CNC (talk) 11:34, 31 December 2025 (UTC)

  The consensus is so clear for both that neither really needs a close. The first one is A and this one is 25/30. As someone said, we're not kindergartners, we can all read, and count. Levivich (talk) 14:50, 31 December 2025 (UTC)

  If you can read and count, maybe you should try actually doing so? The first one is A is clearly untrue, as was already described in detail above. Anomie⚔ 16:58, 31 December 2025 (UTC)

  I did. Out of 109 votes, almost all the proposed changes got 28 or fewer supports (even counting "weak" votes, "second-choice," "open to," etc.). Those are decidedly "consensus against." The only one that came close was more sigs (D), with 42 43/109, or 39%. Frankly, I'd call that "consensus against" also, but you can call it "no consensus" if you want. 49 48/109 explicit "Support A" votes, which is 45% 44%. "No consensus" on its own, but the point is: consensus against any of the proposed changes. Consensus against increasing or decreasing the sigs or the time, consensus against allowing supports during the petition, consensus against developing a different process or abolishing it altogether. That means status quo, because there is no consensus for any change, and consensus against all of the proposed changes (or all but one, the more sigs one, if you count that as no consensus). In other words, A: maintain status quo, is the outcome of the RFC. Levivich (talk) 17:58, 31 December 2025 (UTC)

  Thanks for actually counting. I think you're pushing too strongly on all your "consensus against" rather than "no consensus" though, and as I said elsewhere by that logic there's also consensus against making no changes as well. Anomie⚔ 18:17, 31 December 2025 (UTC)

  I know I'm drawing a fine line, but I'd call 40/60 "consensus against" and 44/56 "no consensus"; it'd be reasonable to call both no consensus, but it's not reasonable to call 44/56 "consensus against." There is no consensus as to whether anything should be changed at all--not consensus against any changes. That still means A is the outcome of the RfC. It also means that there is nothing wrong with people proposing changes...as long as it's not one of the changes that was already proposed and had consensus against in this RfC (so all except D). Levivich (talk) 18:25, 31 December 2025 (UTC)

  By no means is A the outcome of the RFC. The outcome of the check-in is that there was no consensus for anything specific, including no consensus for the no-change viewpoint. True, the effect of the check-in is no immediate change (just that we probably need further, better-focused discussions), but that's not the same thing as A being the outcome. And there's definitely no support for your "as long as it's not one of the changes that was already proposed" assertion. We, in fact, should more deeply discuss the proposals ("tighten petition numbers" (D+E) and "deeper change" (G+H+I+Mz7)) that got similar or more support than A itself did in the check-in, without a bunch of FUD from you and others that want no-change. Anomie⚔ 19:30, 31 December 2025 (UTC)

  OK so we agree that the effect of the check-in is no immediate change. I also agree that We, in fact, should more deeply discuss the proposals ... that got similar or more support than A but I disagree that all the proposals you listed got similar or more support than A (40+ supports); the only one that got 40+ supports was D, which is being tested in this RfC here. All the others got less than 30, which is why we shouldn't keep discussing them. If people want to make changes, they should suggest different changes than the changes we just voted on or are voting on now. Levivich (talk) 20:40, 31 December 2025 (UTC)

  Yes, because spoiler effects resulted in D and E interfering with each other, and G, H, I, and Mz7's proposal all interfering with each other. It's not that hard to follow, which makes it hard to AGF that you're really not following. Anomie⚔ 00:34, 1 January 2026 (UTC)

  Drop the f'ing shade already, gawd. Levivich (talk) 00:42, 1 January 2026 (UTC)

  I find it disappointing that there has been so much needless drama, and I want to make the case for keeping the status quo for now and, effectively, starting over, but trying to do it better. I'm going to go with the (debatable) assumption that the close of the other discussion (the check-in) should have been A, and nothing more. That would be a consensus that the status quo should continue, and that any changes are going to need consensus, but that nobody is forbidden to brainstorm about possible changes. I think that's something that even the most enthusiastic supporters of the status quo can be comfortable with. Given that, I think it's unlikely that the other discussion, as it is presently formulated, could yield a clearly different result than that, no matter how many more editors come back to enter more opinions, and no matter how much editors argue back-and-forth about what would be the "correct" close. That other discussion (the check-in) should just be re-closed, as having a disputed outcome, but no definitive consensus for any specific change. And then the discussion here should also be closed, early, with the result that there has been no consensus for any specific change, but also nothing forbidding editors from brainstorming about possible changes to propose in the future. And everyone should move on to things that are more productive, and have a happy New Year. Then, without there being any rush, interested editors should brainstorm about possible changes, keeping in mind the experience of these two discussions. When and if something with traction comes out of that, there can be a new RfC, constructed more thoughtfully, in the future. --Tryptofish (talk) 22:22, 31 December 2025 (UTC)

  I completely agree that there is no deadline and that we should probably close these discussions for now and start anew after a cooling off period to void any concern of impropriety and illegitimate basis for any discussions. Katzrockso (talk) 23:02, 31 December 2025 (UTC)

  IMO you start out poorly with assuming A "should have" won and that there's consensus for the status quo (versus no consensus in favor of anything, meaning we remain with the status quo by default). But ignoring that false start, you reach a reasonable conclusion. Anomie⚔ 00:40, 1 January 2026 (UTC)

  Thanks, both of you. Anomie, I actually called that assumption "debatable", so I'm far from convinced that such a consensus actually exists. My reason for formulating it that way was to concede the point, in the interests of reaching out to editors who disagree with me and, hopefully, lowering the temperature. In my opinion, doing things that way is a good approach to what you and I agree is a reasonable conclusion. --Tryptofish (talk) 23:33, 1 January 2026 (UTC)

  The reason for the rush was editors who contended that the recall process was now defunct. Hawkeye7 (discuss) 05:02, 2 January 2026 (UTC)

• These arguments about consensus show that there isn't one. Andrew🐉(talk) 11:42, 1 January 2026 (UTC)

  There are some consensuses, for example there is a consensus against abolishing recall and against some specific changes. I read the outcome as a whole as being general agreement that the status quo can be improved upon but no consensus for any specific change. Thryduulf (talk) 12:14, 1 January 2026 (UTC)

• This discussion is now clearly premature and should be closed given the RfC closure it's based on was rescinded. Consensus in that RfC has not been determined. Let the RfC complete before rushing into deciding how to implement the incomplete results. - The literary leader of the age ✉ 20:09, 1 January 2026 (UTC)

Discussion closure

Due to worries about a conflict of interest or "blue wall of silence" effect, and to avoid even the appearance of impropriety that might lead to a contested close down the line, I believe that this discussion is best left to be closed by a non-admin. Of course, I'm not saying that all admins are automatically biased about recall (I'm one myself!), but the appearance of impropriety, even when the underlying decision is correct, can easily weaken its legitimacy and cause unnecessary complications. Chaotic Enby (talk · contribs) 08:48, 4 January 2026 (UTC)

• I would disagree that it is necessary. It is fine if a non-admin closes it, but I don't think automatically disqualifying someone because they are an admin is the way to go. A good close is a good close, no matter who does it. Same for a bad close, that can be reverted or overturned. Dennis Brown - 2¢ 08:54, 4 January 2026 (UTC)
• +1 to Dennis. I'm concerned by many admins whose opinions seem to be unfairly biased against recall. I do not presume that all admins are likewise. My concern with the Recall Check-in was not Vulpes rights or credentials, but whether they considered an important fact in making their close. Otherwise, I will prefer the usual standards of "A good close is a good close" Soni (talk) 10:42, 4 January 2026 (UTC)

  Wikipedia talk:Requests for comment/Archive 12: On the question of whether an RFC close by a non-admin can be summarily overturned by an admin, in most cases, no, and never if the only reason is that the closer was not an admin. Hawkeye7 (discuss) 22:51, 4 January 2026 (UTC)

• In one sense admins aren't involved, in another most won't meet WP:DETSUIT. While I'm not opposed to an admin closing, it would really need to be one who doesn't care and is as detached as possible from the recall process. Ie ideally someone who doesn't have the appearance of involvement to avoid the existence of evidence that could be used to argue involvement, even if the arguments would be spurious. Ideally a non-admin that passes WP:NACEXP would close this. CNC (talk) 12:16, 4 January 2026 (UTC)
• That this section has been opened is yet more proof of the many problems this abomination of a process has wrought upon the encyclopaedia. Administrators are first and foremost editors. If administrators are purported to be 'biased' against this process, then surely non-administrators can be said to biased in favour of it, and thus have a conflict of interest. Enough is enough. Action should never be taken merely for the purpose of avoiding the appearance of impropriety. Actions, and indeed closures, must be judged on their merits alone. Yours, &c. RGloucester — ☎ 12:27, 4 January 2026 (UTC)

  I've explicitly said that I don't believe (most) admins to be biased against this process, but that I'm instead suggesting it to avoid the issue of a close being contested based on that reason alone and delegitimizing the decision down the line. And yes, the appearance of impropriety is an established concept (although our article on it is sadly in a very poor shape). Chaotic Enby (talk · contribs) 12:35, 4 January 2026 (UTC)

  This is Wikipedia. See WP:NPOV. You may think that it has no relevance in a talk page discussion, but I would say you are wrong. Wikipedia is what it is because we do not twist words to serve the common man a pretty picture that's easy on the stomach. NPOV is a state of mind – anyone that would seek to question a potential discussion closure merely for the closer's holding of the sysop right does not understand how Wikipedia functions – appearance, never – substance, always. Yours, &c. RGloucester — ☎ 12:47, 4 January 2026 (UTC)

• Maybe an uninvolved admin and an uninvolved non-admin can both co-close this? Some1 (talk) 14:10, 4 January 2026 (UTC)

  The argument being made in this case is that "uninvolved admin" is an oxymoron. —Jéské Couriano v^_^v ^{threads critiques} 17:23, 4 January 2026 (UTC)

  I feel like since the votes (similar to the check-in RfC) are based on vibes and opinions, the "outcome" should be based on an objective vote count (which anyone can determine, admin or not), instead of relying on a single closer's own opinion as to the "strength" of the arguments. So this RfC shouldn't be that difficult to close unless consensus swings in favor of something that's not the status quo. So far it seems unlikely:

  There are 61 voters so far in this RfC with xaosflux's vote being the latest one. 36 support keeping the status quo (59%); 21 support increasing the number of sigs (34.43%); and 20 support decreasing the length (32.79%). That's not much different than what the check-in RfC found, so this is unsurprising. Some1 (talk) 17:49, 4 January 2026 (UTC)

  The argument also being made in this case is that "non-admin" isn't "future admin". Or a "past admin". Every one of the admins who were desysopped via RECALL are "non-admins". WhatamIdoing (talk) 23:43, 4 January 2026 (UTC)

• Personally, I don't agree that it's necessary for a non-admin to evaluate consensus for the discussion. Matters of community governance do affect all editors, both admins and non-admins. In my view, nonetheless, I don't think being an admin is disqualifying with respect to being unduly preferential towards a specific viewpoint. isaacl (talk) 19:42, 4 January 2026 (UTC)
• Only a site-banned user should be allowed to close this. Anyone with a history of demonstrated concern about what is best for Wikipedia will be bringing too many preconceptions. Or maybe we should ask ChatGPT to write the close. Give me a month, and I'll find 24 other editors who agree with this. --Tryptofish (talk) 22:54, 4 January 2026 (UTC)

  there is no way 24 other editors will agree with that. ltbdl (skirt) 12:27, 5 January 2026 (UTC)

  Tryptofish is being snarky about the petition process not letting them oppose. Those who opposed recall frequently make such mischaracterisations about how consensus works. Soni (talk) 12:42, 5 January 2026 (UTC)

  But there is nothing snarky about saying that those you disagree with "frequently make such mischaracterisations about how consensus works". And why would I ever be snarky, when editors take what I said literally? --Tryptofish (talk) 00:46, 6 January 2026 (UTC)

  Honestly, ChatGPT would probably do a pretty decent job summarizing this discussion if you copy and pasted it into it. ~ ONUnicorn^{(Talk|Contribs)}problem solving 21:05, 5 January 2026 (UTC)

  Probably true, that. --Tryptofish (talk) 00:46, 6 January 2026 (UTC)

Very rough involved not-a-close summary

I just went through, took out the non-!vote lines, and sorted by !vote. Out of 71 lines, we have about 32 straight 25/30 !votes, with one 25/7 or more, one 25/14, one 25/21, and two 25-30s, with a range from 14 to 30 days. 3 30 sigs, one 35, one 30-40, 8 40s, 3 40-50.

As far as dates go, breaking them out from the signatures, we have roughly 35 for 30 days, one for 21, 9 for 14 or 15, 10 for 7, and various suggestions that can't be broken down to a straight number.

This is only a quick-and-dirty summary, and I would want the actual close to be more nuanced than a straight !vote count. I just wanted to see how the numbers were trending more accurately that a quick visual scan would give me. --SarekOfVulcan (talk) 15:59, 2 February 2026 (UTC)

Another interesting stat: Of the 21 admins who voted, two-thirds supported a change to the status quo. Of the 50 non-admins who voted, roughly two-thirds supported the status quo. Some1 (talk) 23:42, 2 February 2026 (UTC)