User:Cyberpower678/Community Desysopping Procedures Workshop

Introduction (PLEASE READ)

Throughout the years the community has agreed on the fact that once someone is given the admin bit, removing it from them for behaving in a manner inconsistent with an admin would be way too difficult requiring the problem to be escalated to ArbCom, and waiting through month long processes for any form of disciplinary action to take place.

The subsequent result is that standards for adminship have risen making it less possible for notable admin candidates to pass RfA. Because the standards for "lifetime" adminship is so high, fewer promising users are willing to actually go through the process, or users that would otherwise make a promising administrator will fail as a result of these high standards.

A method to bring these standards and enhance Wikipedia's process of checks and balances is to empower the community to remove the bit if they see fit. This RfC will attempt grant the community limited powers to community desysopping while ensuring the process of checks and balances remains in place.

To do this, the RfC will take a slightly different approach to establishing this new policy by segmenting this policy into different components to be discussed, and then the approved segments will be combined into a final worded policy. This will result in the RfC to be rather long, but will allow the options to be thoroughly discussed consider, and hopefully, in the end, be passed and made into a working policy the community can agree on.

So before proceeding, I ask that you please be patient as you work through this RfC and read it over first before going through each segment and commenting.

Part 1

Consensus can change, and the last time consensus was established that the community should have some kind of process for a community desysopping was many years ago. As such the question will be asked again. Please note that this is a general question and the process specific questions will be asked in Part 2 of the RfC.

Question: Should the community have some kind of process, aside from ArbCom, to allow the community to strip the administrative tool set from a problematic administrator?

Part 2

This part will only be about establishing a process for community desysopping. In order to establish the process, Part 1 must be considered passed during the closing of the RfC for Part 2 to be considered.

If Part 1 fails, the entire RfC is considered a failure.

Part A

This section will discuss the general process of the proposed procedure. The specifics will be discussed in subsequent sections.

Starting the process

1. A user reports the admin in question to either AN or ANI.
2. The AN/I discussion runs as normal with users commenting, providing evidence, or refuting the claims made by the OP.
3. An uninvolved user, i.e. users not mentioned in any evidence provided as well not the OP, can open a sub-thread calling for a forced reconfirmation RfA. The thread is either transcluded in a sub-page of AN, or a direct sub-thread of the main thread.
4. The thread will run for a set duration of time, while users either support or oppose starting a forced reconfirmation RfA with the reasons why.
5. Once the thread has run the specified duration, a number of neutral and uninvolved closers, will close the thread and determine if there is sufficient consensus to start the process.
6. If there is consensus, the reconfirmation RfA will be initiated. The admin’s rights will be removed during the start or the end of the RfA.
7. The RfA will run as normal, and will be closed by a bureaucrat.

Checks and balances

(these points will be discussed in sections below)

1. As mentioned the OP or any user mentioned in any evidence being used to question the suitability of retaining adminship for the user may not initiate the call for reconfirmation, and may be reverted immediately.
2. The call for a reconfirmation RfA can only be initiated if sufficient evidence is presented and the participants in the AN/I thread feel it raises questions about the sysop’s suitability to remain a sysop.
3. As mentioned in step 5 above, only users that are uninvolved admins, bureaucrats, or in a specific nominated committee of closers. The number of closers required to close the discussion will be discussed in the RfC.
4. The reconfirmation RfA can only be initiated if the sysop in question volunteers to initiate one, or the call for reconfirmation AN/I thread is formally closed.
5. The sysop in question will either have the bit removed when the RfA is started and returned to them at the end, or the bit will be removed at the end of the RfA, depending on the outcome of the RfA.
6. The sub-thread calling for reconfirmation RfA can only be participated in by users that are established within the community. This restriction also applies to the reconfirmation RfA.
7. Any admin that has successfully passed a reconfirmation within a 6 month period, cannot be forced to go through another one. Administrators being reported can only have a call for reconfirmation thread opened on them once a month. New reports cannot mention previously mentioned evidence, unless it was seen as problematic in the past, but not enough to question the suitability of an administrator. If there are concerns with the behavior of the administrator and this process was unable to adequately address the issue, the user is required to file an ArbCom case or drop the matter.

Rights of the sysop in questions

