Wikipedia talk:Administrators/Archive 19

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 15

←

Archive 17

Archive 18

Archive 19

Archive 20

Archive 21

→

Archive 23

No, I'm not him, I read about it on the BN board. It was turned down for no other reason other than inactivity. Since I can't post on the crat board, as I'm not a crat, I thought I'd protest the decision.

R.I.P Trip Halstead 12:58, 21 March 2018 (UTC)

@KoshVorlon: FYI, "Trip Halstead" is "Tripp Halstead." —SerialNumberParanoia/^{cheap shit room} 13:16, 21 March 2018 (UTC)

@KoshVorlon: 1) "The Bureaucrats' noticeboard is a place where items related to the Bureaucrats can be discussed and coordinated. Any user is welcome to leave a message or join the discussion here." 2) Admin inactivity was the whole reason behind the recently concluded RFC above. --NeilN ^{talk to me} 13:32, 21 March 2018 (UTC)

Crats kinda aren't allowed to IAR unless it is by ignoring a request and pretending they didn't see it (as no volunteer with advanced permissions can be forced to use them). The whole point of 'crats is that they only act within established policy and consensus, not on a whim. TonyBallioni (talk) 13:36, 21 March 2018 (UTC)

WP:IAR is an established policy.  ►К Ф Ƽ Ħ◄ 

R.I.P Tripp Halstead 13:39, 21 March 2018 (UTC)

Sure, and 'crats ignore the IAR policy. Their role is to only act with regards to admin rights based on the

WP:ADMIN policy and community consensus through a relevant RfA. We want it that way. I don't want a 'crat removing might bit for funsies one day, nor do I want him granting it to his friend from back in the day that got desysoped for inactivity 5 years ago but was a good admin then. The role is very different than the admin role. TonyBallioni (talk

) 13:44, 21 March 2018 (UTC)

Sorry, but the canard that IAR is policy, while one of my favorite retorts, requires actually reading

WP:IAR. The policy states, in full, If a rule prevents you from improving or maintaining Wikipedia, ignore it. For the reasons Tony mentioned above, the entire point of bureaucrats on enWiki is to be bureaucratic and follow the rules. While Andrew may deserve to have his sysop bit, there's no argument that a segment of bureaucrats ignoring their role's description would improve Wikipedia. ~ Amory (u • t • c

) 15:14, 21 March 2018 (UTC)

Actually, Amory, I did actually read it. Re-equipping a sysop that was voted in on a landslide victory, who has no issues with the bit, would definetly help to at least maintain or improve Wikipedia. (Improve in that we're always short on Sysops , to say the least). This is a great case for WP:IAR.  ►К Ф Ƽ Ħ◄  R.I.P Tripp Halstead 21:20, 22 March 2018 (UTC)

• Just my bit that I do feel that an inactive desysopped admin who has not yet received a notice of at least a week about the new rule, should not have had his request for the bits rejected. Of course, I agree – the five year thing is perfect and I'm all for it. It's just a matter of decency; if we have been notifying admins of impending desysops because of inactivity, then we should have first informed the inactive desysopped admins and then brought them under the net of the new rule. Lourdes 14:31, 21 March 2018 (UTC)

• Maybe, but that wasn't part of the RfC, so we can't really say there's consensus to only start the five year timer now. If anything, I think most participants specifically wanted it to apply to editors who had already been away. Besides, there's a silly devil's advocate argument to be made that, if the new policy was enough to get them out of retirement (if only briefly), anyone staying up to date on policies would have been aware of it, and thus wouldn't need to be notified. At any rate, I mostly agree with you, but I don't read that the RfC does. ~ Amory (u • t • c) 15:21, 21 March 2018 (UTC)

• As the architect of the new rule, I have to say this is exactly the situation it was aimed at. I don’t recall interacting with this admin before and have nothing against them personally, but they flew through RFA back when it was easy, quit using their tools seven years ago, and quit editing entirely in 2016. They haven’t really been an admin in a very long time.
  talk
  ) 18:25, 21 March 2018 (UTC)

@Amorymeltzer: It might be good to clarify what you disagree with.

You have reverted my edit about changing "Users and IP's" -> "Editors" and I replied by modifying it in this edit.

You then reverted my edit about page linking, unrelated (?) to the other revert. Regarding that, I disagree with the change back to Main article, since the guide is not the main article, but something prospective candidate should also see if they are interested in becoming an administrator.

) 15:02, 11 April 2018 (UTC)

Yes, unrelated. As I said, I disagree: when it comes to "becoming an administrator" I would absolutely say

WP:RFAADVICE, and is probably the main place someone interested should start their reading. ~ Amory (u • t • c

) 15:19, 11 April 2018 (UTC)

First designs for Special:Block with Granular blocks

The Anti-Harassment Tools team enlisted the assistance of Alex Hollender, a User Experience designer at Wikimedia Foundation to create wireframe designs of the Special:Block with the Granular block feature included. Our first wireframes are based on the discussions on the Granular block talk page, Wishlist proposal, and Phabricator to date.

Because the Special:Block page is already at its limits with its current layout and we would like to propose a new organized layout for Special:Block. This will make it easier to add the granular blocking (page, category, namespace, etc) and whatever is to come in the future. All of the same functionality is available on this new layout, but in a more organized, step-by-step process.

) 19:12, 31 May 2018 (UTC)

Interface administrators

I have started a discussion about the new interface administrator user group at

) 14:45, 30 July 2018 (UTC)

WP:INACTIVITY

See

) 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)

I think it more closely matches the close of that RfC, but not what was actually originally proposed in the RfC though. -- KTC (talk) 23:12, 28 November 2018 (UTC)

I’ve opened an RfC at Wikipedia_talk:Blocking_policy#RfC:_blocking_the_admin_who_blocked_you. All are invited to participate. TonyBallioni (talk) 07:36, 21 December 2018 (UTC)

In case anyone's curious, since the five-year clause became policy in March, by my read of

) 22:18, 29 December 2018 (UTC)

I think we should regard them as having lost their tools indefinitely, rather than permanently. Like an indefinite block, the loss of administrator tools can be appealed. MPS1992 (talk) 23:13, 29 December 2018 (UTC)

It can be appealed by going through RFA again, but there is no mechanism to appeal the actual desysop that I'm aware of.

talk

) 23:24, 29 December 2018 (UTC)

see

) 20:48, 23 January 2019 (UTC)

As discussed extensively at

14:37, 21 February 2019 (UTC)

This whole thing is just messy - here is an example what do you think should be done Lourdes:

1. 2009: User:SomeAdmin is active
2. 2010: User:SomeAdmin is active, this is the last year they make an admin action
3. 2011: User:SomeAdmin edits at least once
4. 2012: User:SomeAdmin edits at least once
5. 2013: User:SomeAdmin edits at least once
6. 2014: User:SomeAdmin edits at least once, decides to resign adminship
7. 2015: User:SomeAdmin edits at least once
8. 2016: User:SomeAdmin edits at least once
9. 2017: User:SomeAdmin makes no edits
10. 2018: User:SomeAdmin makes no edits
11. 2019: User:SomeAdmin Asks for restoration under the 'haven't been completely inactive for 3 years' provision.

If this admin didn't "resign" in 2014, they would have been ineligible when they would have removed for inactivity in 2018 under the '5 year rule' - but that 2014 "resignation" prevented us from processing the 'inactivity removal' since it was already done. Do you think we should have go through the "inactivity" process (notifications, etc) even when they have already resigned to avoid this? — xaosflux ^Talk 14:59, 21 February 2019 (UTC)

It's not messy xao, and you probably didn't need to write up such a long table :) You and the other bureaucrats need to get the community's consensus on this. Crats can't decide on their own to include the "voluntary" part just because Crats believe it makes sense (yes, your point of view makes sense; but get consensus). Thanks, Lourdes 15:13, 21 February 2019 (UTC)

Well it was mostly copy and paste ;) I'm not trying to individual make any policy here - just trying to clarify these edge cases, because it is what drives so much heated debates. In the table above, assuming that the current policy allows SomeAdmin to use BN instead of RFA in 2019, would this be avoided if 'notifications' were sent to them in 2018 that they are now 'inactive' - because having to track and notify inactive resigned admins for this seems to be a silly process in my opinion. — xaosflux ^Talk 15:51, 21 February 2019 (UTC)

It would probably be better to iron this all out with a new RfC. And if things need simplifying, do that at the same time as well. No need to have it be five years (that was an arbitrary figure suggested at the RfC). Make it three years for both editing and admin activity. I'd also throw in that it would be nice to treat those going on a break with respect and say that the request to give up tools counts as an admin action, and start the clock ticking at that point. That would remove the potential problem over removal for inactivity versus voluntary removal. Carcharoth (talk) 15:28, 21 February 2019 (UTC)

• Counting the removal request as a final admin action is an excellent suggestion that fixes the messiness in xaosflux' example. —Kusma (t·c) 16:57, 21 February 2019 (UTC)

  @Kusma: it just pushes things forward, such as if in the table above if there were some more years like 2015/2016 it is the same situation: resigning, then becoming inactive has a longer timeline just just becoming inactive. — xaosflux ^Talk 23:18, 21 February 2019 (UTC)

• The goal of the five-year rule was to stop giving a free pass to admins who are almost totally disengaged from the project, it was never intended to apply to users who resigned adminship but were still active otherwise. I would consider that a seperate issue.
  talk
  ) 01:49, 22 February 2019 (UTC)
  • What you say above isn't consistent with what you said here. You say above that it was "never intended to apply" and you said there that it "probably should". Which is it? There is an example right now at the noticeboard of someone resigning adminship. If they want to keep open the option of taking up the bit again, they won't have to make yearly edits and only need to edit every three years. If they do that, they will be able to ask for the bit back at any time. Is that what you had in mind? You also said (in the same diff I link above), that you were aiming low in the hope of getting proposals to pass, and presumably with each proposal you are trying to gradually tighten the requirements bit-by-bit. What is the end goal you intend to achieve with that process? At the moment, the risk is that you will end up with a load of former admins who voluntarily gave up the bit, with varying levels of current activity, all of whom are entitled to ask for the bit back, which could be difficult to keep track of, and who may need notifying if the requirements change again. On a personal note, it would be nice to have some stability without feeling that the requirements will (yet again) change. But maybe incremental change is all that is possible. Carcharoth (talk) 12:34, 22 February 2019 (UTC)
    • • BN discussion cannot not overrule a RFC closure advertised in
        WP:CENT and per this closure admins who have not used the admin tools for a prolonged period (5 years is mentioned) will usually be required to reapply via Wikipedia:Requests for adminship. Fish+Karate 13:25, 3 March 2018 (UTC) "Hence UninvitedCompany
        's edit was correct as it was as per the RFC closure.Now whether one resigned say 15 years ago or even 6 years ago or was inactive is the same thing in practical terms if both have almost totally disengaged from the project for the same period.Why resignation should be treated differently from being inactive .The closure rightly views both as the same.
• Removal for Cause is different as  adminship to these users are typically only returnable through a request for adminship or another condition set by the Arbitration Committee and note the Committee in odd cases like this 2007 one even which barred a user from a RFA He may apply to have them reinstated by appeal to the Committee, but not through the usual means. Similar is the case with compromised which Arbcom alone decides.The fact the one resigns or one loses his tools after being inactive for over an year but both have more then one edit within 3 years and hence are not long term and if both cross the 5 year rule.both should be treated equally.Pharaoh of the Wizards (talk) 20:35, 3 March 2019 (UTC)
• How about something like "Administrators are expected to be engaged with the project and familiar with current community standards." with 'crats given discretion to not resysop anyone who they feel doens't meet this requirement. Thryduulf (talk) 21:31, 3 March 2019 (UTC)

• ::shrug:: A fact to consider is that all it takes is one bureaucrat. An early example is that the original idea with renames was that you had to have a pretty good reason and be an established contributor. That worked for a while and then someone -- I can't remember who it was -- started doing renames for anyone with more than a few dozen edits, and started doing "right to vanish" renames -- something that has never been a subject of serious community discussion let alone consensus. The recent resysop of Master Jay would be similar example, although I think around half the 'crats who commented thought it should be done in that case. UninvitedCompany 22:51, 3 March 2019 (UTC)

• I closed one of the RfCs; I reverted UC's edit above. My view has been clear from the start. Instead of attempting to find out a synthesis in the meaning of the RfCs' consensus (as was done previously), any one interested should start a new RfC to include the voluntary removal part in the five year rule. I'll vote support. But the clause shouldn't be included arbitrarily (with or without the RfC), either by any editor or least of all by a crat, alluding to probable consensus they view in any RfC. This is not an area where common sense should dictate policy. Thanks, Lourdes 00:25, 4 March 2019 (UTC)
• sorry to say disagree on this we already had a  RFC: Slight tweak to lengthy inactivity policy which was open from 31 December 2017 to 3 March 2018 and advertised on
  WP:CENT and if one wants "another RFC it will be the same wording as what it is here and the same closure" .admins who have not used the admin tools for a prolonged period (5 years is mentioned) will usually be required to reapply via Wikipedia:Requests for adminship. Fish+Karate 13:25, 3 March 2018 (UTC) ") and covers both inactivity and resignation and it applies if the admins who have not used the admin tools for a prolonged period whether one resigned or was inactive. Pharaoh of the Wizards (talk
  ) 01:00, 4 March 2019 (UTC)

