User:Mz7/How to fix administrator recall

In this essay, I would like to outline what I think are the deficiencies in the current administrator recall process and my suggestions for how to fix them. In particular, I have a few key observations:

• A certified recall petition is a desysop. When we supported creating the recall process, there was the impression that it would be a two-step process: the petition would just be the first step, a lightweight filter for frivolous requests, and then the re-RFA would be the second step where we actually examine the evidence and discuss whether to desysop. The reality is that it's a one-step process: the petition itself is what functionally desysops administrators and forces them to reassert themselves as an RfA candidate just like any other RfA. The only functional difference between a regular desysop and a successful recall petition is that the effect is delayed by 30 days, and if the recalled admin chooses to do an RfA within those 30 days, the support threshold is slightly lower. See also § A certified recall petition is a desysop.
• No hard requirement for evidence, consensus, or prior dispute resolution. Because a certified recall petition is a desysop, that means that all it takes is 25 editors to sign to desysop someone today, regardless of the strength of the evidence. We have decided essentially to substitute the judgment of 15 of the most vetted and endorsed members of the community (arbitrators) with 25 self-selected editors who can sign their names without needing to provide any good reasons at all. See also § No hard requirement for evidence, consensus, or prior dispute resolution.
• Administrators who could pass RRfA may choose not to try. It is a failure of the process every time a recalled administrator who in theory could have passed RRfA decides not to try for it. It is disappointing that we chose RfA with minimal modifications to be the venue that decides whether a recalled administrator should keep their tools, as it is well-understood that RfA sucks: there is an immense volume of discussions we have had over the many years about the problems with RfA as a process. See also § Administrators who could pass RRfA may choose not to try.
• Using recall to impose an editor's preferred inactivity policy. There seems to be a commonly expressed view that all administrators should be able to pass RfA at any given time, and if that is not true, then the admin has "lost the trust of the community" and should be desysopped. The problem with this view is that it breaks down when it comes to administrators who are temporarily inactive. RfA intentionally has higher standards than the admin inactivity policy. This is because RfA is something you can prepare for, so RfA participants are going to expect you to come prepared. Real life, however, is something that you sometimes can't prepare for. See also § Using recall to impose an editor's preferred admin inactivity policy.
• Recall process is too long. If we have learned anything about recall, it is that recall petitions tend to be highly visible. The English Wikipedia has a larger community than the German Wikipedia, so there's no need to match the German Wikipedia's thresholds. Thirty days is way too long for a petition, and if you pass RfA or survive a recall, the "recall immunity" you get from that lasts too long as well. See also § Recall process is too long.

Below, in § Proposed solution, I outline my proposed solution. My most important argument is that the recall process should require consensus to desysop in order to desysop. This shifts the focus of the recall discussion to evidence that an administrator is actually causing some active harm (or would be likely to cause harm in the future), and it converts the petition system into being a legitimate filter against frivolous desysop requests, as opposed to being the desysop process.

Background

Current process

Flowchart showing the current administrator recall process as of August 2025

History of prior community-based desysop proposals

Our current recall system is inspired by the German Wikipedia process w:de:Wikipedia:Adminwiederwahl. That process also allows for a "request for re-election" (Antrag auf Wiederwahl) to be successful if (1) 25 editors support it within one month or (2) 50 users support it within six months. Before recall existed, there has been a long history of attempts to create a community-based desysop process. See Wikipedia:History of de-adminship proposals. These proposals are referred to as "community-based" to distinguish it from the Arbitration Committee, which also has the responsibility of reviewing administrator conduct. The Arbitration Committee remains the only way to desysop administrators who have "recall immunity".

Observations and problems

A certified recall petition is a desysop

I suspect that some of the editors who supported creating the recall process may have had the idea that RRfAs would be the primary venue to discuss whether to desysop recalled administrators (with recall petitions being a lightweight filter for RRfA), but the reality is that the petition itself is what functionally desysops administrators and forces them to reassert themselves as an RfA candidate just like any other RfA. RRfA requires affirmative consensus to keep the administrator, meaning it is the successful recall petition that is what effectively causes an administrator to enter a desysopped state. In other words, a certified recall petition is functionally equivalent to a desysop. During the brief 30-day "lame-duck" period where the recalled admin technically still has access to the tools, they could be considered "theoretically desysopped" or subject to a "delayed desysop".

The only functional difference between a regular desysop and a successful recall petition is that the effect is delayed by 30 days, and if the recalled admin chooses to do an RfA within those 30 days, the support threshold is slightly lower. When the Arbitration Committee desysops admins, they almost always allow the admin to regain the tools "at any time" via RfA. Similarly, from the moment a recall petition is certified, the only way for a recalled administrator to return to good standing as an admin is by doing an RfA, which they can also do at any time. Yes, there are slight benefits for doing the RfA within 30 days, but the recalled administrator will still have to write up a nomination statement (or find a nominator), answer the three standard questions, and do everything that a standard RfA candidate would have to do. On top of that, recalled admins are going to have the cloud of the recall hanging over them to make it all the more challenging. I suspect that in the majority of cases it would be better for the recalled admin to resign, remain engaged with the community, write some articles, do some maintenance work, find a good nominator, and then go for RfA after at least 6 months or so, instead of taking up the 30-day RRfA offer.

