Archive 35

←

Archive 38

Archive 39

Archive 40

Archive 41

Archive 42

→

Archive 45

I split this to a new section as it wasn't really about the prior requester so much as a general inquiry. — xaosflux ^Talk 17:55, 19 February 2019 (UTC)

Thank you (though the absence of grandfathering clauses does discourage people handing in the tools when going on a long break). Would it be possible to say what the current requirements are for me in terms of activity (both editing and admin actions) if I went inactive now (with or without voluntarily giving up the sysop bit), and how I or any other admin considering going inactive and/or handing in their bit, would work out these requirements (i.e. is the length of time calculated from the point of going inactive or from the last logged action)? Or is it generally considered that active admins should be capable of working this out themselves? The reason I ask is that the current wording of the policy seems to imply that if an admin has had no logged actions for over five years (but has been editing), and they voluntarily give up their bit, then they are also giving up the right to request the bit back and have to go through RfA again. I am not sure this is actually what was intended, but I think the current wording does imply that. (If this should be a new section, feel free to create that.) Also, would my talk page be the only place I would get notified of any changes to this inactivity policy? Thank you for the reminder about the Administrators' newsletter. Carcharoth (talk) 17:25, 19 February 2019 (UTC)

@Carcharoth: the verbiage of the updates to the newer '5 year rule' was a bit clumsy, and the last time it was discussed the current summary was born: For any administrator who does not have a logged administrator action in five years, bureaucrats should not restore administrator access upon request. In this case it doesn't matter how/why someone stopped being an admin. — xaosflux ^Talk 17:55, 19 February 2019 (UTC)

As far does someone have to personally deliver policy change news to you: nope (there is no policy that requires such :D ) - though things like ADMINNEWS usually to carry this information. — xaosflux ^Talk 17:56, 19 February 2019 (UTC)

Xaosflux, where was that discussion of the verbiage to the five year rule? The original RFC was to apply that five year rule only to former administrators who were desysopped for inactivity, not voluntary removal. That is to say, an admin who hadn't made a logged edit in five years, requested tool-removal on BN, and then requested them back the next day, would get them back. Useight (talk) 18:23, 19 February 2019 (UTC)

@Useight: it was updated by User:UninvitedCompany following discussions here last year. — xaosflux ^Talk 18:34, 19 February 2019 (UTC)

See Wikipedia:Bureaucrats'_noticeboard/Archive_39#Refactor_of_Wikipedia:Administrators#Restoration_of_adminship. -- KTC (talk) 18:44, 19 February 2019 (UTC)

I believe the original RFC was extremely unclear. The originator of the RFC used confusing language that resulted in a "No" !vote being a vote in support of a policy change. Several early expressions of support (er, "No" !votes) offered tweaks to the wording, and the closing summary was a broader change than the original proposal. I believe that the closing summary -- that adminship should not automatically be restored when 5 years has elapsed between the last logged action and the request for restoration of access -- is a reasonably accurate reading of the community sentiment at the time of the RFC. My updates to the policy page reflected that. UninvitedCompany 22:51, 19 February 2019 (UTC)

Thank you for the replies. The original wording was added here (by Lourdes). The change that UninvitedCompany made is here. The major change by UninvitedCompany in the wording is to the status of those who request voluntary removal. Previously, those who requested voluntary removal could ask for the tools back at any time. This has been changed to this '5-year rule' regardless of whether the tools were removed for inactivity or voluntarily given up. This was clearly not the intent of the original RfC. I am pinging Beeblebrox (who started that RfC) and the closer (Fish and karate) to try and get this clarified. The question I am trying to get a clear answer to is whether an admin who is actively editing but not using the tools, and voluntarily gives them up, will be affected by this five-year rule? It may be that a further RfC is needed to clarify this, and that in the meantime the previous wording should be restored. On a slightly pedantic point, can a request to give up the admin tools (which will get logged by the bureaucrat action) be considered a 'logged admin action'? Technically, no, but it does show that the admin is active and taking an action in relation to their tools. Carcharoth (talk) 11:43, 20 February 2019 (UTC)

I agree with Carcharoth. What Uninvited has done with their edit is in the spirit of the connected RfC; but the fact is that the said RfC never focused on the voluntary stuff. Revert till clarified by consensus. Lourdes 11:47, 20 February 2019 (UTC)

I closed the RFC as I saw it, how that translates into changes to Wikipedia:Administrators wasn't really in the scope of the RFC, but I would say two things - one, the RFC covered inactivity-removals only, so whether that five year requirement should also extend to those who have voluntarily handed in the bit is not determined within the RFC I closed, and two, the amount of times this will ever practically matter is going to be really, really small, we're now talking about edge cases of edge cases. On the pedantic point, I would say no, a request to give up the tools is not a logged admin action by the (former) administrator in question, it's a logged action by the bureaucrat who fulfilled the request. Fish+Karate 13:13, 20 February 2019 (UTC)

Fair point about edge cases. I found the admins-by-editing-activity tracking pages, but are there statistics anywhere tracking admins by logged admin actions, and is there a list anywhere of former admins (desysopped for inactivity) who have to go back through RfA because they have now crossed the threshold established by these 3-year and 5-year rules (maybe no-one has yet, but I suspect some former admins will have crossed this threshold), or is this checked on a case-by-case basis by bureaucrats for each re-sysop request? I suspect there may be some former admins who gave up the tools voluntarily, who also fall under these 3-year and 5-year rules, but am not about to try and check that myself. It shouldn't be impossible for someone to extract the data and do the calculations, though. I did try and do a table listing the various combinations of active vs inactive, voluntary desysp vs inactivity desysop, and 3 years editing inactivity and/or 5 years admin inactivity, but it was taking too long. Carcharoth (talk) 13:48, 20 February 2019 (UTC)

@Carcharoth: the table below may be what you are looking for, resigned admins that are not totally inactive from editing, but whose last admin action is 5+ years ago that we would currently refer to WP:RFA. — xaosflux ^Talk 14:33, 20 February 2019 (UTC)

• Examples: The list of 78 admins here: Special:PermaLink/884252872 are examples of current admins, that have had 0 logged actions in 5+ years, but have at least one edit in the last 13 months so haven't been removed for inactivity. Under the 5 year rule wording above if they stop being an admin they would need to ask for it back via WP:RFA. This was a fast query, and the actual number may be higher (as this query counted any logged action, not just administrative logged actions). — xaosflux ^Talk 14:12, 20 February 2019 (UTC)

Thank you. On a practical matter, the notification given to the admins who have their permissions removed due to inactivity may need to be updated to be more specific (or at least link to the relevant section). Currently the wording is 'Subject to certain time limits and other restrictions, your administrative permissions may be returned upon request at WP:BN'. That example is from the talk page of a former admin who is still lurking and left this message. They went inactive around a year ago and may not be following the current discussions and may not be fully aware that there are 3-year (reset to 9 February 2022 by that edit) and 5-year thresholds (22 November 2023) after which they will have to go via RfA rather than this noticeboard (BN), though that is unlikely in this case, I think. Thanks for the two lists. By table, I meant a flow chart of the various possibilities presented as generic outcomes. Carcharoth (talk) 14:43, 20 February 2019 (UTC)

The "subject to..." section you referenced above should cover the edge cases - we expect administrators to be able to look at the admin policy. — xaosflux ^Talk 14:47, 20 February 2019 (UTC)

Yes, I am aware of the 3-year and 5-year limits. Honestly, if I reach that point, I doubt I'd ever be looking for the tools back, either due to being gone for good or just happily editing without them. The limits are pretty prominently posted in the resysopping section of the administrator policy. Reaper Eternal (talk) 06:45, 22 February 2019 (UTC)

• Since I was pinged here, just chiming in that it was not my understanding that the five-year rule applied in the case of voluntary removal. It probably should, but I deliberately aimed low with the proposal because it has been so difficult to make any changes to this policy. Beeblebrox (talk) 19:55, 20 February 2019 (UTC)
  • Thanks. Not sure where to go from here. I would like to see the inconsistency in how the voluntary removal of tools is handled sorted out, but I am also aware that there are ongoing discussions elsewhere, to which UninvitedCompany has just recently added (in his own words) a wall of text. So what is best to do? To continue here to ask for the situation with regards to the thresholds for re-requesting tools in relation to the voluntary removal of tools (as opposed to removal for total inactivity) to be clarified, or to raise it over there (which may get lost in the noise)? Carcharoth (talk) 09:56, 21 February 2019 (UTC)
    • Carcharoth- I think it would be best taken up at WT:Administrators. UC noted his changes in this thread. –xeno^talk 13:52, 21 February 2019 (UTC)
      • I could. But I am disillusioned that despite pointing out that this change was made without consensus, and numerous people saying that the ultimate change made was not what was originally proposed, no-one seems willing to admit to having made a mistake here and reverting until a clearer consensus can be gained. One of the comments in the original RfC stated: "The proposal should also specify whether admins who voluntarily resigned not under a cloud can ask the tools back without an RFA and during which period this could happen. Otherwise, if it passes, it might lead to inconsistencies." It feels like when a mistake is made, that those pointing it out have to do the work, rather than those who made the mistake. It feels like a bureaucrat acting as a super-user to make changes based on their re-interpretation of an RfC, rather than having to do an RfC to ascertain what the actual consensus is. I will leave a note at WT:ADMIN and see if that helps. Carcharoth (talk) 14:20, 21 February 2019 (UTC)
        • Carcharoth, I have reverted UC's additions and started discussions at Wikipedia talk:Administrators#Removing "voluntary_removal" from the 5-year etc rule. Thanks, Lourdes 14:38, 21 February 2019 (UTC)

We can make an immediate good faith common sense revert of the "voluntary" part. There's no need to wait for reverting something that was added without consensus. Lourdes 10:05, 21 February 2019 (UTC)

• Carcharoth, I'm just coming across this discussion now. My goal in the original edit was clarity, not any meaningful change in policy. I am pleased that the policy is finally receiving the attention it deserves, and hope that we can do something with the original text to improve it even if the more substantial changes under discussion at the new RFC are not adopted. I believe that the idiosyncrasies of the policy -- particularly, the separate treatment of resignations from inactive admins; and the way some of the time periods are calculated -- are just artifacts of the way it was drafted and changed by RFCs over the years. If we wish to retain those, I believe we should still make the policy clearer, by breaking out how it affects former admins based on the circumstances of their departure. UninvitedCompany 18:59, 21 February 2019 (UTC)

• There are about 50 admins in Wikipedia:Former_administrators/reason/resigned who resigned in good standing the remaining resigned in during arbcom cases and other issues which may come in   "controversial circumstances" or are already in long term inactive.Out of this 50 around 15 are eligible to be resysoped currently there are around 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.It was open from 31 December 2017 to 3 March 2018 for a considerable period of time and was posted in WP:CENT and consensus was clearly in favour. Pharaoh of the Wizards (talk) 13:25, 21 February 2019 (UTC)

• Realistically, I don't expect Stephen to come ask to be admin fifteen years after he resigned, and I don't think he'd be shocked when his request wasn't acted on. The fact that only fifteen users are even eligible makes them a fringe case in of itself. I think bureaucrats could handle those fifteen cases should they arise, which isn't a frequently occurring problem. — Moe Epsilon 15:27, 21 February 2019 (UTC)

• Would you agree that even if none of them wanted the tools back, it would have been courteous to notify those former admins that this change had removed their right to re-request the tools and that they would have to go to RfA instead? Carcharoth (talk) 15:33, 21 February 2019 (UTC)

• I think the answer to that question depends on whether you see adminship as an entitlement given as a reward to favored contributors, or as something granted based on the needs of the project. Historically, we've always acted like it's the former and claimed it's the later. UninvitedCompany 18:35, 21 February 2019 (UTC)

