Wikipedia talk:Arbitration Committee/Removal of advanced permissions (proposed)

Emergency Steward Desysop

Resolved

One major flaw that I see in this proposal is overbureacracy. I remember stewards being able to enact some judgment (scandalous) in desysopping users who deleted the main page and then started blocking Jimbo and the Cabal members, for example. The way I read this, with this new policy, stewards would have to wait for three arbitrators to decide that the account has been desysopped, something that the hundreds of users who happen to be online would notice and be able to report to the Stewards IRC channel or Meta Permissions Page far more quickly than three different members of the ArbCom would. NuclearWarfare _(Talk) 04:29, 14 February 2009 (UTC)

I believe a steward always has the ability to within their discretion without ArbCom's permission or even notification, but arbcom will undergo the listed proccess before directing a steward to act - I could be wrong though--Tznkai (talk) 04:33, 14 February 2009 (UTC)

Yes, the procedures here are for the Committee, not for the stewards (who have their own). Kirill ^[pf] 04:38, 14 February 2009 (UTC)

Well, if I could only think... NuclearWarfare _(Talk) 04:41, 14 February 2009 (UTC)

Temporary removal

I feel that this section isn't well defined. What exactly separates temporary removals from emergency removals? What is a satisfactory explanation - what if the committee isn't satisfied, do they vote again - do they file their own case and pursue permanent removal as described - and who determines the times scale under: "The Committee will then consider the appropriate course of action and set a time-scale for further discussion" Are you going to have a vote to determine how long you until the next vote? By "inconsistent with the level of trust required" do we mean "likely to abuse for personal gain" or "conduct unbecoming community norms for administrators?"

Some fleshing out could be done here.--Tznkai (talk) 04:30, 14 February 2009 (UTC)

Re: Permanent removal

