User:EVula/opining/RfA overhaul

RfA is... not broken, but not well.

I've recently rewritten this proposal from its original form. It was then modified by.

The problem
There are two sides to the problem with the current request for adminship process:


 * 1) RfA is currently seen as a major gauntlet that editors have to run just to help out more. Lots of people fixate on tiny things, and that in turn sinks perfectly good candidates, some of whom can become disenchanted with the project.
 * 2) Adminship is, more or less, for life. That means administrators that aren't the best fit for a collaborative environment can't be taken to task; once the community has approved of someone, it has no venue for removing them. It takes a major screw-up to net a desysopping to be handed down via a lengthy and complicated process involving arbitration.

The solution
Create a process for de-sysopping (for lack of a better phrase, an RfDA) that is roughly similar to the process for gaining adminiship.

The proposal
One of the reasons that this idea (a process for de-sysopping) hasn't gone forward is that, being Wikipedians, we just love to discuss and analyze every damn thing. Page after page after page of discussion and we've gotten nowhere. Why? Because we're overthinking.

Let's implement the de-sysopping process similar to the current RfA system. People propose someone be de-sysopped; if the proposal is deemed valid, the request is up for a week for questions and feedback from the community - and then bureaucrats gauge consensus. Keep it simple.

The process
In summary, the process is initiated once a user prepares a request for de-adminship page, the request is seconded by another editor, and the candidate is notified of the request. The candidate is given one week to make a statement after which the request may submitted for certification. At least 48 hours after being submitted for certification, a bureaucrat will determine if the request has been certified and either close it as not certified or open the discussion for community questions and comment. This discussion lasts at least 7 days, at which point a bureaucrat will open a bureaucrat discussion lasting at least 48 hours in which bureaucrats gauge community consensus. Finally, a bureaucrat will close the bureaucrat discussion and implement the consensus decision.

Prerequisites
The prerequisites to submit an RfDA request for certification are:
 * Examples of recent or ongoing behaviour incompatible with adminship must be supplied.
 * At least two recent or ongoing examples must have resulted in separate attempts of genuine dispute resolution of some sort (including extended community discussions involving the candidate, noticeboard threads, RfCs, or arbitration).
 * A request may be filed for a single incident with dispute resolution if a candidate has exhibited behaviour grossly incompatible with adminship (though in such cases the Arbitration Committee may be better suited to handle).
 * Examples with dispute resolution must not have been examined in a previously certified RfDA; examples used in a previous uncertified RfDA should only be submitted alongside fresh examples including at least one with dispute resolution.
 * At least one other editor must second the request before the request may be submitted for certification, requests not seconded may be deleted.
 * The candidate must be informed on their talk page of the RfDA's existence and be given the opportunity to make a statement and schedule the process; if no statement is made within one week, the request may be submitted for certification.
 * During certification, a candidate may restrict their statement to the subject of certification; however, if the request is certified, they should consider to expanding their statement to address the concerns raised.

Certification
Once the RfDA sub-page is created and a candidate has been given one week to make a statement and arrange scheduling, it may be posted by a bureaucrat for a 48-hour certification period unless it obviously does not meet the prerequisites.

During the certification phase, community members are invited to provide their opinion on whether the prerequisites have been met.

It is important to note that the certification process is , but only if the prerequisites to submit the request have been met. A user may certify the request yet still opine in the later phase to retain the administrator, and indeed if a participant feels strongly that the candidate should remain an administrator they should not oppose certification on these grounds alone - only on the grounds that the request has not met the prerequisites. Comments rejecting certification on these grounds alone may be weighed accordingly by the bureaucrat processing the certification.

Similarly, a participant should not certify a request if they feel the prerequisites have not been made out (even if they feel the candidate should not remain an administrator). The certification process is in place to ensure that requests for de-adminship do not proceed without evidence of recent and ongoing behaviour incompatible with adminship coupled with prior attempts at dispute resolution. As above, comments will be weighed accordingly.

Questions may be raised in the certification discussion but these questions should remain focused on the certification process; if certified, there will be an opportunities for questions of a wider scope.

Once the minimum certification period has elapsed, a bureaucrat will determine if the request has been certified by the community. If the bureaucrat determines the request has been certified, the request moves into the opinion phase; if not, it is closed.

Questions about certification decisions should be raised with the bureaucrat in question first, and bureaucrats noticeboard if necessary.

Opinion period
Once certified, a bureaucrat will open the opinion phase which is similar to an RfA:
 * The discussion runs for at least 7 days (no "snow" or non-bureaucrat closures).
 * Optional questions may be posed to the candidate.
 * The community is invited to opine in support, neutrally, or in opposition to the administrators' continuing adminship.
 * Bureaucrats and uninvolved users are tasked with monitoring the discussion and attempting to maintain decorum.

