From Wikipedia, the free encyclopedia

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

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

  • Carefully consider whether the conduct you plan to report is actually so contrary to Wikipedia's goals and policies that such a drastic action is needed. Consider other forms of dispute resolution.
  • Before reporting here a good faith effort must be made to resolve the issue with the administrator involved. Any case presented without evidence of previous attempts at resolution by users in good standing [1] will be speedily rejected.
  • Reports must include clear evidence, preferably in the form of diffs, that the administrator in question has used either their administrator tools or status in a way not consistent with the reason they were granted the tools, or is otherwise acting in a way not consistent with what is expected of an administrator.
  • Processes like this one usually result in intense scrutiny of all involved parties. The bright light you are about to shine on a particular administrator will reflect on you as well. If you are a new or inexperienced user it is likely your report will be viewed with suspicion and you may become the subject of a sockpuppet investigation.
  • In all but the most extreme cases, there should be a demonstrable pattern of repeated unacceptable behaviors, not just a single incident.
  • Generally, very new administrators or administrators who have recently (i.e. within the last 3-6 months) had a report on them closed should not be reported.

Possible reasons for reporting here

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

  • Refusal to engage in direct (non-template) communication with other users, especially those affected by their administrative actions
  • Speedy deleting articles which do not clearly qualify for speedy deletion
  • Issuing blocks which are not consistent with the blocking policy
  • Threatening non-admin users, using the power of their administrative rights as weapons instead of tools (note that this does not include warning and/or blocking actual vandals and other disruptive users)
  • Using the implied authority of their position to lend status or credibility to users abusing multiple accounts
  • Long term incivility towards other users

What not to report here

Process

Reporting

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

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

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

Footnotes

  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

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

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

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. Ϣere SpielChequers 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

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. Ϣere SpielChequers 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

"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. Ϣere SpielChequers 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

  • Currently, it says that anyone may initiate, subject to two other editors in good standing certifying it. After comparing the other proposals being discussed, I'd like to suggest that this part of the process be tightened up a bit, to make it harder for cranks or payback-seekers to start it, while still leaving it in the hands of the community. I would suggest that a good way to accomplish that would be to incorporate the part of the proposal by Roux, spelling out more specifically a certain number of edits and the absence of related sanctions, etc., to apply to the two editors who certify the complaint. That way, anyone can still start a complaint, but there are greater safeguards in place before it goes forward.
  • Related to that, several of the other proposals being discussed allow ArbCom to refer admins into a process such as this. I think that can be a useful feature, in that it gives ArbCom the option of letting the community decide whether to desysop. I'm not suggesting that instead of what's here, but rather, I think that stating explicitly that ArbCom can start a case (without the need to certify) as a second, alternative, way to initiate, would be an improvement. -- Tryptofish ( talk) 18:11, 3 November 2009 (UTC) reply

Closing percentage

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

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

From Wikipedia, the free encyclopedia

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

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

  • Carefully consider whether the conduct you plan to report is actually so contrary to Wikipedia's goals and policies that such a drastic action is needed. Consider other forms of dispute resolution.
  • Before reporting here a good faith effort must be made to resolve the issue with the administrator involved. Any case presented without evidence of previous attempts at resolution by users in good standing [1] will be speedily rejected.
  • Reports must include clear evidence, preferably in the form of diffs, that the administrator in question has used either their administrator tools or status in a way not consistent with the reason they were granted the tools, or is otherwise acting in a way not consistent with what is expected of an administrator.
  • Processes like this one usually result in intense scrutiny of all involved parties. The bright light you are about to shine on a particular administrator will reflect on you as well. If you are a new or inexperienced user it is likely your report will be viewed with suspicion and you may become the subject of a sockpuppet investigation.
  • In all but the most extreme cases, there should be a demonstrable pattern of repeated unacceptable behaviors, not just a single incident.
  • Generally, very new administrators or administrators who have recently (i.e. within the last 3-6 months) had a report on them closed should not be reported.

Possible reasons for reporting here

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

  • Refusal to engage in direct (non-template) communication with other users, especially those affected by their administrative actions
  • Speedy deleting articles which do not clearly qualify for speedy deletion
  • Issuing blocks which are not consistent with the blocking policy
  • Threatening non-admin users, using the power of their administrative rights as weapons instead of tools (note that this does not include warning and/or blocking actual vandals and other disruptive users)
  • Using the implied authority of their position to lend status or credibility to users abusing multiple accounts
  • Long term incivility towards other users

What not to report here

Process

Reporting

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

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

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

Footnotes

  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

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

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

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. Ϣere SpielChequers 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

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. Ϣere SpielChequers 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

"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. Ϣere SpielChequers 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

  • Currently, it says that anyone may initiate, subject to two other editors in good standing certifying it. After comparing the other proposals being discussed, I'd like to suggest that this part of the process be tightened up a bit, to make it harder for cranks or payback-seekers to start it, while still leaving it in the hands of the community. I would suggest that a good way to accomplish that would be to incorporate the part of the proposal by Roux, spelling out more specifically a certain number of edits and the absence of related sanctions, etc., to apply to the two editors who certify the complaint. That way, anyone can still start a complaint, but there are greater safeguards in place before it goes forward.
  • Related to that, several of the other proposals being discussed allow ArbCom to refer admins into a process such as this. I think that can be a useful feature, in that it gives ArbCom the option of letting the community decide whether to desysop. I'm not suggesting that instead of what's here, but rather, I think that stating explicitly that ArbCom can start a case (without the need to certify) as a second, alternative, way to initiate, would be an improvement. -- Tryptofish ( talk) 18:11, 3 November 2009 (UTC) reply

Closing percentage

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

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


Videos

Youtube | Vimeo | Bing

Websites

Google | Yahoo | Bing

Encyclopedia

Google | Yahoo | Bing

Facebook