• I was hoping for a more specific answer. You made that change. You said in your edit summary that "The intent is that the actual policy remain unchanged". In fact, your change did change the policy and did change the status of those former admins. Would you, personally, agree or disagree that it would have been courteous to notify those former admins that your change had removed their right to re-request the tools and that they would have to go to RfA instead? This might seem a small deal now, but later changes might affect far more people and cause a lot of ill-feeling if not done more carefully. Carcharoth (talk) 12:44, 22 February 2019 (UTC)

Just opining here - but for anyone who wants to wave to no big deal banner - why would there be an issue for someone to run an 'I'm back and ready to help again' RfA - wouldn't you expect the same NBD support there? — xaosflux ^Talk 18:38, 21 February 2019 (UTC)

Espresso Addict (current rights · rights management · rights log (local) · rights log (global/meta) · block log)

Hello -- I am reporting back for administrative duties, if the bureaucrats consider that I retain the trust of the community. I would plan to patrol main-page errors, help out at DYK, and patrol the speedy categories I'm familiar with. Regards, Espresso Addict (talk) 08:56, 28 February 2019 (UTC)

I can't see any issues but there's a standard 24 hour wait before we process these requests. WJBscribe (talk) 12:02, 28 February 2019 (UTC)

Seems fine, prior removal was by self request, recent admin activity. Welcome back to mopping. — xaosflux ^Talk 12:40, 28 February 2019 (UTC)

 Done. WJBscribe (talk) 10:54, 1 March 2019 (UTC)

The following Wikipedia:Inactive_administrators/2019#March_2019 administrators are being desysoped due to inactivity. Thank you for your service.

1. Schneelocke (talk · contribs · blocks · protections · deletions · page moves · rights · RfA)
2. Siroxo (talk · contribs · blocks · protections · deletions · page moves · rights · RfA)
3. Sarah (talk · contribs · blocks · protections · deletions · page moves · rights · RfA)

— xaosflux ^Talk 00:11, 1 March 2019 (UTC)

