Wikipedia:Administrator recall (2006 proposal)

This is but one idea for community recall. Similar works-in-progress may be seen at User:Dmcdevit/Proposal for desysopping and Wikipedia:German de-adminship solution. For the previous suggestions that were not enacted, see Wikipedia:Requests for de-adminship.

Overview

At most levels of user access, the decision to grant is made through community consensus. Local to the English Wikipedia, administrators and bureaucrats are selected by the community by requests for adminship, are expected to be "known and trusted member[s] of the community" before they are promoted. In some cases the subsequent behavior of the editor after being promoted may cause them to lose that trust.

For severe or acute abuse of administrator privileges, a request for arbitration is an appropriate step. The Arbitration Committee has ruled with regards to administrator conduct, and have revoked privileges as required. For problems that are chronic or that do not involve direct use of privileges, the Committee has traditionally been reluctant to open a case. In these cases, recall allows the community to discuss the administrator's continued position of trust.

For real-world examples of related processes, see the Wikipedia articles on votes of no confidence and recall elections.

Proposed processes

Two similar but structurally different proposals came out of the rejection of the earlier formulation, Wikipedia:Admin recall (August 2006 proposal). For convenience, they are labeled according to their primary author, although both have changed significantly during discussion.

Process 1 (Doc_glasgow)

Wording is taken strictly from Doc's original proposal at this point.

1. The initial step is a request for comment - to allow an attempt at solutions by community discussion.
2. If this is obviously failing to address the concerns, after 3 days, any administrator may initiate a 'recall petition' on the RfC.
3. Providing that this motion is supported by at least six other administrators, it may be referred to Arbcom.
4. Arbcom shall then consider whether an administrator: 1) still enjoys the confidence of the community, and 2) is still of net benefit to the project.
5. If Arbcom deems the administrator to fail one of these conditions, it may order the desysopping of the administrator, or impose other restrictions or remedies as it sees fit.

Process 1 Mk II

1. The initial step is a request for comment to allow an attempt at solutions by community discussion.
2. After at least undecided number of days Z^[1] days of discusion, any administrator may initiate a 'recall petition' on the main request for comment page.
3. Providing that this motion is endorsed by at least undecided number X^[2] other administrators and undecided number Y^[3] users total, a request for recall/reconfirmation will commence.
4. This process will have a similar structure of an existing request for adminship, and consensus^[4] will be interpreted by a bureaucrat.
5. Arbcom shall then consider whether an administrator still enjoys the confidence of the community, and is still of net benefit to the project.
6. If Arbcom deems the administrator to fail either of these conditions, it may certify the outcome and order the desysopping of the administrator, or impose other restrictions and remedies as it sees fit.

Process 2 (Tony's Hybrid)

1. User submits request at ArbCom page, with a similar filing format to a standard request for arbitration (template to be developed later).
2. The Arbitration Committee reviews this filing in up to 7 days (give or take). If four active members agree to a recall, it will move to a recall/reconfirmation RfA^[5], or ArbCom may decide to "escalate" it to a full case review under their jurisdiction. The usual rejection criteria for failed applications also apply (see Wikipedia:Arbitration policy).
3. As in a normal RfA, a bureaucrat will make a decision based on everything presented. A steward will remove access if the bureaucrat decides that this is the consensus.

Gatekeeper function

A strong component of criticisms of the original proposal was that the process not be susceptible to "gaming" or abuse by trolls. As such, it was proposed to include the Arbitration Committee as a "gatekeeper" to exclude frivolous filings. One of the primary differences between the two proposed processes above is where this gatekeeper function takes place: before or after the recall/reconfirmation^[6].

Exclusions

Jimbo Wales, current employees of the Wikimedia Foundation, Stewards, Developers, and any active member of the Board_of_Trustees are all excluded from this policy.

I can understand why such users would be exempt, but if one such user/admin should start abusing said powers and privileges? what would we do, wait until the next election? I feel they ought to be recallable just as the rest of the admins. Don 20:45, 3 September 2006 (UTC)

Repeated recalls

At present, there is no firm opinion on the subject of "immunity" against repeated recalls, ostensibly to prevent abuse/trolling by users filing against unpopular admins. Please discuss on the talk page if this sort of protection is important to you; note that both proposals contain the gatekeeper function of the ArbCom's involvement.

Notes

1. ^ Rough consensus for the parameter-free version of this policy may be established prior to implementation. Undecided details such as numbers X, Y, and Z can then be determined at a second stage of consensus gathering.
2. ^ It has not been decided yet whether the recall/reconfirmation will take a recall ("Shall this person retain their sysop privileges?") or reconfirmation ("Shall this person have their sysop privileges removed?") format. This will have a great impact on the numbers required; in one case, consensus is required to retain the sysop bit, while in the other, consensus is required to take it away.

See also

• Wikipedia:Admin accountability poll
• Wikipedia:Requests for de-adminship