User:EVula/opining/RfA overhaul

Source: Wikipedia, the free encyclopedia.

This is an old revision of this page, as edited by EVula (talk | contribs) at 02:00, 3 November 2014 (→‎Possible concerns: MORE ENTHUSIASTIC). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

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

I've recently rewritten this proposal, after it was shot down in its original form.

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 (ArbCom).

The solution

Create a process for de-sysopping (for lack of a better phrase, an RfDA) that is roughly as easy to implement as the process for gaining administratorship.

My 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, they are up for a week of questions from the community with feedback, and then a bureaucrat gauges consensus. Keep it simple.

The process

Using my admin recall criteria as a baseline, the cornerstone to an RfDA request would be three individual examples of admin abuse. Each example must be paired with an attempt at dispute resolution of some sort (such as noticeboard threads, RfCs, or ArbCom cases). In addition to the abuse/DR diffs, the candidate must be informed of the RfDA's existence.

Once the RfDA sub-page is created, it should be posted to WP:BN for a bureaucrat to check to make sure that it is valid:

  • that there are at least three pieces of evidence;
  • that each piece of evidence has a dispute resolution attempt attached to it; and
  • that the candidate has been informed.

Once a bureaucrat has approved the RfDA, they will add it to the main RfDA page.

Once the RfDA is live, it's similar to an RfA: it runs for a week, the general community is able to comment on it, and it is closed by a bureaucrat. There will be no WP:SNOW closures, which in turn means no non-'crat closures.

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.
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 thru live-fire exercises.
EVula, how about you awkwardly segue into mentioning various facts that you're not sure how to work into this page otherwise?
Good idea!
  • I'm imagining the main RfDA page will be fully-protected; this will eliminate any "what if someone sneaks an RfDA in?" ideas, and help reinforce the fact that the process is solely in the hands of bureaucrats. (yes, full protection restricts it to admins, not just 'crats, but there's no protection level for that).
  • Creating the RfDA would, by default, be limited to autoconfirmed users, in that IPs and new accounts can't create sub-pages.
  • Though I'm placing a lot of emphasis on bureaucrats, it's chiefly to help address the concerns of axe-grinding that were brought up the first time I proposed this. I still very much consider this to be the community's process; they will still be tasked with the responsibility to weigh the evidence presented, and to sniff out SPAs that are trying to tank the process (though the 'crats also have a role to play in that).
What is the role of the bureaucrat in the RfDA process?
Bureaucrats make sure that the requirements of the RfDA have been met, not to gauge the validity of the request (there they have some latitude, obviously; someone attempting to have their proposed RfDA go thru with their "dispute resolution" evidence being discussion on an unrelated page with no candidate contact will have their RfDA denied). They will monitor the RfDA in the same fashion that they would monitor an RfA, and will gauge consensus at the RfDA's conclusion. Bureaucrats can also deny RfDA requests that are based on the same evidence as a previous RfDA that resulted in a "keep".
Bureaucrats weren't picked to desysop people.
Correct, but they were picked to gauge consensus. That's why I'm modeling the RfDA process after the RfA process as much possible, to minimize the amount of role-changing for bureaucrats.
People will submit admins over and over!
This is why bureaucrats are tasked to check if an RfDA has the proper prerequisites. Evidence that has already been presented (and considered to be fine) will be thrown out.
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.
This doesn't address the problem of inactive administrators and bureaucrats.
Correct. Though I, personally, feel that inactive editors should have their unused userrights removed, that's 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 inactive userrights, the RfDA process can be adapted at that time.
This doesn't seem to have a statute of limitations. How old could the three incidents/disputes be?
This would be up to the community. If someone's strongest evidence that an administrator needs to have their rights removed is a year old, the community will (justifiably, in my mind) disregard it. Codifying an exact time-frame on evidence may not be a bad idea, but I do want the RfDA system to be open enough that we can remove the genuine bad apples, and showing that an administrator is habitually a problem would naturally mean that some proposed evidence will be older than others.
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.