User:EVula/opining/RfA overhaul: Difference between revisions

Source: Wikipedia, the free encyclopedia.
Content deleted Content added
EVula (talk | contribs)
m →‎Possible concerns: MORE ENTHUSIASTIC
re-write; feel free to modify or revert; added: certification period, bureaucrat closure discussion, re-wrote q&a to suit
Line 3: Line 3:
[[WP:RfA|RfA]] is... not broken, but not well.
[[WP:RfA|RfA]] is... not broken, but not well.


I've recently rewritten this proposal, after it was shot down in its <span class="plainlinks">[http://en.wikipedia.org/w/index.php?title=User:EVula/opining/RfA_overhaul&oldid=264688991 original form]</span>.
I've recently rewritten this proposal from its <span class="plainlinks">[http://en.wikipedia.org/w/index.php?title=User:EVula/opining/RfA_overhaul&oldid=264688991 original form]</span>. It was then modified by {{u|Xeno}}.


==The problem==
==The problem==
Line 9: Line 9:


# 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.
# 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.
# 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).
# 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==
==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.
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==
==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.
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.
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===
===The process===
In summary, the process is initiated once a user prepares a request for de-adminship page and notifies the candidate. The candidate is given 24 hours 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 [[Wikipedia:bureaucrat discussion|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.
Using [[User:EVula/opining/admin recall|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.


====Prerequisites====
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:
The prerequisites to submit an RfDA request for certification are:
* that there are at least three pieces of evidence;
* Examples of recent or ongoing behaviour incompatible with adminship must be supplied.
* that each piece of evidence has a dispute resolution attempt attached to it; and
* At least two examples must have resulted in separate attempts of genuine dispute resolution of some sort (including extended discussions involving the candidate, noticeboard threads, RfCs, or arbitration).
* that the candidate has been informed.
* 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.
* The candidate must be informed on their talk page of the RfDA's existence and be given the opportunity to make a statement; if no statement is made within 24 hours 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 a bureaucrat has approved the RfDA, they will add it to the main RfDA page.
Once the RfDA sub-page is created and a candidate has been given 24 hours to make a statement, 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.
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.

It is important to note that '''the certification process is {{red|not about whether the candidate should remain an administrator}}''', 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.

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 [[wikipedia:bureaucrats noticeboard|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==
==Possible concerns==
;People will make bad-faith requests.
;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.
: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!
;We don't have a baseline percentage for de-admining!
: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.
: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 <s>and love</s> 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?
;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 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 submtited 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 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.


: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.
;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.
;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 <s>and love</s> 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?
;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.
: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 inactive administrators and bureaucrats.
;This doesn't address the problem of administrators and bureaucrats who do not use their tools.
: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.
: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 three incidents/disputes be?
;This doesn't seem to have a statute of limitations. How old could the 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.
:This would be up to the community. 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. However, in submitting a request to remove administrative privileges examples may need to show a habitual problems, so putting an arbitrary time limit on examples isn't indicated.


;EVula, you're just so smart for coming up with this. And handsome. And awesome.
;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.
:I know. A wonderful concern that you have there, however; thank you. Xeno is pretty cool too.

Revision as of 16:46, 1 July 2015

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

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

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 as easy to implement as the process for gaining administratorship.

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 and notifies the candidate. The candidate is given 24 hours 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 examples must have resulted in separate attempts of genuine dispute resolution of some sort (including extended 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.
  • The candidate must be informed on their talk page of the RfDA's existence and be given the opportunity to make a statement; if no statement is made within 24 hours 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 24 hours to make a statement, 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 not about whether the candidate should remain an administrator, 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.

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 submtited 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. 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. However, in submitting a request to remove administrative privileges examples may need to show a habitual problems, so putting an arbitrary time limit on 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.