User:NoSeptember/Arbcom punishments

The NoSeptember Admin Project

Intermediate admin punishment proposals

Ideas for intermediate punishments for admins who come before Arbcom. Related ArbCom policy (see Footnote #1)

Deficiency of the current punishments applicable to admins:

• Punishments are either minor (reprimand) or major (desysopping), ArbCom has not been applying intermediate punishments to admins.
• Unlike user sanctions, where blocking is an effective enforcement mechanism, admins can unblock themselves and can not be physically restrained from violating a probation if they are determined to violate it, except by desysopping.
• Admins involved in such cases often have many relationships throughout the community. The lack of flexibility of sanctions and the unresolved nature of the current desysopping with reapplication process can cause the case to continue to live on in the minds of the community long beyond the conclusion of the ArbCom case.

A sanction that is not intermediate:

1. Desysopping with permission to reapply via the RfA process
   • a desysopping with the requirement to reapply for adminship is in practical effect a permanent punishment (since most admins involved in any significant dispute could not succeed in a new RfA, given the enemies they pick up just doing their job as admin and the low percentage level of opposition required to block adminship) (see Resysop applications)
   • An example: The difference in the future of adminship for Ashibaka, BorgHunter, Carnildo and Karmafist were clearly determined by ArbCom in its decision. The wheel war had supporters on both sides, neither side could have overcome the 20-25% opposition level that it takes to deny adminship in an RfA, so the decision to desysop was for all intents and purposes the final say on the matter, and it was ArbCom not the community that made that decision.
   • A major impact of a sanction widely perceived as too harsh by many is the departure from the project of many editors, not just those involved in the case, but also those who are watching the controversy. We have seen several major contributors depart in the recent case where this sanction was applied.

An aspect of admin accounts that can be exploited by ArbCom in their sanctions:

• Unlike sanctions against users that can be avoided by that user creating new accounts, an admin's buttons can not be obtained by new account creation. This fact is the key to enforcement of probationary sanctions against admins who may otherwise willingly violate a probation. While a permanently banned user can continue to come back by just finding an unblocked IP, an admin does not have this option when it comes to the use of the admin buttons.
• All the actions in an admin's account are quite transparent, so a violation of probation would be visible and enforcement of a violation would be swift.

Intermediate sanctions proposed:
Given the lack of sanctions between the minor and the major, and the inability of admins to create alternate admin accounts, the following intermediate sanctions could be effective (options 2 - 5 are the new proposals being made here).

1. Probation (this has used by ArbCom)

   Can be applied to the specific circumstances of the case. (Example: In a case where moves and/or deletions are the issue, the sanction could be to prohibit the move or deletion of any article beyond a certain size.)

   1. Timed probation against blocking
   2. Timed probation against deletion
   3. Timed probation against protection
   4. Timed probation against actions that can be performed by non-admins (moves, involvement in specific articles, etc.)

   Enforcement can involve an extention of the probation period or a reopening of the case in case of violations.

2. Temporary timed desysopping
   (example: X is desysopped for 3 months, adminship to be restored automatically)
   • In a community where participants may only stay for a few years, a 2, 3 or 4 months desysopping penalty is a significant yet non-permanent punishment.
   • Probation in areas not requiring admin buttons can run concurrently.
   • If the sanctioned admin has a meltdown during this temporary desysopping, the ruling can be reconsidered by ArbCom before adminship is restored.
3. A negotiated penalty between Arbcom and the admin with enforcement action available if violated. See Carnildo's negotiation proposal (comment below his acceptance), which if it were an ArbCom case, could be a first step to negotiate a sanction. ArbCom will of course only accept a sanction that they feel is adequate, and an impasse may occur, leaving the decision to ArbCom to make in the end. A negotiation can show the good faith of the involved admin, and past successful negotiations could generate precedents for other effective intermediate sanctions in the future.
4. Presenting a choice of penalties to the admin (example: X has the option of accepting a timed desysopping of 4 months or reapplying earlier via RfA).
5. An alternative to RfA for resysoppings. In most cases in Wikipedia a consensus is required to change the status quo (i.e. a lack of AfD consensus means the article is kept). The opposite is the case with desysopping. In a desysopping case, the status quo going into the controversy is that the user is an admin, yet we require a consensus to maintain the status quo and a lack of consensus changes the status quo. Perhaps, instead of requiring an RfA, an RfD (request for desysop) could be ordered, requiring a consensus to desysop (with perhaps a 60% level considered a consensus).

The Bottom Line:
The current policy stated in Footnote #1 below is inadequate in the range of sanctions to be applied against admins who abuse their powers. ArbCom should try various intermediate penalties, encourage community feedback, and develop more options for handling admin abuse cases. Continuing to limit its sanctions to either reprimand on the one hand or permanent desysopping (where reapplication is required) on the other makes for a very clumsy enforcement policy.

Without intermediate sanctions, desysopping as a punishment is used much less frequently than it could be (with temporary desysoppings). This results in the RfA community appying very high standards to admin candidates, and makes adminship a "big deal", since once someone passes RfA only very rarely will they be desysopped, even if they become a "problem admin".

Footnote #1: The current ArbCom policy, Wikipedia:Arbitration policy/Past decisions#Administrators:

Statement(s) of principle

• Administrators of Wikipedia are trusted members of the community and are expected to follow Wikipedia policies. (See Wikipedia:Administrators.)
• Administrators are expected to pursue their duties to the best of their abilities. Occasional mistakes are entirely compatible with this: administrators are not expected to be perfect. Consistently poor judgement may result in removal (temporary or otherwise) of admin status.
• Wikipedia:Administrators are Wikipedia users who on the basis of trustworthiness have been granted the power to execute certain commands which ordinary users can not execute. This includes the power to block and unblock other users or IP addresses provided that Wikipedia:Blocking policy is followed.
• Sysop powers must not be used to win a dispute about content.
• One aspect of the responsibilities of an Administrator is to attempt to prevent disruption to the Wikipedia site and its users.

Previous penalties relating to principle

Administrators who abuse their powers may be subjected to a reapplication for adminship via RFA procedure.