As a result of an investigation carried out off-wiki for security/privacy reasons, in which case the removal will follow a procedure similar to that for temporary removal. The bolded portion is simply not good enough. Similar can mean "procedures at least as stringent as temp sysop"; "procedures containing all the elements of temp sysop but in not necessarily in the same order"; "procedures based on temp sysop but the committee votes on a case by case basis which steps can be left out and/or left out of the public record"; "procedures based on temp sysop but the committee member taking lead on the case can decide which steps to leave out and/or leave out of the public record"; etc. (I can get more creative if anyone doesn't find a reading of "similar" they dislike on the short list) --BirgitteSB 04:44, 14 February 2009 (UTC)

The wording does need to be improved there, as the temp process outlined will not always be suitable based on what I have seen of the previous private cases, which have varied greatly. Rather than flesh out how private cases will be conducted, which will import a lot of other issues, I think that this proposal should focus on the decision making and notification aspects, and the fourth step of the temp process looks like it will work. Private cases do need more controls than normal cases, however developing those now will consume a lot of time. An RFC on private cases would be a good idea. John Vandenberg ^(chat) 14:34, 14 February 2009 (UTC)

I understand the answer is not an easy one, but I can't pretend that what is given here is an acceptable answer. You would be better off putting a placeholder there like "As a result of an investigation carried out off-wiki for security/privacy reasons, in which case the removal will follow a procedures outlined for private cases." And dealing with what the private case procedures are later.--BirgitteSB 15:17, 14 February 2009 (UTC)

Defining the procedure for private cases at a later time would be good. Would it help if we put "private case procedure" on our next published agenda? The last agenda was published Jan 20, and the "acceptance of private evidence" on that agenda is referring to private evidence as part of normal cases.

I am not sure when we would be able to focus on the procedure for private cases, so I would like to see some basic procedures in place for them. So far we have been using a procedure which is essentially the fourth point of the temporary procedure, which includes two expectations which the community should be able to take for granted:

1. Removal of permissions may take place once a motion to do so has been endorsed by a majority of active arbitrators.
2. A notice will be posted to WP:AC/N, WP:AN, and the user's talk page, including a brief explanation of the reason for removal, and the names of the arbitrators who have authorized the removal.

We should also attempt to contact the person before their permissions are removed, and ensure that they have an opportunity to respond to the concerns. The wording of that should be easy to obtain agreement on.

Are there other fundamentals we may be able to quickly lock in place now? John Vandenberg ^(chat) 22:47, 16 February 2009 (UTC)

Those are the main points. The main angle that concerns me is that a person is given notification and time to respond before a motion goes forward for permanent removal. Given that there are procedures for temporary removals when it is needed there should be something that discourages arbitrators from proceeding to vote to permanently remove permissions from a person before they are given a chance to respond to the issue. A little tangent on private cases. The problem with private cases is two-fold, the tendency towards confirmation bias and inability to refute conspiracy theories. The former is about the insiders reaching the correct decision; the latter is about the perception outsiders have about the decision. The worst case scenario of a private case is that confirmation bias leads to error that is later exposed and conventional wisdom decides the error is due to a conspiracy which arbcom can't convincingly refute because the proceedings need to remain private. But even absent any errors in the decision, following a slower and more careful procedure will work to counter any arguments asserting a conspiracy. Some goals you might want aim for in setting private procedures are to make it difficult to reach a rushed decision, to make it difficult to reach a decision without hearing from all sides, and to standardize feedback so as to make everyone feel that they were listened too. Those things need not, and problably should not, be dealt with explicitly in this proposal. It would be fine to just list the two points you set out here as they are the only points really specific to permissions removal. However if any case does go forward, before private procedures are fleshed out, where the attempt to contact the person was not given a reasonable amount of time before arbs began making up their minds, then I feel you all would be exposing yourselves to a greater risk of censure than is absolutely necessary or wise for that matter. I would like to see private case procedures on the agenda, but it would only be helpful to put it there if arbcom is really ready to tackle it.--BirgitteSB 00:24, 17 February 2009 (UTC)

Why is this necessary?

I mean, have we really had a problem with emergency removal before? Every time it happens its generally handled well and handled quickly, not that it comes up very often. Having a whole policy for it, especially such a bureaucratic one, seems rather excessive. Mr.Z-man 04:53, 14 February 2009 (UTC)

It seems likely to me that a) the committee realizes it has very little or no space left anymore to do something surprising and have the community support them on faith b) the committee has a history of badly predicting what the community will find surprising c) bureaucracy is surefire way to make certain a process does not surprise anyone. (Bureaucracy still doesn't help with people being surprised by results)--BirgitteSB 05:06, 14 February 2009 (UTC)

To an extent; but keep in mind that this is intended primarily as a procedure that arbitrators must follow. We've had a number of situations in the past where emergency action by some subset of the Committee has led to misunderstandings and disputes over authorization and such; the idea is to prevent that by having a formal rule authorizing such action under certain specific circumstances. Kirill ^[pf] 05:11, 14 February 2009 (UTC)

Do internal bylaws of the committee require community approval? — Carl (CBM · talk) 05:16, 14 February 2009 (UTC)

I don't believe they have, traditionally; that doesn't mean we aren't interested in feedback, however. Kirill ^[pf] 05:17, 14 February 2009 (UTC)

The community continues to surprise the committee with new and different "emergencies", which may not even be visible to the community at the time so it is beside the point to say "a steward will do it". This proposal defines emergencies broadly, preventing the committee from overreaching without realising it. Where there is agreement that a situation is an emergency, a process like this allows the committee to know the drill in advance and execute it quickly. It may take a little longer to follow a process, but it will require less thrashing under the water line to achieve the same graceful movement. The proposed process also records what needs to be done after a decision has been made, which includes informing the community of the reason and which arbitrators signed off on it being an emergency. John Vandenberg ^(chat) 12:21, 14 February 2009 (UTC)

That is very reasonable explanation of the motivation behind the emergency desysoping section. I do agree it would be good for the committee to have an agreement internally about what to do in such cases. I'm going to change my feedback on the other side of this page somewhat. — Carl (CBM · talk) 14:57, 14 February 2009 (UTC)

Frankly I am not sure the committee will be doing themselves any favors with this proposal and my speculation that more in the same vein are forthcoming. The mixture of detail versus ambiguity is really problematic, because you are leaving too many of the principles behind what you trying achieve unspoken while giving a step-by-step of mundane actions. Whatever the next thing is to be released on you schedule is try to have twice as much detail of the principles and half as much detail on the steps taken. It is preferable to leave flexibility for carrying out set in stone principles rather than a set in stone process for enacting flexible principles.--BirgitteSB 16:21, 14 February 2009 (UTC)

This is intended to be only one step forward. It would be nice to have a lot of principles fleshed out, but this is a vague framework. It defines key terms (emergency, temporary, permanent), describes the rough process and .. yes ... includes many mundane details because those are easy to lock in place quickly. A significant percentage of our email traffic is inefficient decision making, and quite often there is a concurrent meta discussion about the decision making process required for each situation. And then there is the possibility that an individual arb or Jimbo trumps the ongoing discussions. And finally we have a post-mortem discussion on how it was all handled.

The default arbcom response should be "there is no emergency; arbcom action is not needed at this stage", but we are expected to evaluate the issues sent to us, so each "inaction" requires varying amounts of discussion. This proposal would lock in place how we will deal with one type of reoccurring situation, and do so publicly so that the community knows what level of committee support will be obtained before anyones permissions are removed courtesy of the Arbitration Committee. John Vandenberg ^(chat) 21:29, 15 February 2009 (UTC)

Emergency removal endorse/rescind

The full Committee will review, as expeditiously as is practical, all emergency removals of permissions and either endorse or rescind the action. This should needs better wording. "Endorse emergency removal" and "rescind emergency removal" should not be presented as mutually exclusive items. Or you mean something else here, "endorsing emergency removal" is not clearly equivalent to "permanent removal".--BirgitteSB 04:56, 14 February 2009 (UTC)

I'm not following you. When the full committee endorses the emergency removal, those tools would be permanently removed until the action is appealed. i.e. the full committee is expected to quickly verify that the situation is an emergency, as opposed to evaluating the body of evidence which may or may not expand while the full committee is coming online. Would it help to use "uphold or rescind the action" instead? It is quite possible that an arbitration request happens concurrently, and a case is opened soon afterwards. The committee needs to be able to quickly determine whether the emergency desysop was warranted without deciding the outcome of the arbitration request and/or case. John Vandenberg ^(chat) 13:23, 14 February 2009 (UTC)

Uphold/Rescind is better. The problem I see, is that the action of emergency removal could be endorsed by the full committee while at the same time once the emergency is passed there may not be agreement on permanent removal. Or in other words, the committee may not always wish for restoring the access to be seen as a censure of the emergency action. Endorse/Rescind implies Censure/Approve. Choosing not to rescind is approval; choosing not to endorse is censure. Do you follow that better?--BirgitteSB 15:32, 14 February 2009 (UTC)

Yes, I follow. Is "Uphold/Rescind" good enough? If so, please make the change, or I can.

It is also possible that if the emergency evaporates before the full committee has come online, the original three arbs and others feel comfortable overturning the removal sooner, but I dont think it is necessary for this proposal to cover every situation. John Vandenberg ^(chat) 20:01, 15 February 2009 (UTC)

I made the change. I agree it shouldn't be overly detailed.--BirgitteSB 20:42, 15 February 2009 (UTC)

Comment

To be perfectly honest, and with respect to the ArbCom, I'm not sure where I stand on this proposal. Were there a "broadly neutral" section, that's where I would be at the moment. At this point, I think we need to have some sort of directory on what we should do for emergency situations. I have no reason to believe that the Arbitration Committee's involvement in such a situation would make things worse, as I trust pretty much every single one of its members (no exceptions). The "official" status of the arbitration committee could ideally serve as a voice of guidance in such circumstances. However, the position of ArbCom in this sort of thing is a double-edged blade. While I trust the ArbCom and believe we need some sort of official dispute resolution reinforcement power, we also need to continue to support the community as a source of dispute resolution, before the ArbCom. One of the key issues we face with the committee is that it has a reputation for acting as too much of a political force in Wikipedia - if this proposal were to pass, it would only empower this notion, which would be detrimental to the encyclopedia. Also, if that were the official way for involuntarily desysopping rogue admins, it could take way too long and would be far too cumbersome a process to rely on.

I feel that, while I have no qualms whatsoever about the Arbitration Committee being entrusted with the power to desysop administrators, I do not want the ArbCom to be the only process in doing so. I believe the best way to deal with emergency situations is simply for anybody to contact a stewart to remove the user's advanced access level - possibly having the ArbCom simply confirm it subsequently.

Thoughts? Master&Expert (Talk) 05:01, 14 February 2009 (UTC)

The process for obvious abuse in an emergency should be something like this:

1. Someone goes to #wikimedia-stewards, types !steward, explains problem
2. Steward desysops user
3. User is blocked locally
4. Thread started on WP:AN or WP:ANI
5. ArbCom votes and decides to make the desysop officially permanent
6. ????
7. Profit!

Which, coincidentally, is how it generally works now without an official policy defining it. Mr.Z-man 05:07, 14 February 2009 (UTC)

Indeed. I don't see much need for change - though I don't mind ArbCom being involved in the desysop of a rogue administrator (in fact they should be involved in community affairs), I just don't want a cumbersome process for getting things like this done. Master&Expert (Talk) 05:10, 14 February 2009 (UTC)

I agree if a steward, without backup authority from arbcom, can't see it is clear emergency for desysoping it should be treated as a temp desysop.--BirgitteSB 05:12, 14 February 2009 (UTC)

If the stewards are willing to desysop on that basis, that's fine; I rather suspect they'll act on an individual request only in the most obvious of cases. In any case, the procedures aren't meant to govern community/steward interaction, but only ArbCom/steward interaction; in other words, the intent is to formalize the method the Committee will use to request desysoppings under various circumstances, without necessarily implying that other methods (not involving the Committee taking initial action) are no longer available. Kirill ^[pf] 05:17, 14 February 2009 (UTC)

Then you need a new name for it I think. Stewards are willing to desysop in an emergency. If Stewards are not willing to desysop it is something short an emergency. "Expedient Desysop" ? I predict that not changing something substantial in in this section will be a deal breaker.--BirgitteSB 05:22, 14 February 2009 (UTC)

Maybe a better description of this process (or how it started) is something like: arbitrator becomes aware of possible emergency situation, but is unsure of whether to report to a steward in the said arbitrator's role as an ordinary editor, or whether to report to a steward as an arbitrator, or whether to discuss with rest of committee (or as many as available) and get an official request "from the committee", or whether to discuss with the community at a place such as ANI, and so on. Lots of possibilities, and no real guidance. This is meant to codify things to some extent, as Kirill said above: "...this is intended primarily as a procedure that arbitrators must follow. We've had a number of situations in the past where emergency action by some subset of the Committee has led to misunderstandings and disputes over authorization and such; the idea is to prevent that by having a formal rule authorizing such action under certain specific circumstances..." It's the old problem of arbitrators acting as individuals, versus them acting as a group (committee). There is a fair amount of tension and balance between these aspects of an arbitrator's role, not so much in voting and discussion, but in specific actions like this (and also in actions such as blocking to enforce ArbCom remedies, especially if the incident is not clear). Too much "committee" action and paralysis sets in. Too much "individual" action and inconsistencies and drama can result. Anyone who has ever served on a committee will recognise these problems. Or to put it another way, how much should ArbCom's authority be delegated to individual arbitrators? On cases, the voting mechanism ensures the results are group decisions, but any process where individual arbitrators can be delegated to do something (eg. ban or block reviews) needs to be clear where the delegation starts and ends, and where the group decision is made (if needed). Carcharoth (talk) 20:51, 14 February 2009 (UTC)

I understood the process. My problem is not with the process, but rather the principle. What, in principle, is the difference between an emergency desysop and a temporary desysop? What is the underlying reason for creating these different categories of desysoping? A difference that is not arbitrary, something more than that one is a "three arb only desysop" and the other is an "all active arb desysop". I ask this because my initial thoughts given above don't match up well with the proposal. (My answer was: Emergency desysop is when a steward will desysop on their own authority. When a steward will not desysop without local process being fulfilled then it is not an emergency) Maybe the real problem is the arbcom is trying to take on things it inherently unsuited for. Committees are inherently unsuited for being responsible for decisions which must be made in a short time-frame. Sometimes when people ask you to volunteer to be responsible for something; the most responsible answer you can give them is "No I can't manage that". That might be the case with emergency desysoping, but I can't say that it is with confidence—you are more familiar with it all than I am.--BirgitteSB 05:42, 15 February 2009 (UTC)

There are times when an individual arbitrator or an individual editor will think something is an emergency, and a steward will disagree. Unless you think stewards are right all the time, or do not err on the side of caution, then a rapid desysop process may be needed where the individual (whether arbitrator or editor) can appeal to the committee to make a rapid decision. Getting the committee to agree (or even comment) on a proposed temporary desysop can, shall we say, take a while (which in some ways is good). This applies whether it is proposed on the mailing list (for various reasons) or by a public motion at RFAR. It may not be a recognised steward-endorsed emergency, but having a quicker process does speed things up so long as people trust any three arbitrators to make the right decision, subject to a full review by the whole committee (and before anyone mentions the community, a community discussion can equally stall or peter out without a conclusion, or take even longer and cause huge amounts of drama). A temporary desysop can also apply when we are waiting for answers to be given and there is no response. Rather than wait forever, a temporary desysop (which can be reversed) is applied (you'd be surprised how easy it is for things to slide without action when there is no response). I'm going to mention four examples, and I'll start a new post for that. Carcharoth (talk) 10:13, 15 February 2009 (UTC)

I can recall four examples from this year alone where calls were made for emergency or temporary desyoppings, two of which resulted in actual desysoppings (one of which is still under review) and two which did not. The first two are the January 2009 and the first (so far) February 2009 example on this list. Of the latter two (the ones that did not result in desysoppings), both involved access to deleted revisions (or at least the log of deleted revisions). The suggestions to desysop were made by e-mail in one case, and on-wiki in the other case. The case of access to deleted revisions is a peculiar case because access to deleted revisions is not logged, so abuse (or possible misuse) is only detected when someone admits they got information from the deleted revisions log (or announced an intention to do so). It also depends greatly on the content being retrieved. Anyway, the onwiki appeal for an emergency desysop can be seen here, and the community discussion (which was varied in opinion) petered out and was archived here. The other example, since the desysopping suggestion wasn't public, I'm not sure about pointing out yet. I probably will, but need to check a few things first. But my question to you, Birgette, and others, is what you think should have been done in those cases? The February 2009 example is still under review, so should probably not be discussed here. That leaves two examples: this one and this one. Were any of them emergencies, and was temporary desysopping needed in any of those cases? What would have happened if an individual editor (not an arbitrator) had requested an emergency desysop from a steward? Do you think the steward would have said "you need to ask your ArbCom to make this request"? And if so, what should have happened at that point? Carcharoth (talk) 10:22, 15 February 2009 (UTC)

I am not sure where best to reply. I suppose that in those cases the temp desysop process should begin. I am not sure why possible/inactive sleeper accounts and looking at deleted revisions out of curiosity constitute an emergency. If steward mistakenly won't desysop someone and there truly is an emergency it will be clear that this is a mistake within minutes and the error will be rectified. If the situation is not escalating on a time-scale that is shorter than an hour it is probably not an emergency. I am still not sure what you are using to define "emergency" in principle. You are concerned that a steward will err on the side of caution. Well I will give you that. But what do you think will happen if such error occurs? If the steward is actually wrong, then the situation will quickly get worse. The situation getting worse will overcome the caution the steward initially felt and very likely another steward whose has been watching the situation since the steward call went out on IRC will also realize it is a real emergency. Even with the time delay of an intial error this will most always happen more quickly than even a hack of a committee can deal with it. If you need another process that is quicker than a temp desysop; I will not argue that you are wrong, as you are better informed than I. However please do not broaden the term "emergency" to cover things which are not obviously serious and immediate abuses of permissions. Call it something else.--BirgitteSB 15:41, 15 February 2009 (UTC)

"I am not sure why possible/inactive sleeper accounts and looking at deleted revisions out of curiosity constitute an emergency." Your description here doesn't tally with my understanding of the examples I gave - I saw no mention of sleeper accounts and no mention of curiosity. Are we misunderstanding each other here? Remember that sleeper accounts may not be sleeping - they could be in use for "reader preferences" or to "view deleted revisions" - neither activity is, as far as I'm aware, logged in the same way that other "account" actions are. I broadly agree with your other points, but one point is clear - in one of those examples emergency action was taken - see here. If you had come across that situation, would you have requested an emergency desysop from a steward? If not, what should have happened? Is it a concern that emergency action was taken when it might not have been necessary? I haven't yet mentioned the other example where someone, upon noticing that an admin was accessing and publishing logs of deleted revisions, suggested that a temporary suspension of admin tools might be a good idea. Mainly because the admin in question doesn't know that their use of the admin tools has been questioned. Maybe the best way to do this is to ask what your response would be to reading this blog? Don't get me wrong, I don't think publishing the deleted history of a page off-site is wrong at all in this case (though in some cases it would be), but it is something that requires careful judgment. If someone said "that shouldn't be done", and went and requested that a steward carry out an emergency desysop, what do you think the steward should do? Agree? Refuse? Require a mandate from that wiki's ArbCom? And now, out of courtesy, I am going to inform the two admins I mentioned in this post and the previous one that they have been raised as examples here of where calls (both on- and off-wiki) were made for desysopping (at least temporarily). Carcharoth (talk) 17:45, 15 February 2009 (UTC

Here is what I was referring to from your examples Further checkuser investigation shows serious concerns and irregularities that had not come to light, including a possible nest of sleepers. and have access to private deleted (unoversighted) information, which he may choose for serve his own interest or from a personal pique or interest - as he has admitted to doing once before. If you wish me to understand something particular, please explain that rather than leaving blank diffs. These particular two comments can hardly equal to the whole story of the situations you use as examples, where I am afraid you have an advantage of understanding on me. Perhaps I would have been wiser to decline to comment on such cursory understanding of a situation in the first place, but I will at least decline to compound my errors further. I am not arguing against arbcom having an expedited means of desysoping anyone, I don't have the information to have an opinion there. I am trying point arbcom in the direction of changes to this proposal which will lead to more support from the community. Leaving "emergencys" to steward discretion while renaming the process for quicker desysops and clarifying the backside of these desysops will increase support for the proposal. If you want to know why this is true, I can try and explain it again. But you currently seem stuck on the idea the proposal can only be arbitrary, and that people should just accept that these are the arbitrary choices that were agreed on. In fact it is not necessary to have this proposal based solely on arbitrary choices. And even though not everyone will articulate this as why they dislike the proposal, arbitrariness generally is a turn-of to people who did not have hand in a decision. So you need to have a thread of something based on solid principle that can be followed throughout proposal and downplay the things which can only be arbitrary decisions.--BirgitteSB 18:19, 15 February 2009 (UTC)

Sorry, I missed the reference to sleepers. The second example was not "curiosity" but more "to serve his own interest" - I gave a link to a very long ANI discussion that should give the background needed. My view on what happened there is that ArbCom were aware and watching (as it stated in that thread), and individual arbitrators were waiting for the community to do something. In the end, what happened was that the thread petered out and got archived by the ANI archive bot (which is what I meant by the community not following through and resolving something). There may have also been some assumption that ArbCom might do something. I agree about the emergency stuff being left to stewards, and anything below that requiring faster action can be done by ArbCom. One point though (which may have got lost) was whether individual arbitrators requesting desyops will get more "attention" from stewards, even if they are only acting as ordinary editors (not as arbitrators). If an ordinary user makes a borderline request, a steward would likely reject it. If an arbitrator made the same request, the steward might grant it. If that is all too involved and too much focused on examples, I'll bring this back out to a general question: "when someone, on-wiki or by e-mail, suggests a temporary or emergency desysop, what should the response from ArbCom be?" In other words, who is responsible for emergency and temporary desysops? If the answer is the stewards do emergency desysops, and ArbCom do temporary ones pending review, then that's fine. But as you say, emergency and temporary need to be defined. Are we back on the same wavelength? Carcharoth (talk) 18:37, 15 February 2009 (UTC)

I only read the green diff and should have looked up "pique" in the dictionary even though I thought it meant curiosity. It was an error to comment at all on the minimal information I read. When someone suggests an immediate desysop to Arcom, it would probably be best to tell them that they should bring it to the attention of a steward if the situation is or becomes an immediate abuse of permissions. And at the same time reassure them that arbcom will conduct a review of the situation within the next few days. People really should not be going to a committee when there is an emergency, but I understand that it will happen.--BirgitteSB 18:57, 15 February 2009 (UTC)

Thanks for striking the earlier bit. I agree with what you say here, and possibly this proposal may reappear at some point with various changes, or it might just become an "internal" process. Part of the reason for putting this out for review was to see what the community thought. Some of the processes described here are how things are done right now (it might have been good to make that clearer). So if there is too much bureaucracy, or things are unclear, it's been good to get the feedback. Thanks. Carcharoth (talk) 19:10, 15 February 2009 (UTC)

Criteria for permanent desysop

One thing we have not included in very much detail are any criteria for permanent desysop. I hope to see community feedback on (a) whether there should be certain bright-line desysopping situations and (b) what criteria should result in permanent desysop. Risker (talk) 05:18, 14 February 2009 (UTC)

I would prefer to see more bright-line criteria, and they should reflect the expectation that admins should not push the envelope. Perhaps an escalating sequence of desysop times would be easier for people to agree one - a 1-month break, then a 6-month break, then permanent. I think that a standard of 1-month off is better than a standard of simply giving an admonition. — Carl (CBM · talk) 05:23, 14 February 2009 (UTC)

Logically, a permanent desysop would involve either a) egregious abuse of community trust with no apology/agreement not to do it again, or b) Chronic misuse (or frequent albeit minor abuse) of the tools after having a sufficient number of chances to rectify the situation. The former should be done ASAP; the latter should have both community and ArbCom imput. Master&Expert (Talk) 05:25, 14 February 2009 (UTC)

