212.186.133.83 (talk) |
|||
Line 161: | Line 161: | ||
*I think it is time to separate the "status" and the "access to tools" components, just as we separate blocks and bans. Currently we only allow ArbCom to remove the community "status" of administration, but as noted there are other ways that access to tools can be (temporarily) removed (Including "self-request", "inactivity") and including "emergency" in the temporary access list really shouldn't be that big of a deal due to the number of people that can do it being extremely small, with high trust, and under high scrutiny. If a blocked admin is using the BEANsy part of the tool kit that work when blocked disruptively, having a steward, Jimmy, or even a 'crat put an emergency stop to it pending a committee review should be NOBIGDEAL. — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 15:14, 8 December 2018 (UTC) |
*I think it is time to separate the "status" and the "access to tools" components, just as we separate blocks and bans. Currently we only allow ArbCom to remove the community "status" of administration, but as noted there are other ways that access to tools can be (temporarily) removed (Including "self-request", "inactivity") and including "emergency" in the temporary access list really shouldn't be that big of a deal due to the number of people that can do it being extremely small, with high trust, and under high scrutiny. If a blocked admin is using the BEANsy part of the tool kit that work when blocked disruptively, having a steward, Jimmy, or even a 'crat put an emergency stop to it pending a committee review should be NOBIGDEAL. — [[User:Xaosflux|<span style="color:#FF9933; font-weight:bold; font-family:monotype;">xaosflux</span>]] <sup>[[User talk:Xaosflux|<span style="color:#009933;">Talk</span>]]</sup> 15:14, 8 December 2018 (UTC) |
||
*:Agree - IMO a sensible policy is that "In an emergency, anyone who has the rights to remove sysop permissions can do so." but only Arbcom can actually finalize any removal.; simply losing the permissions temporarily should not be a massive deal. [[User:Galobtter|Galobtter]] ([[User talk:Galobtter|pingó mió]]) 15:22, 8 December 2018 (UTC) |
*:Agree - IMO a sensible policy is that "In an emergency, anyone who has the rights to remove sysop permissions can do so." but only Arbcom can actually finalize any removal.; simply losing the permissions temporarily should not be a massive deal. [[User:Galobtter|Galobtter]] ([[User talk:Galobtter|pingó mió]]) 15:22, 8 December 2018 (UTC) |
||
* '''Oppose''' This is similar to the question of [[reserve power]], how much power a monarch or state president should hold in parliamentary systems. In the US, there's the [[executive order]], and in the UK, the Queen should also at least theoretically be able to dismiss disobedient ministers, if not the entire government. Consequently, there should be some executive power left for Jimbo, if you regard him as some sort of Wiki-president or monarch. Apart from that, I agree with {{user|Andrew Davidson}}. --[[Special:Contributions/212.186.133.83|212.186.133.83]] ([[User talk:212.186.133.83|talk]]) 15:25, 8 December 2018 (UTC) |
Revision as of 15:25, 8 December 2018
Wikipedia Help NA‑class Top‑importance | ||||||||||
|
Index |
This page has archives. Sections older than 30 days may be automatically archived by Lowercase sigmabot III. |
This page has archives. Sections older than 30 days may be automatically archived by Lowercase sigmabot III. |
Clarifying "controversial circumstances"
- "While it could be said that [an editor] resigned in "controversial circumstances" (the only relevant criteria mentioned at Wikipedia:Administrators#After voluntary removal), their administrative actions were not called into question at the time and accordingly, their administrative status did not seem in jeopardy i.e. they were not "evading scrutiny of their actions that could have led to sanctions" (the criteria in place at Wikipedia:Bureaucrat#Restoration of permissions). Please consider this as your semi-regular reminder that these two pages are somewhat out of sync and that bureaucrats should generally defer to policy pages (Wikipedia:Administrators) over information pages (Wikipedia:Bureaucrats); accordingly, the guidance at the policy page should be clarified to reflect actual practice as it is presently rather vague." (redaction to make it clear this is not about any specific user).
I have also noticed that there is a theoretical conflict between this section and the lengthy inactivity section regarding users who voluntarily step-down but subsequently have an extended period of inactivity.
Accordingly I propose to change the wording on this page from:
To:
Notes:
- The first bullet uses the wording at Wikipedia:Bureaucrats which is the defacto standard the crats are currently using, so updating the policy to match actual practice.
- The second bullet defers to the inactivity standard and makes it clear that an admin who has a period of three or more years with zero edits after after the bit was removed (for any reason) will need to pass a new RFA. I don't believe this is a change from the current policy, and it certainly matches my understanding of the intent of the inactivity policy (and also matches the procedure at Wikipedia:Bureaucrats. The wording chosen means that should the standard for inactivity change then we don't need to make any changes to this section.
- The third bullet is unchanged.
I will advertise this proposal at WP:AN and WP:BN. Thryduulf (talk) 19:28, 29 October 2018 (UTC)
Comments on clarification proposal
- I'm fairly certain this is following on Kudpung's recent request which was piled on a bit by users with the opinion that Kudpung's earlier resignation ought to have been considered avoiding scrutiny. These are supposed to be simple requests (either you meet the criteria to get the mop back on request or you don't) but I fear that the first bullet of the proposal opens up the process into a sort of back-door community desysopping, if enough people show up to convince the 'crats that the resignation was really under a cloud. I'm in favour of making this sort of clarification, but I think it needs a bit more work. There should be specific indicators that a resignation is avoiding scrutiny, rather than just a "feeling" that this was intended. Ivanvector (Talk/Edits) 19:39, 29 October 2018 (UTC)
- No, I know it's not about any one user, I'm just referring to that discussion as an example of what we should be aiming to avoid. BN shouldn't be a venue for debating the merits of a resysop request, that's what a reconfirmation RFA is for. Ivanvector (Talk/Edits) 20:00, 29 October 2018 (UTC)
- @Ivanvector: I think this proposal is on the same page as you, and you're perhaps misinterpreting it. The format of a bulleted list aside, the core of the proposal appears to be to convert
"not considered to be in controversial circumstances"
to"not evading, or attempting to evade, scrutiny"
. The other bullet points are just secondary procedural aspects. I think the more specific clarification of the wording would assist in our goal to prevent BN from turning into a drama board any time an admin associated with any type of 'controversy' tries to return. This has happened at least two times in recent memory, in which an admin was within their rights to have the tools back but was viciously mobbed by hostile users when making the request. It's not right, and the lack of clear written guidelines was an issue both times. I think this clarification would reduce the vagueness and uncertainty of written guidelines that currently allows users to attempt to desysop by retroactively establishing "controversy" at BN. Swarm talk 21:22, 29 October 2018 (UTC)
- Support the wording change. This should resolve the inconsistency between the two pages and codify current practice. 28bytes (talk) 19:42, 29 October 2018 (UTC)
- I don't think the proposed text is sufficiently clear. It changes the policy from "in controversial circumstances" to "evading scrutiny that could lead to sanctions", which is still incredibly broad. The de facto practice is that crats will resysop unless the requestee would have been desysopped had they retained the tools. So a better wording would be "when voluntarily requesting removal they were not evading, or attempting to evade, an already-initiated desysop process that would have likely resulted in the removal of their sysop access". Or something that accurately reflects the reality of the situation. -- Ajraddatz (talk) 19:54, 29 October 2018 (UTC)
- Your proposed wording would not cover a situation where an ANI thread was unambiguously leading to an arbitration request but where the admin in question resigned the bit before the request was filed. At present that situation would clearly prevent automatic resysopping. Thryduulf (talk) 20:00, 29 October 2018 (UTC)
- At present, the only path to a desysop for misconduct is through the arbitration committee, and so a determination that a resignation was "under a cloud" should also only be made definitively by the arbitration committee, if we're tying that to a condition under which an admin can be prevented from getting the tools back. I'm just thinking out loud here, I don't have a definite solution to suggest at the moment. Ivanvector (Talk/Edits) 20:07, 29 October 2018 (UTC)
- If an ANI discussion should be included, then my wording could be changed to something like "... an already-initiated process that would have likely resulted in the removal of their sysop access". That would be more clear than "sanctions" anyway. But I would generally agree with Ivanvector - since ArbCom is the only group that can desysop an admin outside of emergencies, it would make sense that they make the cloud determination. I'm not sure what the wording of that would look like, since I stay as far away from ArbCom as possible for the most part. -- Ajraddatz (talk) 20:16, 29 October 2018 (UTC)
- Ajraddatz: The current committee was nearly unanimous in stating their reticence to step in the last time they were queried about resolving cloud concerns, handing the responsibility back to the community/bureaucrats: https://en.wikipedia.org/w/index.php?oldid=851052847#Clarification_request:_Return_of_access_levels –xenotalk 06:11, 30 October 2018 (UTC)
- There are some cases where administrators have resigned without an ArbCom case, but where it should be considered to be "under a cloud": plagiarism/copyvios, socking, wheel warring, and other "serious" things like that There are examples on Wikipedia:Former administrators/reason/resigned where bureaucrats have declined to resysop under those circumstances. --Rschen7754 02:01, 30 October 2018 (UTC)
- I think it's important to note that a failure to resysop is not the same as a desysop, rather it is saying that there is sufficient concern that the community should decide rather than the bureaucrats. The result may not be much different for the end user, but there's a clear process difference between "You're clean, welcome back" and "Eh, this is muddled enough that the wider community should have a say." The community decides whether someone should have the bit, Bureaucrats interpret clouds and consensus about that decision. ArbCom can remove if they see fit, but we have crats for a job so let's let them do it. ~ Amory (u • t • c) 12:38, 30 October 2018 (UTC)
- The wording of this is a bit wider than intended, I think, because "sanctions" could include blocks and things like topic bans. --Rschen7754 00:38, 30 October 2018 (UTC)
- I'm uneasy about limiting the evading scrutiny condition to scenarios with filed cases that would have "likely resulted in the removal of their sysop access", because this requires bureaucrats to make a prediction based on a partially completed case. Resigning to forestall a case from being filed is also a scenario that I think ought to be at least evaluated with respect to evading scrutiny. isaacl (talk) 06:49, 30 October 2018 (UTC)
- Thanks for the context and further discussion everyone - this all makes sense to me. Maybe part of the problem is that we're trying to condense what's actually a pretty complex series of situations into a single sentence? Maybe it would be better to have a small paragraph describing what could prevent resysop instead, if that could provide us with more clarity. Also interesting that ArbCom is hands off on this topic... you'd think they would want the work now that they only deal with a few cases per year. -- Ajraddatz (talk) 23:53, 31 October 2018 (UTC)
- Moral support. Good idea to make this consistent. However, would suggest using this opportunity to make it a bit clearer what level of sanctions are being referred to. Presumably, the chance of at most a troutslap or even a warning is not sufficient to be called "controversial circumstances". I have no problem in leaving bureaucrats some leeway, but would recommend somewhat tighter wording, like "significant sanctions, such as potential desysopping" to avoid this being interpreted as unintentional tightening of the requirements. That being said, Ajraddatz' version above to me seems like *too* stringent, but opinions may vary. Martinp (talk) 23:13, 29 October 2018 (UTC)
- Support This essentially keeps the status quo, and makes the wording consistent. If there is reason to change the standard, this should be discussed separately, for there is unlikely to be consensus there. DGG ( talk ) 18:02, 30 October 2018 (UTC)v
- Support idea, oppose specific wording would suggest something "were not currently under scrutiny for misuse of their admin tools or other sanctionable behavior" or something along those lines. The new phrasing does not capture the problem accurately; "avoid scrutiny" implies intent, which we cannot know. What we want to make clear is if an admin is currently under scrutiny for bad behavior, they can't resign to just get the tools back at a later date when the heat dies down. Basically, if there is a legitimate complaint which could reasonably lead to an admin being sanctioned (either desysopped or admonished) and they resign the tools during the discussion of that complaint, they need to re-apply for RFA. --Jayron32 18:16, 30 October 2018 (UTC)
- Support. Point 2 is an appropriate addition to align with the "3-years of complete inactivity rule". Point 1, while imperfect as discussed above, is still clearer than the current text in my opinion. I should note that setting a simple rule and then trusting bureaucrats' judgement to apply them is the only way we can prevent "mob-desysop by backdoor". Deryck C. 21:21, 10 November 2018 (UTC)
- If there are no other comments in the next few days I think an uninvolved admin can close this - there hasn't been enough engagement for me to feel comfortable closing it myself even given the relative lack of expressed opposition. Thryduulf (talk) 00:57, 5 December 2018 (UTC)
WP:VPPOL discussion on WP:INACTIVITY
See this discussion on changing WP:INACTIVITY. Galobtter (pingó mió) 19:08, 22 November 2018 (UTC)
Clarification of policy regarding restoration of adminship
I have refactored this section, combining several paragraphs that were redundant. My intent was to leave the actual policy unchanged, while expressing it more clearly. The Uninvited Co., Inc. 19:52, 28 November 2018 (UTC)
- @UninvitedCompany: I have put the 1+2 bit back in. They were two separate proposals and don't overlap (completely). There will be former administrators where one applies but not the other. -- KTC (talk) 21:03, 28 November 2018 (UTC)
- I think the new working on the "5 year rule" more closely matches the RfC, the "subsequently" part seemed out of place. I think "Over five years since administrative tools were last used" (at the time of the restoration request) seems more in line with the closing. — xaosflux Talk 22:41, 28 November 2018 (UTC)
"Administrators may be removed by Jimbo Wales, by stewards, or by a ruling of the Arbitration Committee."
As far as I know, stewards only possess the technical ability to remove administrator rights, but they cannot revoke an administrator's entitlement to the toolset. In a compromise situation, they are more likely to globally lock the account. And I don't think Jimbo Wales has exercised his right to revoke administrators in quite a long time. Probably this can be shortened,
Thoughts? –xenotalk 18:27, 6 December 2018 (UTC)
- To make it clear that the change is not meant to constrain stewards acting in emergency situations, I have adapted some text from the existing Wikipedia:Global rights policy and added it to the paragraph to address concerns by @Hut 8.5 and Rschen7754: –xenotalk 13:26, 7 December 2018 (UTC)
- Support - as you said I don't think any current local policy supports stewards formally desysopping anyone, and the global policy prohibits stewards doing anything in place of a local function as far as I know so they also wouldn't remove the bit if a 'crat would do it otherwise, on enwiki anyway. And although he's technically able, if Jimbo were to unilaterally desysop someone it would be followed by extreme drama. Ivanvector (Talk/Edits) 18:39, 6 December 2018 (UTC)
- Support in principle. Two questions: surely there is a policy on meta somewhere (I'll look for it later) governing when Stewards may remove the admin bit? Second; the history of Jimbo using his judgement to sanction admins is complex, AFAIK, but does this revision amount to the community removing the policy basis of his ability to de-sysop someone? I'm fine with doing that, FTR, since I think it's too much authority for any one person; indeed I'd be fine with depracating the founder flag, but we have neither the ability nor the authority for that. Vanamonde (talk) 18:45, 6 December 2018 (UTC)
- What if instead of just changing the wording, we actually improved something and started an RfC for community desysopping? Natureium (talk) 18:48, 6 December 2018 (UTC)
- Given the history of proposals to remove administrative privileges based on a community discussion, it will be some time before agreement can be reached on a procedure. I think the current wording may as well be brought into line with practice first. isaacl (talk) 18:52, 6 December 2018 (UTC)
- That's a bit of a tougher nut to crack, Natureium. Once upon a time, I worked on a draft for community de-adminship but was talked off the ledge by Risker. –xenotalk 18:59, 6 December 2018 (UTC)
- According to the global rights policy here and the steward policies on Meta, stewards have the authority to remove permissions in cases of emergency. In practice we rarely do this, since locking is the preferred action to prevent further damage in most emergency situations. But there are some situations where desysops are still done on our initiative, such as when an admin on a small wiki is being abusive but likely isn't compromised. As I read it, the policy separates the authority to decide to desysop someone and the technical ability to desysop them. Stewards do have both, albiet in a restricted set of situations. I have no objections with clarifying the policy to reflect that. -- Ajraddatz (talk) 18:55, 6 December 2018 (UTC)
- (edit conflict) Wikipedia:Global_rights_policy#Stewards already allows for stewards to act "In emergency situations where local users are unable or unavailable" and I don't see any reason to remove this. The last arbcom case regarding desysoping activity seems to show that there is also at least a modicum of support for 'crats to act in "an emergency" however it would be along the same lines as stewards (basically this is a 'suspension of tool access' not necessarily a community "status change" since "being an admin" is treated as much more than just someone with some extra buttons). — xaosflux Talk 19:01, 6 December 2018 (UTC)
- Oppose Admins are already too powerful because our checks and balances are inadequate – no term limits, vast powers and slack terms of reference such as WP:IAR which let them do just about anything. Much of this accretion of power has come about because of Jimbo's "no big deal" philosophy and, as he's the source of this, he should retain oversight powers. Arbcom is not enough because its regular elections make it politically weak and so we now see admins flouting Arbcom sanctions and threatening its members. And notice that we had several admin accounts subverted recently and so need to retain multiple layers of security against such infiltration. Andrew D. (talk) 19:05, 6 December 2018 (UTC)
- He's not talking about changing the actual policy, just the wording. Natureium (talk) 19:17, 6 December 2018 (UTC)
- Changing the wording is changing the actual policy. As a fresh example of the need for independent oversight, see the GiantSnowman case at ANI which "reeks of the admin corps protecting itself". In the discussion here, we see that most of the support is from admins, acting in a self-interested way to reduce independent oversight of their actions. Quis custodiet ipsos custodes?. Andrew D. (talk) 09:20, 7 December 2018 (UTC)
- He's not talking about changing the actual policy, just the wording. Natureium (talk) 19:17, 6 December 2018 (UTC)
- Support - Stewards will only ever lock a compromised English Wikipedia admin account, and will not remove rights unless instructed (per a local consensus). Echo Xaosflux's concern ref stewards acting in 'emergency situations', but this has been clarified by Xeno above - TNT 💖 19:13, 6 December 2018 (UTC)
- @Ajraddatz and There'sNoTime: Perhaps I'm misreading something, but you seem to be saying different things here. Do stewards have the authority (not the technical ability) to remove the sysop flag in cases of admin abuse, without there being local consensus that abuse has, in fact, occurred? I'm not seeing that in the policy...Vanamonde (talk) 20:27, 6 December 2018 (UTC)
- @Vanamonde93: In my statement above, I refer only to "
English Wikipedia admin account[s]
" - this is a large project with its own policies and many active bureaucrats, so there's no reason for a steward to desysop here On smaller projects, where there are no bureaucrats for example, we do perform desysops. As for cases of admin abuse without local consensus, I believe we would preferably wait for a local discussion (per policy) but there are of course exceptional circumstances. I defer to Ajraddatz on any further specifics - TNT 💖 20:44, 6 December 2018 (UTC)- There are some situations in which stewards would desysop rather than lock, even on enwiki. A perfect example is the recent Fred Bauder situation - if he had unblocked himself and then started blocking other people, then a steward could have responded with an emergency desysop. As Xaosflux says, this would only remove their technical access, not the status of adminship, and the desysopping steward would need to inform ArbCom of the removal so they could follow up. My own comment above was perhaps a bit ambiguous: I was trying to draw a distinction between bureaucrats, who cannot remove the technical access on their own initiative, with stewards, who can remove the technical access without being told to but only under a certain type of situation. In the past we have also removed the status of adminship from some people, but that's only done on small wikis without enough of a community to properly oversee the admin's activity and wouldn't be done here. Is that a clearer description? Basically I'm fine with the change, so long as the role of stewards in emergencies is not curtailed. -- Ajraddatz (talk) 21:16, 6 December 2018 (UTC)
- @There'sNoTime: There are several instances in recent years where stewards have desysopped on wikis with bureaucrats: [1], [2], [3], [4]. If you go through stewards-l it has never been a question of whether stewards had the ability to do this in emergencies, on any wiki, the question has always been whether it was overstepping in the particular situation. --Rschen7754 06:43, 7 December 2018 (UTC)
- @Rschen7754: If these are the good examples of recent years that you've, then this change is quite needed on enwiki.
- Your first link was a mere fulfilling of request made on authority of Arbitration Committee. This was in 2012 when enwiki bureaucrats were not given the technical ability to desysop. If it were today it would be handled here. So, this example is not applicable anymore on enwiki.
- The second link is a desysop on a test project where even yourself had to admit: there was
"no real community or RFA process."
Besides being mere test project it's completely opposite of what enwiki is, a live, vibrant gargantuan community' This one too is not applicable, we're live content project not test - Your third link is to a project which is shy of being "mid-size" wiki and where the bureaucrats lack technical power to remove adminstrator(custodian) group and also has no Arbitration Committee to deal with the user. Another inapplicable example, local bureaucrat here have the technical ability and we've Arbitration Committee with the social authority.
- The last link is to another project where bureaucrats lack the technical power to remove administrator group and has no Arbitration Committee. Ditto. Inapplicable.
- So your comment
"There are several instances in recent years where stewards have desysopped on wikis with bureaucrats:"
left out important context. All the desysops were to projects quite different from enwiki and where the stewards are needed by technical necessity. They're just more reasons to support this change to reflect reality. –Ammarpad (talk) 21:51, 7 December 2018 (UTC)- No. Most other wikis handle desysops through community voting, so they have a way to handle the "social authority". An ArbCom is not the only way for a wiki to have admins removed by stewards. I will also point to eswiki, where a steward chose not to do an emergency desysop, but where it is clearly implied that the authority is there. I will also point out that technical ability is not a large factor here: very few wikis allow for desysop by bureaucrat (and the sizes of the wikis vary greatly, see m:Bureaucrat for a full list), and also stewards can use CU/OS on all wikis, even those with elected CU/OS, in emergencies (or if those users have been inactive for a very long time). --Rschen7754 01:44, 8 December 2018 (UTC)
- I'm not sure how relatively ancient examples from other wikis have any relevance here, where we are seeking to clarify local policy. –xenotalk 03:08, 8 December 2018 (UTC)
- One of the reasons people want to write stewards out of the policy is because stewards supposedly never do emergency desysops. Which is news to me. --Rschen7754 03:10, 8 December 2018 (UTC)
- As I've said, the intent is to clarify that only the Arbitration Committee has the authority to remove an administrator from the ranks (i.e. a formal demotion). Stewards can certainly remove permissions (a technical ability) but they cannot actually come out and say "X is desysopped and may only regain permissions via RfA" the way the committee can. –xenotalk 03:39, 8 December 2018 (UTC)
- One of the reasons people want to write stewards out of the policy is because stewards supposedly never do emergency desysops. Which is news to me. --Rschen7754 03:10, 8 December 2018 (UTC)
- I'm not sure how relatively ancient examples from other wikis have any relevance here, where we are seeking to clarify local policy. –xenotalk 03:08, 8 December 2018 (UTC)
- No. Most other wikis handle desysops through community voting, so they have a way to handle the "social authority". An ArbCom is not the only way for a wiki to have admins removed by stewards. I will also point to eswiki, where a steward chose not to do an emergency desysop, but where it is clearly implied that the authority is there. I will also point out that technical ability is not a large factor here: very few wikis allow for desysop by bureaucrat (and the sizes of the wikis vary greatly, see m:Bureaucrat for a full list), and also stewards can use CU/OS on all wikis, even those with elected CU/OS, in emergencies (or if those users have been inactive for a very long time). --Rschen7754 01:44, 8 December 2018 (UTC)
- @Rschen7754: If these are the good examples of recent years that you've, then this change is quite needed on enwiki.
- @Vanamonde93: In my statement above, I refer only to "
- @Ajraddatz and There'sNoTime: Perhaps I'm misreading something, but you seem to be saying different things here. Do stewards have the authority (not the technical ability) to remove the sysop flag in cases of admin abuse, without there being local consensus that abuse has, in fact, occurred? I'm not seeing that in the policy...Vanamonde (talk) 20:27, 6 December 2018 (UTC)
|
- Partial Support with a question: has Jimbo ever had his ability to remove adminship taken away? It may be one of those ephemeral "We don't think he ever would do it, but we've never said he can't" issues, but is it something we should be silent on if he still has the right to exercise it, even if he never does? Depending on what the answer is to that, I could fully support this: I agree that removing the stewards from the wording is useful: They have the technical ability to, but not the right to, remove adminship, and we don't need to mention them here. What I am wondering is if Jimbo still has the right or not? --Jayron32 19:27, 6 December 2018 (UTC)
- @Jayron32: yes Jimbo still has "edit all user rights" access here on the English Wikipedia. — xaosflux Talk 19:29, 6 December 2018 (UTC)
- (ec) Jimbo's local user group, founder, gives him the ability to add and remove all user rights. He used to have that ability globally, but it was removed following an RfC at Meta. So yes, he does have the technical ability to add/remove adminship, but I expect in practice there would not be community support for him doing so. -- Ajraddatz (talk) 19:30, 6 December 2018 (UTC)
- Yes, see Special:listGroupRights. I'm not proposing to remove his technical ability, fwiw. –xenotalk 19:33, 6 December 2018 (UTC)
- See also Wikipedia:Role_of_Jimmy_Wales for other "monarchy" type access Jimbo still has here (such as dissolve the arbitration committee). — xaosflux Talk 19:33, 6 December 2018 (UTC)
- What I really want to know, then, is if he is functionally a steward in this regard, or does this founder group also come with community consensus to act upon such a right? It's not a major point of contention, I do broadly agree that functionally we've been working under the "Only ArbCom can desysop" for as long as I can remember, but I don't want to put something into policy now that isn't based on actuality. --Jayron32 19:35, 6 December 2018 (UTC)
- In my mind, Jimmy remains as the last line of defense against a hypothetical rouge committee, but this could just be a flight of fancy. –xenotalk 19:38, 6 December 2018 (UTC)
- @Xeno, even in that case I can't imagine Jimmy either intervening or being allowed to intervene; for him to unilaterally declare that he didn't trust the Wikipedia community and was taking direct control would be a PR disaster from which Wikipedia would probably never recover. In a hypothetical situation where Arbcom was taking actions that clearly went against policy and consensus and in which Wikipedia's usual mechanisms couldn't solve the problems (arbs can be blocked just as much as anyone else if they're violating policy, so a rogue arbcom would normally just mean fifteen blocked arbs and a fresh election), I assume the WMF would temporarily impose direct rule from SF with Trust & Safety and Community Engagement running things until fresh elections could be held. I can't imagine any circumstances in which this could arise on en-wiki (although I could see it on some of the smaller wikis that only have a couple of admins). ‑ Iridescent 18:36, 7 December 2018 (UTC)
- WMF has ordered that desysops take place before (examples: 1, 2) but I feel that on this wiki they would make their case to ArbCom and let them do the desysop. They have been fairly conservative about where they intervene, though (there are some cases where I feel they should have, but they did not). I have seen a lot of removals on behalf of WMF for technical reasons though (didn't re-sign the new private data policy, for example). --Rschen7754 04:37, 8 December 2018 (UTC)
- @Xeno, even in that case I can't imagine Jimmy either intervening or being allowed to intervene; for him to unilaterally declare that he didn't trust the Wikipedia community and was taking direct control would be a PR disaster from which Wikipedia would probably never recover. In a hypothetical situation where Arbcom was taking actions that clearly went against policy and consensus and in which Wikipedia's usual mechanisms couldn't solve the problems (arbs can be blocked just as much as anyone else if they're violating policy, so a rogue arbcom would normally just mean fifteen blocked arbs and a fresh election), I assume the WMF would temporarily impose direct rule from SF with Trust & Safety and Community Engagement running things until fresh elections could be held. I can't imagine any circumstances in which this could arise on en-wiki (although I could see it on some of the smaller wikis that only have a couple of admins). ‑ Iridescent 18:36, 7 December 2018 (UTC)
- In my mind, Jimmy remains as the last line of defense against a hypothetical rouge committee, but this could just be a flight of fancy. –xenotalk 19:38, 6 December 2018 (UTC)
- What I really want to know, then, is if he is functionally a steward in this regard, or does this founder group also come with community consensus to act upon such a right? It's not a major point of contention, I do broadly agree that functionally we've been working under the "Only ArbCom can desysop" for as long as I can remember, but I don't want to put something into policy now that isn't based on actuality. --Jayron32 19:35, 6 December 2018 (UTC)
- support The current wording, while technically accurate, does not reflect the on-the-ground reality. We should make policies as concise and reflective of actual practice as possible and this change does that. Beeblebrox (talk) 20:02, 6 December 2018 (UTC)
- Support as these pages should reflect reality. We should be removing reference to WP:Appeals to Jimbo wherever they occur; while he has theoretical rights, in practice he has no powers to use advanced permissions (last time he tried to block someone he was forced to make a public statement that he'd never block anyone again, and there's no reason to think the reaction would be any different if he attempted to overrule consensus in any other area), and it just confuses good-faith new and newish editors who assume that our policy pages are correct, try to appeal to him, and end up being jumped on by the rabble of fruitcakes, loons and racists who infest his talk page. ‑ Iridescent 20:31, 6 December 2018 (UTC)
- Support. Given the controversy the last time it happened (in 2008), it doesn't seem like Jimmy is supposed to be removing adminship in the course of normal operations (in other words, when we're following rules and policies.) He retains the technical ability to do so in an emergency, which would be him invoking WP:IAR, but realistically any situation where he did so would be followed by an ArbCom case to decide whether it "sticks", which means that they're the ones with the official say. The same is even more true for stewards. If some sort of wiki-constitutional-crisis ever does emerge - eg. if Jimbo flatly refused to abide by the ArbCom's conclusions - this page might require updating, although that would be the least of our concerns. But I think that sort of hypothetical conflict is outside the scope of our policy; current practice is 100% that if you want a "by the rules" desysoping, your sole resort is to go to Arbcom, and policy should make this clear. --Aquillion (talk) 21:00, 6 December 2018 (UTC)
Opposestewards can revoke someone's "entitlement to the toolset", at least temporarily. If your account is compromised or you go on some Robdurbar-like vandal spree then they can desysop you and you have no particular entitlement to get the tools back. Jimbo could theoretically do the same thing. I think this wording is likely to be interpreted as meaning that stewards can't do emergency desysops without getting the approval of ArbCom, which isn't a good policy to have. Hut 8.5 21:54, 6 December 2018 (UTC)- That would remove their technical access to the toolset while they remained entitled to the same unless it was subsequently revoked by the committee. I think I will add the global rights policy ("emergency") aspect now, to eliminate this confusion (edit: done in Special:Diff/872388767) . –xenotalk 00:09, 7 December 2018 (UTC)
- The change you've made above has addressed this, so I've stricken the oppose. Hut 8.5 20:00, 7 December 2018 (UTC)
- That would remove their technical access to the toolset while they remained entitled to the same unless it was subsequently revoked by the committee. I think I will add the global rights policy ("emergency") aspect now, to eliminate this confusion (edit: done in Special:Diff/872388767) . –xenotalk 00:09, 7 December 2018 (UTC)
- Oppose stewards retain the ability, both policy-wise and technical, to desysop in emergencies, on all wikis. Doing otherwise is not only dumb, it is dangerous (think wheel warring, adding malicious code to site JS, and a whole host of other things that I should probably not name). BTW, I have no problem with removing Jimbo. --Rschen7754 06:38, 7 December 2018 (UTC)
- Well, except in practice they never do. Policy should reflect existing practice, it does not determine it. Stewards, to my knowledge do not desysop, even in emergencies. What they do is globally lock the account, which disables (but does not remove) the sysop toolset. This change in policy would reflect practice. --Jayron32 12:26, 7 December 2018 (UTC)
- They do. See the links above. (For the record, I was a steward from 2014-2015). A wheel warring account should not be globally locked, because 1) this is a local issue and should not prevent content contributions on other wikis, and 2) global locks are harder to appeal because you cannot login. --Rschen7754 19:12, 7 December 2018 (UTC)
- Wheel warring "behind the curtain" is not a situation I would consider an emergency in which steward should intervene. –xenotalk 19:32, 7 December 2018 (UTC)
- Wheel warring can be grounds for emergency desysop if it is persistent beyond a warning, or if it involves self-unblocks or other extenuating circumstances. --Rschen7754 19:39, 7 December 2018 (UTC)
- I still think that's a matter for the Committee but no need to get hung up on hypotheticals. I've added the bit about stewards being permitted to act in emergencies (reasonable minds can differ about what is an emergency), which I believe addresses your concern. –xenotalk 21:14, 7 December 2018 (UTC)
- Wheel warring can be grounds for emergency desysop if it is persistent beyond a warning, or if it involves self-unblocks or other extenuating circumstances. --Rschen7754 19:39, 7 December 2018 (UTC)
- Wheel warring "behind the curtain" is not a situation I would consider an emergency in which steward should intervene. –xenotalk 19:32, 7 December 2018 (UTC)
- They do. See the links above. (For the record, I was a steward from 2014-2015). A wheel warring account should not be globally locked, because 1) this is a local issue and should not prevent content contributions on other wikis, and 2) global locks are harder to appeal because you cannot login. --Rschen7754 19:12, 7 December 2018 (UTC)
- Rschen7754: the intent here is to clarify that while stewards can remove, technically, administrator permissions on an emergency basis, they cannot revoke an administrators community-granted role as an administrator (as this procedural authority is held by the Arbitration Committee alone). Note I have already added text adapted from the Wikipedia:Global rights policy to reinforce this fact. –xenotalk 13:35, 7 December 2018 (UTC)
- Well, except in practice they never do. Policy should reflect existing practice, it does not determine it. Stewards, to my knowledge do not desysop, even in emergencies. What they do is globally lock the account, which disables (but does not remove) the sysop toolset. This change in policy would reflect practice. --Jayron32 12:26, 7 December 2018 (UTC)
- Support anything that removes Jimmy from policy as much as possible is a Good Thing®. The addendum is fine and covers what rights stewards have on en.wiki, both under the global rights policy and our local policy and ArbCom procedures. TonyBallioni (talk) 03:42, 8 December 2018 (UTC)
- Support Policies document accepted practice and should fully reflect reality. Stewards only have the authority to desysop on test projects and quasi-communities. On English Wikipedia only the Arbitration Committee has the authority to desysop. The time steward will be needed on enwiki is only for locking. This has been proven both by policy and by actualities. Technical ability is quite different from authority and the former cannot confer the later. –Ammarpad (talk) 05:26, 8 December 2018 (UTC)
- I think it is time to separate the "status" and the "access to tools" components, just as we separate blocks and bans. Currently we only allow ArbCom to remove the community "status" of administration, but as noted there are other ways that access to tools can be (temporarily) removed (Including "self-request", "inactivity") and including "emergency" in the temporary access list really shouldn't be that big of a deal due to the number of people that can do it being extremely small, with high trust, and under high scrutiny. If a blocked admin is using the BEANsy part of the tool kit that work when blocked disruptively, having a steward, Jimmy, or even a 'crat put an emergency stop to it pending a committee review should be NOBIGDEAL. — xaosflux Talk 15:14, 8 December 2018 (UTC)
- Oppose This is similar to the question of reserve power, how much power a monarch or state president should hold in parliamentary systems. In the US, there's the executive order, and in the UK, the Queen should also at least theoretically be able to dismiss disobedient ministers, if not the entire government. Consequently, there should be some executive power left for Jimbo, if you regard him as some sort of Wiki-president or monarch. Apart from that, I agree with Andrew Davidson (talk · contribs). --212.186.133.83 (talk) 15:25, 8 December 2018 (UTC)