• Noting for the record that Special:Log/Siroxo shows Siroxo last logged action as March 2008, which is ~11 years since a logged action, meaning he would not be eligible for resysop under the 5 year rule. TonyBallioni (talk) 00:18, 1 March 2019 (UTC)
• I'm sad to see Sarah on this list. It does upset me when I see someone whom I met in my first weeks on Wikipedia go inactive and/or lose their adminship through inactivity. :'( Sarah was so helpful, so encouraging to me back in the day. She is definitely someone who is behind why I'm still editing today. Acalamari 11:51, 1 March 2019 (UTC)

Per the bureaucrats policy the following bureaucrats are being removed under provision 2. This is purely a procedural action as a result of bureaucrat activity tracking. Due to lenghty bureaucratic inactivity, restoration of bureaucrat access will require a new requests for bureaucratship.

• Kingturtle (talk · contribs · blocks · protections · deletions · page moves · rights · RfA)

With thanks for your many years of service, — xaosflux ^Talk 00:21, 1 March 2019 (UTC)

Removed. I join with thanks. --ᛒᚨᛊᛖ (ᛏᚨᛚᚲ) 00:55, 1 March 2019 (UTC)

Adding my thanks for Kinturtle for long service - part of the first batch of bureaucrats appointed by the community after the user right was created. WJBscribe (talk) 16:31, 1 March 2019 (UTC)

If I'm reading the timeline correctly this is the first time since 2004 there have been fewer than 20 bureaucrats here. 28bytes (talk) 03:44, 1 March 2019 (UTC)

There hasn't been a successul RfB since 2016... me and So Why in 2017 broke a streak of successful RfBs that had been uninterrupted since 2012 and nobody has even dare try for RfB since. On one hand I'm sure many would see the lessened need for 'crats to be a good thing overall, but others are obviously concerned about one of the two biggest factors (other than renames being globalized) being the slowing of RfAs and decline of adminship. Ben · Salvidrim! ✉ 04:07, 1 March 2019 (UTC)

The bureaucrat pool is pretty old (in Wikipedia terms, no comment on anyone's biological age!). With the exception of the slightly more sprightly Worm and 28bytes (who became admins in summer of 2011) all bureaucrats, regardless of how recently they passed, RfB have been admins for over 10 years. WJBscribe (talk) 11:41, 1 March 2019 (UTC)

Nah, we're definitely old in all aspects! :P But yes, I would like to see some newer admins, with newer accounts, become bureaucrats. That most admins and nearly all bureaucrats have held adminship for over a decade is worrying. Acalamari 11:51, 1 March 2019 (UTC)

But why? I am a Wikidata crat, there are three of us there, I am reasonably active, and I do not even make crat action every month because there are so few of them. Of course the English Wikipedia is way bigger in terms of editors, but was there any point in the last three years (after the renames were taken to Meta) that it was clear we do not have enough crats? Something which was not acted upon swiftly, or some chat there were not enough opinions?--Ymblanter (talk) 11:58, 1 March 2019 (UTC)

I don't think anyone's worried about lacking the necessary number of bureaucrats, more questioning whether we're representative of the current makeup of the community and whether we'd benefit from having newer blood with fresh ideas. By dint of who we are, we probably ingrain some rather old ideas into our approach... WJBscribe (talk) 12:12, 1 March 2019 (UTC)

But crats are not elected to provide fresh ideas, crats are elected to implement existing policies. In this respect, an active crat who has been around for a long time is the best one, because they have been continuously exposed to policy/practice evolution.--Ymblanter (talk) 12:16, 1 March 2019 (UTC)

RfAs are so brutal, it would take a truly exceptional candidate to want to weather a RfB election these days. Plus, when our current crew of bureaucrats can handle the few activities these days, it doesn't seem like it is worth it to venture an RfB, IMHO. Liz ^{Read! Talk!} 03:52, 2 March 2019 (UTC)

Right. I figure if more people believed we need more crats, it would be easier to recruit candidates. Enterprisey (talk!) 06:29, 2 March 2019 (UTC)

As with admins, I don't really think "we need more" is the right approach. Ideally, all admins should be crats, just like es-wiki does it (and they did not wreck their project either). Imho, cratship should be awarded to any admin after a year of adminship because if they couldn't be trusted, we certainly knew by then (and abuse concerns could be addressed by limiting the number of (de)sysops one crat can perform). Of course, as someone who the community twice rejected for cratship, my opinion might be a little biased. Regards SoWhy 20:21, 2 March 2019 (UTC)

• For the record, my view is that crats should be representative of the active community and that the the best current candidate is Primefac. What people other than me think is obviously their business. TonyBallioni (talk) 06:53, 2 March 2019 (UTC)
• Making it my business for the moment, ^^^ seconded. ——SerialNumber54129 12:24, 2 March 2019 (UTC)

More bureaucrats would be welcomed. As would more admins. And more editors. Being more friendly, encouraging people at every step, participation at and pushing back against excessive inflation of standards at RfX are good ways to help with these things. --Dweller (talk) Become old fashioned! 10:44, 4 March 2019 (UTC)

Under the Level 1 desysopping procedures, the administrator permissions of Bogdangiusca (talk · contribs · blocks · protections · deletions · page moves · rights · RfA) have been temporarily removed as a suspected compromised account.

Supporting: BU Rob13, KrakatoaKatie, GorillaWarfare

For the Arbitration Committee, Bradv🍁 18:21, 2 March 2019 (UTC)

Discuss this at: Wikipedia talk:Arbitration Committee/Noticeboard#Level 1 desysop of Bogdangiusca

• For some reason this was processed by a steward. Shouldn't have been needed since the account was already locked, but regardless there is no action we can take now. Reinstatement will require a request by ArbCom. — xaosflux ^Talk 18:27, 2 March 2019 (UTC)
  • It is part of the standard process when an account needs to be globally locked due to apparent compromise. Even if the account qualifies for lifting of the global lock, return of admin rights is not automatic and must be authorized by Arbcom. Risker (talk) 20:56, 2 March 2019 (UTC)
    • I think Xaosflux was asking, given the account was already locked and thus not an immediate concern, why the desysop request wasn't made locally. And I believe his second sentence said roughly what your second sentence said: clarifying for the archives that, given action by the steward, there was nothing for bureaucrats to do in this particular case until prompted by the Committee. ~ Amory (u • t • c) 22:17, 2 March 2019 (UTC)
      • We're both in agreement with the "ArbCom needs to request access restoration" (or I suppose an RfA COULD occur after an unlock) - though I also would never expect stewards to add the access back at all, even with a request from Arbcom - as that is something that would never constitute an emergency and can be handled locally. There is some follow up on the process/timing for local vs stewards handling at Wikipedia_talk:Arbitration_Committee/Noticeboard#Level_1_desysop_of_Bogdangiusca for anyone concerned. — xaosflux ^Talk 22:42, 2 March 2019 (UTC)
        • I personally don't care who dealt with it, as long as it was dealt with. My real concern WHY are we now dealing with Security Incident #4 to happen within the last 365 days? After everything that has happened, why do we still have admin accounts with no 2FA enabled, or at least using a strong unique password? With all of the security notices that have gone out, I consider this to be negligent, and the tools should not be restored until the user in question adopts better security measures.—CYBERPOWER (Chat) 18:45, 3 March 2019 (UTC)
          • For reasons explained at length in pretty much every previous discussion about 2FA, not every administrator is able to use 2FA even if they wanted to, and there are concerns about the Foundation's capacity to deal with the volume of issues. Thryduulf (talk) 21:33, 4 March 2019 (UTC)

            Thryduulf, Doesn't excuse not using a uniquely strong password. Ideally one should have both, but at the very least it should not be a reused password as other common sites, that are prone to data breaches. —CYBERPOWER (Chat) 22:16, 4 March 2019 (UTC)

Following the successful closure of Wikipedia:Requests for bureaucratship/DeltaQuad, please welcome DeltaQuad to the 'crat club. DQ, if you are fast enough there's a request above that will soon be actionable :D — xaosflux ^Talk 01:30, 13 March 2019 (UTC)

Welcome! Also, about 1.5 hours on the above item. ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 01:40, 13 March 2019 (UTC)

I promise not to action it unless it is at least 12 hours overdue! — xaosflux ^Talk 01:41, 13 March 2019 (UTC)

Done, let me know if I screwed up the paperwork at all...I'm sure I missed something. *looks for the thick how to be a crat manual* -- Amanda (aka DQ) 03:37, 13 March 2019 (UTC)

@DeltaQuad: mostly it is all at WP:CRAT - but for the most part everyone loves clerking for us (especially User:Graham87 - thanks Graham!) and will do most of the "paperwork" right away if you don't. — xaosflux ^Talk 03:40, 13 March 2019 (UTC)

@DeltaQuad: (Non-administrator comment) There is 1 small thing you missed - when you added back Reaper Eternal's sysop bit, you left them with the redundant extended confirmed flag. Xaosflux already took care of that here, but for future reference the standard procedure appears to be removing the extended-confirmed flag. Anyway, congrats! --DannyS712 (talk) 03:48, 13 March 2019 (UTC)

Thanks to you both. -- Amanda (aka DQ) 03:50, 13 March 2019 (UTC)

Welcome DeltaQuad! 28bytes (talk) 01:44, 13 March 2019 (UTC)

(And LOL at the mad scramble among the 'crats to close the first successful RfB in years.) 28bytes (talk) 01:45, 13 March 2019 (UTC)

Yes, definitely lol. -- Amanda (aka DQ) 03:37, 13 March 2019 (UTC)

Welcome to the 'crat club DQ. Mostly old fuddy duddies, but I was called spritely recently! ;) Worm^TT(talk) 09:09, 13 March 2019 (UTC

Yes, Worm That Turned...but by whom?!  ;) ——SerialNumber54129 17:37, 13 March 2019 (UTC)

Another one of those old fuddy-duddies welcoming you to the team. Useight (talk) 17:30, 13 March 2019 (UTC)

Who are you calling old?! Get off my lawn! –xeno^talk 15:25, 14 March 2019 (UTC)

Welcome, great to have a new face here! Warofdreams talk 14:15, 14 March 2019 (UTC)

Welcome! As to our edit-conflicting closers, I give higher marks to Nihonjoe's close, as he remembered to remove the "voice your opinion" link... Sorry Xoasflux ;) WJBscribe (talk) 15:36, 14 March 2019 (UTC)

<fist pump> Yes! ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 18:05, 14 March 2019 (UTC)

It will be a great moment of shame forever! But I did shoot first :D — xaosflux ^Talk 19:03, 14 March 2019 (UTC)

Under the Level 1 desysopping procedures the administrator permissions of Necrothesp (talk · contribs · blocks · protections · deletions · page moves · rights · RfA) have been temporarily removed as a suspected compromised account.

Supporting: AGK, Courcelles, GorillaWarfare, KrakatoaKatie, Mkdw, Worm That Turned

For the Arbitration Committee; Worm^TT(talk) 16:50, 24 March 2019 (UTC)

Discuss this at: Wikipedia talk:Arbitration Committee/Noticeboard#Level 1 desysop of Necrothesp

Please could a crat implement? I don't generally like doing so myself - conflict of hats. Worm^TT(talk) 16:52, 24 March 2019 (UTC)

Updated the list of supporting arbs (and fixed a typo). GorillaWarfare (talk) 16:55, 24 March 2019 (UTC)

 Done — xaosflux ^Talk 17:03, 24 March 2019 (UTC)

Please see Wikipedia_talk:Arbitration_Committee#Compromised_account. RhinosF1^(chat)_{(status)(contribs)} 16:46, 24 March 2019 (UTC)

Hi, I don't intend to use administrator functions going forward. You could remove this flag. Thanks Christopher Parham (talk) 15:29, 25 March 2019 (UTC)

 Done with thanks for your prior service. — xaosflux ^Talk 15:35, 25 March 2019 (UTC)

• Dreamy Jazz Bot (BRFA · contribs · actions log · block log · flag log · user rights)

Greetings. Can someone please revoke the bot flag from this account, per the user's request? Dreamy Jazz has retired and requested a self-block for both their main account and bot, which I have actioned, but a Bureaucrat is needed to complete their parting requests.[8] Thanks! ~Swarm~ {talk} 20:58, 31 March 2019 (UTC)

 Done per operator request. — xaosflux ^Talk 21:02, 31 March 2019 (UTC)

Greetings! I haven’t used my administrator tools in quite a long time, and given my long absence from the community I think it’s best that those privileges be removed. Please remove my administrator flag at your convenience. Thank you for all that you do! Bratsche | talk 11:00, 1 April 2019 (UTC)

 Done, with thanks for your past service. Do feel free to let me know if there are other user rights you would find useful and I can grant those. –xeno^talk 11:28, 1 April 2019 (UTC)

The following inactive administrators are being desysoped due to inactivity. Thank you for your service.

1. Kyle Barbour (talk · contribs · blocks · protections · deletions · page moves · rights · RfA)
2. Kzollman (talk · contribs · blocks · protections · deletions · page moves · rights · RfA)
3. Madman (talk · contribs · blocks · protections · deletions · page moves · rights · RfA)

— xaosflux ^Talk 00:32, 1 April 2019 (UTC)

Sad to see Madman fall into shadow, given all the light he has created. With thanks to all three for their service. –xeno^talk 02:47, 1 April 2019 (UTC)

@Xeno:, I appreciate that. Thanks for the kind words. It's strange not being an admin, even though it's (!) 15 years later and a long time since I worked a lot here. I really did enjoy it. Kyle Barbour 05:07, 1 April 2019 (UTC)

@Xeno: Likewise appreciated. I don't think I did that much during my tenure, but time has probably made the memories fade. Do you mind removing the bot flag from MadmanBot so I can officially retire him too? Cheers, — madman 22:07, 6 April 2019 (UTC)

@Madman:  Done — xaosflux ^Talk 01:07, 7 April 2019 (UTC)

Hey @Xaosflux: — thanks for handling this. I got the email a while ago and meant to voluntarily let go of the mop and just forgot. Thanks for managing it and sorry for the extra work, I meant to deal with it myself and hope it wasn't too much of a bother. Kyle Barbour 05:05, 1 April 2019 (UTC)

@Kyle Barbour: no worries for sure! And of course 'edit' and 'create article' are only ever one click away for you if you want to get back in to the swing of things! — xaosflux ^Talk 11:55, 1 April 2019 (UTC)

Please see Wikipedia:Requests for adminship/RexxS/Bureaucrat chat. Maxim_(talk) 18:49, 8 April 2019 (UTC)

@Maxim: perhaps dropping a MMS to Wikipedia:Bureaucrats/Message list would be useful as well? — xaosflux ^Talk 21:03, 8 April 2019 (UTC)

Done. It's the first time I've used MMS; it took me longer to figure out than I would have liked to. :p Maxim_(talk) 22:09, 8 April 2019 (UTC)

Glancing over the most recent RfB, there's some discussion regarding the role of bureaucrats in the community, including but not limited to using IAR for bureaucrat actions. I've always felt there is a bizarre dichotomy of picking admins with particularly good judgment but relegating to fairly automated button pushing. I think it would be useful to have a discussion on the expectations of the community with regards to the role of bureaucrats.

My thoughts are summarized as follows. The recent arb case involving bureaucratic actions ended in requests from several arbs on the Proposed Decision page to not do what I did again. There were two first choice and one second choice vote for admonishing me, one vote to de-crat me, and one thank you. The circumstances of that case are largely moot now (no self-unblocks anymore). Regardless, I would argue there does remain room for bureaucratic judgment/discretion. At any rate, the rumours of my shaming are somewhat exaggerated. :p

I'm pinging @Xaosflux, Ritchie333, and Cyberpower678 as from looking over the RfB, they commented in particular on the recent arb case. Maxim_(talk) 22:28, 2 April 2019 (UTC)

I would suggest having the discussion over at the Village pump (not sure which sub-board) as that will attract a wider participation from the community. ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 22:53, 2 April 2019 (UTC)

Or at least linking in to this. — xaosflux ^Talk 22:59, 2 April 2019 (UTC)

Please do that. Village pump discussions are too hard to follow unless you stay sitting there. --SmokeyJoe (talk) 00:22, 3 April 2019 (UTC)

Maybe move it over to Wikipedia talk:Bureaucrats. –xeno^talk 15:50, 4 April 2019 (UTC)

• I think that if we 'crats invoke IAR to do something, it needs to be clearly (though perhaps not immediately evident to an outside observer) in support of a community need to maintain or improve the project. As an example I used IAR last year related to granting temporary IAdmin access to maintainers in the absence of a community mandate authorizing it and it was more glowsticks-and-sporks than torches-and-pitchforks from the villagers. — xaosflux ^Talk 22:59, 2 April 2019 (UTC)
• The arb case in question was as a result of virtually everyone involved acting with a miscalibrated "sense of urgency" meter. If instead of clicking the "revert", "block", "(self) unblock", and "desysop" buttons each editor had instead put the keyboard down and eaten nachos and watched TV for an hour or three, there would not have been an arb case. So I'm not sure we want to make policy or even gauge community feeling on IAR actions based on that particular episode. I think people will give a lot of slack to IAR actions based on actual emergencies rather than perceived ones. 28bytes (talk) 23:51, 2 April 2019 (UTC)
  • +1 to that. That was an extremely rare set of circumstances, that as it happens is now impossible. A broad discussion of the role of 'crats in this era of WP is probably a discussion worth having, but I don't thin it should focus ont hat particualr incident or it's real or imagined after effects. Beeblebrox (talk) 00:31, 3 April 2019 (UTC)
  • It's possible that for everyone who jumped in, there were a dozen people eating nachos. But obviously it's the one person who acts fastest (or most severely) that determines the actual response. It's a bias that seems to affect a lot of admin areas. I wish there were a pithy "X effect" name for it. – Joe (talk) 05:44, 3 April 2019 (UTC)
  • I agree. That case involved the application of IAR to perform an emergency desysop where (no offence, Maxim) there wasn't really an emergency. Thereafter two questions got somewhat conflated, namely: (i) whether bureaucrats may ever invoke IAR to desysop in an emergency and (ii) whether, if they can, it had been an appropriate instance to do it. Question (i) remains undetermined. Indeed, there is a bit of a catch-22 here. If there was a community consensus allowing a unilateral emergency desysop by a bureaucrat, there would be no need to invoke IAR. Likewise, a rule that bureaucrats may never rely upon IAR would presumably also be subject to IAR... WJBscribe (talk) 11:49, 3 April 2019 (UTC)

    And that is not the only Catch-22, it becomes perversely a bureaucrat ignoring the emergency rules we have because someone else has ignored some other rules - rule ignoring good for me, but not for thee. Alanscottwalker (talk) 14:53, 3 April 2019 (UTC)

  • I also agree with this. I don't want to comment too much as mixing my old hat with my new hat, but I want to echo @Beeblebrox and WJBscribe: in their comments. Can someone tell me where the nachos refills are? My bowl is empty and someone forgot to restock the 'crat cupboard. :/ -- Amanda (aka DQ) 14:23, 3 April 2019 (UTC)
    • It's probably on "backorder" like the mythical TP for the functionaries' washroom. —DoRD (talk)​ 02:21, 4 April 2019 (UTC)
  • In my opinion, a lot depends on the history of the 'crat in question and the assumption of good faith. DeSysopping is very easy to correct (the switches move in both directions, you know). In theory, I would lean to supporting someone who has years of good wikiservice and good judgement, who made the call that it was an emergency, acted in that fashion and then brought everything to the proper venues. As WJBscribe said, a situation where consensus is clear is almost certainly not an emergency. Remember, different people will interpret the same situation differently, and neither is necessarily wrong. Emergencies require after-action reports because people have to interpret and react under time pressure. Thank you. -- Avi (talk) 04:33, 4 April 2019 (UTC)
    • That seems like an argument for ad hoc personal privilege. It's perhaps one thing when the community has no process, so that some one person thinks they have to aggregate power to themselves, it's another when the community processes have been articulated. When the 'when' of when things are done and by whom has already been written, than follow it, or get it re-written. It is precisely because one person's view is not other's views that we go through the effort to write policy and process down to mediate those differences. Alanscottwalker (talk) 15:22, 4 April 2019 (UTC)
• There is a premise asserted in RfB standard question 3, "Wikipedians expect bureaucrats to adhere to high standards of fairness, knowledge of policy and the ability to engage others in the community." Where did that come from? It is pretty good. "The ability to engage others in the community" is ideal. I think bureaucrats err on the side of being cautious, but of course that is the side to err on. My reading of the Maxim ArbCom case is that he deserved the "thank you", and I raised my eyebrows at the notion that 3 hours is evidence that something is not an emergency. Bureaucrats are at the top of the hierarchy of formal recognition of an understanding of consensus. If ever there is an IAR rationale for anything, I expect a bureaucrat is best qualified to do it. A good IAR action is proven by consensus support afterwards. --SmokeyJoe (talk) 00:22, 3 April 2019 (UTC)

  The context was important too. Its notable that this was a fight over an internal Wikipedia page with no indication that anyone was going to go disrupt anything important. (That and the fact that the arbs themselves declined a level 1, which would seem to be the most evident standard for an out of process revocation). In any case, what's the point of this discussion? It has already been established (by that case) that the 'crats can do what they will (in an IAR sense) without fear of reprisal. The policy has been de-facto amended (by the only body that has authority to enact this particular aspect of community consensus). Crazynas ^t 21:52, 3 April 2019 (UTC)

• My view is that before self-unblocks were disabled, it would have been well within the spirit of WP:IAR for a bureaucrat to unilaterally desysop an administrator account that is clearly compromised. An unfortunately common example is an account vandalizing the Main Page. Before we removed the ability to self-unblock, it was critical that, once discovered, a compromised account be desysopped immediately, since blocks would be useless and compromised admins can wreak havoc over millions of pages in the space of a few seconds (the Main Page is a naive target for vandals, templates are the really potent stuff). For this reason, I was quite surprised to discover the no consensus result at Wikipedia:Requests for comment/Bureaucrat removal of adminship policy (2011), and if self-unblocks weren't now disabled, I would have strongly considered starting a new RfC to revisit the issue.
  This is all moot because nowadays any one administrator can stop a compromised administrator account via a block. In response to the broader question of whether bureaucrats can invoke WP:IAR with respect to bureaucrat actions, I would say the answer is clearly "yes, they can". The relevant question to consider is "would applying the rule seriously harm the encyclopedia, and would ignoring the rule prevent that from happening?" – I trust that bureaucrats have the judgment needed to answer this question. Mz7 (talk) 12:34, 3 April 2019 (UTC)

  Can a blocked admin account view deleted edits? A globally locked account cannot (because you can't log in to the account at all) but I don't know if disabling self-unblocks has addressed that particular issue with a local block. WJBscribe (talk) 13:33, 3 April 2019 (UTC)

  @WJBscribe: yes a blocked admin can still use (deletedtext) and a number of other permissions that I'm not going to spell out here. Notable they can NOT use: block (except for a retaliatory block on the admin that blocked them), protect, userrights, delete; and those are generally the biggest impacting things. — xaosflux ^Talk 15:25, 3 April 2019 (UTC)

• For what it's worth, my vote to de-crat was largely because the standards to become a bureaucrat are so high that I think the standards to remove have to be correspondingly low. In other words, it's a very small fall to below the level of the community's trust when the threshold to pass an RfB without a crat chat requires more than five supports for every one oppose. Since ArbCom had no precedent on what the threshold should be for de-crat, I made an argument for a fairly low threshold. I would not vote to de-crat in similar future circumstances, most likely, since a precedent has now more-or-less been set that de-crat should have the same threshold as desysop.

  To the substance of the question, the community has proscribed bureaucrats a very narrow role and declined to expand it at various RfCs throughout the years, such as the one I referenced in my voting at that case. That included explicitly declining to allow crats to perform emergency desysops without an ArbCom motion. I think that decision is weird – why would you not want a crat to act in a genuine emergency, such as a compromised account? – but it is what it is. If the community didn't even approve unilaterally desysopping compromised accounts as an emergency, then it seems clear they never intended IAR desysops to be a thing. ~ Rob₁₃^Talk 14:04, 3 April 2019 (UTC)

  FWIW I think there would have been much less of a backlash from the community if Maxim had 'pushed the button' on a compromised account that was vandalizing the main page before the Arbs had had a chance to post a formal Level 1 request here. That's a straightforward application of WP:BURO not so much a cowboy IAR. Crazynas ^t 21:43, 3 April 2019 (UTC)

• Aggregating "emergency" power to a single person is a bad idea, nor is it necessary, this is Wikipedia, not life and death. Alanscottwalker (talk) 14:14, 3 April 2019 (UTC)

  How much chaos is "emergency" desysoping someone going to cause? It's not a permanent thing, and it affects one user. It's not like they have a big red "shut down Wikipedia" button. Natureium (talk) 14:27, 3 April 2019 (UTC)

  See also Wikipedia:Role_of_Jimmy_Wales#Arbitration_Committee ... — xaosflux ^Talk 14:30, 3 April 2019 (UTC)

Indeed, less and less aggregation to that individual to where it's almost non-existent on paper, at least. Alanscottwalker (talk) 15:00, 3 April 2019 (UTC)

• Maxim stepped into a situation where processes were working, just not fast enough for Maxim's ipsa dixit liking, and turned it into a months long thing, so long it's being discussed even now. Alanscottwalker (talk) 14:53, 3 April 2019 (UTC)

  I don't think we need to make any assumptions about why Maxim acted beyond assuming that he acted in good faith. Hindsight is 20/20. That said, I do agree that the case in question shouldn't reflect more broadly on how the community views IAR relating to bureaucrat actions. I personally think that the community gives quite a bit of latitude to bureaucrats when deciding who gets sysop rights (crat chats, discretionary zones, etc), but the removal of sysop rights is a bit different since the decision-making body for removal is not the community. -- Ajraddatz (talk) 15:31, 3 April 2019 (UTC)

  What? Maxim stated that Arbcom was unable to act expeditiously enough for Maxim (it being Sunday), that is not only good faith assumption, that's fact. As for the rest, why do you think the job-title given by the community is blatantly, bureaucrat? Alanscottwalker (talk) 15:46, 3 April 2019 (UTC)

  Maybe I read into your statement too much. It sounded like you were assuming that he knew the process was working, when his justification seemed to be that the process would not have been able to work in time. -- Ajraddatz (talk) 16:22, 3 April 2019 (UTC)

  Either way -- 'I know there is a process, and it's not good enough', or 'I don't know there is a process, and that's not good enough' -- it's an aggregation of power to the individual to act, except the later suggests the individual should have worked to be informed. Alanscottwalker (talk) 16:35, 3 April 2019 (UTC)

• Perhaps paradoxically I've always believed IAR is more important when there are less rules to ignore. When WP had comparatively few rules compared to today, and those rules were drafted by a smaller group of editors and changed relatively easily without much review, then there were many circumstances in which a rule didn't work or didn't cover the situation at hand. As the rule base has grown, the drafting has improved and the review process has become of very high quality, there is much less grey space in which IAR is needed. There will always be some situations where a different approach is required, so crats should retain the ability to apply their discretion, but it's a diminishing requirement IMO and it feels unnecessary to give significant weight to it during RFBs. QuiteUnusual (talk) 15:51, 3 April 2019 (UTC)
• Beyond IAR and the specific incident in question, I think Maxim's bizarre dichotomy is, much like with sysop vs. admin, partially down to the fact that we're stuck with the word bureaucrat. The [y]ou are technically correct... the best kind of correct compliment of Hermes Conrad has been used ad nauseam, but even just the word bureaucrat can convey that sense of fairly automated button pushing. Ideally, while bureaucrats may be expected to only act in specific situations, that isn't the same as behaving robotically (or bureaucratically); that is, the bureaucratic part of the job is when to act, not how to act. A big part of how we view people is how we talk (and joke) about them. ~ Amory (u • t • c) 02:17, 4 April 2019 (UTC)

  @Amorymeltzer: I don't see any reason why the community couldn't come to a consensus to rename the Bureaucrat user group. The Spanish Wikipedia calls its equivalent of administrators "Bibliotecarios", which translates literally as "Librarians", for example. {{3x|p}}ery (talk) 18:54, 7 April 2019 (UTC)

  "Trustees"? Leviv ich 23:08, 8 April 2019 (UTC)

  Nah, "trustees" has a specific meaning within the WMF; they are the members of the Board of Trustees. I was inclined to go with "enablers", but that might be misconstrued. Risker (talk) 02:32, 9 April 2019 (UTC)

  Old folks' home? Natureium (talk) 03:09, 9 April 2019 (UTC)

Following his successful RfB, please welcome @Primefac: to the 'crat crew. Primefac, always feel free to post any questions or open discussions here about anything relevant. Best regards, — xaosflux ^Talk 18:30, 7 April 2019 (UTC)

Thanks! Will do. Primefac (talk) 18:49, 7 April 2019 (UTC)

​ yeah, we are always happy to help —usernamekiran(talk) 18:50, 7 April 2019 (UTC)

Welcome aboard. -- Avi (talk) 04:48, 9 April 2019 (UTC)

The Arbitration Committee has resolved by motion that:

On March 14, 2019, the administrator permissions of Necrothesp (talk · contribs · blocks · protections · deletions · page moves · rights · RfA) were temporarily removed as a suspected compromised account under the Level 1 desysopping procedures.

Following discussion concerning account security, and pursuant to the procedures for return of revoked permissions, the Arbitration Committee resolves the following:

For the Arbitration Committee, – bradv🍁 03:03, 10 April 2019 (UTC)

Discuss this at: Wikipedia talk:Arbitration Committee/Noticeboard#Restoration of sysop privileges to Necrothesp

• {{on hold}} @Necrothesp: as there is no technical mechanism for bureaucrats to verify if you completed the provision required above, would you please reply to affirm that you have satisfied this requirement? — xaosflux ^Talk 03:24, 10 April 2019 (UTC)
  • @Xaosflux: 2FA now enabled. Thanks. -- Necrothesp (talk) 09:27, 10 April 2019 (UTC)
•  Done welcome back to the corps! — xaosflux ^Talk 11:36, 10 April 2019 (UTC)

Hi - now that you've sorted out RexxSit, can you solve Brexit please? That must be a piece of cake after trying to resolve an RFA like that . Seriously, although I opposed, I've read through your discussion, and can't fault the conclusion you came to. I think you all need a !vote of thanks for your hard work. I've bookedmarked the crat chat page, just to remind me never to run for RFB myself! — O Still Small Voice of Clam 17:51, 11 April 2019 (UTC)

I'd start a chat about making the UK a colony of the US; that should solve everything, right? . -- Avi (talk) 05:41, 12 April 2019 (UTC)

Damn, has it come to that now? And it used to be the other way round as we thought it was the US that couldn't sort out its governance... [9]  — Amakuru (talk) 06:11, 12 April 2019 (UTC)

The UK's future was predicted in 1949. QuiteUnusual (talk) 08:50, 12 April 2019 (UTC)

Resolved

 – The case was declined (Special:PermanentLink/892308310#RexxS RfA bureaucrat chat).

Kindly note a recently filed arbitration case request (Special:PermanentLink/891981728). –xeno^talk 12:12, 11 April 2019 (UTC)

I can see the concern; in the previous crat chat, civility/conduct/temperament was also the primary concern, but ~70% support wasn't enough for the bureaucrats participating in that discussion. It seems like the rationales used by bureaucrats in their discussions are completely arbitrary. I'm not particularly concerned that RexxS was promoted; I'm sure he will be able to press the buttons correctly, despite the civility concerns. -- Ajraddatz (talk) 16:26, 11 April 2019 (UTC)

I think it's a Good Thing™ that no RfA ever influences its successors—or should. Each on their merits and every argument stands alone. ——SerialNumber54129 16:53, 11 April 2019 (UTC)

Agree, you cannot compare any one RfA to another, or two different bureaucrat chats, for that matter. Completely different set of circumstances and just saying "well, this one at 64.1% didn't go to a chat" or "this bureaucrat chat at 70% didn't result in promotion" are comparing apples and oranges almost all of the time. –xeno^talk 17:29, 11 April 2019 (UTC)

The arbitration request is a bureaucratic version of WP:IDONTLIKEIT. I agree with Ajraddatz that it doesn't help when decisions appear to be arbitrary but that's life. QuiteUnusual (talk) 17:22, 11 April 2019 (UTC)

The difference between the last crat chat and this one was that we had two new crats who are significantly more active and thus familiar with community norms taking part in it. Ajraddatz knows (or at the very least, he and I have discussed it before), that I think we should make RfA a hard vote with 70% as the cutoff, get rid of crats, and let stewards flip the bit. I think that would be more fair to everyone and would get us away from the “not a vote, but it really is, except when we decide it isn’t” situation that RfA appears to be.

At the same time, my view on this is a minority view: the en.wiki community has consistently voiced the view that RfA should be a discussion. So long as that is the case, crats decide what consensus is, and making sure that we have crats who are active in the community in addition to the old hands is important. While I’d prefer that we just go ahead and make RfA an actual vote, this is how the community wanted it to work, and you can’t fault crats for doing their “job”. TonyBallioni (talk) 17:41, 11 April 2019 (UTC)

Also different participants for that matter. -- Avi (talk) 17:52, 11 April 2019 (UTC)

Actually, and this is clearly mentioned in the crats' rationales, the main difference between Jbhunley and RexxS was not the personnel, but that there were two separate valid Oppose concerns in the former (civility and lack of content) but just one in the latter, once the crats decided to discount opposition based on the RFA being badly timed or jokey . For better or for worse, number of separate issues plays a big part in crat chats. I think that's OK. Having a straight pass/fail percentage, particularly one set at 75%, would not be a good idea IMHO. Giving that much power to simple headcount would leave it open to socking, canvassing, meating, and all the usual reasons why we don't build consensus by vote.  — Amakuru (talk) 06:22, 12 April 2019 (UTC)

Admitting that I am on the other side of the decision which I think was wrong, I would just add this - which applies regardless. The actual written up statement of at least 4 of the 'crats decisions are actually just really badly written waffle. If a little more time had been spent on actually forming a complete, articulate and short written opinion rather than rather rambling excitable prose, maybe the decisions would be clearer and less disputed. It seems ironic that the brief, clearly stated "no consensus" opinions stand out in comparison to opaque, wavering, "cover every angle" consensus opinions. Regardless, there are some very highly critical and well made points at the Arbcom case which hopefully will inform 'crats that a notable segment of the community does not think that you have collectively done the right thing here. Leaky caldron (talk) 10:08, 12 April 2019 (UTC)

And I could just as easily say that in Jbhunley's case there was just one major instance of incivility, whereas here it was more long-term and thus a bigger concern. Closing discussions based on the opinion of the closer works in other places where the closer needs to balance consensus against established policy; i.e. requests for deletion. There are also some good reasons for crats to discount votes - revenge votes, votes based on one single issue years ago, and even concerns with process rather than candidate. The first two did not happen happened here, and the third only counted for a few votes. Crats discounted some votes to bring the request into the discretionary zone, and then ignored more to close the request as successful. And what this really demonstrates is the wildly different behavioural expectations for new vs established users, both in terms of the context of the nomination, and the crats seemingly ignoring legitimate concerns about civility with justifications like "the supports cancel out the opposes". -- Ajraddatz (talk) 15:20, 12 April 2019 (UTC)

• AnkitAWB (BRFA · contribs · actions log · block log · flag log · user rights)

Officially retired almost 2 years ago after clearing almost all empty categories, never got around to request removing the bit. I do not think I will be putting it to use in the future either. With thanks. --qedk (t 桜 c) 18:38, 27 April 2019 (UTC)

 Done Maxim_(talk) 18:40, 27 April 2019 (UTC)

Please grant the sysop bit to JJMC89 bot III (task list ⁽¹⁾ · logs ^{(actions · block · flag)} · botop ^{(e · t · c)} · contribs · user rights). Maxim already granted the bot bit. — JJMC89 (T·C) 23:16, 27 April 2019 (UTC)

 Done and I also fucked up the log summary. Is there anything else I can mess up for you? :p Maxim_(talk) 23:24, 27 April 2019 (UTC)

Thanks, Maxim — JJMC89 (T·C) 23:36, 27 April 2019 (UTC)

For our archives, this is per Wikipedia:Bots/Requests for approval/JJMC89 bot III. — xaosflux ^Talk 00:50, 28 April 2019 (UTC)

Please remove the flag from my bot which has not run for a long time. Thanks — Martin (MSGJ · talk) 13:38, 29 April 2019 (UTC)

 Done. Primefac (talk) 13:45, 29 April 2019 (UTC)

The following admins can be desysopped for inactivity:

• Peripitus (t · th · c · del · cross-wiki · SUL · edit counter · pages created (xtools · sigma) · non-automated edits · BLP edits · undos · manual reverts · rollbacks · logs ^{(blocks · rights · moves)} · rfar · spi · cci) (assign permissions)^{(acc · ap · fm · mms · npr · pm · pcr · rb · te)}
• Andonic (t · th · c · del · cross-wiki · SUL · edit counter · pages created (xtools · sigma) · non-automated edits · BLP edits · undos · manual reverts · rollbacks · logs ^{(blocks · rights · moves)} · rfar · spi · cci) (assign permissions)^{(acc · ap · fm · mms · npr · pm · pcr · rb · te)}
• EWS23 (t · th · c · del · cross-wiki · SUL · edit counter · pages created (xtools · sigma) · non-automated edits · BLP edits · undos · manual reverts · rollbacks · logs ^{(blocks · rights · moves)} · rfar · spi · cci) (assign permissions)^{(acc · ap · fm · mms · npr · pm · pcr · rb · te)}

Thanks to all of them for their service to Wikipedia. Graham87 10:36, 1 May 2019 (UTC)

@Graham87: Shouldn't this be labeled May 2019? March 2019's was on March 1, and the other April 2019's was on april 1 --DannyS712 (talk) 10:40, 1 May 2019 (UTC)

@DannyS712: Ooooooops, yes it should! I've fixed it. Graham87 11:10, 1 May 2019 (UTC)

 Done Thanks to all for their service. -- Amanda (aka DQ) 11:49, 1 May 2019 (UTC)

@DeltaQuad: please inform these users of your removals. You can use the template at Template:Inactive admin. — xaosflux ^Talk 15:56, 1 May 2019 (UTC)

Thanks, done that also. -- Amanda (aka DQ) 16:15, 1 May 2019 (UTC)

• Noting for the record that EWS23's last logged admin action was in 2012, and thus he appears to be ineligible for resysop under the current rules. TonyBallioni (talk) 20:46, 2 May 2019 (UTC)

Please remove my administrator rights. I haven't had time or need for tool use in forever, and that doesn't seem likely to ever change. Consumed Crustacean (current rights · rights management · rights log (local) · rights log (global/meta) · block log). Cheers! -- Consumed Crustacean (talk) 22:55, 3 May 2019 (UTC)

 Done. Thank you for your past service. 28bytes (talk) 01:09, 4 May 2019 (UTC)

I'd like to thank Amanda (and any other crats who I might have missed) for her clerking at the current RfA. As recent events have shown, RfA is an important responsibility for the bureaucrats team and having crats rather than sysops or even editors (as had recently happened) be the ones to clerk feels like it is in keeping with this group's role. Best, Barkeep49 (talk) 17:20, 24 April 2019 (UTC)

I agree entirely and I’m glad that DeltaQuad is being proactive in this area.Pawnkingthree (talk) 11:13, 25 April 2019 (UTC)

Honestly, it is something that has been needed for a long time, and 'crats in my two cents should be administering it. If we want to change some of the level of toxicity of RfA, then this proactive enforcement is needed by the 'crat team. Whenever there is an RfA, I try to keep tabs on it as much as I can with life, so I'm at least aware of what is going on. -- Amanda (aka DQ) 08:29, 26 April 2019 (UTC)

Agree wholeheartedly, both with you and with the giving of thanks. I think a quick hand is called for, if only because others may take action in the absence of 'crats. It's unfortunate, but clerking has been done by editors, sysop or otherwise, which is not ideal to say the least. Any port in a storm, sure, but it's shaky ground. It's nice to have 'crat hands. ~ Amory (u • t • c) 11:08, 26 April 2019 (UTC)

Absolutely agree as well. Proactive clerking has long been desperately needed at RfA, and while any user can technically do this, most avoid it to avoid getting embroiled in the toxicity of RfA. Thus, it naturally falls to the 'crats, who hold the only position of authority at RfA to speak of. It is a travesty that the crats have traditionally neglected this role, and I hope that the fresh blood can continue to bring some much needed change. ~Swarm~ ^{sting} 21:36, 26 April 2019 (UTC)

Definitely a good idea, and something I'll make an effort to keep an eye on in the future. Primefac (talk) 01:40, 27 April 2019 (UTC)

It's definitely welcome to have more of this. Now, if only we had more RFAs, too... GAB^gab 09:26, 29 April 2019 (UTC)

If I recall correctly, throughout all the investigations and analyses of what's wrong with RfA, none of the suggestions for clerking met even with sufficient consensus of the work groups to start a formal RfC on the subject of clerking. Moreover, significant opposition was raised by other users who claim that clerking is not explicitly within the mandate of Bureaucratship. Exacerbated by the long time it takes for closures to RfA or getting a 'crat chat together when required, this seems to demonstrate that not many Bureaucrats are as active as they once were. I welcome the rare and recent promotions to Bureaucrat in the anticipation that this may now change. Kudpung กุดผึ้ง (talk) 01:27, 1 May 2019 (UTC)

I think the clerking is a good idea in theory but I'll put on my cynic hat. If we collectively as bureaucrats start clerking/policing RfA more, it would be make it more difficult for us to also be dispassionate RfA closers. Bluntly speaking, we'd be "clerking" the oppose section more than anywhere else, and when it would come to a borderline RfA with or without a crat chat, there would at least be a perception of impropriety. I'm not sure we have enough crats where you'd have a couple "clerking" to leave enough for a chat if that was needed. In terms of active crats, I do closely follow RfAs (I guess RfBs too on those rare occasions) despite not actually making edits for weeks at a time. I'll review them quite frequently, especially during the first couple of days. Maybe there are other lurker-crats too. Maxim_(talk) 02:04, 1 May 2019 (UTC)

Broadly agree- Every RfX goes on my watchlist; I follow them closely even while not making edits; I try to avoid most participation, though do clerk where necessary and not already handled by another community member. (Also Kudpung- long time for RfA closure?! I think you’ll find most RfAs are closed the minute they expire or slightly before - though I am always happy to have fresh blood on the team, carne por la machina). –xeno^talk 14:03, 5 May 2019 (UTC)

An arbitration case regarding Enigmaman has now closed and the final decision is viewable at the link above. The following remedy has been enacted:

For the Arbitration Committee, – bradv🍁 13:19, 6 May 2019 (UTC)

Discuss this at: Wikipedia talk:Arbitration Committee/Noticeboard#Wikipedia:Arbitration/Requests/Case/Enigmaman closed

 Done and notified, thanks again for their service. -- Amanda (aka DQ) 13:35, 6 May 2019 (UTC)

I updated the details at WP:Former administrators. Useight's Public Sock (talk) 14:35, 6 May 2019 (UTC)

There are multiple discussions ongoing at WT:ACN and WT:ADMIN concerning the role of bureaucrats with respect to resysoping individuals whose administrator account was compromised. Maxim_(talk) 13:31, 5 May 2019 (UTC)

Discussions at WT:ACN concerning administrator account security and restoration following compromise

There are ongoing discussions of interest at WT:ACN concerning administrator account security and restoration following compromise, bureaucrat comment has been invited. –xeno^talk 13:38, 5 May 2019 (UTC)

@Xeno: which section should we keep? :D Maxim_(talk) 13:39, 5 May 2019 (UTC)

Damn! Well I started typing it an hour ago or something :p –xeno^talk 13:41, 5 May 2019 (UTC)

Redundant section is redundant. ;) —DoRD (talk)​ 14:51, 5 May 2019 (UTC)

• In a nutshell, is anything actually changing as far as our actual current practice? My current read is that if your access is removed by an arbcom motion it is creating "a cloud" and we won't give it back without an arbcom motion/ruling (which removes the cloud) or a new RfA. - which is really the status quo. — xaosflux ^Talk 18:58, 5 May 2019 (UTC)

  Yeah, nothing should be different on your end; only change was ArbCom saying that they might not automotion regranting of perms to previously-compromised sysops. Not that that diminishes any value in the discussion concerning bureaucrats; you've all certainly been mentioned, if by policy rather than name. ~ Amory (u • t • c) 19:27, 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). [x-post from WT:ADMIN] –xeno^talk 15:21, 6 May 2019 (UTC)

• I guess the more relevant question is, should we authorize bureaucrats to remove the permissions of obviously compromised admin accounts, and then return them when informed that the owner has re-secured the account? I'll note in passing that Arbcom depends largely on the information provided by stewards and WMF Trust & Safety; checkuser isn't usually all that helpful in confirming this information. Frankly, it looks like (just from a workload perspective), this should be a no-brainer; 'crats have time, they're usually reachable, can act immediately as individuals, and arbcom needs to dig up a minimum of three people to make their desysop motion. Plus...at least in the current policy, you already seem to have the authority to do so. Risker (talk) 23:12, 5 May 2019 (UTC)

  I believe pulling the rights in a compromised account situations remains in the province of IAR, no? A precious RFC and the recent RFAR speak to it. –xeno^talk 23:16, 5 May 2019 (UTC)

  WMF Trust and Safety (and stewards as first responders) are the two groups with the technical access required to fully stop abuse from compromised accounts and return the accounts to their owners. There is no reason why local bureaucrats or ArbCom should be involved here at all. If an account needs to be desysopped before access is returned, then it could be done by a steward or a request to local bureaucrats depending on the situation. I think you could do away with the practice of desysopping compromised accounts that are already locked entirely and see no negative impacts. -- Ajraddatz (talk) 18:55, 6 May 2019 (UTC)

  My reading of the general current local state is that: If you let your account get compromised, you shouldn't have advanced access here anymore until we are satisfied that you won't get compromised again. This assumes that compromises are caused by lack of due care of an account holder. While the lock/unlock process stops damage and presumably ensures the right person is in control of the credential for an account, it doesn't directly address the continuing care concern. — xaosflux ^Talk 19:04, 6 May 2019 (UTC)

  The first thing that a steward or WMF T&S person does when unlocking a compromised account is asking them to change their password to something more secure. We also have ways to check if they have done this. That should fill the ongoing security requirement of the policy much better than a bureaucrat or ArbCom asking the user to take steps without any way to confirm what has happened. -- Ajraddatz (talk) 19:21, 6 May 2019 (UTC)

  A re-breach is not going to happen, for all practical purposes. And, for all other cases of admin-conduct brought before the committee, the mop stays with with them, until the festival ends. ∯WBG^converse 19:28, 6 May 2019 (UTC)

  (edit conflict) Those activities only reflect the instantaneous actions of the compromised individual, and are expected to ensure that the correct account holder is in control and will be less likely to have another immediate loss. It does not provide additional information our community has stated is important such as: determining if the loss was due to carelessness of the account holder, or determining if the account holder is committed to exercising due care in the future. As continuous care is expected of advanced rights holders, continuing community support for advanced permissions may no longer be present in such situations. — xaosflux ^Talk 19:45, 6 May 2019 (UTC)

  If that is a concern, then there is value to asking them. But that hasn't been the case for any of the compromised accounts, suggesting that maybe a follow up process rather than desysopping any impacted accounts would be a more sensible policy. -- Ajraddatz (talk) 22:10, 6 May 2019 (UTC)

A major problem with 2FA as presently implemented is that there is no mechanism in place for resetting 2FA in the event a user is locked out. At present the proces is to open a ticket on phabricator and try to convince a developer that the request is both legitimate and worthy of attention.

2FA lockouts can occur fairly easily and are common over a time horizon of years with a user base numbering in the thousands.

The main problem in dealing with reset requests is confirming the legitimacy of the request. While we do not have a policy at the present time, we should be able to create one combining elements of:

1. The passage of time, so that the legitimate operator of an account has the opportunity to log in and reject the request
2. Comparing the requestor's identity to previous public statements by the account.
3. Comparison of the requestor's appearance to photos from meetups or other similar events
4. Confirmation that the email address associated with the account is under the requestor's control

This is a process that requires judgment that is best performed by someone answerable to the ENWP community. I believe that the 'crats are in the best position to perform these tasks.

I believe the best process to achieve this would be to build consensus locally and then involve WMF trust and safety. I would imagine that we would be forwarding approved reset requests for 2FA reset to developers (perhaps via phabricator) until there is sufficient volume to warrant an automated interface.

I believe that having a well-defined, fair process for 2FA resets will speed the adoption of 2FA and improve security. Even if the exisitng 2FA system is replaced with something better, the need for a process for handling reset requests will be ongoing.

I'm starting here and if there is sufficient support can open an RfC or otherwise get this in front of a wider audience.

UninvitedCompany 22:06, 6 May 2019 (UTC)

If I'm remembering correctly, I believe there were talks of Stewards being a potential bridge between a community and whatever method of removing 2FA is/will be available. Given 2FA is applied globally (i.e. applies to logging in via CentralAuth - it isn't project-specific once enabled), should this not be handled centrally? Just my 2 cents - TNT ^💖 22:18, 6 May 2019 (UTC)

It came up at the last steward call, and it's still being worked on. Agreed that this is a global issue and should fall to stewards rather than local bureaucrats, especially given the nature of sensitive information required to make an informed judgement to remove 2FA. -- Ajraddatz (talk) 22:25, 6 May 2019 (UTC)

With "accounts" being global, this isn't something that any local project would deal with. So staff, stewards, or some other special-build global group would be the best way to deal with credential resets. — xaosflux ^Talk 00:52, 7 May 2019 (UTC)

• There are a couple of problems with the base assumptions of the original post. First, there are only two ways to log into Phabricator: if one has a developer account (a tiny subset of people who post on Wikimedia sites), one can use that LDAP sign-in. The other way is to be logged into your Wikimedia SUL account; however, if your account is globally locked, you cannot log in, and you therefore cannot log into Phabricator, nor can you make posts there. Secondly, there is a diminishingly small likelihood that (a) a Wikimedian who has never posted to Phabricator will understand how to do so; (b) in the case where the person was successful, that it will be noticed and/or managed in a prompt and timely way and (c) that they'll encounter anyone who knows them well enough to vouch for them, know what to do about the situation, or have the technical ability to do what needs to be done (only a small subset of developers, mostly WMF staff, have the ability to sort 2FA problems out). None of these have anything to do with project-specific bureaucrats. All of these issues are problematic and highlight how poor the support for 2FA problem-solving really is. Jehochman had problems, but he has a broad enough range of Wikimedia/MediaWiki contacts that he was able to get them sorted; many enwiki admins don't have that depth of knowledge or the right contacts. There are over 5000 admins on Wikimedia projects, and many of them have never been to meet-ups, never posted significant personal information publicly (in which case, an imposter could have found that information as well), don't have a [non-mandatory] email address attached to their acount, and again it's not possible to log into a globally locked account so they can't "reject the request". I get the motivation to want to push forward 2FA (although with changes that were made to admin rights back in November, and the splitting off of interface admin rights, I'm not really sure there's much that a hijacked admin account can do that can't be undone pretty quickly); however, without proper WMF developer and staff support, the end result will be bad for enwiki, and potentially disastrous for projects that only have a handful of admins. And no, it should absolutely NOT be left to volunteers to sort out who is and isn't a legitimate account holder; site security is the WMF's bailiwick, and if the stewards had any sense, they'd say so and also push for a proper 2FA extension. Risker (talk) 04:13, 7 May 2019 (UTC)
  • I just want to echo Risker’s comment that there really isn’t much that someone with +sysop can do that can’t be undone, which I think is a fact that often gets glossed over here. For those of you who aren’t aware, Risker was probably the most active functionary dealing with the account compromises of this fall. She’s hardly an anti-security advocate. The simple fact is, however, that compromised admin accounts are more about egg on our face than anything else. Yes, security is needed, but let’s not pretend +sysop is like having the keys to Fort Knox. TonyBallioni (talk) 04:29, 7 May 2019 (UTC)
    • Thanks, TonyBallioni. I'll mention in passing that the overwhelming amount of damage done by compromised accounts in the past year has been done by compromised ordinary editing accounts; the only activities that compromised admin accounts performed that ordinary editor accounts could do were a few blocks (now not possible due to changes in what blocked admins can do), and editing of a couple of fully-protected pages, and the total amount of vandalism/misbehaviour of the compromised admin accounts was well under 5% of the total number of problems. I know the security folks came up with some suggestions for preventing that kind of "ordinary account" harm too, and some of them have been put in place, but the ones that are pretty typical for most websites (e.g., automatically blocking or deleting accounts that have been inactive for a set period, requiring mandatory email links, etc) are antithetical to existing core policies and of course can't be applied to the Wikimedia site. Risker (talk) 04:40, 7 May 2019 (UTC)
  • Everything Risker said is spot on. I'm a named editor, which helped me authenticate outside normal channels. I have maintained decade long email correspondence with other admins, to the extent that they can recognize my writing "voice" and my references to past events. Many other editors and admins can't generate that level of trust independently of being able to login. Also, it is worrisome that developers are using LDAP for user authentication. LDAP is weak security They should set up Kerberos for authentication and use LDAP for storing identity attributes, which is how network security is meant to be. Jehochman ^Talk 14:18, 7 May 2019 (UTC)
  • Risker, thanks for being engaged with this matter. I think we broadly agree. Perhaps I was unclear -- my goal was to propose the bureaucrats handle the "bureaucracy" of the requests in accordance with the wishes of the local community and in light of the threat model that community faces. The bureaucrats would be then responsible for reviewing requests that arrive from an IP or via email since the affected user cannot log in. The bureaucrats would review these requests and vet them in accordance with local community expectations. The 'crats would then forward vetted requests to whoever is empowered to act up on them -- presently developers, who have a preference for using phabricator for ticketing, which is why I suggested it. The relatively small population of bureaucrats would be able to deal with whatever klunky interface is present as part of their duties until things improve. To your point about many users not having email, public identity, etc. I agree that all those things are valid points. The most universal way to vet a 2FA reset request is time. If someone edits every day, then abruptly stops and requests (even anonymously) a 2FA reset, then makes no additional edits for (e.g.) 7 days, it is plausible to presume that the request is genuine. My hope would be that we will evolve towards an environment where admins start putting some form of backup identity information on their user pages -- a public key for which they retain a private key, a list of other users who they trust to authenticate them, a real-world identity, etc. While there is no one mechanism that works well for everyone, there are mechanisms that, all together, will work for the vast majority of admins.

I disagree that this is best handled by stewards. Stewards do not know the local community, the local user base, or the local culture. I think there should be allowances for the vastly different situtation in, for example, EN vs. ZH. And I think that many of the means of being sure that someone is who they say they are require local knowledge. UninvitedCompany 16:24, 7 May 2019 (UTC)

As I see it, the best way to handle 2FA resets would be to make users provide multiple ways of confirming identity when they sign up for 2FA. Once such a system is in place, resetting 2FA could be handled primarily or entirely by automated system. As pointed out above, all accounts are global now so the 2FA confirmation system would also need to be global. Also as pointed out above, site security is primarily the responsibility of the WMF, so the Foundation alone should be responsible for operating and maintaining any 2FA confirmation system. The only community input I see as needed would be deciding what identity confirmation methods to implement. Sario528 (talk) 17:45, 7 May 2019 (UTC)

All that you would need to do is post a SHA-3 (or similar) hash on your user page and if you happen to get locked out of your 2FA and need a reset is provide the answer to the steward so they know it's you who is the true owner of the account. — Moe Epsilon 02:18, 8 May 2019 (UTC)

Stewards cannot handle 2FA reset as of now and you must contact cawikimedia.org to get it unlocked. — regards, Revi 13:12, 8 May 2019 (UTC)

2FA system is global, and if you can convince zhwiki crats to unlock your 2FA, you're doomed on enwiki. Head shot. — regards, Revi 13:16, 8 May 2019 (UTC)

Vejvančický (current rights · rights management · rights log (local) · rights log (global/meta) · block log)

• Please remove the admin flag from my account. I'm no longer in touch with changing WP policies. I'm now mayor in a small and beautiful Moravian market town, see Boleradice. It is far more difficult administration, I'd say:) You are welcome to visit us and taste our great wines. ...and I also have two kids. Wikipedia is a good experience. I'll be around here, sometimes. Good luck to you all. Thank you. --Vejvančický (talk / contribs) 08:40, 17 May 2019 (UTC)

 Done. Congratulations on becoming mayor! 28bytes (talk) 10:55, 17 May 2019 (UTC)

Please remove the administrative flag from Nv8200pa (talk · contribs · blocks · protections · deletions · page moves · rights · RfA) per Wikipedia:Arbitration Committee/Noticeboard#Level 1 desysop of Nv8200pa. Thank you. For the Arbitration Committee, Mkdw ^talk 23:07, 22 May 2019 (UTC)

•  Done –xeno^talk 23:13, 22 May 2019 (UTC)

Am full-time with further studies and don't presently have need for admin tools. Can Euryalus (current rights · rights management · rights log (local) · rights log (global/meta) · block log) please be desysopped for now. -- Euryalus (talk) 06:42, 26 May 2019 (UTC)

 Done Thank you for your service and let us know if you need other tools in the meantime. -- Amanda (aka DQ) 07:04, 26 May 2019 (UTC)

• Wishing you the best with your studies and hoping that you'll take up the bit again when you have more time. TonyBallioni (talk) 20:04, 26 May 2019 (UTC)
• Echoing Tony's comment. I hope you are enjoying your academic journey. AGK ■ 21:38, 26 May 2019 (UTC)

I am voluntarily relinquishing my administrator privileges. I haven't been active in years and I'm honestly surprised you haven't taken them yet.

Fun fact: back in the day, most people approved my RFA based on my username alone. HereToHelp ^{(talk to me)} 02:21, 30 May 2019 (UTC)

 Done thank you for your service. — xaosflux ^Talk 02:32, 30 May 2019 (UTC)

If you didn't show up we'd have finally processed your removal in a few days. — xaosflux ^Talk 02:34, 30 May 2019 (UTC)

Please also remove the admin rights from my account. I haven't used the tools at all in nearly three years and don't foresee becoming active again anytime soon — I've got multiple years of grad school ahead of me. Like the above poster, I'm surprised they haven't been removed for inactivity yet. Maybe I'll request them back if I return one day, but I prefer writing content to administrative work anyways. Best, StringTheory11 (t • c) 03:33, 30 May 2019 (UTC)

 Done with thanks for your service (the admin inactivity policy has a very-very-very low bar for 'activity'). Best wishes for your studies! — xaosflux ^Talk 03:37, 30 May 2019 (UTC)

The following inactive administrators are being desysoped due to inactivity. Thank you for your service.

1. Syrthiss (talk · contribs · blocks · protections · deletions · page moves · rights · RfA)
2. Flyguy649 (talk · contribs · blocks · protections · deletions · page moves · rights · RfA)
3. Moink (talk · contribs · blocks · protections · deletions · page moves · rights · RfA)

— xaosflux ^Talk 00:00, 1 June 2019 (UTC)

Noting for the record that Flyguy649’s last logged action was in 2011 and Moink’s was in 2008, so both appear to be excluded from resysop without an RfA by the five year rule. TonyBallioni (talk) 01:17, 4 June 2019 (UTC)

Fram has been unblocked. I see no community consensus that the administrative user rights of Fram should have been revoked. Can anyone think of a reason the user rights should not be restored without delay? Alternatively, restored following the standard 24 hour hold period for commentary? –xeno^talk 20:12, 11 June 2019 (UTC)

Fram is still technically banned from en.wp. The actual T&S ban has not been reversed yet. —A little blue Bori v^_^v ^Bori! 20:14, 11 June 2019 (UTC)

Fram is unblocked. The Rambling Man (talk) 20:15, 11 June 2019 (UTC)

A block is different from a ban, and you know it. He may be unblocked, but any editing he did here would immediately be seen as a violation of the ban, and the last thing we want at this moment is for WMFOffice to escalate this. —A little blue Bori v^_^v ^Bori! 20:21, 11 June 2019 (UTC)

• I know I'm not a 'crat any longer but there was nothing offered by even the near-silent WMF that suggested Fram abused the tools. The desysop wasn't under a cloud, so a technical re-sysop is just natural. The Rambling Man (talk) 20:15, 11 June 2019 (UTC)
• Fram is currently banned from enwiki, per the office action. If a bureaucrat were to restore the sysop flag at this point, that may well lead to a de-cratting. ~ Rob₁₃^Talk 20:16, 11 June 2019 (UTC)

If you want to restore rights, the 24 hour hold is not the major issue as Fram remains office-banned. You would be acting outside of any established norms. Maxim_(talk) 20:16, 11 June 2019 (UTC)

Indeed, Fram should be re-sysopped in 23 hours time. The Rambling Man (talk) 20:18, 11 June 2019 (UTC)

(Non-administrator comment) There is nothing normal about this situation. (edit conflict) –MJL ‐Talk‐^☖ 20:18, 11 June 2019 (UTC)

Allow me to quote from Wikipedia:Office actions#Secondary office actions.

In extremely rare situations, the Foundation may become aware of circumstances and information regarding major breaches of trust performed by Wikimedia functionaries or other users with access to advanced tools that are not possible to be shared with the Wikimedia communities due to privacy reasons and therefore can not be handled through existing community governance mechanisms. In some of those cases the abuses reported may not rise to the level of irreversibly expelling Wikimedians from the communities; however, they may be severe enough to have breached the community’s trust in the individuals involved and therefore warrant removal of administrative rights. Removal of user rights are usually either permanent or long term. Rebuilding trust is not impossible, which is why individuals are encouraged to reflect on their actions leading up to their advanced rights removal and consider how they may best serve the communities moving forward. In situations of long term removals, and once the no-rights period has elapsed, a contributor may have to fulfill additional criteria before they are permitted to reapply for advanced rights; those are made known to them at the time of the removal of advanced rights.

Reversing an office action out of process is not something that [is] not possible to be shared with the Wikimedia communities due to privacy reasons. And, reversal of an office action that has broad community opposition is not breach[ing] the community's trust. There is no grounds for an office decratting here. * Pppery * _{it has begun...} 20:22, 11 June 2019 (UTC)

• To the best of my knowledge Fram is currently under a WMF Ban, and access removal was an office action. So summary restoration is out of line of the bureaucrat mandate. Additionally, as the access removal was clearly not for inactivity or voluntary, an RfA should be required to ensure community support, following the prohibition period of the ban. — xaosflux ^Talk 20:18, 11 June 2019 (UTC)

  To the best of your knowledge, Fram was banned for a year yet has been unblocked. To the best of your knowledge, you have absolutely no idea why Fram was de-sysopped, so to mandate another RFA is complete nonsense. The Rambling Man (talk) 20:19, 11 June 2019 (UTC)

  Blocks are technical measures that may be used to enforce bans, removal of blocks does not negate a ban. — xaosflux ^Talk 20:20, 11 June 2019 (UTC)

  Lawyering. The community have already summarily ignored an office action by reinstating Fram's editing ability. You're just lawyering ("technical"? What?) to avoid hard questions. The Rambling Man (talk) 20:25, 11 June 2019 (UTC)

(Non-administrator comment) The 24 hour hold certainly should apply; bureaucrats should not be hasty in heated circumstances such as these. Unless the WMF re-blocks Fram or issues a new statement, I see no reason he shouldn't be re-sysoped tomorrow. power~enwiki (π, ν) 20:21, 11 June 2019 (UTC)

• While I agree with TRM, I understand if no crat wants to stick their hand in this fire and I dont think you can reasonably hold it against them if they stay away from this. Its also functionally a grey area in that the crats are elected by ENWP community to enact the decisions of the ENWP community in an impartial manner. Restoring rights that have been removed as part of an office action *but have no backing from the community* is clearly not something that has any real precedent here. The removal was not at arbcoms or the communities request and we generally as a community dont *want* crats to start getting creative - crats mandate is not to act on behalf of or for the WMF in any sort of dispute. Only in death does duty end (talk) 20:22, 11 June 2019 (UTC)

If ever there were a situation where allowing a little time to pass might make the consensus clearer, this would be it. I myself would wait until it is clear whether the community consensus will prevail regarding the block itself. UninvitedCompany 20:23, 11 June 2019 (UC)

Agree, additionally I'd want to see a response on-wiki from Fram (which would also indicate that they are willing to violate their WMF Office ban). — xaosflux ^Talk 20:24, 11 June 2019 (UTC)

• I personally am not willing to take any bureaucrat action on Fram's account either way until the situation is resolved. Resysopping Fram is also not supported by the relevant policy, and there's no precedent to draw on. It's not for the bureaucrats to set precedent by acting unilaterally. For now, I think it's better for the situation to become clearer before acting. --Deskana (talk) 20:26, 11 June 2019 (UTC)
• My sense is that this it is too soon for 'crats to be taking any action here, irrespective of the various arguments for/against re-sysopping. Let the dust settle, and give WMF a chance to respond to the recent unblocking. There's no point in discussing a resysop if there's going to be a wheel war about the unblocking. Waggie (talk) 20:26, 11 June 2019 (UTC)
• Both the block and the desysop were WP:OFFICE actions, so it was out-of-process to unblock, and it would be out-of-process to resysop. Why are we talking about procedural stuff like a 24 hour hold when we have so flagrantly disregarded the procedures surrounding WP:OFFICE? In the past, the Arbitration Committee has threatened to summarily desysop administrators who modify office actions, see [12]. Any bureaucrat seeking to resysop here, 24 hours or otherwise, would put themselves at risk to losing their bureaucrat access. Mz7 (talk) 20:27, 11 June 2019 (UTC)

  Well, the reason why it's being mooted is because the community has agreed that Fram should be unblocked, and has been. There was no reason given as to why he was banned in the first instance, so retention of his sysop status should be natural (as a c.f. I was blocked while retaining admin rights). Why is this any different? The Rambling Man (talk) 20:31, 11 June 2019 (UTC)

  There are some technical considerations, the executive summary is that no one cares enough that blocked admins can still do some admin things to fix that leak. See my talk. –xeno^talk 20:35, 11 June 2019 (UTC)

  I'm sure. There has been no indication that Fram has warranted a desysop. But I'm now seeing how the game goes. He's unblocked but still "banned" which means that if he dares edit, the ban will be lengthened. He didn't abuse his tools once. Amazing. Way to go WMF. The Rambling Man (talk) 20:38, 11 June 2019 (UTC)

  Office actions are explicitly outside of the control of community consensus. Procedurally, we can't overturn their action no matter what our consensus is. It's quite dictatorial, but this is what it is. Resysopping would still be reversing an office action. Mz7 (talk) 20:41, 11 June 2019 (UTC)

• Can't say I blame the 'crats for not wanting to act here. In fact it would be outside of their remit to be "activist" and re-admin Fram without a mandate to do so.

However I completely disagree with the contention that Fram needs a new RFA should they be unbanned. The local community had no say in this process, and there is no indication he has lost this community's trust to handle the tools. That is the only reason to require a new RFA. Vague handwaving at secret evidence that as far as anyone knows has nothing to do with admin tools does not make this under a cloud by any previously accepted definition. Beeblebrox (talk) 20:53, 11 June 2019 (UTC)

Agreed. Until WMF actually get round to telling us why they decided to desysop Fram, this is just a purely cosmetic desysop, made by a few people in California. There's no cloud. As soon as any ban expires, Fram gets to be a sysop again. The Rambling Man (talk) 20:56, 11 June 2019 (UTC)

The ban will expire in 1 year, right? -- Magioladitis (talk) 21:06, 11 June 2019 (UTC)

• For every desysop of Fram there should be someone willing to re-sysop again. They're not going to desysop everyone. That would cause irreversible harm if they did that. But they'll always be those who consider their admin rights to be higher than their morals. Cassianto^Talk 21:00, 11 June 2019 (UTC)
• (Non-administrator comment) I'm with Beeblebrox on this. Fram, though he may be a bit strident and controversial at times, has not generally lost the confidence and the trust of the community as a whole. Should he be reinstated as an administrator, it would be best done without any sort of RfA or pseudo-RfA process. Of course, given the standing ban, etc., I would certainly not fault any bureaucrat for taking no action at this time; or, once action is authorized (or independent action is taken), implementing a 24-hour hold. All the same, when all's said and done, I do wonder who shall be the courageous. —Javert2113 (Siarad.|¤) 21:03, 11 June 2019 (UTC)
• Going to agree with Beeblebrox here; absent a motion or determination by Arbcom that Fram's tools should not be reinstated at the end of whatever is going on at T&S, there is no valid reason not to return the tools at the end of that time, should he request them. If Arbcom believes he no longer meets the requirements to be an admin on this project, then they need to bite that bullet themselves. We have a community desysop process - it is via Arbcom. While I would never counsel the bureaucrats on this project to deliberately rescind an OFFICE action, once that action has expired, I can't really see a reason why the tools would not be reinstated upon Fram's request as of this writing. (And given the fact that almost nobody on the T&S team or the chain of individuals who are involved in OFFICE action decisions are actually in California and in many cases aren't even in the US, I think it may be time to let go of that canard.) Risker (talk) 21:07, 11 June 2019 (UTC)