Personally I think bright lines are worse than useless when it comes to evaluating people. And they don't work [when applied to people] in an environment where judges don't have real external authority--BirgitteSB 05:26, 14 February 2009 (UTC)

The predictable can of worms

I would like to hear the arbiters' opinion about community-initiated removal of advanced permissions, even if (as I frankly expect) that opinion is a firm "no".

I'm aware that periodically reconfirming all admins is wildly impractical, but should bureaucrat / checkuser / oversight permissions be granted for life, as they are now? If some editor with BC/CU/OS rights loses the trust of the community, should that user retain the advanced permission? If some BC/CU/OS editor doesn't use those tools for a long time, and then suddenly uses them just once, doesn't that make the action seem unnecessarily controversial (as it could have been handled by the "regular" BC/CU/OS people)? Since BC/CU/OS removal is only rarely discussed seriously (to my knowledge), it wouldn't hurt to look at it from every angle, including this one. >Radiant< 11:45, 14 February 2009 (UTC)

I think that WP:RFC/USER is a workable framework for community-initiated removal of advanced permissions. If there is broad consensus at an RFC that the tools should be removed, an RFAR would likely be a rubber stamp, which the committee may expedite it by a motion instead of a case. The committee might also reject the request if they thought that the admin understood the gravity of the situation and promised to address the problem, in which case I would be more inclined to desysop if a second RFC, using new examples, found there was still a problem and consensus to desysop remained. John Vandenberg ^(chat) 13:43, 14 February 2009 (UTC)

