Return to the project page "Administrators".
|This is the talk page for discussing improvements to the Administrators page.
|Archives: Index, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19|
|The project page associated with this talk page is an official policy on Wikipedia. Policies have wide acceptance among editors and are considered a standard for all users to follow. Please review policy editing recommendations before making any substantive change to this page. Always remember to keep cool when editing, and don't panic.|
|Wikipedia Help Project||(Rated NA-class, Top-importance)|
|NOTE: This talk page is not the place to post questions for administrators.|
|NOTE: This talk page is not the place to request yourself as an administrator. For Requests for Adminship, see WP:RfA.|
|This page has been cited as a source by a notable professional or academic publication:|
Stvilia, B. et al. Information Quality Discussions in Wikipedia. University of Illinois U-C.
Based on the recent arbcom motion, proposing a change, as below:
Discretion on resysopping temporarily desysopped administrators is left to bureaucrats, who will consider whether the rightful owner has been correctly identified, and their view on the incident and the management and security (including likely future security) of the account.
Subject to Wikipedia:Arbitration Committee/Procedures#Return of permissions, discretion on resysopping temporarily desysopped administrators is left to bureaucrats, who will consider whether the rightful owner has been correctly identified, and their view on the incident and the management and security (including likely future security) of the account.
Thanks, Lourdes 08:07, 4 May 2019 (UTC)
discretion on resysopping temporarily desysopped administrators is left to bureaucratsis no longer true based on my read of the procedure amendment. The bureaucrats do not have discretion in regards to compromised accounts; the committee does. I do not think your amendment goes far-enough. --Izno (talk) 12:32, 4 May 2019 (UTC)
- It would be good to clear up this discrepancy, but this wording doesn't make sense: how are crats subject to an ArbCom procedure that doesn't even mention them? My understanding of the current practice (putting aside what's written in WP:ABCXYZ for the moment) is that, because ArbCom is responsible for emergency desysops under WP:LEVEL1, it's also ArbCom's job to decide when/if to resysop. I think the crats' perspective is that an emergency desysop is a "cloud" and they don't want to resysop until they hear from us that it's cleared. It would be good to hear from some of them though. – Joe (talk) 10:29, 5 May 2019 (UTC)
- I think the major point of contention is that the committee does not really have the authority to grant administrative permissions- the final job to decide when/if to resysop really lies with bureaucrats. The committee should instead be recommending the permissions be restored (following their investigation of the breach and receiving satisfactory assurances, etc.), or, in the case of gross negligence of account security practices, passing an explicit motion permanently revoking the administrative privileges of the user involved (which would be binding on bureaucrats and look less like a backdoor desysyop). –xenotalk 11:06, 6 May 2019 (UTC)
- I think the policy is clear enough, "the revocation of privileges may be permanent." Bureaucrats are only given authority when the revocation is "temporary". Which leaves "permanent" to Arbcom, where it's always been, until there is a new RfA, which throws it back to the community. Alanscottwalker (talk) 11:22, 6 May 2019 (UTC)
- I think both of the points that Joe Roe and xeno made are good. I think the top-level point in all this, which we all basically agree on save for the text, is that bureaucrats are really not the ones making determinations of account security. They push the buttons based on Arbcom's direction. I don't mean that to be derogatory: separating the functions of determining whose admin bits should be rescinded and the actual removal of the bits is good practice. We should update our policies to reflect that.
- The way I've generally read the LEVELn procedures (as a non-arb and non-crat) is that Arbcom has the authority to suspend an administrator's userright (which can only be granted by the community) for certain named breaches related to security and otherwise, indefinitely if they see fit, with much the same definition of "indefinite" as administrators can block an account indefinitely. That is: never permanently, but until the cause is rectified. And so I find the "will not be resysopped automatically" language in the Arbcom procedures problematic. It's not wrong, it just feels like an overstep of authority stated this way.
- If in the course of investigating the LEVELn situation Arbcom finds that the administrator was not following WP:SECUREADMIN or will not update their security to comply, then the administrator is in violation of the community admins policy, and Arbcom should pursue desysopping for cause under that policy. That is, there should be a formal description of the events and a motion that so-and-so-admin is desysopped for cause, or a full case if the circumstances fit. I personally think it's pretty important to make the distinction between "desysopping temporarily to protect Wikipedia" and "desysopping permanently for not following the policy". One is under a cloud and one is not. Also, doing it this way assures transparency, not that I think the Committee has necessarily been opaque on this save for privacy issues.
- In short, what xeno said, but recognizing that it's Arbcom making security determinations, not the bureaucrats. Ivanvector (Talk/Edits) 15:37, 6 May 2019 (UTC)