But "SanFranBan" rolls off the tongue so nicely... Ivanvector (^Talk/_Edits) 21:18, 11 June 2019 (UTC)

Nick (t · th · c · del · cross-wiki · SUL · edit counter · pages created (xtools · sigma) · non-automated edits · BLP edits · undos · manual reverts · rollbacks · logs ^{(blocks · rights · moves)} · rfar · spi · cci) (assign permissions)^{(acc · ap · fm · mms · npr · pm · pcr · rb · te)}

If you could remove my sysop bit please. I'll re-collect it when the Wikimedia Foundation comes to its senses and properly deals with the Fram block, the Floquenbeam desysop and the inevitable Bishonen desysop. I'm not all that busy/useful anyway, and don't have the time to really get involved in challenging the WMF at this time in the way Floq, Bish and others have. Nick (talk) 07:31, 12 June 2019 (UTC)

Off-topic discussion
The following discussion has been closed. Please do not modify it.
@Nick: Why not hang on to it long enough to unblock Fram if the WMF undoes Bishonen's unblock? Beyond My Ken (talk) 08:00, 12 June 2019 (UTC) No need, Ken; it turns out handing back the tools amounts to the same thing. I'm only now realizing that unblocking Fram is a mere gesture (doesn't mean I regret making that gesture), and makes no difference to his ability to edit. See explanations on User talk:Fram: he remains banned, and will presumably be hit even more harshly if he does edit, even once. Bishonen | talk 09:45, 12 June 2019 (UTC). Bish - It's true that Fram remains banned and that they should not, under any circumstance, edit here at this time. However, there is more than a "mere gesture" here. Each unblock requires the office to 1) re-block Fram, 2) de-sysop the unblocking admin, and thus 3) further inflame the situation. If you hand in your tools with a "I resign because of the conduct of the WMF" comment, the WMF can simply ignore it all until it blows over. It makes no difference to Fram, perhaps, but it makes a difference to 1) us and 2) the WMF, who is forced off the sidelines. Mr rnddude (talk) 10:17, 12 June 2019 (UTC) It is a novel argument that it is the WMF inflaming the situation when an admin acts in blatant violation of the Terms of Use they agree to when they edit this site. ~ Rob13Talk 13:01, 12 June 2019 (UTC) @BU Rob13: Out of interest, do you mind telling us how you know what actions Fram was actually banned for? I've not seen the evidence behind the ban, ArbCom hasn't, the community hasn't. Have you? Boing! said Zebedee (talk) 13:50, 12 June 2019 (UTC) I never said I did know. I know that Fram was already warned for his actions toward Laura, because he told us as much, and hasn't interacted with her since due to an IBAN. I can logically conclude he must have been banned for something else, especially given the WMF explicitly stated he had continued the pattern of behavior that initially got him warned and then reminded of that warning. ~ Rob13Talk 13:54, 12 June 2019 (UTC) OK, so you were stating your personal conclusions as fact (as, also, are many others). Thank you for the clarification. Boing! said Zebedee (talk) 14:23, 12 June 2019 (UTC)

 Done. Let me know when you want it back. Primefac (talk) 10:53, 12 June 2019 (UTC)