I'm honestly curious why all the existing CU/OS users besides the sitting Arbs aren't being put forward for a check on their trust in the community, and only the new ones. I think I'll ask on the election policy page, as a better place for this discussion. rootology (C)(T) 17:54, 14 February 2009 (UTC)

Interesting question. But I wonder on what basis would the community determine trust? It seems to me that the only criterion that really counts is whether the CU/OS operator has done the job with a high degree of competency and kept secrets in the past. The community has no way of judging this. --ROGER DAVIES ^talk 22:42, 14 February 2009 (UTC)

Hence the concept of a review board that consists of users that have the tools (in order to be able to review the use of them), and includes users that are experienced in CU/OS matters, but also those who are outsiders (who are not part of the current CU/OS team) and so can independently judge matters. This is one reason, I believe, why cross-project review has been mooted in the past. Carcharoth (talk) 22:45, 14 February 2009 (UTC)

Issues with Temp section

• The purpose of the removal is protective, to prevent harm to the encyclopedia while investigations continue, and the advanced permissions will normally be reinstated once a satisfactory explanation is given or the issues are satisfactorily resolved. Bolded is really not good enough. If you really mean to keep the process this wide open you really shouldn't be writing a public document about it at all. Is a fully attended revote required if reinstatement is specifically asked for? Can the case be labeled "not yet satisfactorily resolved" indefinitely or will the "temporary desysop" be reviewed periodically and/or officially be resolved as a "permanent desysop"? What conditions could possibly lead to things being satisfactorily resolved and permissions abnormally not reinstated?
• 3. The Committee will then consider the appropriate course of action and set a time-scale for further discussion. This is really meaningless filler and is a non-step that should be taken out completely.
• 4. Removal of permissions may take place once a motion to do so has been endorsed by a majority of active arbitrators Is there some where on the arb pages where which arbs are active is kept updated? If so, please make a link in that statement. Also this is unclear about how dissenting votes are taken into account. Is the voting counted like arb cases or just a simple majority?--BirgitteSB 16:31, 14 February 2009 (UTC)

