Wikipedia talk:Administrators/Archive 19

Archive 15

←

Archive 17

Archive 18

Archive 19

Archive 20

Archive 21

→

Archive 23

BN request from Andrew C

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. Andrew C's RFA had 61 supports, 1 decline and 1 neutral. He has a clean record on Wikipedia (way cleaner than mine), and declining his request and actually requesting him to go back through RFA again is moronic. We have WP:IAR for a reason, it would seem to fit for this reason.  ►К Ф Ƽ Ħ◄  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)

User:TonyBallioni 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. Beeblebrox (talk) 18:25, 21 March 2018 (UTC)

Reverts discussion clarity

@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. E to the Pi times i (talk | contribs) 15:02, 11 April 2018 (UTC)

Yes, unrelated. As I said, I disagree: when it comes to "becoming an administrator" I would absolutely say the guide should be linked as the main page. WP:RfA itself is arguably the main page, but I think it's patently unhelpful to link that page prominently. The guide is helpful, and links to plenty of other documents like 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.

Take a look at the wireframe and leave us your feedback. For the Anti-Harassment Tools team, SPoore (WMF), Trust & Safety, Community health initiative (talk) 19:12, 31 May 2018 (UTC)

Interface administrators

I have started a discussion about the new interface administrator user group at WP:VPM#RFC: Interface administrators and transition. Please take a moment to review and/or comment. --Izno (talk) 14:45, 30 July 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)

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)

Clarifying "controversial circumstances"

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

At a WP:BN thread, Xeno said:

"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)
  • This is explicitly not about any individual user and is intended only to match current practice. If you think things should be more explicit than at present then please make an alternative proposal that does that. Thryduulf (talk) 19:56, 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/enwiki/w/index.php?oldid=851052847#Clarification_request:_Return_of_access_levels –xeno^talk 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)
  • Indeed, as noted the wording in point 1 is the defacto current standard anyway and has avoided mob-desysop, although not mobs. Thryduulf (talk) 17:34, 17 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)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

RfC: blocking the admin who blocked you

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)

Password confirmation for some admin actions

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Due to the recent incidents of compromised admin accounts causing trouble, I propose that some admin actions be confirmed with a password. Such actions that might require confirmation include:

• Blocking confirmed or extended confirmed accounts
• Protecting pages
• Deleting pages
• Granting or revoking user permissions requested by user accounts
• Editing fully protected pages
• Any other actions likely to be abused by hackers

I know that this extra security will be useless if the hacker knows the admin's password, but it will help if the hacker gained access to the account through bypassing the login or if the admin accidentally forgot to log out of a public computer. - ZLEA _Talk\^Contribs 17:37, 28 December 2018 (UTC)

Aside from the fact that all the recent incidents are where the attacker clearly had access to the password, do you think it is reasonable to make admins to enter their password once every few minutes or even once a minute or less - since an active admin would often be doing those sort of actions at that rate? Galobtter (pingó mió) 17:47, 28 December 2018 (UTC)

Something like this has been discussed to some degree for CU/OS (pinging Risker as she’s been a voice of sanity on these things.) My position on that discussion as well as this is that action based authentication is a waste of time that is extremely burdensome to the end user and provides little added benefit, as what we’re essentially talking about is physical security and if the people I live with want to use my open laptop on the couch to mess up Wikipedia while I’m in the bathroom, I have bigger issues than Wikimedia. TonyBallioni (talk) 17:53, 28 December 2018 (UTC)

I'm not suggesting that all actions be confirmed, but the most serious. Maybe admins should confirm when editing the main page, when blocking another admin, or granting permissions, and not the when performing the other actions listed. You've seen what an admin account in the wrong hands can do. The possibility of several accounts being compromised at around the same time by knowledge of passwords is low. To me it's obvious that at least one of the recent hacks was not done in this way. - ZLEA _Talk\^Contribs 18:08, 28 December 2018 (UTC)

I regularly block 5+ accounts and have blocked over 20 at one time. Anyone who works SPI on the regular has. I’ve also deleted at least 50 pages at once using d-batch. The added benefit of my roommate not being able to do that doesn’t outweigh the significant cost in terms of my time. TonyBallioni (talk) 18:20, 28 December 2018 (UTC)

I don't expect there to be much enwiki customization for this, however the larger issue is being discussed in phab:T197136 and related tasks. — xaosflux ^Talk 18:22, 28 December 2018 (UTC)