Using recall to impose an editor's preferred admin inactivity policy

There seems to be a commonly expressed view that all administrators should be able to pass RfA at any given time, and if that is not true, then the admin has "lost the trust of the community" and should be desysopped. The problem with this view is that it breaks down when it comes to administrators who are temporarily inactive.

RfA intentionally has higher standards than the admin inactivity policy. This is because RfA is something you can prepare for, so RfA participants are going to expect you to come prepared. Real life, however, is something that you sometimes can't prepare for. Suppose an administrator has some personal event that causes them to go on an extended wikibreak. The potential reasons are endless: having kids, getting a new job, getting laid off, medical problems. Suppose after 1 year, their situation improves, and they can come back to Wikipedia. If an RfA candidate is inactive for the 12 months prior to their RfA, then that RfA is probably not going to pass. But our policy allows that administrator to request the tools back as long as they have made some effort to remain engaged with our community. That's intentional.

Wikipedia needs more editors doing the janitorial administrative work, and at the moment, there are only two ways for that to happen: either (1) we add more administrators through WP:RFA or WP:AELECT, or (2) we make it easy for existing administrators who are temporarily away to come back and re-engage. If we forced all temporarily inactive administrators to have to go through RfA again, most of them probably would not have come back. At Wikipedia:Administrator recall/Night Gyr, countless administrators—many of whom are highly cherished contributors on this project—offered testimony at how our policy making it easy for former admins to re-engage was what motivated them to return: see e.g. [1][2][3][4][5].

Because of this, it is disappointing to me that the administrator recall process has been used frequently to desysop administrators because they are inactive. We already have a procedural policy for desysopping inactive administrators. If you think that policy is not strict enough, then you should propose changing that policy, not use the recall process to impose a higher activity requirement than specified in policy. In order to recall an administrator, there should be clear evidence that they are actively causing harm or would cause harm if they were to return to activity as an admin. That leads me to my next topic of discussion.

No hard requirement for evidence, consensus, or prior dispute resolution

The most remarkable thing about this whole situation to me is that we spent years—nay, decades—agonizing over how best to create a community-based desysop process that tries to make it easier for editors to file complaints while also recognizing the need to make decisions based on high-quality evidence and well-reasoned judgment. And then the solution we ended up going with can desysop administrators based on no evidence at all. As long as 25 editors sign with 4 tildes, then an administrator is desysopped, no good reasons required. (As I explained above, a certified recall petition is effectively a desysop.)

Furthermore, there is no hard requirement for prior dispute resolution. Yes, there might be a social requirement: we got lucky with Wikipedia:Administrator recall/Necrothesp in that the editors who started the petition agreed with withdraw it within a few hours of starting it once editors pointed out that they could have resolved their dispute at WP:ANI first. In the next recall, we may not be so lucky: as long as there is any one signature still valid on a petition, it cannot be closed early, and given the propensity for editors to pile-on and sign petitions "per XYZ editor" with no further reasoning, it seems likely that even the most frivolous of recall petitions would be forced to stay open for 30 days. To this day, not a single petition has ever managed to remain open for the full 30 days and fail to hit 25 signatures. I will be surprised if one ever happens.

Moreover, consensus is not even a requirement at recall. As I mentioned above, the recall petition itself is where we effectively desysop administrators, not the RRfA. Elsewhere throughout Wikipedia, if you start a discussion that ends without consensus in favor of a change, then the default result is to go with the status quo ante ("the way things were before"), which in this case means allowing the administrator to keep their tools. However, even if 50 editors oppose recall, as long as 25 editors have some beef with an admin, they are effectively desysopped and are forced to undergo RfA again, where "no consensus" would mean they are still desysopped.

Administrators who could pass RRfA may choose not to try

It is well-understood that RfA sucks. As I have stated in the past, RfA often overemphasizes isolated incidents and recent dramas, fails to require corroboration for any allegations or claims, and requires candidates to submit to an intense and often unpleasant examination of every nook and cranny of their Special:Contributions. There is an immense volume of discussions we have had over the many years about the problems with RfA as a process. In fact, the discussion which led to the creation of the recall process was borne out of desires to improve the RfA process. The theory was that by making it easier to remove administrators, Wikipedians would be encouraged to lower the standards for promoting new administrators. The jury is still out on whether that has actually happened. I personally have perceived no change in RfA standards. They're still as high as they ever were.