WP:AC has the master arbitrator list--Tznkai (talk) 18:43, 14 February 2009 (UTC)

Interesting idea for discussion from User talk:Misza13

On this general topic... this might be a better way to quickly and efficiently deal with a truly "rogue" admin from an easy software level. Read this. Basically, it would be a simple software extension for MediaWiki (already written!) that would allow ANY admin to emergency desysop ANY admin, and any 'crat to do likewise to any other 'crat, to remove the 'crat bit--but at the cost of their own +admin or +crat bit temporarily, in a form of mutually assured destruction. So--hypothetically--if Newyorkbrad flipped out one day and deleted the Main Page, blocked Jimmy, and began a bot-assisted deletion rampage I could hit Special:EmergencyWhatever, and kill +sysop on both of us instantly. The Arbitration Committee would then sort it all out. The admin or 'crat that took a bullet for the wiki for a few minutes or hours would get his bit back with a slap on the back and a huzzah, and the other guy... well, he's retired. rootology (C)(T) 20:31, 14 February 2009 (UTC)

It's not a bad idea. One thought: in borderline cases there could be lots of drama ("it was the right thing to do" - "no it wasn't") and both users might never regain the tools in question. There would still need to be some guidance on what constitutes an emergency, and what to do in cases where it is not clear if it is a true emergency, but where temporary action might be needed. Essentially a spectrum of degrees of responsiveness, with healthy dollops of common sense. Carcharoth (talk) 20:36, 14 February 2009 (UTC)

