Wikipedia:De-adminship proposal checklist

New methods for removing the sysop bit from admins are a perennial fixture at the Village Pump. Wikipedia:Requests for de-adminship (WP:RFDA) lists many of these proposals; they seem to appear approximately quarterly, and they have universally failed to attract community consensus.

Any proposed process ought to consider – and, where applicable, to answer – the following questions.

Questions

Clarity

• How does it work?

Are timelines, outcomes, and structure (who presents what, where, and when) clear? How does the process start and end? What are the key milestones? Is there a mechanism for appeal?

• Who makes the call?

Is it unambiguous who is responsible for making the final decision to desysop? Is the basis on which they are to make that call spelled out explicitly?

• Does this affect other processes?

Will this proposal include changes to the scope and responsibilities outlined in the RfA, RfB, RfC, Arbitration, or other existing processes?

Utility

• Would the proposed process have made previous desysoppings 'better' for the community in some way?

At the time of writing, WP:RFDA lists 46 users who were involuntarily desysopped. Would the proposal under consideration have been potentially useful in any of those desysoppings? Would the proposal have reduced drama or paperwork in those cases? Could the proposal have resulted in a 'better' outcome (possibly not requiring desysopping, or including the desysopping of other parties)?

• Does the proposal risk making things substantially 'worse' for the community in some way?

If the process were used as designed, is there a substantial probability that its outcomes would be unsatisfactory to some significant fraction of the community? Will many cases end up referred or appealed to ArbCom or other venues anyway, leading to a longer, slower resolution process? How will those concerns be addressed?

• Is there a new class of admins who would be exposed to desysopping?

Does the process contemplate desysopping for a broader range of offenses than has historically been the case?

• Do you have any current examples of candidates for this process?

While suggestions of this sort should not be made lightly, the community is likely to find a proposal more persuasive if it can be demonstrated that an existing problem will (or could) be solved. Does the proposed process address a candidate case that could not be effectively handled within our existing desysopping framework?

• Is the process open to abuse in ways that existing process are not?

Can the process be used in bad faith to desysop admins who should not be desysopped, or gamed to retain admins who should be removed? While almost every Wikipedia process is open to abuse simply by the nature of a wiki, a process that's too easy to abuse will likely not be acceptable. On the other hand, a process that attempts to close possible avenues for abuse with extra bureaucracy is also problematic.

Superfluity/Redundancy

• Is the proposed process substantially similar to an existing dispute resolution method?

Does the proposed process represent a small modification to an existing process (like RfC)? Is there a way to use the existing process without building a new parallel structure? Instead of getting bogged down in a month or two of pointless process wanking, could you just go ahead and run a pilot RfC/ArbCom/WP:AN/what-have-you case?

• Does the process duplicate ArbCom?

Does the proposal produce a new deliberative body/tribunal/council that will be substantially similar to ArbCom; if so, is there a beneficial difference?

• Is this proposal something that should instead be addressed by modification of another policy?

Is this proposal intended to resolve a matter that could be more easily or appropriately be addressed by modification of an existing policy? Could changes be incorporated into WP:ADMIN or the Arbitration policy to accomplish the same goals? (Have those changes been proposed, discussed, and/or rejected before?)

• Is this proposal substantially similar or identical to a proposal made in the past?

If so, what differences are there between the current proposal and the rejected one? What efforts been made to rectify deficiencies identified previously? What circumstances may have changed in the community to warrant reopening a rejected proposal or to nullify past concerns?

Trust

• How will confidential information be handled, and by whom?

Some cases will involve information regulated by our privacy policies and other Foundation rules. Who will be the gatekeepers for private information (CheckUser data, private emails and email addresses, real-world names and addresses, etc.)? How will information of this type which impinges on a case be presented or discussed? If all communication is planned to take place on-wiki, will there be WP:BEANS problems? If off-wiki communications channels are to be used, will there be accountability issues? If changes are required to any Foundation-imposed policies, has the Board (or any Board member) commented?

• How will the overseers of the proposed process be selected?

Will there be some sort of community confirmation or vetting? Will there be restrictions on who may or may not oversee the process (admins, not admins, Arbs, etc.)? If desysopping power is granted to an existing group (bureaucrats, for example), will there be a reconfirmation process or an opportunity for the community to examine those candidates? Will there be term limits?

Technical

• Does this proposal require changes to the MediaWiki software or configuration?

Are new user rights or categories going to be created? Does the interface need any changes? Is there someone willing to do the work? At a minimum, has an expert been consulted to determine the likely scale or difficulty of any proposed modifications?

Implementation

• How will consensus to activate the proposal be determined?

Under what conditions should the proposal be enacted? Will it apply to all admins, or a subset (admins created before or after a certain date, participating volunteers, etc.)?

• How will the performance of the process be reviewed?

After each of the first few cases, will there be a 'post-mortem' to determine what is and is not working? Is there a mechanism for amendments to the process (above and beyond minor tweaking and evolution)? Will there be a review at some set future date to evaluate the process? Should that review include a binding recommendation on whether or not to maintain the process?

See also

• Wikipedia:Administrators
• Wikipedia:Arbitration policy
• Wikipedia:Removing administrator rights (the current how-to guide)
• Wikipedia:Requests for de-adminship
• Wikipedia:Administrators open to recall