Administrator Request for Comment is a process by which the community can discuss whether a particular Wikipedia administrator has lost the trust of the Wikipedia community and should have their administrator status revoked. Unlike other request for comment proceedings, an Admin RFC can result in sanctions or the removal of user rights if that is the consensus reached in the discussion.

Purpose

[edit]

The purpose of this process is to re-evaluate administrators that may no longer be serving the Wikipedia community in a manner consistent with what is expected of an administrator. It is not a forum for overturning specific deletions, blocks, or bans, but rather for examining a particular administrator's actions as a whole in order to determine whether they should continue serving as an administrator. If an administrator has simply made a mistake or two and has shown that they understand that they have made an error and do not intend to repeat it, they do not need to be reported here. There are no firm guidelines as to what exactly can lead to administrator status being removed, in the same way that there is no explicit standard for having it granted in the first place.

Before reporting cases

[edit]

Possible reasons for reporting here

[edit]

This is not a complete list, it is intended to provide examples of behaviors that may be considered valid grounds for reporting here

What not to report here

[edit]

Process

[edit]

Reporting

[edit]

Any user in good standing may initiate a report on an administrator by creating a subpage of the main admin RFC page with the following format: [[Administrator requests for comment/(admin name here, followed by number if there are multiple cases)]]. This does not mean that any report made will be accepted and investigated. Reporting users are expected to demonstrate that there has been an ongoing problem with the subject of the report, that there have been previous attempts to resolve said problem or problems, and that those efforts have failed. The admin in question must be informed immediately that they are the subject of a report in order to give them a chance to respond. After posting a case, it must be certified by at least two other users in good standing who were not previously directly involved in the matter and have thoroughly reviewed the report to insure it meets the minimum standards for further discussion. Any other involved users may also add their names and/or endorsements to the original posting during this period. Any report not certified within 48 hours of being posted may be removed. Reports found to be without any merit whatsoever will be deleted. Reports that do not meet the criteria in other ways will be archived, and may be deleted in the future if the case does not move forward, warranting a full RFC. The administrator may be asked not to use their "tools" during the RFC period, especially in the disputed areas, but this is not binding. Administrators should not remove or delete reports on themselves under any circumstances.

Discussion

[edit]

Immediately following certification of the report there will be a 24 hour "grace period" in which the administrator in question may resign their admin rights voluntarily without further comment or discussion. This period may be extended in some cases, and can be waived by the reported admin. A comment period follows the grace period, in which users may ask questions both of the administrator in question and the reporting user or any other involved parties. Although similar to a "reverse request for adminship", it should be stressed that this is meant to be first and foremost a discussion as opposed to a vote. Users may make bolded "!votes" of the kind seen at RFA, but there is no "default position" not requiring a rationale . Any simple votes without clear rationales attached will not be considered. Some administrators may choose not to participate in the process, this should not be seen as a valid reason to discontinue the process and pursue other venues as the decision reached through this process is binding regardless of the subject's participation or lack thereof.

Closing

[edit]

Most cases should run for the same standard seven day period as a Request for Adminship. Some discussions may be closed sooner if there is a rapid and clear consensus that the admin should be retained, similar to a reverse WP:NOTNOW closure at RFA. The period may be extended if new information comes to light towards the end of the week, or if more input is needed to determine what action or lack thereof should be taken. Any previously uninvolved user may close the case if there is a clear consensus. As gaining the tools requires a supermajority of 70-80% support, removal of those tools likewise requires a similar level of support. In the event of borderline cases in the 65-75% zone, it is appropriate for several previously uninvolved users to discuss the close on a separate subpage created specifically for that discussion before making a decision. It is only appropriate for an involved user to close a case if the case is withdrawn by those who presented it before significant debate has taken place, or if the administrator in question voluntarily gives up their administrator tools. If there is a clear consensus to remove admin status, a bureaucrat will be called upon to remove the user's sysop rights. In cases where consensus cannot be found, the administrator will not have their status revoked

Current cases under consideration

[edit]

Footnotes

[edit]
  1. ^ For purposes of this page, a "user in good standing" is any user with autoconfirmed or better user rights, with a clean recent block log.

Discussion of this draft page

[edit]

As this is only a draft, and already a talk page, use this section for discussion Beeblebrox (talk) 05:38, 25 October 2009 (UTC)[reply]

who closes it

[edit]

One of the first objections I got was to the idea that an uninvolved admin should do the close. When I thought about it, this seemed a valid objection since other RFC processes can be closed by anyone. Now others are objecting because the current version says any uninvolved user may do the close. This change was made in order to avoid the appearance of admins closing these discussions simply to "save" another admin. Any close that did not reflect the consensus of the discussion would doubtless be overturned, and I have specified that there should be a closing discussion with several users in marginal cases. Closers can be admins but don't have to be. Really, closing most RFAs doesn't actually require a crat or even an admin if there is a clear consensus, the crats are just needed for the technical task of granting the sysop rights. Beeblebrox (talk) 18:53, 25 October 2009 (UTC)[reply]