It would be super-rare I think for the obvious reason--if you do it Wrong, your days as a sysop are potentially toast forever. The only real viable reasons for use would be A) stop a truly out of control admin (delete spree etc), B) 'crat (+sysop spree) immediately, or C) retire yourself. rootology (C)(T) 20:40, 14 February 2009 (UTC)

I tried proposing that at the Village Pump.[1] It died. During that same discussion, Werdna did make a really good point about focusing on issues with articles, rather than dramatic administrator-related things that pop up twice a year at most. I think I'll go off and follow that advice. NuclearWarfare _(Talk) 20:37, 14 February 2009 (UTC)

You're right. This would be just another piece of the admin toolbox, easy to code, wouldn't need a big policy discussion--if you do it, you better be dead fucking right on the usage, since you just gave control of your own +whatever to the AC--and then hopefully sit idle like the life insurance you bought. rootology (C)(T) 20:40, 14 February 2009 (UTC)

I would support this, there is likely going to be admins available in timezones where there will not be sufficient arbs. Kamikazee sysops removing Jimbo or others bits as a final gesture will be rare, I suggest, and also preferable than using their bits to damage the content side as a means of a parting shot. LessHeard vanU (talk) 22:44, 14 February 2009 (UTC)

It should be noted that Werdna has said (on the other side of this page): "That extension is a horrible idea that will never be implemented. — Werdna • talk 02:05, 15 February 2009 (UTC)". Noting this here for the record. Carcharoth (talk) 11:25, 15 February 2009 (UTC)

And I've asked Werdna here if it's the particular technical writing of it he dislikes a dev or the idea. If it's the idea, as far as I'm aware, that is not a developer-level decision to make. rootology (C)(T) 16:40, 15 February 2009 (UTC)

I like the idea in concept, but I have some concerns about adding another layer of inter-administrator control for everyone when most admins don't encounter the wiki-world that discusses policy and administrator abuse.--Tznkai (talk) 14:57, 15 February 2009 (UTC)

I'm not keen on it at all because of the potential for vast and continual drama it introduces. Can you imagine the furore if one popular admin desysops another equally popular admin, with two huge camps of warring supporters battling it out? --ROGER DAVIES ^talk 16:46, 15 February 2009 (UTC)

It's mostly the idea which is opposed, I don't know anything about the implementation, but it will doubtless have its shortcomings, being from a newer developer. I imagine Brion will say something like "That's a bit of a silly idea" and not give its implementation any priority. It's silly because it hands emergency decision-making power to administrators with no training in making these decisions. Administrators will doubtless make snap decisions which they will regret later. A steward would perhaps be a minute or two later, but make a decision more consistent with their experience in resolving emergency situations, and probably a better decision.

The reason we don't allow admins to desysop is not because we don't trust them not to deliberately misuse the ability, but because they aren't trusted to make snap decisions. An admin who thinks they are right will assume that they will be resysopped immediately regardless, and so it's no different to letting admins desysop, from a practical perspective.

This all needs to be considered in light of the fact that there is no problem with emergency desysopping. It happens almost immediately, because we have lots of stewards, at least one of which is almost always online and on IRC. The huge potential for problems caused by half-cocked decisionmaking outweighs significantly the fixing of a problem which cannot be demonstrated to exist.

While we all like speculating about "emergency" "exciting" situations like a rogue administrator, it is perhaps more prudent to focus on problems that actually exist, rather than just those which excite us. — Werdna • talk 02:38, 16 February 2009 (UTC)

