Open main menu
Wikipedia Help Project (Rated NA-class, Top-importance)
This page is within the scope of the Wikipedia Help Project, a collaborative effort to improve Wikipedia's help documentation for readers and contributors. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks. To browse help related resources see the Help Menu or Help Directory. Or ask for help on your talk page and a volunteer will visit you there.
 NA  This page does not require a rating on the project's quality scale.
 Top  This page has been rated as Top-importance on the project's importance scale.

Proposed changeEdit

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.

to

  • 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 bureaucrats is 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)
No changes should be made to the text while discussion is still in progress. ——SerialNumber54129 12:49, 4 May 2019 (UTC)
This one or another? --Izno (talk) 14:38, 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)
Return to the project page "Administrators".