That is why I am pretty disappointed that we chose RfA with minimal modifications to be the venue that decides whether a recalled administrator should keep their tools. I strongly suspect that administrators who could pass an RRfA simply choose not to. It is not difficult for me to empathize with them. RfA is a very stressful process, and it is probably doubly so when you know your RfA is going to be controversial due to the cloud of the recall petitions hanging over you. We are all volunteers here, and none of us would participate here if we didn't enjoy it at least to some extent. Being forced to go through the recall process and undergo the stress of RfA again is something that would understandably drain the enjoyment out of Wikipedia, at least temporarily. I am not surprised that out of the 9 completed recalls we have had, only 1 ever went to an RRfA.

It is a failure of the process every time a recalled administrator who in theory could have passed RRfA decides not to try for it. It is ironic that the process we created to try to improve RfA and add more administrators may actually be making our administrator shortage worse.

Recall process is too long

There are two parts of the recall process that take way too long:

• Thirty days is too long for a recall petition. If a petition is truly frivolous, that is an agonizingly long amount of time to wait. If we have learned anything about recall, it is that recall petitions tend to be highly visible. If recall petitions took place on some back alley page that no one knows about, 30 days might make sense, but it seems clear to me that a substantial quorum of the active editing community becomes aware of recall petitions within at most 7 days or so. (There is a requirement to post each one at WP:AN, for example.) Having it be thirty days also increases the risk that frivolous petitions will get certified anyway due to pile-on voting behavior.
• Recall immunity lasts too long. You cannot recall an administrator (they have "recall immunity") in the following cases: (1) in the last 12 months, the administrator passed RfA, RRfA, an administrator election, a requests for bureaucratship (RfB), or an Arbitration Committee election, or (2) in the last 6 months, a recall petition against the administrator went the full 30 days without reaching 25 signatures. These lengths don't make a whole lot of sense to me. If an administrator is behaving poorly and below the admin standards of conduct, shouldn't we be able to recall them sooner rather than later? I agree there should be some defense against repeated frivolous recall petitions, but the current immunity length seems like overkill to me.

Proposed solution

From a broader perspective, I do now agree that some community-based desysop process is desirable. I can see how the previous requirement of going to the Arbitration Committee for desysops turned it into an intimidating process that has historically delayed the removal of administrators who for a long time should not have been administrators. However, it is unfortunate that the pendulum has now swung in the complete opposite direction, where we have substituted the judgment of 15 of the most vetted and endorsed members of the community (arbitrators) with 25 self-selected editors who can sign their names without needing to provide any good reasons at all.

Here is how I would modify the administrator recall process to address the observations and problems I identified above.

• Convert "re-request for adminship" (RRfA) into "request for de-adminship" (RfDA).
  • The recall process should require consensus to desysop in order to desysop. This shifts the focus of the recall discussion to evidence that an administrator is actually causing some active harm (or would be likely to cause harm in the future), and it converts the petition system into being a legitimate filter against frivolous desysop requests, as opposed to being the desysop process.
  • The RfDA needs to have a minimum support threshold of 60% in favor of desysopping the administrator. (I'm open to persuasion on the exact threshold here. Maybe we can do 50%.)
  • If there is no consensus or consensus against desysopping, then the recalled administrator will retain the toolset. This would align the recall process with how decision-making works elsewhere throughout Wikipedia: requiring consensus to change something, and then falling back to the status quo ante if there is no consensus for change (the status quo being allowing the administrator to retain the tools).
• Start the request for de-adminship discussion automatically. This eliminates the requirement for the recalled administrator to have to prepare their own RRfA discussion and addresses the problem where an administrator who could theoretically pass RRfA may not be motivated to try it. The responsibility of proving that it would be a benefit to the project to remove an administrator should lie on those seeking to remove the administrator. There should be a hold period of, say, 24-48 hours after the recall petition is certified, which gives the recalled admin the chance to think about resigning or preparing some kind of statement, but after a short hold period, the de-adminship discussion should start without the recalled admin needing to do anything.
• Recall petitions should have a hard minimum requirement of evidence and prior dispute resolution in order to be valid. This means a link needs to be provided to at least one thread at a community forum like WP:AN or WP:ANI that was started in the last 6 months, where the consensus of that discussion was that the administrator engaged in conduct below the standards expected of administrators. Diffs should be provided at the petition page as well showing evidence of conduct unbecoming an administrator.
• Shorten the petition to 7 days. It does not need to be 30 days.
• Eliminate or shorten the period of recall immunity. This is in part because I think recall immunity is unnecessary and also in part to counterbalance the effect of shortening the petition length to 7 days. If after 7 days a petition fails, and then a few weeks later, new evidence comes to light that change people's minds, then a new recall petition can be started again. Editors who repeatedly submit frivolous recall petitions can be dealt with as usual for editors who refuse to get the point: WP:IDHT.

This is actually remarkably similar to the unsuccessful 2021 desysop proposal: Wikipedia:Requests for comment/Desysop Policy (2021). There are some adjustments to make it fit well with the existing recall system.

Flowchart

Flowchart for new process

Proposed policy wording

Under construction