(these points will also be discussed in sections below)

1. The sysop being reported may participate and refute evidence as they see fit.
2. The sysop being reported may oppose the call for reconfirmation.
3. The sysop being reported may preemptively close the call for reconfirmation and initiate one themselves, or relinquish their admin access.
4. The sysop may withdraw from the RfA, and relinquish their admin access, provided the RfA was a forced reconfirmation or a voluntary reconfirmation as a result of the AN/I.

Procedural remarks

1. If the sysop relinquishes their sysop bit during the RfA, or call for reconfirmation, the removal is considered to be under a WP:CLOUD.

Part B

This part discusses the specifics of the proposed process in Part A. If Part A has failed to reach a consensus, this RfC is considered not passed.

Checks and balances 1

In point 1 of the proposal, the process does not allow any involved user to initiate the sub-discussion which calls for the sysop to undergo a reconfirmation RfA. Included in this prohibition, is the original poster of the initial AN/I thread as well as any user listed in the evidence presented against the administrator in question, with the exception of the administrator in question. This is to prevent possible lynching from disgruntled involved users.

Question: Should the prohibition be part of the process? If so, who is considered prohibited from starting the sub-discussion?

Checks and balances 2

In point 2 of the proposal, the process only allows the sub-thread that will call for a reconfirmation RfA, to only be opened if the main AN/I thread has sufficient evidence presented that an uninvolved user can reasonably question whether or not the reported administrator is fit to remain an administrator. This is to prevent baseless accusations from turning into a witch hunt against the administrator.

Question: Should this restriction be part of the process? If so, what is considered sufficient evidence?

Checks and balances 3

In point 3 of the proposal, the process requires a certain number of closers of a specific group. The group can consist simply of uninvolved admins, bureaucrats, or a dedicated committee of closers that handle these threads. They are responsible for making sure the discussion is valid and that they have sufficient consensus to initiate a forced reconfirmation RfA.

Question: Who should be allowed to close these discussions, and how many are required to close the discussion to initiate a forced reconfirmation RfA?

Checks and balances 4

In point 4 of the proposal, the process states that only the reported administrator can voluntarily start a reconfirmation RfA. In addition to that any user can initiate a forced reconfirmation RfA, if the AN/I sub-thread calling for the reconfirmation RfA is formally, and correctly, closed in favor of starting one.

Question: This is a straightforward point. Do you agree with this condition of the process? If not, why not and what should be changed?

Checks and balances 5

In point 5 of the proposal, the process requires either the bit to removed at the start of the RfA, or at the end. If at the start, the bit will be returned if the RfA is considered passed. If at the end, the bit will be removed if the RfA is considered failed. This also applies to RfAs initiated voluntarily as a result of the AN/I discussion.

Question: Simple question. Should the bit be removed before or after?

Checks and balances 6

In point 6 of the proposal, the process states that only established users can participate in the discussion calling for reconfirmation RfA, as well as the reconfirmation RfA itself. This prevents trolling accounts and SPA accounts from trying to manipulate the outcome. Optionally, these discussions can have a level of protection applied to it to prevent disqualifying users from participating.

Question: What should be considered an established user? Should the discussion calling for a reconfirmation be on a page that is protected to prevent disqualifying users? Should the reconfirmation have the same level of protection?

Checks and balances 7

In point 7 of the proposal, the process states any admin that has successfully passed a reconfirmation within a 6 month period, cannot be forced to go through another one. Administrators being reported can only have a call for reconfirmation thread opened on them once a month. New reports cannot mention previously mentioned evidence, unless it was seen as problematic in the past, but not enough to question the suitability of an administrator. If there are concerns with the behavior of the administrator and this process was unable to adequetly address the issue, the user is encouraged to file an ArbCom case. This prevents administrators from getting dragged through a never-ending process running in an infinite loop. If this process disallows the reconfirmation from being initiated, then the next step would be to go to the Arbitration Committee.

Question: Do you agree with these limits? If not, what do you want to see to prevent administrators from being subject to never-ending processes?

Rights of the sysop in question

In the above section, there is an outlined proposal of what the reported administrator may be allowed to do during the process. Simply state if you agree or disagree with the respective points in the sections below, with a brief rationale.