Wikipedia:Administrators/RfC for binding administrator recall

Introduction

In the past, the Community de-adminship proof of concept RfC established consensus for some community-based method of removing sysop privileges from an administrator in situations where attempts to amicably resolve issues have not been successful. Significant community concern was also demonstrated regarding the need for any de-adminship process to be resistant to frivolous complaints.

The current situation of de-adminship procedures is as follows, with the table taken from WP:BARC.

Current methods to remove adminship
Process	Does not require fresh request for adminship	Requires fresh request for adminship
Voluntary removal	For most reasons that the administrator chooses to resign their userright	If the administrator chooses to remove the userright "under a cloud", i.e. whilst their actions are under scrutiny, perhaps during an arbitration case or elsewhere. If the administrator has agreed to removal due to a successful "recall"
Inactivity	If the administrator has been completely inactive for between 1 and 3 years	If the administrator has been completely inactive for more than 3 years
For cause	N/A	If the administrator has the user-right removed. Arbcom can do this with a case, or without in certain circumstances.
Other	Technically, the stewards or bureaucrats have the ability to remove the tools in an emergency. Also, Jimbo Wales could theoretically also remove administrator access at his discretion. These situations would likely have subsequent repercussions. In the most severe cases, the community can site ban administrators, regardless of their status.

Background on other Wikipedias

On certain other language Wikipedias, there exists a process for administrator recall. Distinct from WP:RECALL, a voluntary and non-binding de-sysopping method on the English Wikipedia, administrator recall (more accurately translated as administrator re-election) provides a process for de-adminship that applies to all administrators. One example is Adminwiederwahl on the German Wikipedia. The general components of this process are as follows, as explained by Gestumblindi at WP:BARC.

1. To initiate the process, a certain number of editors must request recall over a specified period of time. This is described as a quorum.

   German Wikipedia uses a quorum of 25 editors over a one month period or 50 editors over a six month period.

2. Once a quorum is obtained, the administrator must go through a recall RfA (RRfA) to retain sysop privileges, using the same procedures as WP:RfA.

   Should the RRfA fail, the administrator's sysop privileges are removed. They may regain them at any time through a successful RfA. Should the RRfA be successful, the administrator retains their sysop privileges.

3. On some other language Wikipedias, there is a "cooldown" time between potential recalls, meaning an administrator cannot be required to go through RRfA more often than once in a certain specified period of time.

   On the German Wikipedia, this time period is a year.

4. Administrators have a certain period of time (grace period) to respond to a quorum, at which point they can decide whether to go through a RRfA. Failing to agree to and start the RRfA within the grace period after a quorum has been reached results in the removal of sysop tools.

   The grace period exists to allow sufficient time for an admin to decide whether they wish to go through a RRfA and to provide a guideline on when to remove tools if an admin does not respond. It also ensures the admin is not removed while on a wikibreak, as they have control over when the RRfA is started, within the grace period. This time period is 30 days on the German Wikipedia.

5. Bureaucrats fill the same role in recall as they do in a normal RfA. They determine consensus in borderline cases.

Statistics from German Wikipedia

From 2009 to February 2015, the German Wikipedia has had the following outcomes from recall quorums. Note that different numbers/time periods were used to determine quorum early on, and that there was a large number of recalls in 2009 when this policy first came into effect.

1. Re-elected: 45 (31.7%)
2. Not re-elected: 44 (31.0%)
3. Chose to retire: 33 (23.2%)
4. Automatically de-sysopped (did not respond): 20 (14.1%)

Total: 142

For reference, the following stats exclude 2009, which was the first year this was in effect.

1. Re-elected: 33 (44.0%)
2. Not re-elected: 10 (13.3%)
3. Chose to retire: 12 (16.0%)
4. Automatically de-sysopped (did not respond): 20 (26.7%)

Total: 75

Proposal for Admin Recall

It is proposed that the community create a system of binding admin recall similar to that of the German Wikipedia. In particular, such a system will include the following features, adapted from above:

1. To initiate the process, a quorum of editors must be established. Editors in the quorum would be expected to act in good faith to resolve any cited issues prior to calling for recall.
2. Once a quorum is obtained, the administrator must go through an RRfA to retain sysop privileges, using the same general procedure as WP:RfA.
3. There will be a "cooldown" time between potential recalls, meaning an administrator cannot be required to go through an RRfA more often than once in a certain specified period of time.
4. Administrators have a grace period to respond to a quorum, during which they can decide whether to go through an RRfA. Failing to agree to and start the RRfA within the grace period after a quorum has been reached results in the removal of sysop tools.
5. Bureaucrats fill the same role in this process as they do in a normal RfA. They would determine consensus in borderline cases as well as discard calls for recall and !votes that are not made in good faith.

The current proposal is intended as a starting point for creating a process for binding admin recall, and omits many of the important details. The following details would be established at a future RfC:

1. How many editors make up a quorum
2. What period of time a quorum must be established in
3. What period of time will be used as a "cooldown" before a recently recalled administrator can be the subject of recall again
4. What grace period is given before sysop tools are removed when the administrator does not agree to an RRfA, either explicitly or through lack of response
5. Burden of proof for support required to maintain admin tools in a recall (i.e. Is the baseline "Admin must prove consensus to keep tools" or "Community must prove consensus to remove tools"?)

Relation to similar RfCs and timetable

At the time of writing, there is a similar RfC pending that seeks to establish a different type of de-adminship procedure. These RfCs are completely independent, and one does not affect the other. Please keep in mind that both RfCs are explicitly asking the question "Do you support this?" The comparison being made is the proposal versus our current situation, not the two proposals to each other. The comparison of other proposals to admin recall can be handled in a future RfC once all possible options have been finalized, if necessary. This is not a final discussion to approve implementation; it is a discussion to determine whether the idea merits further investigation and could feasibly lead to a process that would have consensus.

The proposed timetable for RfCs is as follows:

1. General approval for proof of concept
2. Seek consensus on details, as described above
3. Final approval (including comparison to similar solutions if necessary)

Voting

Do you support the adoption of this proposed system of binding administrator recall, with final details to be debated in a later RfC and subject to final approval? ~ Rob^Talk

Support

1. Support as proposer. My hope is that this is a truly community-based proposal that responds to the concerns of editors who have opposed other de-adminship procedures, while also greatly limiting potentials for abuse. ~ Rob^Talk 05:33, 10 August 2015 (UTC)
2. This method tackles all my issues with "mandatory recall". It is a truly community effort, the reconfirmation RfA will show that the community whether still trusts the administrator. The grace period allows the administrator to decide when the reconfirmation RfA happens. Alternatives to Arbcom should exist for desysopping, and since this method already works in de.Wp, it's better than re-inventing the wheel. Worm^TT(talk) 07:42, 10 August 2015 (UTC)
3. Support partially, because it's community driven, but with a strong caveat that while drawing the comparison with the German Wikipedia is interesting, the European German language region has an entirely different culture from our Anglo-American ways of thinking and interacting, and to try and compare them is to compare apples with oranges or to end up with a false dichotomy. There is also a further fundamental difference in German systems in that like most other Wikis, they demand users to be stimmberechtigt, i.e. eligible to vote according to fixed criteria. I do think that to make access easier to an equitable and reasonably punctual process for both plaintifs and admins, desysoping should be significantly relieved from its 100% Arbitration Committee control. I'm not saying that the Committee dispenses poor justice any more than a crat chat at RfA might reach the wrong decision, but unlike RfA which is still littered with dubious voter motives in both sections, I still do not believe that any free-for-all voting system will keep kangaroos, pitchforks, and peanuts at bay here in the English speaking world. Oppose #3 (Wehwalt) expresses further important caveats and advice on the politics and timing of desysopping RfCs, but not enough to land me in that section.Kudpung กุดผึ้ง (talk) 13:15, 10 August 2015 (UTC)
4. Support We need a community based system in place that can deal with problematic admins. The basis of the general outline is good and I am sure there will be a lot of fine tuning in the future with RFC's on specifics already planned. AlbinoFerret 15:41, 10 August 2015 (UTC)

Oppose

