Carcharoth (talk | contribs) →Comment: reply to Birgitte |
Carcharoth (talk | contribs) →Comment: examples from this year |
||
Line 67: | Line 67: | ||
::::::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.--<i><font color="#9966FF">[[User:BirgitteSB|Birgitte]]</font><font color="#CC99CC" size="2">SB</font></i> 05:42, 15 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.--<i><font color="#9966FF">[[User:BirgitteSB|Birgitte]]</font><font color="#CC99CC" size="2">SB</font></i> 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. [[User:Carcharoth|Carcharoth]] ([[User talk:Carcharoth|talk]]) 10:13, 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. [[User:Carcharoth|Carcharoth]] ([[User talk: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 [[Wikipedia:Former admins#Desysopped by_ArbCom, Jimbo Wales or otherwise|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 [http://en.wikipedia.org/w/index.php?title=Wikipedia:Administrators%27_noticeboard/Incidents&diff=prev&oldid=262911985 here], and the community discussion (which was varied in opinion) petered out and was archived [[Wikipedia:Administrators' noticeboard/IncidentArchive507#Admin misusing viewdeleted|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: [http://en.wikipedia.org/w/index.php?oldid=261745852#Temporary_emergency_desysop_of_User:Hemanshu this one] and [http://en.wikipedia.org/w/index.php?title=Wikipedia:Administrators%27_noticeboard/Incidents&diff=prev&oldid=262911985 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? [[User:Carcharoth|Carcharoth]] ([[User talk:Carcharoth|talk]]) 10:22, 15 February 2009 (UTC) |
|||
== Criteria for permanent desysop == |
== Criteria for permanent desysop == |
Revision as of 10:22, 15 February 2009
Emergency Steward Desysop
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)
- Yes, the procedures here are for the Committee, not for the stewards (who have their own). Kirill [pf] 04:38, 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)
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)
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)
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:
- Someone goes to #wikimedia-stewards, types !steward, explains problem
- Steward desysops user
- User is blocked locally
- Thread started on WP:AN or WP:ANI
- ArbCom votes and decides to make the desysop officially permanent
- ????
- 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 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)
- 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)
- 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)
- 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)
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)
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)
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)
- 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)
- Oh, and this one was a "genuine" emergency desysopping back in the dim-and-distant. – iridescent 23:39, 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)
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)