Please note, the WMF Office has removed sysop access from User:Floquenbeam with the log entry: Foundation Office Action - Temporary (30 days) - assisting user under Office Action. This is mostly for our records, just as with Fram - BN is not the best venue to discuss the WMF actions. I have no way to know what will happen after 30 days (i.e. will WMF staff restore access, or will they leave it to us to deal with). I suggest a discussion at WT:ADMIN is held to determine if users that are involuntarily desysoped by office actions can be summarily restored upon their request, or if they will require a new RfA. Of course a new RfA is an available route if the requester chooses to go that way. My current read of the administrator policy says this is not a current route, as it is only available in cases of voluntary resignation or for inactivity. Best regards, — xaosflux ^Talk 01:14, 12 June 2019 (UTC)

Discussion on the admin policy possible options started at: Wikipedia talk:Administrators. — xaosflux ^Talk 01:20, 12 June 2019 (UTC)

(edit conflict)Quoth WMFOffice: "If they wish for their admin rights to be restored, 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." (for clarity) Ben · Salvidrim! ✉ 01:19, 12 June 2019 (UTC)

@Salvidrim: thanks, I didn't see that note (but haven't searched everywhere yet). So this is "left to us", thanks for that note. — xaosflux ^Talk 01:21, 12 June 2019 (UTC)

