Newyorkbrad (talk | contribs) →Desysop motion analysis from DeltaQuad: comment; punct |
Carcharoth (talk | contribs) |
||
Line 139: | Line 139: | ||
**Maybe 'Full' or 'Complete' removal? The substantive difference is (or should be) 'removal without necessarily requiring further review' versus 'removal with the possibility of requesting further review'. Immediate (because it is obvious and needs doing quickly) vs relatively quickly (because it is not so obvious and not so urgent). The whole text could do with some simplification. There are too many caveats and maybes and 'almost always'. It should be simple, direct and decisive, so no-one can get confused. [[User:Carcharoth|Carcharoth]] ([[User talk:Carcharoth|talk]]) 14:51, 18 October 2016 (UTC) |
**Maybe 'Full' or 'Complete' removal? The substantive difference is (or should be) 'removal without necessarily requiring further review' versus 'removal with the possibility of requesting further review'. Immediate (because it is obvious and needs doing quickly) vs relatively quickly (because it is not so obvious and not so urgent). The whole text could do with some simplification. There are too many caveats and maybes and 'almost always'. It should be simple, direct and decisive, so no-one can get confused. [[User:Carcharoth|Carcharoth]] ([[User talk:Carcharoth|talk]]) 14:51, 18 October 2016 (UTC) |
||
***Would it be worthwhile for Carcharoth to try his hand at a simplified version. As a two-time Committee alumnus he should have a good handle on the relevant considerations. (I won't offer to do it, as simplifying things is not necessary my forte, either by reputation or by reality.) [[User:Newyorkbrad|Newyorkbrad]] ([[User talk:Newyorkbrad|talk]]) 16:58, 18 October 2016 (UTC) |
***Would it be worthwhile for Carcharoth to try his hand at a simplified version. As a two-time Committee alumnus he should have a good handle on the relevant considerations. (I won't offer to do it, as simplifying things is not necessary my forte, either by reputation or by reality.) [[User:Newyorkbrad|Newyorkbrad]] ([[User talk:Newyorkbrad|talk]]) 16:58, 18 October 2016 (UTC) |
||
****Sadly, I fear not (and like you I don't intend to offer). Though I thank you for the kind suggestion. There is enough feedback here for the current arbs to work with. [[User:Carcharoth|Carcharoth]] ([[User talk:Carcharoth|talk]]) 18:43, 18 October 2016 (UTC) |
Revision as of 18:43, 18 October 2016
Motions
Motion to modify removal of advanced permissions ArbCom procedure
When an account with administrator, bureaucrat, CheckUser and/or oversight permission(s) seriously or repeatedly engages in conduct harmful to the project or contrary to the expectations of advanced permission holders, the Committee may authorize removal of these permissions. If the account has multiple permissions, removal will generally apply to all of them. Nothing in these procedures prevents prevents the Committee from imposing sanctions, such as restrictions on certain uses of the permissions.
Permanent removal
- Criteria
This procedure may only be used when there is overwhelming evidence of egregiously unacceptable conduct that makes the examination of patterns of conduct superfluous. Examples include, but are not limited to:
- "Bad faith" adminship, for example abusive sock puppetry, or using advanced tools when obviously involved
- Serious or repeated breaches in basic policies (such as outing);
- Serious or repeated inappropriate use of advanced tools. This includes wheel warring or breaches of policies core to the permission, such as the deletion, blocking or protection, oversight or CheckUser policies
- Procedure
Before removing permissions, the permission holder should almost always be given an opportunity to explain their actions through contact on their talk page, by email with the Committee or discussion on one of the Committee's Wikipedia pages
If a satisfactory explanation is not provided and the situation not resolved within a reasonable period of time an arbitrator may propose a motion to remove the permission(s). The motion shall be proposed at the most appropriate location, such as in response to a clarification request, a standalone motion or in private if required.
If a majority of active, non-recused arbitrators support it, the motion shall be enacted by posting a request to remove the permission(s) at the bureaucrats' noticeboard (an arbitrator or clerk may remove the permission themselves) or the Meta-Wiki permissions page. The text of the motion is also to be posted to the user's talk page and the Committee's noticeboard.
If requested by the permission holder, or if at least three arbitrators support it, arbitration proceedings will be opened to examine the removal of permissions.
The motion to remove the permission(s) will specify how they can be reinstated. Generally, the user will need to reapply for the permission by a new request for adminship or bureaucrat or appointment as a CheckUser/Oversighter by the Committee.
Interim removal in emergencies
If an account with any of the permissions listed above
- (a) appears to be obviously compromised,
- (b) is intentionally and actively using advanced permissions to cause harm in a rapid or apparently planned fashion, or
- (c) multiple accounts are actively wheel-warring and blocks have not worked,
any of the following processes may be used to remove the permission(s).
- Bureaucrat action
In an emergency, English Wikipedia bureaucrats may temporarily remove the administrator permission without the authorisation of the Committee. If a bureaucrat determines that an interim emergency removal of the administrator permission is required, they must:
- If a compromised account is suspected, contact the stewards so that the account can be globally locked.
- Note on the user rights management page the reason for removal and include a link to this procedure;
- Leave a message on the user's talk page and the Bureaucrats' noticeboard indicating the reason for removal, link to this procedure, and ask the user to contact the Committee;
- File a new case request and include in their statement the username of the account in question and detailed information describing the reason for the interim removal. If the interim removal was based entirely on private information, this step will be skipped and the bureaucrat will email the Committee.
- Committee action
- If a compromised account is suspected, contact the stewards so that the account can be globally locked.
- An arbitrator will send a message to arbcom-l (a) stating the name of the account, (b) briefly describing the issue and providing examples of inappropriate conduct, and (c) specifying why interim emergency removal is required.
- A request for removal of permissions is approved once at least three arbitrators have indicated their support and no arbitrators have opposed emergency removal.
- Once removal has been approved, an arbitrator will (a) directly request removal from a bureaucrat or steward as appropriate, (b) make a formal statement on the bureaucrats' noticeboard or Meta-Wiki permissions page to confirm that the request is based on the authority of the Committee, and (c) post a notice to the Committee's noticeboard and the user's talk page, including a brief explanation of the reason for removal and the names of the arbitrators who voted on it.
- Steward action
These procedures do not constrain the authority of the Wikimedia Stewards to undertake emergency removal of permissions (including the administrator permission) pursuant to the global rights policy and other relevant policies.
- Review and return of permission(s)
The full Committee will review the removal of permissions and determine any further action to be taken. This action includes reinstating the permission(s), making the interim removal permanent for one or more of the user's permissions or applying further sanctions.
Removal is protective, intended to prevent harm to the encyclopedia while investigations take place, and the permissions will normally be reinstated once a satisfactory explanation is provided or the issues are resolved. If requested by the advanced permission holder or if the Committee wishes, arbitration proceedings (such as a full case) will be opened to examine the removal of permissions and any surrounding circumstances.
- For this motion there are 12 active arbitrators. With 0 arbitrators abstaining, 7 support or oppose votes are a majority.
- Support
- Salvio Let's talk about it! 15:50, 11 October 2016 (UTC)
- Thank you to everyone for their comments on this proposal. I feel that we're at a point where we can move forward with approving this change. Callanecc (talk • contribs • logs) 08:55, 17 October 2016 (UTC)
- Oppose
- Abstain
Discussion by arbitrators
- This proposal aims to fix a couple of the things which have been discussed by both the Committee and community about the current procedure. Primarily it provides a policy basis for the people with the ability to desysop to do so in emergencies (see the incident in November 2015) and to provide a clearer criteria for the removal of permissions both by Committee action and in an emergency. Callanecc (talk • contribs • logs) 07:19, 10 October 2016 (UTC)
- Arbitrators may wish to take a read over the proposed changes and an analysis of them. -- Amanda (aka DQ) 02:42, 15 October 2016 (UTC)
- See also #Desysop motion analysis from DeltaQuad. Callanecc (talk • contribs • logs) 07:27, 15 October 2016 (UTC)
Community comments
- If an arbitrator is also a bureaucrat, he'd thus have two choices: do it right away and THEN inform ArbCom, or put it to an ArbCom vote and only desysop after a net four vote. This also gives the impression of putting 'crats judgement above Arbitrators. ☺ · Salvidrim! · ✉ 16:01, 10 October 2016 (UTC)
- I don't think that's much of an issue. Crats are specifically selected to be boring and not go rouge. We haven't had a crat boldly do something controversial like that since 2004 or 2005. The WordsmithTalk to me 17:06, 10 October 2016 (UTC)
- One would expect "Bureaucrat action" to occur in situations that are more urgent than allows for "Committee action". I think the policy should say that - i.e. that bureaucrats should only take action if they judge the situation to be too urgent to follow the procedure under "Committee action". We can perhaps contrast the three scenarios in which this is said to apply:
(a)/(b)"appears to be obviously compromised" or "is intentionally and actively using advanced permissions to cause harm in a rapid or apparently planned fashion" - likely to go down the "Bureaucrat action" route. And I suspect a non-bureaucrat Arb would just flag a bureaucrat or steward to do the emergency desysop based on their own judgment. Why wait for three other Arbs, and then have to find a bureaucrat or steward to do the desysop?
(c) "wheel-warring and blocks have not worked" - may vary in urgency depending on where the wheel war is happening, the speed of the wheel war, and how much harm it is causing. May not require immediate action.
WJBscribe (talk) 17:22, 10 October 2016 (UTC)
- @WJBscribe: Yeah that's how I look at - actions by crats would generally be done when urgency is important and there isn't time for the Committee to act. Committee action would be in cases where the reasons are private or there is a little more time (such as wheel warring). Personally, I'd actually prefer to make it less prescriptive in this area (and just leave the definition of an "emergency" up to discretion, than more prescriptive so that it can better cover the situations we don't think of now. Callanecc (talk • contribs • logs) 09:33, 13 October 2016 (UTC)
- Regarding Bureaucrat emergency actions, I strongly suggest that a similar posting requirement to WP:BN be required as is for committee actions, to have a central communication that an action has taken place and referring follow up to the case opened (or in the event of private information that follow up is to the arbcom mailing list). — xaosflux Talk 17:36, 10 October 2016 (UTC)
- @Xapsflux: Done. Callanecc (talk • contribs • logs) 09:33, 13 October 2016 (UTC)
- Comment - the section on emergency removal is a bit outdated. While removing permissions from compromised accounts and then blocking them does stop the outward abuse, it doesn't do anything to prevent the abuser from going into the account preferences and changing the password/email so that the holder of the account can no longer recover it. The current best practices for stewards when it comes to dealing with compromised accounts are as follows:
- Lock the account. This logs the person out, and prevents them from logging in again anywhere on Wikimedia. This means that there is no way for the potential attacker to change any of the user information if they haven't already, and because they cannot log in there is no need to remove permissions at this point.
- Work with local users to investigate whether or not the account was compromised through CheckUser and through doing our best to contact the account owner.
- Ultimately, it's up to the local community to decide whether or not the account was actually compromised. For the final step of deciding whether or not to remove permissions, it's not up to us since there is no longer an emergency, though of course we will remove permissions for groups that local 'crats can't remove.
- So I would propose the following workflow for dealing with accounts suspected of being compromised: Identify --> contact stewards through IRC, email or on Meta-Wiki --> they will work with local users to resolve the problem. This way can lead to the abuse being stopped faster, because there is always at least one steward around rather than a coin toss whether a 'crat is here, and can help keep account information and control safe. -- Ajraddatz (talk) 18:38, 10 October 2016 (UTC)
- In my mind, this text needs a serious shortening. Otherwise, Ajraddatz's suggestion seems fairly reasonable. Jo-Jo Eumerus (talk, contributions) 18:51, 10 October 2016 (UTC)
- The procedures for permanent removal include this sentence: "The motion is to be proposed as the most appropriate location, such as in response to a clarification request, a standalone motion or in private if required." (Trivial: "as... location" should be "at".) I can easily imagine situations where private disposition of emergency removals is necessary, but I have some concerns about "in private if required" for the kinds of egregiously obvious problems that would result in permanent actions. I can understand the need to omit private information for situations involving checkuser or oversight, but such situations usually can still be discussed on-site with the omission of the private information. In most other cases where permanent removal is required, there will already be an on-site record that the community has seen. Therefore, I think that over-reliance on private discussion reduces community confidence in the Committee. At a minimum, "if required" needs some definition or limitation. --Tryptofish (talk) 20:26, 10 October 2016 (UTC)
- Minor copyediting suggestion: for clarity, I suggest changing the sentence "The motion to remove the permission(s) is to specify how they can be reinstated." to "The motion to remove the permission(s) must specify how it can be reinstated." isaacl (talk) 21:09, 10 October 2016 (UTC)
- Thanks for modifying the sentence in question. In addition, can "The motion shall be proposed as the most appropriate location" be modified to something like "The motion shall be proposed in the most appropriate location"? isaacl (talk) 12:57, 13 October 2016 (UTC)
- Thanks for making the change. isaacl (talk) 17:43, 14 October 2016 (UTC)
- Thanks for modifying the sentence in question. In addition, can "The motion shall be proposed as the most appropriate location" be modified to something like "The motion shall be proposed in the most appropriate location"? isaacl (talk) 12:57, 13 October 2016 (UTC)
- Similar to Isaacl above, I think the use of "is to" in this motion is ambiguous. It can either mean a purpose or a command, particularly "The motion to remove the permission(s) is to specify how they can be reinstated". I think all parts of the motion use "is to" in the command sense, so we should replace "is to" with "shall". Other than that, the proposed procedures don't differ significantly from existing procedures but give more elegant names to things, so I can support it. Deryck C. 09:46, 11 October 2016 (UTC)
- @Deryck Chan: Done, to either shall or will. Callanecc (talk • contribs • logs) 09:33, 13 October 2016 (UTC)
- The proposed modified procedure is too long, too wordy, and needs a good bit of copy editing. Substantively, I'm not sure it clarifies much for me. It would be helpful to know what the arbitrators think has changed as well as what is new.--Bbb23 (talk) 12:30, 13 October 2016 (UTC)
- @Bbb23: I have made a page outlining what I think the changes are. This is my first chance to dip into the entire thing, and I haven't read anything about this on any arbitration back channel. Therefore I apologize to @Callanecc: for not getting to it sooner and commenting on them before he posted this. -- Amanda (aka DQ) 02:41, 15 October 2016 (UTC)
- DeltaQuad and Callanecc, I've read Amanda's analysis and Callanecc's response. In my present mental state (no sleep), I couldn't get my brain around either. Perhaps I'll try again later this weekend or early next week. It doesn't help that I'm not and never have been an arbitrator and am not privy to current or previous discussions about this topic. In the interim, I've done the little I can do that doesn't require a great deal of thought: I've created User:Bbb23/Modified removal of advanced permissions, which is an edited version of the proposal to remove excess verbiage and make other copy edits. Even those of us who are not lawyers write too much like lawyers, and I tried to cut down on the legalese without losing what I thought was Callanecc's intent.--Bbb23 (talk) 10:49, 15 October 2016 (UTC)
- The temporary removal section doesn't obviously contain provision for a situation such as that which happened when the arbcom archives were leaked a few years ago. One possible source for the leak was that an arbitrator's account had been compromised, but one arbitrator could not be immediately contacted to determine whether they were in control of their account or not - as a preventative measure the account was locked and permissions removed, despite there being nothing in the contributions or logged actions to suggest it had been compromised (it turned out their account was not compromised and permissions were restored). Thryduulf (talk) 23:42, 13 October 2016 (UTC)
- Permanent removal, under criterion 2, is for "Serious or repeated breaches in basic policies." Can't it be argued that the recent TRM case could then have been bypassed by ArbCom finding repeated breaches of the civility policy? It's not an approach in line with the implied severity of the outing policy example, but all it says is "basic policies", the meaning of which is open to interpretation. Seems a potential issue to me. EdChem (talk) 06:48, 15 October 2016 (UTC)
- @DeltaQuad: Re "The stewards here are given a "you can do this" card, but directs them to do so under a poorly worded policy page or "other global policy"...I'm no expert in global policy, but i'm pretty sure a global lock is about all that the can do. I don't like the idea of this brushing stewards out of this, as Arbs and Crats aren't always around at convenient times, and maybe should be put under the same authority as crats." - stewards still retain the ability to do emergency desysops on all wikis, including large wikis such as the English Wikipedia, without ArbCom's approval. One case besides a compromised account would be repeated wheel warring (think several times within minutes). This provision has not been used in several years on enwiki (and I can't think of any recent cases on any large wikis) but it is still there, in case of emergency. I can think of a few other unique cases that I won't mention onwiki, but I'm sure are discussed in the arbcom-l archives somewhere. --Rschen7754 07:03, 15 October 2016 (UTC)
- We desysopped someone on a small-sized Wikipedia back in March, and were considering an emergency desysop to enforce the ToU on a medium-sized wiki somewhat recently. So yes, stewards do retain the technical ability and community mandate to desysop in cases of emergency or abuse, though of course the matter is put to the community after that. As I was saying above though, in most recent cases we lock the account instead to do fact-finding. A somewhat recent example of this happened with a now-arb here back in 2013. Emergency desysopping is really only useful when we are 100% sure that the account is not compromised, and in practice this only happens on smaller wikis with less-well-vetted admins these days. -- Ajraddatz (talk) 07:20, 15 October 2016 (UTC)
- Regarding the place of stewards, the enwiki policy (which ArbCom can't change/overrule) says In emergency situations where local users are unable or unavailable to act..., stewards are asked to use their global rights to protect the best interests of Wikipedia (WP:GRP#Stewards) and the global Stewards policy says If there are any doubts as to whether or not an action should be performed, stewards should not act unless it is an emergency situation requiring immediate action or there are no active local users to do it (which the local policy pretty much reflects). Callanecc (talk • contribs • logs) 07:34, 15 October 2016 (UTC)
- We desysopped someone on a small-sized Wikipedia back in March, and were considering an emergency desysop to enforce the ToU on a medium-sized wiki somewhat recently. So yes, stewards do retain the technical ability and community mandate to desysop in cases of emergency or abuse, though of course the matter is put to the community after that. As I was saying above though, in most recent cases we lock the account instead to do fact-finding. A somewhat recent example of this happened with a now-arb here back in 2013. Emergency desysopping is really only useful when we are 100% sure that the account is not compromised, and in practice this only happens on smaller wikis with less-well-vetted admins these days. -- Ajraddatz (talk) 07:20, 15 October 2016 (UTC)
- On a quick read, this seems to add a lot more requirements on bureaucrats, who previously would simply have acted to remove the permission and notify Arbcom, and also makes it much more complex to notify bureaucrats. IRC, email to the 'crat list, or personal direct contact with a bureaucrat all seem to be taken off the table, which is a bit absurd if the situation is time-sensitive. I'd rather see the process be simplified rather than made more complex. Incidentally, what constitutes "basic policies"? I know from my time on Arbcom that it was entirely possible to violate one policy by upholding another because we have so many intertwining policies, and WP:5 (which I'd guess is what you might be suggesting are basic policies) is a guideline and has been deliberately kept at the guideline level over multiple community discussions. Risker (talk) 03:14, 16 October 2016 (UTC)
- It's not a matter of more requirements it's that there are now requirements. As can be seen from the thread on BN when those two admin accounts were compromised the initial email was to email ArbCom for a desysop rather than do it themselves, even when the crat did desysop them they knew there was a possibility of sanctions against them. I'm not sure what you mean by those opinions being taken off the table, they are still ways to let a crat know that an account has been compromised. As happened last time, resysoping happened (and will happen under this procedure) when ArbCom gave the go ahead. Outing is probably around the level of basic we're talking about (were talking things like privacy, outing, egregious harassment) about as far as it's going to go, given that is has to be "egregiously unacceptable conduct". Callanecc (talk • contribs • logs) 06:02, 16 October 2016 (UTC)
- Another possible scenario is mental health concerns, without going into details. --Rschen7754 07:44, 16 October 2016 (UTC)
- It's not a matter of more requirements it's that there are now requirements. As can be seen from the thread on BN when those two admin accounts were compromised the initial email was to email ArbCom for a desysop rather than do it themselves, even when the crat did desysop them they knew there was a possibility of sanctions against them. I'm not sure what you mean by those opinions being taken off the table, they are still ways to let a crat know that an account has been compromised. As happened last time, resysoping happened (and will happen under this procedure) when ArbCom gave the go ahead. Outing is probably around the level of basic we're talking about (were talking things like privacy, outing, egregious harassment) about as far as it's going to go, given that is has to be "egregiously unacceptable conduct". Callanecc (talk • contribs • logs) 06:02, 16 October 2016 (UTC)
Desysop motion analysis from DeltaQuad
- @Bbb23 and DeltaQuad: Some comments on the analysis:
- The sentence about not limiting other options was added as, during discussion on the list, an arb (can't remember who) expressed concern that the procedure (without this) limited the Committee from imposing other sanctions by motion.
- This procedure doesn't remove the possibility of vote-by-proxy (using any means) they just don't outright say it. Part of the reason for this is that vote-by-proxy has been accepted for other things so stating that it's specifically allowed implies that it isn't other times.
- Regarding four net, the intention was to standardise it with WP:AC/P#Calculation of votes, however I've no issue with changing it back to three support and no dissenting opinions. Alternatively, we could change it to one arbl however I'm not sure how that would be taken, given there's nothing else like this that a single arb can do.
- Regarding BN vs Meta, perhaps Ajraddatz could give us some more information on it. But I was under the impression that the stewards won't act when local crats are able to, unless it's an emergency. So while opinions both are there, the arb posting it would use BN for desysops (which is standard practice). Not having that written in there allows for situations we haven't thought of, the discretion of individual arbs and makes it less wordier.
- I'd prefer that the names of supporters and opposers are always announced publicly (unless there are very good reasons not to, e.g. strong privacy/legal issues), but that's not the position of the rest of the Committee.
- Whenever a crat desysops someone (or anyone gets desysoped anyway) there are going to be people talking about it. I'd prefer that that happens at ARC where there are stronger controls on civility and personal attacks (etc), plus it ensures that the whole Committee reviews the situation. This also goes to ensuring that every removal of permissions is reviewed by the Committee, which is one of the big things in the Committee's discussions.
- It does really limit the scope of the crat's since they currently have no scope in this area. We can't think of every situation, but when we're delegating the authority to do something controversial (which the community has historically refused to delegate from the Committee, ie desysoping) it should be restrictive.
- Regarding the global policy referral for stewards, this gives them pretty wide latitude to do whatever they need to do, and in any case, the Committee can't override this piece of community policy (which reflects the global steward policy).
- Regarding one crat vs one arb, see third dot point.
- The Committee is discussing whether to handball compromised accounts straight to stewards or add contacting them to the current procedure.
- The point of introducing a criteria which is more restrictive than the current version, is that there have been a number of comments both from arbs and others the Committee should generally lean away from desysop-by-motion and instead towards opening a case (see also "summary proceedings" at WP:ARBPOL#Forms of proceeding). This tries to limit those situations, while also not being too restrictive as to prevent the Committee acting. There were originally more dot point examples however these where removed in discussion with the rest of the Committee as instances where a full case could be opened. There is a bit there which expressly states that the list is not restrictive but instead just suggestions.
- I've no issue with adding a note that it should be very rare for the Committee not to contact the permission holder, but I feel that doing so probably isn't needed.
- An individual arbitrator started the process by themselves without consultation in the old/current procedure. The new procedure doesn't specify how it starts, and I don't mind that really. Each year's Committee is different, some work by discussion first (as this year's does) some work by action then discussion, I don't really see a strong need to specify that discussion is required first.
- I agree that a case should be accepted as normal (with votes to accept) but that's not the opinion of other arbs (Opabinia regalis might like to comment on this?). Reason being to try and avoid a situation where the same people who desysoped 'review' the situation by declining to actually review (i.e. a case) the situation.
- "normal arbitration proceedings" includes a private discussion / review on ArbWiki; a "case" strongly implies a standard public one.
- Cross posting to AN (and WT:ACN) is covered in the clerks' procedures so even if an arb doesn't do it (although it is standard practice) a clerk would do it.
- I imagine these comments are going to be difficult to respond to, so if anyone can think of a better way to do so, please share. Callanecc (talk • contribs • logs) 07:27, 15 October 2016 (UTC)
- Regarding BN versus stewards; it's really a question of urgency. If sysop tools are actively being used to cause harm to the project, stewards can act. Stewards are in part selected on the basis of timezone coverage and availability, which isn't a concern for local crats (nor should it be), so if ArbCom is faced with needing to desysop immediately it would be best to refer to us. For sysop tools being removed by Committee motion after the fact, that is a case for local bureaucrats.
- Regarding compromised accounts, I don't think it would be worth tossing the entire case to us - as I suggested in my earlier post, the only thing that we really do alone is lock the account or remove permissions depending on the case, before sending it back to the local community. We lack knowledge of the situation and methods of contacting the user in question, as well as more practical tools like using CheckUser here for accounts which are primarily active here. But I think it is worth informing stewards, either to begin with or early on, so the initial technical actions can be done. After that, the issue can be resolved locally, and then we can be informed of the result so the account can be unlocked, permissions removed/restored, etc. So, I'll modify my suggested workflow to: suspect an account of being compromised --> contact ArbCom or stewards --> both groups will contact the other and proceed with resolving the situation. The only benefit to initiating the process with the stewards is the availability component, which might be enough of a consideration to have it as "option 1", though I imagine we'd be contacted very quickly in such a situation anyway. -- Ajraddatz (talk) 07:48, 15 October 2016 (UTC)
- I was thinking of adding step to the Committee (as part of step 1 or 3) and crat (between steps 2 & 3) actions to let the stewards know if they suspect the account has been compromised, how does that sound? Callanecc (talk • contribs • logs) 07:53, 15 October 2016 (UTC)
- At that point it would be useful for investigating the implications for the user's global account (i.e. permissions on other projects, etc), but it misses out on resolving the situation with the least possible actions taken. If the account is suspected of being compromised, locking it deals with all the effort of desysopping and blocking in a fraction of the time while keeping the account secure. If the path flows through local processes first, then there is added time spent on wheel warring, trying to contact local users which may or may not be around, etc. So it would be useful in the Committee step 1, but perhaps also as a replacement to the bureaucrat step 1. For other types of emergencies, such as when an admin who has long disliked one user goes ahead and blocks them and starts reverting all their edits, locking isn't needed. But it's a good first step in situations where the account is potentially compromised. -- Ajraddatz (talk) 08:01, 15 October 2016 (UTC)
- My consideration with still having a local desysop occur is a situation like this, perhaps you could offer some insight into about the stewards would handle it (policy-wise). An admin account (which is active on other projects) is locked after someone email the stewards alerting them to it (the account wasn't blocked and it wasn't desysoped) because they are thought to be compromised after they deleted a highly viewed page or blocked someone for no reason (and no explanation). They emailed the stewards and it was established (the same day) that it wasn't a compromised and they wanted to return to editing the other projects all also edit. Would a steward then unlocks the account (it's no longer compromised so that reason doesn't exist anymore)? Callanecc (talk • contribs • logs) 10:12, 15 October 2016 (UTC)
- I can't provide you with much of a policy perspective; stewards have very few policies to begin with, instead operating mostly by best practices, and all existing restrictions are lifted in cases of emergency like this. In the case you describe, we would lock the account and contact ArbCom/other local users for context and contacting the user in question. At this point, ArbCom could initiate any action in terms of a desysop motion and have it carried out, by local bureaucrats or stewards if none were around. Once it was established that the account was in the right hands, we would unlock, but first making sure that any local restrictions required were in place on all effected projects (desysopping and potentially blocking being the main ones here). Now, it's just my opinion that stewards are better equipped to deal with these situations. Giving bureaucrats the ability to intervene won't impede our ability to help and take action as needed, and it makes sense to give them the mandate in case they ever need it. -- Ajraddatz (talk) 19:07, 15 October 2016 (UTC)
- Thanks Ajraddatz, the Committee is discussing it. Callanecc (talk • contribs • logs) 05:56, 16 October 2016 (UTC)
- Just on Callanecc's point 14 above: one concern I've always had about this process is that summary removal of permissions by arbcom is only practically appealable back to arbcom, so the more of us are involved in the original decision, the less confident the affected person would be in having a fair review. My original suggestion was that arbs participating in an "interim" decision recuse from any subsequent case and present the evidence on which they based the decision. However, that's a recipe for cases decided by a small number of people, once other recusals, inactivity, and attrition are accounted for. Opabinia regalis (talk) 07:20, 16 October 2016 (UTC)
- Thanks Ajraddatz, the Committee is discussing it. Callanecc (talk • contribs • logs) 05:56, 16 October 2016 (UTC)
- I can't provide you with much of a policy perspective; stewards have very few policies to begin with, instead operating mostly by best practices, and all existing restrictions are lifted in cases of emergency like this. In the case you describe, we would lock the account and contact ArbCom/other local users for context and contacting the user in question. At this point, ArbCom could initiate any action in terms of a desysop motion and have it carried out, by local bureaucrats or stewards if none were around. Once it was established that the account was in the right hands, we would unlock, but first making sure that any local restrictions required were in place on all effected projects (desysopping and potentially blocking being the main ones here). Now, it's just my opinion that stewards are better equipped to deal with these situations. Giving bureaucrats the ability to intervene won't impede our ability to help and take action as needed, and it makes sense to give them the mandate in case they ever need it. -- Ajraddatz (talk) 19:07, 15 October 2016 (UTC)
- My consideration with still having a local desysop occur is a situation like this, perhaps you could offer some insight into about the stewards would handle it (policy-wise). An admin account (which is active on other projects) is locked after someone email the stewards alerting them to it (the account wasn't blocked and it wasn't desysoped) because they are thought to be compromised after they deleted a highly viewed page or blocked someone for no reason (and no explanation). They emailed the stewards and it was established (the same day) that it wasn't a compromised and they wanted to return to editing the other projects all also edit. Would a steward then unlocks the account (it's no longer compromised so that reason doesn't exist anymore)? Callanecc (talk • contribs • logs) 10:12, 15 October 2016 (UTC)
- At that point it would be useful for investigating the implications for the user's global account (i.e. permissions on other projects, etc), but it misses out on resolving the situation with the least possible actions taken. If the account is suspected of being compromised, locking it deals with all the effort of desysopping and blocking in a fraction of the time while keeping the account secure. If the path flows through local processes first, then there is added time spent on wheel warring, trying to contact local users which may or may not be around, etc. So it would be useful in the Committee step 1, but perhaps also as a replacement to the bureaucrat step 1. For other types of emergencies, such as when an admin who has long disliked one user goes ahead and blocks them and starts reverting all their edits, locking isn't needed. But it's a good first step in situations where the account is potentially compromised. -- Ajraddatz (talk) 08:01, 15 October 2016 (UTC)
- I was thinking of adding step to the Committee (as part of step 1 or 3) and crat (between steps 2 & 3) actions to let the stewards know if they suspect the account has been compromised, how does that sound? Callanecc (talk • contribs • logs) 07:53, 15 October 2016 (UTC)
Without flyspecking every word of the proposals—and without undue confidence that it's possible, even in theory, to anticipate every possible unusual circumstance that might come along—I have two comments at this time, one purely wording-related and one substantive:
- In differentiating between interim and longer-term removal of permissions, I am hesitant to endorse use of the phrase "permanent removal of permissions." I understand that this means "permanent unless overturned," as opposed to "explicitly interim." Even so, we know from experience that it creates confusion to describe something as a "permanent removal of permissions" when that same removal is subject to the proviso that "If requested by the permission holder, or if at least three arbitrators support it, arbitration proceedings will be opened to examine the removal of permissions." So I would suggest replacing the word permanent, although I must admit that having thought about this for a week I haven't come up with a good suggestion for what to replace it with.
- My second comment arises from the same provision that following a "permanent" removal, the administrator may as a matter of right may open an arbitration proceeding to examine the removal of permissions." If this means that on request a full arbitration case will be opened, then an exception is required for extraordinary circumstances—especially if what is meant is automatically a full on-wiki arbitration case. There have been a couple of instances I can think of which it was, or would have been, a serious mistake to open such a case following an emergency desysopping. One of these is Archtransit, and I'm not going to mention the others here, but I'll be glad to e-mail the Committee if requested to. Our wiki values weigh in favor of transparency and on-wiki discussion, both in fairness to the (ex-)administrator and to the community as a whole, but there can be countervailing considerations as well. Newyorkbrad (talk) 20:00, 17 October 2016 (UTC)
- That was our difficulty too. Needs to be a word analogous to "indefinite" for a block. Regarding reviewing the decision to desysop I've now linked arbitration proceedings which includes both full cases and private hearings as required. Callanecc (talk • contribs • logs) 06:27, 18 October 2016 (UTC)
- I'm looking through the thesaurus and can't find anything other than permanent and indefinite. Indefinite already has a special meaning here and seems to apply, plus later you go on to explain how the bit can be regained. Either is fine to me, but those do seem to be your choices. Dennis Brown - 2¢ 10:18, 18 October 2016 (UTC)
- Maybe 'Full' or 'Complete' removal? The substantive difference is (or should be) 'removal without necessarily requiring further review' versus 'removal with the possibility of requesting further review'. Immediate (because it is obvious and needs doing quickly) vs relatively quickly (because it is not so obvious and not so urgent). The whole text could do with some simplification. There are too many caveats and maybes and 'almost always'. It should be simple, direct and decisive, so no-one can get confused. Carcharoth (talk) 14:51, 18 October 2016 (UTC)
- Would it be worthwhile for Carcharoth to try his hand at a simplified version. As a two-time Committee alumnus he should have a good handle on the relevant considerations. (I won't offer to do it, as simplifying things is not necessary my forte, either by reputation or by reality.) Newyorkbrad (talk) 16:58, 18 October 2016 (UTC)
- Sadly, I fear not (and like you I don't intend to offer). Though I thank you for the kind suggestion. There is enough feedback here for the current arbs to work with. Carcharoth (talk) 18:43, 18 October 2016 (UTC)
- Would it be worthwhile for Carcharoth to try his hand at a simplified version. As a two-time Committee alumnus he should have a good handle on the relevant considerations. (I won't offer to do it, as simplifying things is not necessary my forte, either by reputation or by reality.) Newyorkbrad (talk) 16:58, 18 October 2016 (UTC)
- That was our difficulty too. Needs to be a word analogous to "indefinite" for a block. Regarding reviewing the decision to desysop I've now linked arbitration proceedings which includes both full cases and private hearings as required. Callanecc (talk • contribs • logs) 06:27, 18 October 2016 (UTC)