• Strong Oppose - While it is an interesting idea and I commend the highly clueful Misza13 for suggesting it, I would never support giving this power to just any admin. We need to reserve something like desysopping somebody else for the best - those who are eminently mature, sensible, and level-headed; basically somebody who is in complete control of their emotions. While the number of drama-llama's that RfA produces has been minimized in recent memory and I admit that there are quite a few admins whom I would definitely trust with that power, there are still some overly-bold sysops who remain active on Wikipedia, and RfA doesn't block out all the drama queens who are otherwise qualified. I can probably think of five administrators off the top of my head who I would never, for the life of me, trust with the ability to desysop another administrator. To put it bluntly, it's too prone to dramatic consequences. Master&Expert (Talk) 20:59, 16 February 2009 (UTC)

I have introduced a Neutral section in the straw poll

It seems that many of the opposes are fragmented, in that the intent of the proposal is supported but not the wording, or such, so I have created a neutral section where !votes can be recorded as neither supporting (for whatever main reasons given) but also not generally opposing. This way, I hope, a better evaluation of both the aim of the proposal and how it is supposed to work might be gained. (Mind you, if in a couple of days mine is still the only vote in it - chop it out and add it to the opposes.) LessHeard vanU (talk) 22:29, 14 February 2009 (UTC)

I'm glad you did that as the whole thing is in danger of being thrown out without any prospect of a replacement. --ROGER DAVIES ^talk 22:44, 14 February 2009 (UTC)

Well, I don't think a rejection of this proposal is a rejection of the existing processes. At least I hope not! Carcharoth (talk) 23:13, 14 February 2009 (UTC)

Good idea; it would be bad if those without an opinion had nowhere to voice their opinion :) --bainer (talk) 03:00, 15 February 2009 (UTC)

Examples?

Maybe some examples of cases where removal of the bit was controversial or clearly appropriate might help. Would this process have helped in such cases? Wikipedia:Former admins might help provide such examples. Specifically, this section. That is admins. Are there any examples of involuntary or emergency removal of bureaucrat, checkuser or oversight bits, on this project or other projects? Carcharoth (talk) 22:38, 14 February 2009 (UTC)

For the benefit of anyone who spent 2008 living in a cave, there's a rather obvious example. – iridescent 23:18, 14 February 2009 (UTC)

Thank you. Any others? Carcharoth (talk) 23:24, 14 February 2009 (UTC)

One prominent example of an emergency admin desysop is this one and the desysoppings discussed here. Carcharoth (talk) 23:34, 14 February 2009 (UTC)

User:RickK and User:Zoe were emergency desysopped here last year when Kelly Martin alleged they were socks and published the password (the same on both accounts) as evidence – it'll be buried in the ANI archives somewhere. – iridescent 23:36, 14 February 2009 (UTC)

Oh, and this one was a "genuine" emergency desysopping back in the dim-and-distant. – iridescent 23:39, 14 February 2009 (UTC)

Links to the ANI discussions for RickK and Zoe (can be added to Wikipedia:Former admins) and details of who actually requested Drini to do the desysop, would be good, though I've heard this was a case of an off-wiki request. Who requested the Robdurbar desyopping? It was later confirmed by ArbCom - see here. Carcharoth (talk) 23:42, 14 February 2009 (UTC)