Special:Diff/901457495 - diff for our notes. — xaosflux ^Talk 01:23, 12 June 2019 (UTC)

@Xaosflux: The WMFOffice account didn't add extendedconfirmed, which appears to be the standard practice when removing +sysop. Of course, there are other rights that could be granted for the 30 days as well, but those could appear as circumvention of the desysop... --DannyS712 (talk) 01:19, 12 June 2019 (UTC)

@DannyS712: it will be auto-granted on Floq's next edit. We only need to do it manually if it was manually removed past the autopromotion period in the past. — xaosflux ^Talk 01:21, 12 June 2019 (UTC)

@DannyS712: I don't see any other prohibition on "lesser" access listed, and most would not be able to "interfere" with the WMF Office action. I highly suggest that if Floq want's some other flags in the mean time to use the normal WP:PERM process and let someone completely uninvolved deal with the request. — xaosflux ^Talk 01:25, 12 June 2019 (UTC)

Also note that Meta interface does not have 500/30 userrights, and you can't add/remove any user rights that does not exist on Meta (when trying to manipulate the user rights on Meta). That's why I had to grant +steward to remove researcher access on this wiki from someone in the past. — regards, Revi 01:33, 12 June 2019 (UTC)

@Xaosflux: although the WMF clearly has the desysop right, they've said it was temporary. For me the only meaning of that is that it should be automatically restored after 30 days. The WMF office doesn't have the right to advise on an RfA in any case. And to repeat myself, there's no need for an RfA if the desysop is temporary. It's my guess that the person who wrote the statement isn't familiar with how we work. Doug Weller talk 10:19, 12 June 2019 (UTC)