• Well, simply put...if the account is compromised (i.e., someone other than the rightful account owner has the password), then this will prevent absolutely nothing. So, let's stick to the basics. Do we want admins to do the things listed above? (I think yes.) What is the advantage of making things more difficult for admins to do these tasks? In other words, what's the risk/benefit ratio? On what basis would we think that any of these actions over the last month (an arbitrarily selected period) were committed by inappropriate access to an admin account by someone who did not already have the password? Do we have *any* evidence that *any* of these actions were committed in this way? How many admin helper tools and scripts would have to be redesigned or rebuilt in order to allow the insertion of a password? How many admins are going to go to protect a page, realize they have to log in again, and just not bother? Would this apply to each individual action, and if so, what about times when admins block a whole series of socks? Would adminbot operators reprogram their bots, or would they just discontinue them? And let's talk about the security angle here, as well. The more times someone has to enter their password, the higher the likelihood that their password will be captured. And if the admin has elected to activate 2FA...they will have to get their new token as well.

  Bottom line, unless there is some genuine evidence that there are so many routinely compromised admin accounts that this is actually a problem, I think the hypothetical risk is dwarfed by the real cost (including decreased security) that this would bring. On the other hand, I do agree that admins need to better articulate and illustrate that they do take account security seriously. I just don't think making it harder to do admin tasks (and this would make things a LOT harder) is really the answer. Risker (talk) 18:27, 28 December 2018 (UTC)

• This is likely to make things less secure, rather than more. –xeno^talk 18:48, 28 December 2018 (UTC)

• Software design by committee is generally a bad idea when the committee members aren't software engineers. I recommend that you request tightening security of admin accounts and then leave it to the software engineers to figure out how to do that. Wikipedia's 2FA implementation is defective to the point of being useless. If anybody wants to connect me with a developer I could discuss with them possible approaches that are known to work. Jehochman ^Talk 19:02, 28 December 2018 (UTC)

• Oppose per Risker, Jehochman and TonyBallioni. This would massively decrease admin productivity and so motivation. Also it doesn't defend against the kind of hacks we've been seeing recently: these exploit password reuse, so the attacker knows and can keep entering the password to do naughty things. 🎄BethNaught🎄 (talk) 19:07, 28 December 2018 (UTC)

The only people who wuld support this are that lot at @HTD.borg :D ——SerialNumber54129 19:53, 28 December 2018 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

the effect of the five-year clause

In case anyone's curious, since the five-year clause became policy in March, by my read of Wikipedia:Inactive administrators/2018, a total of 7 admins permanently lost their tools this year, and a further 2 will follow if they don't edit before the new year. This is about what I expected, and why it was defined as a "slight tweak" and not a major change. Beeblebrox (talk) 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. Beeblebrox (talk) 23:24, 29 December 2018 (UTC)

New RFC on activity standards

see Wikipedia:Administrators/2019 request for comment on inactivity standards Beeblebrox (talk) 20:48, 23 January 2019 (UTC)

"Administrators may be removed by Jimbo Wales, by stewards, or by a ruling of the Arbitration Committee."

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

The proposal passess; the page will be amended as proposed. Primefac (talk) 18:57, 27 January 2019 (UTC)

---

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

  Indeed, I do not mean to constrain stewards from acting in emergency situations. This could be clarified further down. –xeno^talk 19:07, 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)

• 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.

  1. 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.
  2. 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
  3. 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.
  4. 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. –xeno^talk 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. –xeno^talk 03:39, 8 December 2018 (UTC)

Offtopic, I was wrong ~ Amory (u • t • c) 14:57, 8 December 2018 (UTC)

This is neither here nor there, but one thing I'd like is for the community and/or ArbCom is to define when or how a user starts or stops being an administrator. Is it if and only if they currently have the +sysop group, or is it if they could? It's a minor point perhaps, but comes up in the cracks here 'n there. ~ Amory (u • t • c) 12:21, 8 December 2018 (UTC) @Amorymeltzer, as far as I'm aware it's always been "do they currently have the bit?", not "are they entitled to it if they want it?". This comes up reasonably often with regards to the more esoteric permissions—e.g., as a former arb I'm entitled to be added to the functionaries mailing list on request, but it wouldn't make sense to treat me as a member. With regards admins, the reasons for not treating temporarily desysopped admins as still being admins are fairly straightforward; there's no reason to assume that they've kept up with changes in policy, plus counting them as still being admins distorts the count. The definition should be a straightforward "do they appear on Special:ListUsers/sysop?". ‑ Iridescent 14:27, 8 December 2018 (UTC) ​I agree that it has always been assumed to be that, but has that been affirmatively expressed/decided? What if Fred tried to impose discretionary sanctions before the recent case closed? What if Lourdes had in the months between her RfA and taking up the bit? As I said, it's an incredibly minor point, but if a steward were to desysop someone, what is the default view of the community/ArbCom before the community/ArbCom has made a decision? It's mostly an academic/bureaucratic flight of fancy, but, hey, you never know. ~ Amory (u • t • c) 14:50, 8 December 2018 (UTC) Amorymeltzer, Wikipedia:Arbitration Committee/Discretionary sanctions#Role of administrators: To act in enforcement, an administrator must at all relevant times have their access to the tools enabled. Former administrators – that is, editors who have temporarily or permanently relinquished the tools or have been desysopped – may neither act as administrators in arbitration enforcement nor reverse their own previous administrative actions. Galobtter (pingó mió) 14:53, 8 December 2018 (UTC) Whelp, that'll teach me to not read! Thanks, pie on face. ~ Amory (u • t • c) 14:55, 8 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. –xeno^talk 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. –xeno^talk 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)

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

