User:Roux/RFA-reform

The following is a proposed Wikipedia policy, guideline, or process. The proposal may still be in development, under discussion, or in the process of gathering consensus for adoption.

This page in a nutshell: A proposal for a mirror-image of RFA to provide a community-driven method of removing sysop permissions from admins who have abused the tools.

A large number of Wikipedians are in agreement that RFA is broken. What they cannot agree on is how it is broken, or what to do in order to fix it.

That being said, a great number of Wikipedians agree that the community needs some sort of desysopping process that doesn't involve having to go to Arbcom (with its attendant prerequisites) or Jimbo (with the attendant concerns about having a 'constitutional monarch' become directly involved in day-to-day process).

It is probably fair to state that a large number of people who say RFA is broken feel that way due to the possibly unfairly adversarial nature of the process. And it is probably fair to say further that one of the reasons the bar is set so high is the very lack of a robust desysopping process; admins are currently essentially promoted for life, and so a great deal of care must be taken--perhaps too much--when promoting them.

There are many desysop processes that have been proposed. The one below has been largely ~~stolen from~~ inspired by the one at User:MBisanz/Recall.^[1]

This process is intended to fit into the dispute resolution ladder somewhere between getting a third opinion and going to Arbcom. Unlike admins open to recall, Requests for De-Adminship is intended to be a non-optional procedure for all admins.

New RFDA proposal

Who may initiate an RFDA

An RFDA may be initiated by any registered user who:

Is not under editing restrictions imposed by an admin pursuant to arbitration enforcement, Arbcom in a case where the user is named, or the community. Editing restrictions imposed by an admin unrelated to the above reasons do not count.^[2]
Has at least 500 edits^[3]
Has at least three months tenure on enwiki^[3]
Has never been blocked by the admin who is the subject of the RFDA, except where that block was found to be improper or excessive by ArbCom, community discussion at AN or AN/I.^[2]

Users who do not meet the above criteria may ask any uninvolved editor to file a request on their behalf, but are cautioned to avoid canvassing, and ensure that the request is made openly onwiki. Any user that files a case on behalf of someone else must clearly state such in the request. In particularly serious cases, the certifier(s) of the RFDA may ignore any of the above conditions, but are cautioned to be judicious when doing so.

An RFDA may be initiated

Once per incident, with 'incident' broadly defined.^[4]^[5]
Once per editor per year.^[6]
Once per editor per admin.^[7]
Only for actions that involve use of an administrative function (something an auto-confirmed user couldn't do), or abuse of the role of an administrator. There are plenty of noticeboards to handle other actions as well as User Conduct RfCs.

Who may comment on an RFDA

Any user who may initiate an RFDA may comment on one. Users who wish to comment on an RFDA but do not meet the criteria may comment on the talkpage or in the discussion section, but are not permitted numbered !votes.^[8]

Grounds for initiating an RFDA

RFDA may only be used after other avenues of dispute resolution have been pursued. At minimum, an attempt at either formal or informal mediation, an RFC/U, community discussion on AN or AN/I, or an Admin Review^[9] must have been attempted without any resolution of the abusive behaviour. Or in a nutshell: try other dispute resolution processes first, and use this only if the abuse has not been resolved. Truly egregious cases and emergency desysoppings are handled by Stewards and/or ArbCom as part of their regular duties.

Events at issue must be reasonably current and either egregious or part of a repeated pattern of abuse. Resurrecting stale cases is not acceptable and it is essential to assume good faith and allow for the possibility of honest mistakes.

An admin must have abused one or more of the following admin abilities in order for an RFDA to be filed. If there has previously been a community discussion on this issue at AN or AN/I where the consensus was that no abuse occurred, the person initiating the RFDA is encouraged to re-visit that consensus and examine whether another form of dispute resolution would be a better way to address the issue.

Procedure

A user who wishes to initiate an RFDA will create a subpage (location to be determined, using a template same as RFA does), add a short summary of what they are basing the RFDA request on (must be less than 1,000 words and 100 diffs), and place an "X" in the check boxes of the administrative power(s) abused; the statement of the request must explain how each administrative tool was abused.
They must notify the admin of the initiation of the RFDA. (The order of steps 1 and 2 may be reversed at filer's discretion).
They must then place a notice on the talkpage of WP:RFDA, indicating that they have started an RFDA
The RFDA must be:
a) certified by any two administrators,^[11] using normal Wikipedia guidelines on being uninvolved when making admin-related decisions. This is to prevent frivolous complaints. If the RFDA is not certified within one week, it is closed and courtesy-blanked with no further action required. Uncertified RFDA requests, if the user feels there is a valid case, should be brought to ArbCom via RFAR. Note that the certifiers do not need to agree that the admin should be desysopped; they are only required to double-check that the request has prima facie grounds and that the filer has followed necessary prerequisite steps.

b) or, if the AdminReview process is adopted by the community, a finding of admin abuse there allows the initiator of the RFDA to bypass the need for certification.
Upon certification, the subject of the RFDA will be given 72 hours to include a statement/rebuttal before the RFDA is transcluded to WP:RFDA. If they do not respond but have edited in that time period, the RFDA will be transcluded anyway. If they have not edited or made any admin actions in that time, the RFDA will remain on hold until a reasonable time after they next edit.
The RFDA will remain open for seven days, same as an RFA.
After seven days, the RFDA will be closed by a bureaucrat, same as RFA, using the same general principles as the pass/discretionary/fail percentages^[12] in use at RFA.^[13]^[14]