• You probably haven't read the first line of the RfC you are linking to. Lourdes 01:07, 4 March 2019 (UTC)

• • • Closure of any RFC is relevant and it does not distinguish between between inactivity and having resigned and treats admins who have not used the admin tools for a prolonged period equally and this statesadmins who have not used the admin tools for a prolonged period (5 years is mentioned) will usually be required to reapply via Wikipedia:Requests for adminship. Fish+Karate 13:25, 3 March 2018 (UTC) " .The RFC was closed in March 2018 and UninvitedCompany made the change in 28 November 2018 .Further Wikipedia:Former_administrators/reason/resigned .Out of this 50 who resigned in good standing around 15 are eligible to be resysoped currently there are 35 cannot under the 5 year rule.Now if one is saying there will be no 5 Year rule then anyone who resigned at any time in good standing then a user like Stephen Gilbert who resigned in 2004 can come and ask back for his tools and really most of the 50 had there RFA before 2010 including 4 by email . Pharaoh of the Wizards (talk) 03:38, 4 March 2019 (UTC)
      • Ok. Wow! Good luck with that interpretation. See you around. Lourdes 08:32, 4 March 2019 (UTC)

I ask to evaluate this diff. If possible, erase it, please. Respectfully, Baden-Paul (talk) 09:22, 12 March 2019 (UTC)
Many thanks for the operational assistance. With best regards, Baden-Paul (talk) 09:33, 12 March 2019 (UTC)

At the top of Wikipedia page on Led Zep it says Origin, London. Surely they came from the Midlands Numptyd (talk) 09:22, 24 April 2019 (UTC)

@Numptyd: This is the wrong place to ask this question, which should be on Talk:Led Zeppelin, but no, they were formed in London and first rehearsed in a basement studio in Gerrard Street. Dave Lewis' books have further information. Ritchie333 ^{(talk) (cont)} 11:58, 24 April 2019 (UTC)

 You are invited to join the discussion at

🖋 21:54, 8 April 2019 (UTC)

Seems like a little bit of overkill there to open an RFC on such a slight difference of opinion... --Izno (talk) 22:09, 8 April 2019 (UTC)

Well, Izno when you have admins edit warring over a small bit of text being included or excluded and the page ends up being protected... it's no longer overkill, sadly. Dusti^{*Let's talk!*} 04:42, 9 April 2019 (UTC)

Er, yes, it is still overkill. The remedy of an edit war is a conversation on the talk page. The remedy of many related edit wars across many pages is an RFC. This is the first situation, not the second. --Izno (talk) 12:05, 9 April 2019 (UTC)

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). –xeno^talk 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)