• 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. –xeno^talk 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. –xeno^talk 21:14, 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. –xeno^talk 13:35, 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)

  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. 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 Andrew Davidson (talk · contribs). --212.186.133.83 (talk) 15:25, 8 December 2018 (UTC)
  • Whatever minor function Jimmy Wales had on Wikipedia post-Bish-block now is basically exercised by the WMF and Trust & Safety in particular. If an admin on a project is behaving so badly to require intervention, the WMF will intervene. This is even more the case in regards to functionaries. The WMF recently removed the checkuser flag from a user on ar.wiki and zh.wiki has no local CUs per a decision from the WMF office. On the off chance that reserve powers are needed, it is much better to have them exercised by actual professionals who are paid to do this and who generally speaking operate within strict guidelines because of the potential for legal liability rather than some person who really hasn't had a major place on the project he founded in around a decade. TonyBallioni (talk) 20:59, 8 December 2018 (UTC)
    • Jimmy Wales has a permanent seat on the WMF's Board of Trustees which is its "ultimate corporate authority". That seems quite a major place and it is to be expected that his priority will be that highest level of governance rather than the minutiae of a particular project. That gives him formal power and the founder bit gives him de facto power. As none of that seems to be changing, the policy should not change. Why has this wording change been proposed? It just seems to be tinkering for no particular reason contrary to WP:CHAOS. Andrew D. (talk) 11:35, 10 December 2018 (UTC)
      • You know as well as I do that the board does not interfere on projects except in the most extreme circumstances (Rschen7754 can likely tell you the last time there was a board action on a project.) Office actions are more frequent because 1) they’re easier to implement than board actions and 2) carry less legal liability since you can always claim a staff member is an idiot and fire them, whereas an action by the full board is significantly more difficult to write off. TonyBallioni (talk) 14:58, 10 December 2018 (UTC)
        • If they have I am not aware of it. The closest they have come is writing the policies regarding access to private data. --Rschen7754 01:16, 11 December 2018 (UTC)
      • The Wikimedia Foundation (and accordingly the board of trustees, through the WMF) can choose to override any and all procedures, so it really isn't necessary to state it on every guidance page. Whoever owns the servers makes the rules. isaacl (talk) 19:28, 10 December 2018 (UTC)

      Andrew Davidson: I believe I came to this section after reading the decision of a recent arbitration case concerning the removal of administrator rights, and noticed what seemed to be an erroneous description of policy. That's why I proposed the change. I'm not sure how WP:CHAOS applies. –xeno^talk 19:45, 10 December 2018 (UTC)

      • The relevant point of WP:CHAOS is "Our purpose is to build an encyclopedia, not to test the limits of anarchism. ... Wikipedia is not an experiment in democracy or any other political system. ..." So, arbitrary tinkering with our constitutional policies for no good reason, without a mandate, is improper. Andrew D. (talk) 10:38, 11 December 2018 (UTC)

• Comment Proposal appears to be create a Power vacuum and this proposal and arbitration Committee ruling appear to be mutually exclusive as they seem to prefer Stewards over Crats acting in emergency This recent case as per Point 10 of a recent Arbcom case states that "The 2011 RFC on bureaucratic removal of administrative permissions states that bureaucrats may remove permissions upon request of the administrator involved, at the request of the Arbitration Committee, or due to inactivity.There was no consensus to allow bureaucrats to remove administrative permissions in emergency situations."
  .Now they have been told not to do this even in an emergency that is even if the account is compromised or admin turns rouge goes on deleting spree or blocking spree.While in reality it is only the arbcom which can make desyop permanent personally see no need to change the wording as in a extreme circumstance if the arbcom is not able to resolve an issue .We can go to Jimbo or the stewards that option needs to be open though in 99.99% it is not required ,Do feel we do need Reserve power. As per Andrew Davidson and Rschen7754. Pharaoh of the Wizards (talk) 02:21, 13 December 2018 (UTC)