Outcome

If an RFDA is closed with a clear consensus for desysopping, the closing bureaucrat will direct a steward to remove the sysop rights from the subject. An RFDA that closes with a desysopping confers no prejudice to the subject standing for a full RFA at any time, at their own judgement and discretion. As with community bans, decisions may be appealed to the Arbitration Committee.

Notes

^ as of this edit.
^ ^a ^b Avoiding grudges and axe-grinding
^ ^a ^b Avoiding SPAs and socks
^ This is to prevent multiple attempts to desysop a given admin over a single incident/issue.
^ For example, a series of sockpuppet blocks are one incident rather than 10 separate (ab)uses of sysop tools
^ That means a given user may only initiate an RFDA against a specific admin once per year. Abusive initiation of multiple RFDAs can be handled easily by normal DR process.
^ This means that a given user may only call for a given admin's desysop once.
^ Same principle as IPs in RFA discussions.
^ If the AdminReview process is implemented
^ Regular users who abuse rollback may have the flag removed. This is not possible with admins except via desysop.
^ Non-admin members of any of the following groups can also certify: Arbitration committee members, Arbitration clerks, Mediation Committee members, and Bureaucrats
^ e.g. 80+% support required to desysop, 70-80% support discretionary range, under 70% support means no desysop, though the exact numbers are up for debate
^ Or perhaps RfB, which is slightly more stringent
^ A 'no consensus' should probably result in the admin retaining privileges

[1] s of this edit.

[grudge-2] Avoiding grudges and axe-grinding

[SPA-3] Avoiding SPAs and socks

[4] This is to prevent multiple attempts to desysop a given admin over a single incident/issue.

[5] For example, a series of sockpuppet blocks are one incident rather than 10 separate (ab)uses of sysop tools

[6] That means a given user may only initiate an RFDA against a specific admin once per year. Abusive initiation of multiple RFDAs can be handled easily by normal DR process.

[7] This means that a given user may only call for a given admin's desysop once.

[8] Same principle as IPs in RFA discussions.

[9] If the AdminReview process is implemented

[10] Regular users who abuse rollback may have the flag removed. This is not possible with admins except via desysop.

[11] Non-admin members of any of the following groups can also certify: Arbitration committee members, Arbitration clerks, Mediation Committee members, and Bureaucrats

[12] .g. 80+% support required to desysop, 70-80% support discretionary range, under 70% support means no desysop, though the exact numbers are up for debate

[13] Or perhaps RfB, which is slightly more stringent

[14] A 'no consensus' should probably result in the admin retaining privileges

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]