To me the meaning of the note is that after 30 days Floq can either (a) stand for adminship at RFA (either self-nominating or accepting someone else's nomination) or (b) be resysopped in another way; the choice is the en.wp's community. Personally I would wait for Floq to either (1) start/accept an RFA nomination or (2) ask here. If they choose (2) it would be up to the crats to determine whether to flip the bit themselves (presumably after the standard 24 hours) or ask for an RFA. If anyone else is temporarily deysopped by the WMF (over this or anoyter matter) the same options would apply to them unless specified otherwise by the WMF when blocking. Thryduulf (talk) 11:31, 12 June 2019 (UTC)

I said it elsewhere, and I will say it again here. I think it is unavoidable that the resysopping of Fram, Floquenbeam, and, potentially, Bishonen will go to ArbCom since the policies which relate to it can be read differently, and they can even be read as contradictory. It would be advantageous to use this month and file a clarification ArbCom request (or even a full case if needed). I unfortunately do not have time to do it myself.--Ymblanter (talk) 11:52, 12 June 2019 (UTC)

• "Temporary" means a suspension of the status quo followed by a reversion to the status quo ante. Thus, no extra steps necessary. ——SerialNumber54129 11:36, 12 June 2019 (UTC)

Unblocked

I've unblocked Fram. Stand by for the next desysop. Bishonen | talk 07:25, 12 June 2019 (UTC).

Should you do so and be desysopped, I will restore your admin rights if I remain able to do so. WJBscribe (talk) 23:40, 12 June 2019 (UTC)

Thread withdrawn by user (questions or concerns about individual bureaucrat actions are best directed to the bureaucrat in question first). –xenotalk 15:10, 13 June 2019 (UTC)
The following discussion has been closed. Please do not modify it.
There have been comical suggestions Fram might have been banned for telling Arbcom to F off. WMF have been crystal clear that Fram was banned as a result of reports relating to (what they see as) "harassing and abusing others." In fairness, it's 99.999% likely Fram never intends to harass anyone, they merely try to uphold the integrity of the encyclopaedia. Something at which, in some ways, they are fantastically good at. Also, the vast majority of Fram's attacks are against male contributors, AFAIK there's only been a single female who's been subject to his sustained attentions. But Fram's 14 years of contributions has abundant examples where he took enforcement actions that could be seen as harassment by the WMF, or in indeed by regular editors. On commons, Fram has repeatedly singled out Laura, leading various net denizens to conclude she might be the "grass", and hence to start up further hostility against her. Fram's long been subjecting that editor to negative attention. For example, this 2012 attempt to topic ban Laura, which was snow opposed, with Fram being advised to fix the mistakes in his own article creations, rather than focus his hyper criticism on a prodigious & friendly content creator like Laura. Instead of moving on, Fram kept on attacking , year after year, sometimes getting results when not enough sensible folk up turned up to defend Laura, e.g. with this 2014 attack. This is typical of a long list of repeated attacks by Fram against other highly active content creators, which WMF have likely examined in depth during their weeks of analyses. (Most of it not against Laura, and it's very possible she wasn't the one who reported him.) As Doncram has stated, it gave ordinary editors a "tiny bit of hope" once the WMF finally took action on behalf of the numerous but powerless community of content creators, against a member of the Goliath like enforcement corps. It's understandable that folk like Flo & Bish saw things differently, seeing WMF as the Goliath. Their courageous & timely actions were possibly even necessary to get the ideal resolution to this matter, which is for the board to persuade the Foundation to lift the ban on Fram, albeit with no censure for the WMF or those who supported them, and then for matters to be discussed calmly, to facilitate different sides seeing each other's point of view. It's less easy to understand why crats decided to resysop Flo without waiting for the 30 days to expire. The project could have survived without Flo having the tools for a few weeks. The action achieved nothing essential, and makes it harder to build bridges & heal the distress caused by this incident. With Crats siding so firmly with the enforcement crew, which some will see as being not just against WMF, but against the wider community of powerless regular editors, no wonder there's "entire private groups of people agreeing with (the DJ) too scared to post." The resysop was unnecessary and uncratly. FeydHuxtable (talk) 14:36, 13 June 2019 (UTC) @FeydHuxtable: BN is not for your opinion on crats. Post this to the ArbCom request posted by WJBscribe. --qedk (t 桜 c) 14:38, 13 June 2019 (UTC) Without addressing the other points, WJBScribe acted on his own. This was certainly not a decision of the crats as a whole, see the discussion above. --Rschen7754 14:40, 13 June 2019 (UTC) It's nice how you perceive the threads which led to her TBans as examples, where not enough sensible people turned up and those where she evaded sanctions as the example of optimal discussions. I have known you as one of the sanest members of the community for a long while, but this ain't it. ∯WBGconverse 14:51, 13 June 2019 (UTC) The WMF have been a lot of things this week but I didn't expect to see anyone describe their actions as "crystal clear". Ivanvector (Talk/Edits) 15:01, 13 June 2019 (UTC)