Perhaps it would be better, in light of this issue, to say explicitly that the crat who comes at the end of a decision to desysop is also responsible for reviewing the closure decision and making sure that the decision was made properly. --Tryptofish (talk) 17:52, 3 November 2009 (UTC)[reply]

Early closure

[edit]

As currently written this would allow a desysop to be opened at a quiet time - say when America was sleeping. Get a flurry of !votes and then a swift non-admin closure before many noncanvassed editors get a chance to !vote. A fixed 7 days would prevent this, plus a little clarification to the effect that "after 7 days any editor can close a >75% !vote as consensus for desysop or <65%as no consensus. But I would be more comfortable with crat closures, especially where other options are being considered. ϢereSpielChequers 00:55, 26 October 2009 (UTC)[reply]

I deliberately made it so that anyone could close to try and avoid the impression that this would be like ArbCom or ANI, as there seem to be a lot of users who feel that the rank and file is underrepresented in such processes. You have a point about the timing thing, I suppose I hoped that such obviously bad closures would simply be overturned by the next user to come along. I was thinking more of a reverse "not now" where it could become abundantly clear very quickly that the admin was not going to be removed. I'll see if I can't tweak that section to reflect the intent more clearly. Beeblebrox (talk) 01:43, 27 October 2009 (UTC)[reply]
I think that section better reflects my original intentions now. Beeblebrox (talk) 02:02, 27 October 2009 (UTC)[reply]
I agree that it is better. It seems to me that early closure only applies to cases where there is a decision to keep the sysop tools; in other words, there should never be an early closure to desysop unless the admin resigns voluntarily. Maybe that could be made clearer? Actually, it does say that already. Looking again, I guess the issue is really that a "bad" admin could canvass some friends to close the process early as a keep, against the wishes of the community. About "such obviously bad closures would simply be overturned by the next user to come along", maybe that needs to be spelled out, but in a way that does not, in effect, allow a troll to keep it open. --Tryptofish (talk) 17:55, 3 November 2009 (UTC)[reply]

Sanctions or desysop

[edit]

I would be much more comfortable with this if it followed the lead "an Admin RFC can result in sanctions or the removal of user rights"(my emphasis) as opposed to the closure section which has a straight choice between desysop or not. Much of life is grey, wikilife even more so, and whilst it may be clear to those filing one of these that the admin in question should be desysopped, the consensus may be for a lesser sanction. ϢereSpielChequers 00:55, 26 October 2009 (UTC)[reply]

My feeling was that there are already myriad places to report other problems, this process wold be specifically for making that one determination, and only after other efforts at resolving the issue had failed. Beeblebrox (talk) 01:56, 27 October 2009 (UTC)[reply]

Wikibreaks

[edit]

"Refusal to engage in direct (non-template) communication with other users, especially those affected by their administrative actions" needs a slight clarification to the effect that it only applies to active admins - an admin on a 6 month wikibreak might well have ignored five monthly reminders on their talkpage. ϢereSpielChequers 00:55, 26 October 2009 (UTC)[reply]

In the "purpose" section of the page it explicitly states that inactive admins should not be reported.I moved it to the "what not to report" section to make it more obvious. Beeblebrox (talk) 01:52, 27 October 2009 (UTC)[reply]

Who may initiate the process

[edit]

Closing percentage

[edit]

Here's what I admit is a headache of a question. The current version says that an RfA-like supermajority !vote is needed to desysop. Some other proposals being considered set the percent much lower than 70%-ish. They may be right. I can easily imagine a problem admin who has enough friends to generate about 20-30% of the !vote, even in the face of clear community consensus to the contrary. I could actually make a case that if one needs a supermajority to pass RfA, then one should likewise need a supermajority to retain the tools! Of course, the other side of the coin is that we don't want a small number of persons with grudges to oust a good admin. Would a simple 50%+1 majority be better? In other words, something like 60% or more !voting for desysop results in desysop, 50% or fewer results in keeping the tools, and between 50% and 60% results in a close case requiring a discussion page. --Tryptofish (talk) 18:22, 3 November 2009 (UTC)[reply]

Anyone can edit this

[edit]

Although what you see above is so far my sole creation, I put this in the WikiProject's talk space because I had intended for this to be a group effort, it just didn't quite pan out that way. Anyone who feels they have found a flaw to correct or a chance to improve the proposal is welcome and encouraged to do so. Please note any major changes here. Thanks Beeblebrox (talk) 05:52, 28 October 2009 (UTC)[reply]