1. I fear that any mandatory recall procedure is too susceptible to political maneuvering. ArbCom, for all its, at times, glacial pace, is not subject to crowd mentality or outside canvassing (which is all but impossible to prevent—we are not the NSA . This means that when someone is being considered for bit removal, that consideration is deliberate and as much less prone to any partiality or impropriety. Should we have recall system similar to what is described above, I fear that it will be used as a weapon between various groups of highly-antithetical editors or by aggrieved editors against the administrators or bureaucrats who are enforcing Wikipedia policy and guidelines. In my opinion, this will tend to result in three highly undesirable outcomes:
   1. The loss of good administrators or bureaucrats due to improper application of the recall
   2. The loss of good administrators or bureaucrats due to burn out and exhaustion of undergoing the recall (even if there is a "grace period")
   3. The loss of necessary activity by good administrators or bureaucrats for fear of a recall

   Remember, most administrators or bureaucrats will perform actions that upset someone throughout their tenure, even if they do everything completely properly. Be it the proper deletion of an article, the proper protection of a page, or the proper blocking of an editor. This will cause upsetness, especially against the administrators or bureaucrats who bravely implement ArbCom sanctions, and are in danger of "upsetting" scores of editors. I'd much rather see a streamlined ArbCom process for handling poor admins than something with this potential for abuse. What I would like to see is for administrators or bureaucrats to be held to (reasonable) civility standards. All editors should be civil (and NOTCENSORED is not a reason to use obscenities in conversation, in my opinion) but administrators or bureaucrats should take extra effort to do so, if only because increased their increased responsibility for the project. However, that does not mean that someone who loses their temper should be hauled off to the court of recall. Thank you. -- Avi (talk) 07:13, 10 August 2015 (UTC)

2. I spent some time thinking about this. While I appreciate the effort that went into this, I am too concerned about such an open-for-all recall system generating a chilling effect on administrators working in controversial areas. Or just plainly be misused by people which are in a conflict with the administrators in question, whether in good faith or bad faith - or with an alternate account of the administrator, such as a WMF staffer. One could easily get a sufficient number of recall votes from several controversial decisions that are bound to happen during an administrator's work. Jo-Jo Eumerus (talk, contributions) 08:16, 10 August 2015 (UTC)
3. I also fear the possibility of political maneuvering. There is no gatekeeper here, and very little possibility of one, as you have no one who has a mandate to perform the function and are unlikely to find any group that can attain consensus as such (and that would not be seen as duplicative, basically of ArbCom) .

   Additionally, the admin reform movement is descending to an almost desperate attempt to see what they can throw that will stick, not even waiting for the other (fifteen, I think) proposals to finish sliding down that wall before tossing this, product of a few days' consultation by a limited number of editors. BARC isn't quite dead yet and off we go on another. Do your bureaucrats offend you? Well, then cut them off and see if we can get something vague through (the fact that the proposers won't even commit to whether the admin or the accusers have the burden of proof in a reconfirmation procedure is particularly telling). Let's reform the criminal justice system in principle, except we won't say whether the state or the defendant has the burden of proof! At least it will get us to the next stage. No. Clear the board, discuss it fully, come up with one proposal, and sink or swim by it for a period of time. These constant new proposals do no one any good.--Wehwalt (talk) 08:18, 10 August 2015 (UTC)

   I did not plan to respond to votes, but I should note that I independently decided to write this proposal after seeing the German system mentioned at BARC. While I asked a few editors who advocate reform for their opinions, I am not part of any "movement" or cabal. I'm a single editor who thinks this is the best solution, nothing more. If anything motivated me to write this, it was a dislike of BARC, not an attempt to push through reform at any cost. ~ Rob^Talk 08:28, 10 August 2015 (UTC)

   You did post that you were working on it, with link, and appealed for help in your userspace. Nothing wrong with that, but supporters are still throwing one RfC after another at that wall, and I think Stifle's oppose to the BARC proposal sums up my views on this one better than I did (the camel's nose analogy). These endless RfCs do no one any good. If there is to be change, it should be a final settlement that (to some extent) satisfies enough of the community to end this time sink. I just don't see this as that answer. What works for the German Wikipedia works for the German Wikipedia. They are no more a guide to us, with a different culture and a far greater throughput, than we are to them.--Wehwalt (talk) 08:36, 10 August 2015 (UTC)

4. Strongest possible nuclear attack oppose I posted a reply at Wikipedia:Administrators' noticeboard#RfC for binding administrator recall. The BARC proposal hasn't even been closed yet, and this is the 16th discussion on RfA reform going on at the same time. Enough is enough. "Time sink" is the appropriate description, used by Wehwalt. You, Rob, arrived here two months ago, well, other editors have seen these discussions going on for years, with no result. I hope my reply at AN deters users from coming here. I suggest you withdraw this. Kraxler (talk) 13:54, 10 August 2015 (UTC)
5. Given the proposal offers no criteria by which a recall can be initiated, this basically leaves it wide open to being gamed by a block of users who want to harass or remove admins they do not like. As with others above, this would only create a chilling effect that pushes admins away from work in controversial areas. Resolute 16:15, 10 August 2015 (UTC)
6. Oppose: I'll ask the same question I asked over at WP:BARC; "Before even considering whether this could possibly be a valid process one needs to ask this question: What administrator who was not desysopped would have been desysopped by this process?" If you can't come up with a single example, then it becomes blatantly obvious this process has no purpose." You don't have to name such an admin, but in your own mind if you can't come up with one there's no point to this process. I also share Resolute's concerns. One of the chief problems with any community based desysop process is the extreme potential for chilling effects. Admins crazy enough to work in highly contentious areas would fear working in such areas for fear of reprisals. ArbCom has an evidence process that strongly addresses such concerns. This process does not. --Hammersoft (talk) 16:45, 10 August 2015 (UTC)

Neutral

1. I am unsure that the nicely precise process used in the DeutschWiki would work well with the herd of cats on EnglishWiki ... I would, however, suggest that any admin with no significant use of specific admin tools be flagged as "inactive" rather than allow trivial usage of such tools to reset the game clock. Collect (talk) 13:43, 10 August 2015 (UTC)

   On the other hand, those who hardly use their tools are probably least likely to fall foul of a lynch mob, and removing bits for inactivity generally serves only to keep the stats in order, but that's all for another discussion. I don't think the German system will work well here either but I'm prepared to have it put to the test if there is consensus for it. If it's wrong of course, we'll get lumbered with it for at least a decade before we can get it changed again. --Kudpung กุดผึ้ง (talk) 14:00, 10 August 2015 (UTC)

Discussion

My advice on this RfC was personally solicited as was the advice of others who are or will be voting here. Apart from my experience of a great many years in Germany, I also tendered the following more general reflections on the situation that leads to these RfCs because it's not all about timing and the flurry of parallel discussions in various places, but to remind ourselves of the actual reasons why they are taking place. Those who have a vested interest in desysoping procedures fall very broadly into two camps: admins who know they are not acting in the best of good faith and are afraid of being turned into a public effigy, and non admins who fear that too little is done to protect them from rogue admins. This breaks down however into:

• Users who claim, for whatever reason, that admins have a thing against prolific content providers.
• Users who have never been the object of Wikipedia disciplinary measures or warnings who nevertheless make loud and persistent claims that Wikipedia is doomed due to its admin structure.
• Users who want the bar to RfA kept high to prevent the wrong kind of admins from being elected.
• Those who want the bar to adminship significantly lowered (possibly to get easier access to the coveted tools or status).
• Those who want the bar to adminship significantly lowered but at the same time want it therefore easier to desysop rogue or poor performing admins.
• Those who want a community driven (i.e. an alternative to Arbcom) desysoping process that nevertheless is not driven by trolls and the pitchforks of the peanut gallery.
• And of course admins who are reluctant to work in the front line trenches for fear of reprisals for just doing their job.

Kudpung กุดผึ้ง (talk) 14:15, 10 August 2015 (UTC)

Oi. You forgot a third group: Admins who are working away and doing difficult and sometimes unpleasant things and are tired of people going around saying that they're "not acting in the best of good faith and are afraid of being turned into a public effigy." Please stop insinuating that any admin who opposes these sorts of proposals is inherently deficient in their administrator work. It is incredibly demotivating, particularly to some of us who quite literally are volunteering hundreds of hours of our time each month with nary a thanks. And you wonder why nobody wants to run for RFA anymore. Risker (talk) 15:12, 10 August 2015 (UTC)

To those who wish to continue with community consensus being the primary decision-making mechanism, yes, the consensus process is a time sink. There's just no way for a few hundred interested persons to quickly sort through dozens of options and filter them down to a best approach. To continue with this approach, the community as a whole can either a) avoid spending any time on these matters by accepting all major policies and procedures exactly as they are now, b) be willing to invest time to improve them, or c) empower a working group in each area of interest to develop proposals designed for maximum acceptance which are subsequently ratified. isaacl (talk) 16:45, 10 August 2015 (UTC)