The RickK/Zoe desysop was as a result of this – which in turn was prompted by this thread at Wikipedia Review. (While I actually have a great deal of respect for WR – if not for some of their lunatic-fringe elements – I'm not sure we really want a link to one of their attack threads on a high-ish traffic policy page like WP:DESYSOP.) Robdurbar was outed as a sockpuppet of Wonderfool at this RFCU – the fact that he was on a deletion spree that included wiping the main page was enough to set off alarm bells. – iridescent 01:09, 15 February 2009 (UTC)

How many arbs?

Really, there need only be two; the initiating arb and a reviewer; One Arb gets the notification and believes the criteria is met, and finds Arb Two for a sanity check/review. If agreed, Arb one finds a steward and requests desysop for the given reasons and notes which Arb has confirmed. The steward can then either act upon own judgement or refer to second arb for quick discussion. Any other arbs available are free to comment upon the situation during the process. The reason for three arbs, I suppose, is a tie breaking vote - and if there is a need for a tiebreak then there should not be a need for an emergency desysop. I think this would be quicker/more efficient in a true emergency. LessHeard vanU (talk) 22:40, 14 February 2009 (UTC)

Good points. This is not a decision that ought to be left to one person but perhaps three plus a steward is too many though, thanks to the mailing lists, whistling up three arbs in a hurry is much quicker and easier than most people imagine. --ROGER DAVIES ^talk 22:49, 14 February 2009 (UTC)

What constitutes an emergency?

The proposed definition is not very good (and "appears to be obviously compromised" is an oxymoron). An emergency is a situation in which failure to act immediately has a significant potential to cause harm that is either irreparable or will require an unacceptable amount of work to repair. The three cases listed are specific types of emergencies, but it isn't so hard to think of others. For example, what if an admin explicitly threatens to do something destructive unless placated? That doesn't fall into any of the three categories. Looie496 (talk) 23:05, 14 February 2009 (UTC)

Perhaps a better purpose of this document would be to limit when Jimbo or the AC cannot desysop someone summarily. An emergency is an emergency; if someone is going tools-crazy, just nuke them. But there are situations where someone shouldn't be desysopped without a trial--public, if they wish it. Just a thought. rootology (C)(T) 23:20, 14 February 2009 (UTC)

Then there are some cases that possibly can't be made public. I think a partial explanation is needed in such cases, but have a look at the list of former admins desysopped that I quoted above, and you will find examples where the explanations are vague and parts of the explanations are kept out of public view. Carcharoth (talk) 23:30, 14 February 2009 (UTC)

Use this process when a steward declines an emergency request?

I think what people are missing here is that this process was only ever meant to be an internal one for the committee to follow when a request is received from someone regarding an emergency desysop (or they become aware of a potential emergency desysop situation). The correct reply, arguably is to tell said user (whether arbitrator or editor) to go and ask a steward to do the emergency desysop. If they have done that, and the steward request has been rejected by the steward, then said editor should e-mail the committee (if drama or WP:BEANS needs to be avoided), or open a request at RFAR, or open a community discussion. The crucial point is that individual arbitrators going to a steward shouldn't be presumed to be asking on behalf of the committee, unless there has been an actual discussion (and usually a vote). This raises two questions:

• (1) What to do when a steward seemingly incorrectly turns down an emergency request?
• (2) What to do if a steward seemingly incorrectly accepts a request in a non-emergency situation?

It's rather similar to how WP:ROLLBACK got turned on. Someone told a developer there was consensus, and the developer checked and turned it on. Turns out people disagreed whether there was consensus or not. This proposal was designed, I believe, to avoid deadlock and similar situations with desysoppings. Are the community happy for individual arbitrators to request emergency desysoppings? If so, what happens when arbitrators disagree on what constitutes an emergency? And what happens when stewards disagree with individual requests - should a committee request (which takes longer) be able to over-ride that? Carcharoth (talk) 11:22, 15 February 2009 (UTC)

If it is an internal process, then perhaps it should have been taken to a point where there was a rough/working consensus between the arbcom and "the stewards" (if they are so organised to speak with one voice - but that is outside the discussion remit) which could then be presented to the community. Then the feedback would have permitted refinement or reworking as required. The more I read, the more I feel this proposal was introduced to general comment prematurely. LessHeard vanU (talk) 17:00, 15 February 2009 (UTC)

I have always understood it to be the case that stewards are required to carry out permissions changes when requested by a recognised Arbitration Committee; vide "Should a wiki have existing policies regarding the steward action, stewards must ensure requests conform to the relevant policy...": if a wiki has created an ArbCom with the ability to change user rights, then those requests must be actioned. This policy is, I believe, an attempt to clarify what, exactly, constitutes a request from the Arbitration Committee as opposed to a personal request from an arbitrator (whereby the steward's personal judgement is invoked). Happy‑melon 23:23, 15 February 2009 (UTC)

You have hit the nail on the head.

It looks as though we need to expand on the definition of an emergency to differentiate between emergencies that would be handled by a steward operating under their own judgement, and the ones where a steward is acting on a request that is "on behalf of the Committee". The use of the word "emergency" in this proposal may also be part of the problem.

If a simple emergency lands on the Arbitration Committee desk, we should be sending it straight to a steward without the need for "three arbitrators". This proposal was only intended to address emergencies that are sufficiently complicated that a steward is unlikely to act, however we could expand on when an arbitrator should engage a steward. An example of this would be an oversighter or checkuser running amok. If an administrator is running amok, the community can see what is going on and will initiate the request, and the stewards can see all the evidence and will likely respond quickly.

The poll has also raised concern that the committee isn't going to respond quickly if action requires three arbitrators. I can think of two ways to adddress that:

1. introduce a maximum timeframe for it to be left with the committee. e.g. If there is no dissent after x mins/hours, a lone arbitrator should be able to request steward action on behalf of the committee. In this case, I think that the request to the steward should clearly state that three arbitrators have not approved it yet.
2. allow the stewards to set the timeline. e.g. require that the "emergency" email is sent to both the committee and a steward at the same time, and the steward is empowered to act unless they see dissent from the committee within the timeframe that the steward feels comfortable.

More ideas welcome. John Vandenberg ^(chat) 01:11, 18 February 2009 (UTC)

Why not just eliminate the three Arbitrator requirement, and change it to any arbitrator can director a steward to do so. If the Arbitrator abuses this, a good troutsmack (and recall, hopefully?) will be implemented, but a checkuser/oversight decision has to be looked at quickly, and should not have to wait for multiple arbs, ever. NuclearWarfare _(Talk) 02:02, 18 February 2009 (UTC)

Well, as Jayvdb says up above, any editor (whether or not they are also an administrator or an arbitrator) may approach a steward and ask for an emergency desysop. The stewards have their decision tree and are trusted throughout the WMF to act according to their best judgement. It needs to be clear, however, that if an individual who also happens to be a member of the Arbitration Committee asks for an emergency desysop, he or she is doing it in his or her own name, not in the name of the Committee. We're establishing the minimum standards for the extraordinarily rare situations where the Arbitration Committee as a body will ask that a steward remove permissions. A single arbitrator can ask for a desysop tomorrow, but it won't be a Committee-requested one. Risker (talk) 02:20, 18 February 2009 (UTC)

Suggestion

There seems to be some division around what is an "emergency" and the consulation of "3 arbitrators" to determine whether an emergency exists.

I've had a go at drafting what might be a slightly simpler and more intuitive approach (link). It's also simpler and easier to fine-tune or recategorize issues going forward. I haven't added the procedural details, just addressed the core question.

Thoughts?

FT2 ^{(Talk | email)} 17:56, 22 February 2009 (UTC)

I like it, should we comment further here or on that page's talk page? If here, can you copy it here? davidwr/(talk)/(contribs)/(e-mail) 00:20, 23 February 2009 (UTC)

I posted the text elsewhere to keep this page shorter; it's linked. Comments are probably best here. FT2 ^{(Talk | email)} 23:06, 23 February 2009 (UTC)

I like it. It's way better than what we currently have, needless to say. I also like the fact that it mentions indirect abuse of tools; checkuser threats of 'outting' for example. Yep - looks good to me - Alison ^❤ 04:31, 28 February 2009 (UTC)

Precisions on the scope of the proposal

If as confirmed by arbitrators above, the proposal aims to govern only the removal of advanced permissions by the Arbitration Committee, the text should reflect it. For example, it should be entitled "Removal of advanced permissions by the arbitration committee" instead of "Removal of advanced permissions", and it should acknowledge that stewards can also remove rights following their policies independently of the Arbcom. Cenarium (talk) 17:28, 25 February 2009 (UTC)