The 7 day period is merely a minimum; the request remains open for comment until placed on hold by a bureaucrat and may be extended at bureaucrat discretion.

Closure
After at least 7 days have elapsed, a bureaucrat will place the discussion on hold and open a bureaucrat discussion which will remain open for at least 48 hours.

Uninvolved bureaucrats will review the RfDA and provide their comments as to whether community consensus exists to withdraw administrative privileges (not whether they personally feel the candidate should remain an administrator).

After at least 48 hours have elapsed, a bureaucrat will review the bureaucrat discussion to determine consensus among the bureaucrats and implement the decision. If the consensus is not obvious, the discussion should be closed by a bureaucrat who did not participate in the bureaucrat discussion.

Possible concerns

 * People will make bad-faith requests.
 * Abuse and dispute resolution evidence is a prerequisite to prevent idle editors from "striking back" at administrators that have been doing their job. In order to prevent obviously invalid requests and ensure that RfDAs are not made live before the candidate has an opportunity to make a statement, an RfDA can only be posted for certification by a bureaucrat.


 * People will submit admins over and over!
 * This is why bureaucrats are tasked to check if an RfDA has the proper prerequisites before submitting it for certification, including fresh examples if there were any previous requests.


 * What is the role of the bureaucrat in the RfDA process?
 * Bureaucrats make sure that the prerequisites of the RfDA have been met, not to gauge the validity of the request (there will remain discretion, of course: an RfDA submitted for certification with the dispute resolution evidence being discussion on an unrelated page with no candidate contact will not be sent forward).


 * Their role is intended to help deter bad faith requests, though this will very much be the community's process, and the community is tasked with the responsibility of weighing the evidence presented and ensuring that single-purpose accounts or sockpuppets do not disrupt the process.


 * Bureaucrats will monitor the RfDA in the same fashion that they would monitor an RfA, and will gauge consensus at the conclusion of each stage of the RfDA.


 * We don't have a baseline percentage for de-admining!
 * Correct; that's a feature, not a bug. :) Seriously, trying to determine every single variable now, with no actual experience in how it will play out, is an exercise in futility. Just as the RfA process has evolved over time, rather than springing forth fully-formed as the process that we all know and love today, the RfDA process will need to find its bearings. This can only be done by putting the process in the wild. With the closure discussion, multiple bureaucrats will have an opportunity to gauge community consensus before any decision is implemented.


 * Bureaucrats weren't picked to desysop people.
 * Correct, but they were picked to gauge consensus. That's why this process is modeled after RfA process as much possible, to minimize the amount of role-changing for bureaucrats. This is also the reason for the closure discussion, each request will be evaluated by multiple bureaucrats prior to implementing the consensus decision.


 * How is this different from your original proposal?
 * The original proposal was going to be a rather laissez-faire type of process. This is much more regimented, with a fair bit more bureaucracy involved. Xeno, true to his nature, added even more bureaucracy including the certification period cribbed from the now-historical RFC/U and the closure-by-bureaucrat discussion.


 * With the new changes the process is too long!
 * Removing someone's administrator privileges is a bigger deal than granting it and not to be rushed. The time periods involved are also intended to somewhat distance the discussion from the incident that precipitated it, allowing time for the community to absorb and process the events. If an administrator needs to have their rights removed right now, it would be best to contact the Arbitration Committee.


 * This doesn't address the problem of administrators and bureaucrats who do not use their tools.
 * Correct, but that is not the point of this proposal; the point is to make the RfA process less of a "big deal." If the community changes its mind about disused userrights, the RfDA process can be adapted at that time.


 * This doesn't seem to have a statute of limitations. How old could the incidents/disputes be?
 * This would be up to the community, but the prerequisites do require examples that are "recent or ongoing". If someone's strongest evidence that an administrator needs to have their rights removed is years old, the community could reject it during the certification period or a bureaucrat may decline to submit for certification. However, in submitting a request to remove administrative privileges examples may need to show a habitual problems, so putting an arbitrary time limit on all examples isn't indicated.


 * EVula, you're just so smart for coming up with this. And handsome. And awesome.
 * I know. A wonderful concern that you have there, however; thank you. Xeno is pretty cool too.


 * This process may actually have the opposite of the intended effect and deter individuals from running for adminship because they will be reluctant to become susceptible to this process while simultaneously reducing the number of active administrators.


 * What if the entire premise behind this is wrong?
 * If there is little or no connection between removal of bad admins and the inflation of the most easily measured parts of the criteria for adminship, then RFA will continue to deteriorate after a non Arbcom admin recall system is introduced. Though at least then it might be possible to have a discussion on RFA reform that doesn't get topic changed to admin recall.