• Note, the related VFP discussion (Special:PermaLink/901665843#Allow_bureaucrats_to_quickly_re-sysop_admins_temporarily_de-sysoped_by_WMF_for_carrying_out_out_community_consensus was closed as no-consensus, with a request to further follow up here). — xaosflux ^Talk 13:21, 13 June 2019 (UTC)

Hello, the recent Fram situation, and likely the follow up related to Floquenbeam has brought to question part of the administrator policy. That is, should an admin be involuntarily desysoped by the WMF Office - what avenues to access restoration should be available following an prohibition period. If you would like to address a "Should we just ignore and override WMF Office" - please do so in a new discussion area. I see going through a new RfA as an available option already - but should there be other options? In any event, I think it is obvious that if an intervening community action/arbitration committee action adds additional prohibitions that they would continue under the existing scheme. Thank you for your feedback, — xaosflux ^Talk 01:19, 12 June 2019 (UTC)

If anyone wants to override WMF, I think they will, discussion or no. I see the situation as similar to having rights emergency removed by a steward - but we don't really address that either. --Rschen7754 01:26, 12 June 2019 (UTC)

@Rschen7754: I see the ignore wmf route as different topic (which certainly can be discussed) - but to keep this part on track, I'd like to clarify if there is support for non-RfA restorations following a ban. — xaosflux ^Talk 01:31, 12 June 2019 (UTC)

If you're asking me personally, I would say no. There is the credible argument that the rights were removed under a cloud. --Rschen7754 01:35, 12 June 2019 (UTC)

Adminship on this project is a measure of the community (and the Arbitration Committee)'s trust in an editor, not a measure of the Wikimedia Foundation's trust in that editor. Thus, unless there's some indication that the office-desysopped admin has lost the community's trust (which is clearly not the case for both of the admins the WMF desysopped recently), then there is no cloud and their admin rights should be restorable on request. * Pppery * _{it has begun...} 01:41, 12 June 2019 (UTC)

Well, that's the thing. You and I may still trust them, but enough people probably do not that a new RFA would be a better alternative (as evidenced by some comments that are starting to come from different editors). --Rschen7754 01:47, 12 June 2019 (UTC)

I would have to say no, based on the reasoning above. The only way of establishing the community's trust in an editor is through ArbCom or RfA. Surely an office action counts as removal under a cloud. Hawkeye7 (discuss) 01:45, 12 June 2019 (UTC)

There is an open question as to whether or not this is genuinely under a cloud, however, given Floq was essentially being put into a situation I wouldn't wish on my worst enemy, and she chose to side with the community (who agrees, absent any new information, that this is an overreach). —A little blue Bori v^_^v ^Bori! 02:41, 12 June 2019 (UTC)

Floquenbeam was under no obligation to act, and did so with no illusion that a desysop would likely be forthcoming. Probably also anticipated the possibility long block for violating ToS by overturning an office action and/or disrupting Wikipedia to make a

WP:POINT. Hawkeye7 (discuss)

04:52, 12 June 2019 (UTC)

"Under a cloud" is generally used to annotate resignations in the face of scrutiny, whereas both Floq and Fram were de-tooled for cause. As such, the usual "for cause" provisions regarding regaining the tools should apply here (unless the WMF have specifically stated otherwise) Dax Bane 03:00, 12 June 2019 (UTC)

Good point. But er, what are the usual "for cause" provisions? Hawkeye7 (discuss) 04:52, 12 June 2019 (UTC)

Applying for the tools through the RFA process, sometimes with a minimum waiting time appears to be the usual procedure for re-mopping for cause permission revocations Dax Bane 05:57, 12 June 2019 (UTC)

Please point out the section of the policy that allows for the removals that have occurred. –xeno^talk 10:41, 12 June 2019 (UTC)

Wikipedia:Office actions#Secondary office actions Hawkeye7 (discuss) 11:54, 12 June 2019 (UTC)

I was taking about the community’s policy at Wikipedia:Administrators, but okay- Hawkeye7: please explain how Floquenbeam’s action involves a “major [breach] of trust performed by Wikimedia functionaries or other users with access to advanced tools that [is] not possible to be shared with the Wikimedia communities due to privacy reasons and therefore can not be handled through existing community governance mechanisms.” Everything Floquenbeam did was out in the open, in fact it was telegraphed in advance. There is nothing private in this case. It appears that Trust and Safety has violated the section you’ve linked as the committee could have heard a case regarding the unblock, at the least, if not the precipitating case re: Fram. –xeno^talk 16:10, 12 June 2019 (UTC)

Hi followed you from BN: but I don't think you are looking at the whole policy: "administrators and others who have the technical power to revert or edit office actions are strongly cautioned against doing so. Unauthorized modifications to office actions will not only be reverted, but may lead to sanctions by the Foundation, such as revocation of the rights of the individual involved." Alanscottwalker (talk) 16:45, 12 June 2019 (UTC)

Yes, thank you Asw. I still fail to grasp why the precipitate case was not referred to the existing community governance mechanisms, i.e. the Arbitration Committee (which is capable of handling privacy-sensitive matters). –xeno^talk 17:04, 12 June 2019 (UTC)

What's not to grasp? The WMF is given discretion by policy (and as owners, so also by common sense) to decide when the TOU is not being enforced effectively. So, if you want to be the one to exercise that discretion then you have to go to work for them. Now as it happens both the WMF block message (to get back to the purpose of this discussion) and I think me are open to other ways and means to return tools than a new RfA in this case. Alanscottwalker (talk) 17:23, 12 June 2019 (UTC)

One cannot fail to enforce something if not given an opportunity to do so. –xeno^talk 19:44, 12 June 2019 (UTC)

Of course one can and they do. Opportunity is always present to enforce our policies: you may do so, do it poorly, or not do it at all, but the opportunity is ever present. -- Alanscottwalker (talk) 20:11, 12 June 2019 (UTC)

...That entire page was rewritten by a WMF staffer without consensus or any discussion before or after. Weird. --Yair rand (talk) 03:36, 13 June 2019 (UTC)

• Administrators serve at the pleasure of the community, not the WMF. The section on removal of administrators overleaf does not contain a provision for summary revocation by User:WMFOffice. Once the office actions (which we apparently have to just accept without any avenue of appeal) have lapsed, summary restoration should occur to restore governance to the local community (at which point, local processes may be engaged if needed). –xeno^talk 03:38, 12 June 2019 (UTC)

• • So if Fram or Floquenbeam show up on BN the day after their respective office-mandated desysopping expires asking for the tools back, where would you land in the "sure"/"go to RfA first"/"recuse" triangle, xeno? Dax Bane 03:43, 12 June 2019 (UTC)
    • It has been pointed out to me that there does not presently exist in the policy an avenue for bureaucrats to summarily restore privileges “temporarily” removed by office action. This is of course a function of the unprecedented (on this project) nature of these removals. Should community consensus be established that bureaucrats may restore temporarily removed privileges summarily (and isn’t that a defining characteristic of “temporary”?), I would continue to carry out the community’s will to the best of my abilities. –xeno^talk 03:57, 12 June 2019 (UTC)
• This is certainly a weird one. We know what kind of "situation" has led to Floq's desysop, but we really don't know what triggered the Fram desysop. Indeed, we don't know if he was desysopped to prevent him from using the remnants of admin permissions that aren't affected by his block, or for some other reason. We do, however, have a community process related to removal of admin permissions; I know it's not popular to say it, but Arbcom is that route. I'd suggest that Arbcom should treat these desysops as the equivalent of a case request from the community (because realistically both cases have raised questions within the community), decide whether or not a "case" or "review" is warranted, and determine whether or not re-RFA is required, or if either of these admins can regain permissions on request. While it's not a perfect solution - nothing we do here will be - I'd suggest something along the lines of "Should an administrator's permissions be removed because of a non-permanent WMF OFFICE action, the Arbitration Committee will determine whether or not to review the administrator's permission level and decide whether a new RFA is required at the completion of the WMF OFFICE action. Should the Arbitration Committee decline to review the administrator's permission, or supports by motion that the administrator may regain administrator permission on their request to the Bureaucrat Noticeboard, no new RFA will be required." Risker (talk) 04:01, 12 June 2019 (UTC)
• I support Risker's proposal/idea. TonyBallioni (talk) 04:09, 12 June 2019 (UTC)
  • As do I Dax Bane 22:54, 13 June 2019 (UTC)
• Automatically resysopping editors banned by WMF office action would set a horrible precedent. As the WMF has already said they might not share details of actions with ArbCom, a case may not be able to treat the subject fairly. A new RfA is the only way to properly gauge the will of the community in each of these cases and in any going forward. – bradv🍁 04:22, 12 June 2019 (UTC)
  • I'm not sure that I follow you. Why would it set a horrible precedent? Do you have a problem with the Arbitration Committee reviewing their admin permissions? They are, after all, the elected representatives of the community specifically tasked to review admin permissions. Risker (talk) 04:28, 12 June 2019 (UTC)

    I can imagine a case where somebody did something truly awful and deserved to be desysopped, but for whatever reason WMF enacted it rather than Arbcom. In such a case, Arbcom may not be privy to the evidence and may not be able to put together a fair case. To your second question, I'm of the opinion that Arbcom should continue to be the only body that can desysop people for cause, but if the WMF is going to enact this change there isn't much we can do other than handle this on a case-by-case basis. – bradv🍁 04:33, 12 June 2019 (UTC)

  Bradv Floquenbeam was not banned, they were “temporarily” desysopped. In cases like Fram (with private evidence and in camera decisions), how can the community be reasonably expected to deliberate on an administrator’s fitness when the incident they gave rise to the removal of access is not disclosed? The status quo should be restored and the arbitration committee may be engaged if community members feel it necessary. –xeno^talk 04:35, 12 June 2019 (UTC)

  Xeno, the ideal situation right now would be for the WMF to reverse their ban and refer the matter to ArbCom. If that doesn't happen, I don't know how we're going to handle it in a year. Meanwhile, I'm just concerned about setting a precedent that we may not be able to undo (i.e. someone gets justifiably desysopped, and ArbCom doesn't have the evidence to re-desysop them). – bradv🍁 04:39, 12 June 2019 (UTC)

  The real question is: Why is the Arbitration Committee being bypassed? The T&S page says that they will step in when local procedures have failed. From what we’ve been told, local procedures were never even given an opportunity to handle the situation, despite the committee members being signatories to the confidentiality agreement for access to non-public information. I believe the justification is that T&S cannot disclose a complainant’s identity to the committee but there is no reason they cannot instruct the complainant to first exhaust local processes (which can be done in private) and confirm that they have done so before taking drastic actions that harm community/WMF relations. –xeno^talk 04:48, 12 June 2019 (UTC)

  Xeno, I agree entirely, and it's a question I really hope the WMF answers. It seems to me the relationship between ArbCom and the WMF has been damaged by this incident and in need of repair, which is also why I'm suggesting we not put ArbCom in between the WMF and the community when this thing expires. – bradv🍁 04:51, 12 June 2019 (UTC)

• To voice an opinion on Xaosflux's original question, I think that any of the desysops as Office actions would have to go through RfA. The "under a cloud" phrasing is irrelevant, as it was not a voluntary de-sysop or one due to inactivity. The only other de-sysoppings for cause are the ones that ArbCom imposes as part of their normal process, and they usually specify under what circumstances the tools would be returned: either a new RfA, sometimes after a mandatory waiting period, or appeal to ArbCom. I suspect that WMFOffice's phrasing "a RfA can be opened once 30 days elapse, and the community may decide on the request at that time in such or another way" was meant to leave it open to enwiki's policy - they're neither reinstating Floquenbeam after 30 days, nor barring them from being reinstated after that time. If they intended the tools to be automatically returned, they would have said that. Instead, the tools were removed involuntarily (and "for cause", regardless of whether anyone here agrees with that cause). A 'crat restoring the tools prior to 30 days would be reversing an office action, and a 'crat restoring the tools after that but without consensus (and I see no reason to establish that anywhere but at WP:RFA) would be in violation of
  WP:CRAT
  "they are bound by policy and consensus only to grant administrator or bureaucrat access when doing so reflects the wishes of the community".
• The same would be true for Fram, with the possible but unlikely exception that the WMF might intend to automatically restore their sysop bit at the end (if the theory is that the desysop was to prevent certain admin tools from being exercised while the account was blocked). Ideally the office would clarify their intent (among many other things...) before it becomes relevant, however, I think the most likely answer is that they too would have to go through an RfA unless the office spontaneously reverses their decision. ST47 (talk) 08:42, 12 June 2019 (UTC)

  The community can express their wish that these “temporary” desysops be treated as such, and reversed at their expiry. Unless WMFOffice is using some alternate definition of temporary, policy considerations can be established that new RfA is not required followed these unprecedented “temporary” removals that have no backing in the policy. –xeno^talk 10:47, 12 June 2019 (UTC)

• I don't know where things will end up in 30 days, but after the dust is settled, barring some radical changes the English Wikipedia will still be part of the WMF when any of this becomes relevant. The Floq desysop note suggests the WMF feels a new RfA is required for that bit to be restored. Whether any of us cares is another matter, but it would suggest that any other process would be open "rebellion" against the WMF after "hostilities" had ended. I like Risker's suggestion, but a new RfA would and always will be cleaner. It'll be an easy seven days of Floq adoration, and will establish a strong, irrefutable message going forward. It may even be quicker than ArbCom. If the WMF doesn't demand a new RfA, I'd be happy to expand the bureaucrat discretion to such cases of "temporary" removal. In short, I think our general policy should be to 1) clarify whether the WMF will require an RfA, 2) if not, refer to bureaucrats, but 3) in all cases, heavily prefer a new RfA. ~ Amory (u • t • c) 10:14, 12 June 2019 (UTC)
  • @Amory: The WMF wrote "a RfA can be opened once 30 days elapse, and the community may decide on the request at that time in such or another way". I think that means that they wouldn't objec to the policy xeno suggests. I also support that policy. KSFT ^(t|c) 10:53, 12 June 2019 (UTC)
• Speaking generally, I think that if the WMF desysops someone temporarily and clearly indicates a single method by which tools may/will be regained then that method should be used. In other circumstances, I think the user concerned should never be resysopped without asking for the tools back. They may do this by initiating or accepting an RFA (self-) nomination, or by asking the crats. The crats would then have the option of restoring after 24 hours (given that it's not impossible that a WMF-desysopping was coincident with other things that would place the editor under cloud) or requesting the editor pass an RFA first. In all cases an RFA should be run and closed as normal. If the crats do not want this, then the request should be made to the Arbitration Committee instead per Risker. Thryduulf (talk) 11:51, 12 June 2019 (UTC)

• @Thryduulf:, sorry to repeat myself, but although I know the WMF has the power to desysop permanently or temporarily, where does the ability to make a desysop only temporary and then specificy a method for regaining the tools? Are we even sure this isn't a misunderstanding of enwiki procedures? Doug Weller talk 15:21, 12 June 2019 (UTC)

  @Doug Weller: lets pretend we can ignore the WMF "method" statement and say it was just "use your community process" as they are not asserting that they will take care of restoration processes anyway. I'm trying to determine if there is support for a community process in addition to RfA for giving administrator access to people that were involuntarily desysoped by the foundation. — xaosflux ^Talk 15:31, 12 June 2019 (UTC)

  • (edit conflict) Well they say that CU and OS can only be granted to people who have been through an RFA or a similar process. So it is not implausible they could specify that tools should only be returned after they pass an RFA or similar (currently that means an RFA or being elected to arbcom, afaik nobody has officially asked about anything else). They could also say that arbcom must be consulted first (presumably this would only happen if they had provided private information to arbcom regarding the matter), or they could say that the tools can be restored on request - all of these seem perfectly reasonable parts of a temporary desysop motion (for want of a better word) to me. Wehther they ever would do any of these I don't know (all we know is they haven't on this occasion), but if they do I don't see why we would or should do something different. Thryduulf (talk) 15:38, 12 June 2019 (UTC)
    • @Xaosflux: As I see it, assuming the WMF don't specify anything different, once the desysop period expires the the plausible options in practice are: (1) any crat can restore the tools at any time; (2) any crat can restore immediately on request from the editor; (3) 24 hours after the request, any crat can either restore the tools or decline to do so without a new RFA (based on comments received during that 24 period); (4) require a new RFA in all cases; (5) require arbcom to explicitly decide whether (i) an arbcom case is required, (ii) the crats can restore immediately, (iii) the crats can restore after some waiting period, or (iv) a new RFA is required. Personally I would only support options 3, 4 or 5 and would strongly oppose (1). Thryduulf (talk) 15:46, 12 June 2019 (UTC)

• I would be comfortable with ArbCom deciding, or a decision being made at BN where any controversial cases are referred to a new RfA. I am not comfortable with handing back the tools no questions asked. -- Ajraddatz (talk) 17:29, 12 June 2019 (UTC)
• The WMF had explicitly left it up to us to decide what to do, and therefore I see no reason not to restore the bits immediately upon expiration. If the WMF intended otherwise they would have said. Neither Floq nor Fram has been desysopped by any community process, therefore their original RFAs stand. And to those suggesting ArbCom or an RFA, it seems like neither ArbCom nor the community have any access to the data used to effect the desysop, so it's hard to see what they would be basing a decision on.  — Amakuru (talk) 17:41, 12 June 2019 (UTC)
  • @Amakuru: I'm talking about establishing a policy for this and any future occurrences - in other cases there might be information that arbitrators have the community does not and/or there might be other things that were happening at the time of the desysop that are relevant. We also do not know the users will conduct themselves during the block. I don't see what possible harm comes from waiting another day even when there are absolutely no clouds. Thryduulf (talk) 19:41, 12 June 2019 (UTC)

    @Thryduulf: when I say "immediately" I mean without necessarily mandating a fresh RFA or requiring a full ArbCom confab. A 24 hour waiting period for objections is sensible on any event, certainly. It's not ideal to have to make up policy on the hoof when it directly affects current events, but if it helps clarify things then perhaps an RFC is in order and some new wording on how to handle expired OFFICE desysopps is required. Thanks  — Amakuru (talk) 21:00, 12 June 2019 (UTC)

• I've been thinking very hard about this question, and obviously the only thing that is really clear here is that WMF made an internally contradictory statement. I'm less enthusiastic than others here about ArbCom deciding the issue. ArbCom can certainly evaluate conduct, and so they could consider a case in which they evaluate the conduct of the affected administrators. But ArbCom does not make policy, so I don't think that they can decide what procedure the community can follow. They cannot say either that there must be an RfA or that a Crat should just go ahead and restore the rights. But to get very specific about it, one approach that could work would be for ArbCom to accept a case for the sole purpose of determining whether or not the desysop was "under a cloud". I think that would be reasonable, and then the next step would be determined by existing policy. "Under a cloud" means a new RfA, and "not under" means a Crat can act. (I know that Crats already make decisions about whether or not there was a cloud, but I think we have a difficult situation here where, instead, they should leave that to ArbCom.) And we could ask that the desysopped admin file the ArbCom request, and thereby satisfy the expectation of actively initiating the process.

But otherwise, I think that we have to read the WMF statement about Floquenbeam, dodgy as it is, strictly on face value. They never said that the desysop was indefinite, or that an RfA was mandatory. They only said that it is "temporary" and that there is a 30-day duration. I don't think that we go from there to concluding that they said that the desysop remains in place until there is a successful RfA. "Temporary and lasting 30 days" clearly means that after 30 days the situation returns to what it was before, and that there is an assumption that the admin permissions will be returned at that time unless the community actively decides to do otherwise. --Tryptofish (talk) 23:21, 12 June 2019 (UTC)

Having thought about this more, I'm increasingly coming to the conclusion that the only appropriate course of action following any admin being desysopped for cause, by anybody, is to require a new RFA to demonstrate that they still have the community's trust. If they do then then RFA will easily pass and it's not going to be an issue. If they don't it's far better that we find out before they regain the tools. Thryduulf (talk) 09:28, 13 June 2019 (UTC)

• @Thryduulf: Respectfully, I think that is a completely unfair position. It has been said many times that requiring sitting admins to go through RFA is not a fair process, even for those who've never been under a cloud, for the simple reason that an experienced admin is likely to have pissed off a lot of people in the process of doing their admin duties. Who knows if you or I would pass RFA were we to go through it now? There's a reason why adminship is not subject to reconfirmation. Secondly, if an individual temporarily desysopped under an office action that is typically for reasons that are not disclosed. We have no information on which to judge them. Some people are already slinging mud at Fram without knowledge of why the office banned him. Putting such a user, whom nobody at en-wiki ever thought to desysop before, through an RFA is simply to put them into a kangaroo court, whose outcome cannot be predicted and is not particularly likely to be useful way in judging their suitability for continuing adminship. For me it's very simple. If the WMF tell us we're allowed to resysop someone then we should go ahead and do it. The only other fair alternative to that would be if WMF were to send Arbcom the entire case file an allow them to make a determination. Other than that, no other route is fair to the individual. Thanks  — Amakuru (talk) 13:16, 13 June 2019 (UTC)

Proposal workshop (1)

Should an administrator’s userright be removed by a temporary

, unless specified otherwise the administrator userright may be restored at the user’s request upon the expiration of the temporary action, without prejudice to further examination by local governance mechanisms.

• Workshopping, comments invited. –xeno^talk 13:34, 13 June 2019 (UTC)

  I’ve added “unless specified otherwise” following suggestion by Jo-Jo Eumerus (the underlining is for the workshop, not production). –xeno^talk 17:23, 13 June 2019 (UTC)

• I think "Temporary" is a loaded word here - unless the office plans to personally perform the next step. I see this more as a multi-part activity: (a) The office has removed this access from you (b) The office has implemented a prohibition against you having this access for some period. From the recent comments, it appears that the office won't do the subsequent change, leaving it to a community process - of which we have
  WP:RFA already. For comparison, if they "temporarily" globally lock you, they will normally be the group to unlock you - they don't leave it up to the stewards to decide. — xaosflux ^Talk
  13:46, 13 June 2019 (UTC)

  It’s the language the office has used in these desysoppings. Someone else pointed out that there’s no timer available to automagically reverse userrights changes, so the fact that bureaucrats have to push a button is more of a technicality under this proposal. If their actual motive is to force the user into a fresh RFA, then temporary should be dropped, and RfA specified as required similar to the committee rulings. –xeno^talk 15:52, 13 June 2019 (UTC)

• I'd probably add in "unless specified otherwise by the Wikimedia Foundation"; sometimes they not only pull rights but set out time restrictions and/or other conditions, as happened in this case. Jo-Jo Eumerus (talk, contributions) 14:09, 13 June 2019 (UTC)

  I’ve added “unless specified otherwise”, thank you. –xeno^talk 17:23, 13 June 2019 (UTC)

• Not a comment on the current case, but I'm not super comfortable enshrining any standard which in effect means that the community is condoning misconduct that involves privacy concerns sensitive enough that it can't be shared with the community (also no comment on why the Foundation doesn't feel they can share the information with ArbCom or the functionary team). That's basically what an automatic resysop would amount to, should an applicable situation arise. It's not as if someone could open an ARC requesing "please review this information, the nature of which I am unaware, and which the Foundation refuses to share with you." GMG^talk 15:39, 13 June 2019 (UTC)

  The alternative would be a potential RfA where the community is largely in the dark and forced to sleuth and guess (which rarely goes over well). If there are such concerns, the removal should not be called “temporary”, in my opinion. –xeno^talk 15:59, 13 June 2019 (UTC)

  Yes, the community would need to decide, based on the individual's career, whether they are comfortable restoring access with the understanding that they don't have and will not get all the information. That is less than ideal, but is some level of accountability in a situation where someone may have conduct worthy of deadmining, which ideally would be nearly all situations where the Foundation is compelled to take office action. Yes, it would be a great deal more convenient if the Foundation chose wording that was unambiguious, but I'm not holding my breath for the day when the Foundation is terribly savvy with the projects and communities they oversee. GMG^talk 17:18, 13 June 2019 (UTC)

  I’ve added “unless specified otherwise”. If the WMF or T&S really don’t want us to procedurally resysop on request after a “temporary” sanction based on evidence they won’t disclose, they need to, well, specify. Temporary has a meaning. Also it should be noted that in the case of Fram, the WMFO specifically noted that the removal of administrative userrights was procedural in nature: “The removal of administrator access is intended as enforcement of the temporary partial Foundation ban placed on Fram. It is the community’s decision what to do with Fram’s administrator access upon the expiration of the Office Action ban.” –xeno^talk 17:34, 13 June 2019 (UTC)

• In the absence of any official request to the contrary, yes of course. A case where the WMF *might* be holding back information which they are not even sharing with the people the case is about, we must presume in good faith that that *possible* information just is not important or pertinent to the restoration of rights. --Fæ (talk) 15:46, 13 June 2019 (UTC)
• Mu - I feel that the Office has violated the movement's "appropriate principles and our established constitutional order" referred to by Jimbo,[5] to whom I agree all bans are appealable[6] meaning that T&S shouldn't be modifying any advanced permissions or imposing temporary or local sanctions. They should have only the one tool that they have ever needed for their legitimate purpose of ToU enforcement of serious, legally necessary sanctions: the global permanent ban. Therefore my position is that the new Office actions are an overreach which the community, and admins in particular, should stand firm in asking the Board to reverse, or failing that supporting an all-functionaries fork. EllenCT (talk) 01:09, 14 June 2019 (UTC)
• This sounds pretty good, for a lot of reasons. First, I don't think there will ever be a situation where removal of adminship under OFFICE is ever going to be for such a short duration that it will be impossible for the community in general, or the appropriate community-authorized bodies, to conduct a review. Second, at least at this time we really have no concept of what criteria are being applied to remove these tools. I'll add that I think it's valuable to establish a baseline process now, while we know that this situation has (for the first time ever) occurred; we can always revise it subsequently if other factors change. Risker (talk) 02:21, 16 June 2019 (UTC)
• What are we trying to accomplish here? The bureaucrats can already restore the administrator userright of any user on request - and have done so. If you're trying to prevent them from restoring to users who have them permanently removed, or before the expiration of the temporary action, then this does not accomplish that. Hawkeye7 (discuss) 03:19, 16 June 2019 (UTC)

  @Hawkeye7: part of the admin policy says Former administrators may re-request adminship subsequent to voluntary removal or removal due to inactivity., so my reading is that an office removal fails to meet those criteria to give the requester grounds to seek summary restoration, in that it is certainly not "voluntary". — xaosflux ^Talk 17:29, 16 June 2019 (UTC)

  @Xaosflux: I agree with you completely, but we have recently seen an administrator that had been de-sysopped for successfully apply to have admin userright restored. The bureaucrats considered that section only applies only to voluntary removal or removal due to inactivity, and not admins who have been de-sysopped for cause, who may be re-sysopped on request. Hawkeye7 (discuss) 21:25, 16 June 2019 (UTC)

  @Hawkeye7: I'm sure you are referring to Floq's request which actually was already closed as "not done", but then was overridden by a separate bureaucrat who did it anyway. So "the bureaucrats" are at least divided on the measure, but due to the way we are structured a "not done" requires that no 'crat will agree to do something (c.f. there is an ArbCom case request open on this as well). — xaosflux ^Talk 23:24, 16 June 2019 (UTC)

  I don't know where it says that, but the bureaucrat in question, said in his signing statement that "this project has clear policies and procedures" [7], which he was following (since it would make no sense whatsoever not to follow policies and procedures in a complaint about someone else not doing so). Hawkeye7 (discuss) 04:08, 17 June 2019 (UTC)

• In my opinion, WMF-originated removal of tools should be handled no differently (procedurally speaking) than ArbCom-originated removal of the same tools. Dax Bane 07:24, 18 June 2019 (UTC)

Proposal workshop (1b)

Should any userright be removed by a temporary

, unless specified otherwise the Foundation is indicating that the userright will be restored when the temporary period expires. If the Foundation fails to carry out their obligation in this regard, the userright may be restored by local action at the user’s request, without prejudice to further examination by local governance mechanisms.

If the Foundation did not mean temporary they would not have said temporary. If the Foundation temporarily removes PageMover or somesuch, and the Foundation forgets to restore it, any admin can restore it. And of course bureaucrats can restore admin. If the community sees grounds for removal then we have mechanisms for that. Alsee (talk) 15:18, 16 June 2019 (UTC)

I think we're reading way to far in to the phrasing that was used on this one specific instance, "temporary". My reading is that it is a definite period of prohibition, not any sort of promise of future activity. Your comparison to "page mover" isn't the same, as page mover access is already "discretionary" grantable to pretty much anyone an admin wants to, while we certainly do not allow bureaucrats to discretionarily grant sysop to anyone they want to. And noone is arguing that admins that loose admin access by the foundation can't regain it via an RfA following the ban period. So this is all just back to the initial question of should their be other avenues to restoration, and what should they be? Should they require the former admin to actually request access, or should it be hoisted upon them? Is there a time limit, if so what? Would such restoration be "shall issue" or "may issue", if "may issue" are grounds needed for denial? — xaosflux ^Talk 17:26, 16 June 2019 (UTC)

My reading was that it has the same meaning as ArbCom's own pro forma. I requested an explanation of this back in 2013, and ArbCom responded that (1) the former admin may apply regain access access through RfA after the restriction period, if any, but is not obliged to do so; (2) that ArbCom may itself restore admin access by motion at any time; and (3) it does not preclude restoration of admin rights by other means. Hawkeye7 (discuss) 21:39, 16 June 2019 (UTC)

Page Wikipedia:Administrators is marked by {{policy}}, and is included in Category:Wikipedia policies. Should what seems to be just an informational section "History" (permalink) be moved to information page Wikipedia:Administration? —⁠andrybak (talk) 20:08, 25 June 2019 (UTC)

For old pages it is the norm Wikipedia:Neutral point of view#History. Plus Wikipedia:Administration is about how the project works ( or more specifically the structures) not about admins.--Moxy 🍁 21:37, 25 June 2019 (UTC)

@Moxy: At Wikipedia:Neutral point of view, the "History" section is at the bottom, just above footnotes and "See also". Would it make sense to move "History" down at Wikipedia:Administrators? —⁠andrybak (talk) 09:43, 26 June 2019 (UTC)

Sure why not....should try and have the same positioning in all articles.--Moxy 🍁 22:32, 26 June 2019 (UTC)8

 Done Special:Diff/903811772. —⁠andrybak (talk) 03:58, 28 June 2019 (UTC)

• Just noting that the this section has existed (in something pretty close to it's present form) since 2010 [8] (historical history, if you will) Crazynas ^t 10:32, 26 June 2019 (UTC)

There have been statements made on this page about admin activity, some seem credible to me, and some are not. Instead of having anecdotal evidence, could we may be compile a table (I hope it should not be difficult to compile by bot) which lists (i) all admins who have been AN-resysopped between five years and one year ago after being desysopped for inactivity; (ii) all admins who have been AN-resysopped between five years and one year ago after being desysopped on request (voluntarily); for every admin, the current activity status based say on the last three months (active, inactive, desysopped for activity, desysopped on request, desysopped for cause). Additionally, we can have a list of admins desysopped for cause in the last four years, along with their activity status in the three months prior to being desysopped, and see what the overlap is with the first list. Does this make sense?--Ymblanter (talk) 08:23, 24 July 2019 (UTC)

Or may be it should indeed go to a village pump.--Ymblanter (talk) 08:35, 24 July 2019 (UTC)

Meh. My thing is, there are probably a lot of cases where people are resysopped (or spend a long time gaming the inactivity rules before becoming active again), do boneheaded stuff, but not bad enough to get them desysopped (or it's simply uncaught), and then eventually get better (if they stick around). So I think those stats wouldn't be illustrative of the whole problem. Like there's this one admin with over 100k edits, about 73k of which were made in the last six months of 2015, who has made fewer than 20 edits per year every other year from 2010 onwards. Same guy applied cascade protection to his userpage in 2015 (!!!), which ran for about 7 days and affected a bunch of templates. Same guy seemed to have a penchant for, when blocking, ticking all the boxes (cannot edit own talkpage, email disabled) for first-offense routine vandalism. Fortunately he seems not to have undertaken a single administrative action outside his userspace since 2015 either. —/Mendaliv/^2¢/_Δ's/ 12:00, 24 July 2019 (UTC)

Are you saying that any statistics would be useless and we should stick to anecdotal evidence?--Ymblanter (talk) 13:50, 24 July 2019 (UTC)

To be honest, yes: A poorly designed statistical model is worse than none. At least with what we have we can reason based on principle rather than some amorphous "need" derived from statistics that will likely prove as controversial as the principles we're trying to use them to support. So why not reason directly from principle? The system we have was hardly originally designed around statistical models. —/Mendaliv/^2¢/_Δ's/ 14:44, 24 July 2019 (UTC)

[ec] Statistics may or may not be useful. When a statistical analysis is needed the result can be no correlation. That is however a useful result, as it would indicate that we are probably barking up the wrong tree (Which I think is quite possible). Taking it to the village pump without reasonable evidence of what the causes of the problem are, or at least a strong correlation between a previous condition and a later condition, will in my opinion most likely end in no consensus, as people will want to know what the problem is that we are trying to fix. Anecdotal evidence can be useful for indicating what questions we should be asking. · · · Peter Southwood ^(talk): 14:52, 24 July 2019 (UTC)

Desysopping for cause is extremely rare. Wikipedia:Former administrators/reason/for cause lists 13 cases in the last four years. It's not a big enough sample to make any meaningful conclusions. A resysopped admin who merely uses the tools badly in a few cases is very unlikely to be desysopped unless the incident is particularly high profile. And to be honest out standard for admins should be quite a bit higher than "isn't going to be desysopped by ArbCom". Hut 8.5 11:52, 27 July 2019 (UTC)

13 in 4 years seems a moderately significant percentage of the total number taking into account the number of new admins in the same period. It does show that it does happen. Is there any objective evidence that resysopped admins who use the tools significantly badly continue doing so after the problem has been brought to their attention, and that they are still unlikely to be desysopped if they persist? Is the problem with resysopped admins statistically different to similar problems with admins who have not yet been desysopped, and does it differ between admins who were RfAd 15 years ago and those RfAd 5 years ago? · · · Peter Southwood ^(talk): 05:42, 29 July 2019 (UTC)

As I wrote in the RfC above, I have seen no convincing evidence that resysopped administrators are more problematic, disruptive or incompetent than those administrators who have been serving continuously. Each of us can come up with an anecdote or two on either side of that divide. But we are talking about a group of 1147 people and anecdotes are of little use. What we need before making a change is statistical analysis and convincing evidence. Cullen³²⁸ Let's discuss it 06:15, 29 July 2019 (UTC)

I can not think of any resysoped admins who were desysoped for inactivity who then became problems. But I think there are several resysoped admins who were desysoped for inactivity who were not very active after their resysop. While that might be irritating, this doesn't actually cause any problems for the project. But, of course, data would be more revealing than just anecdotal evidence like what any examples any of us can remember. Liz ^{Read! Talk!} 20:25, 30 July 2019 (UTC)

Unfortunately, the absence of anecdotal evidence used in an argument is itself a form of anecdotal evidence. As stated above, the number of admins desysoped for inactivity who then return to be active users is fairly low, and the number of admins who are desysoped for cause is, statistically speaking, basically indistinguishable from zero. Sysops who maintain, and return to maintain barely a pulse is itself a security problem as I'm sure many know. And unfortunately, there is simply no objective measure of community time wasted on returning sysops who make run-of-the-mill messes not worthy of the exceedingly high standards set by ArbCom. I can think of one in the past few weeks off the top of my head, with an admin that was desysoped for inactivity, and remained an inactive admin for years before really reengaging the project. I don't want to call people out individually. Feel free to shoot me an email. Personally, I think that much of this can be solved simply by requiring returning admins to reengage the project prior to requesting access, rather than granting access based on the possibility that they may reengage at some point in the future. GMG^talk 21:28, 30 July 2019 (UTC)