• Support per reality. Boing! said Zebedee (talk) 12:18, 14 December 2018 (UTC)
• Oppose Even if not exercised, the possibility of a decision to remove rights by somebody other then arbcom (e.g. Jimbo) lends at least a bit of extra much-needed accountability. North8000 (talk) 12:57, 14 December 2018 (UTC)

  You should check out what happened the last time JW exercised this reserve power. –xeno^talk 13:23, 14 December 2018 (UTC)

  We already have that. His name is Jalexander-WMF and he’s a paid professional staffer who can be fired if need be (a real positive) and who can make difficult calls when local communities are unwilling to. This is not a theoretical power like Jimmy Wales’: he and the WMF have removed user rights on projects within the last two months. This is a holdover from the pre-Trust & Saftey days. Nothing more. TonyBallioni (talk) 19:20, 14 December 2018 (UTC)

  And less than a day later we don't :P Galobtter (pingó mió) 13:23, 15 December 2018 (UTC)

  ​Well, we do, it's just now someone else. ‑ Iridescent 13:38, 15 December 2018 (UTC)

  Yeah yeah, I just found it funny that TonyBallioni's statement became dated the very next day. Galobtter (pingó mió) 13:53, 15 December 2018 (UTC)

  This policy page, though, isn't a law, or a contractual agreement. Should anyone feel that an appeal to Jimmy Wales would be helpful, they are free to do so, and if Wales decides to intervene via the Wikimedia Foundation, it can happen regardless of what this page says. So a route for accountability through the WMF is always there, since the owner of the servers makes the rules. isaacl (talk) 23:46, 14 December 2018 (UTC)

• Support - The superpowers of Jimbo Wales are a relic from a bygone era. He does not own WP and really should not even have a permanent seat on the WMF Board, if one gets right down to it. Nor should he have Supreme Superdecider Wikipedia Gameplayer privileges, which is what the current wording ensures, even if he has shown the maturity and political sense not to make use of them in this era. Let's get ourselves onto an orderly basis driven by the rule of law — which the new wording does. Carrite (talk) 18:05, 14 December 2018 (UTC)
• Support - archaic policy with no connection to current reality, citizen Wales has no real authority to remove administrative privileges granted by the community.--Staberinde (talk) 11:37, 15 December 2018 (UTC)
• Support, there is no reason in this day and age to have any individual user named in a policy. —Kusma (t·c) 14:28, 15 December 2018 (UTC)
• Support - The changes mentioned seem perfectly logical and sensible, and they also clearly reflect how things should be handled in reality. TheGeneralUser (talk) 02:51, 27 December 2018 (UTC)
• Support removal of any specific person as authority from policies. Removing stewards from that sentence also makes sense per the nomination. ~ ToBeFree (talk) 00:55, 29 December 2018 (UTC)
• Well just letting you know that -- Stewards had to desysop someone in 2018 on a project after firing a global lock, as some technical issues (fixed now) has caused the locked users to continue blocking/deleting/admin stuff. Just FYI. — regards, Revi 16:48, 27 January 2019 (UTC)
• Oppose This is a structural change, not a wording cleanup. Also removing accountability for admins when there is already too little. North8000 (talk) 17:25, 27 January 2019 (UTC)
  • North8000, you’ve already opposed. Also, admins aren’t accountable to Jimmy Wales as it is. If he tried to desysop, ArbCom would likely desysop him. TonyBallioni (talk) 17:32, 27 January 2019 (UTC)

Oops, I forgot. This has been open a long time. I willl strike. North8000 (talk) 19:48, 27 January 2019 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Removing "voluntary removal" from the 5-year etc rule

As discussed extensively at WP:BN, it is now clear that UninvitedCompany, in good faith, misapplied without consensus the "voluntary removal" of tools to the five-year rule section. I have reverted the changes. Editors can discuss below if they need this to be included, and if consensus is gained for the same, the same can be done. Lourdes 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. Beeblebrox (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 the diff.

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)

Origin

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)

Discussion at WP:VPP#RfC: Should the Administrators policy be amended to include a recommendation to use two-factor authentication?

 You are invited to join the discussion at WP:VPP#RfC: Should the Administrators policy be amended to include a recommendation to use two-factor authentication?. - MrX 🖋 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)

Proposed change

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)

Restoration of access following involuntary desysop by WMF Office

• 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 Wikipedia:Office action, 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 Wikipedia:Office action, 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)

Is "History" an appropriate section on a policy page?

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)

Big picture

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)