Jump to content

Wikipedia:Bureaucrats' noticeboard/Archive 45

Add links
From Wikipedia, the free encyclopedia
Archive 40←Archive 43Archive 44Archive 45Archive 46Archive 47→Archive 50

Advice? Someone's trying to brute-force my account

I've gotten 4 notifications today from the WMF about logins from an unrecognized device; I understand from this page that that represents at least 20 attempts by someone trying to log in as me. I have a secure password that I've never used anywhere else, but as you may know, the most extensive security breach ever (probably) came to light last month, and I think it's too soon to say who or what might be at risk. Is anyone else getting these messages? I emailed the WMF asking what's up ... no reply yet. If I keep getting these messages, I'll ask you guys for a temporary desysop, to be safe. - Dank (push to talk) 00:29, 9 January 2021 (UTC)

If you have a strong password, there is nothing to be concerned about, and (more unfortunate) nothing that we can really do about it. However, should you be concerned that you might lose access to your account, we can of course temporarily remove the bit from your account. Primefac (talk) 00:31, 9 January 2021 (UTC)
Thanks. I think it's too soon to pull the plug, but pull it I will if this keeps up. - Dank (push to talk) 00:33, 9 January 2021 (UTC)
(Non-administrator comment) If you're concerned, I'd recommend you change your password to something new, and/or enable WP:2FA. power~enwiki (π, ν) 00:33, 9 January 2021 (UTC)
I too got notification of 190+ attempts to log in to my account on a new device. Dan and I are both active in maintaining the Main Page, so disruption there might be the intent. I do have a strong unique password for this account. Stephen 00:45, 9 January 2021 (UTC)
Yes do consider WP:2FA if you don't already have it. There were some successful compromises (with a fairly high success rate) in the past few days, and there seems to be more attempts that we don't know about. What I would advise is if you or anyone else gets a notification that someone else has successfully logged in, whether you are still able to log in or not, please contact a checkuser as soon as possible. -- zzuuzz (talk) 00:49, 9 January 2021 (UTC)
I've personally seen an uptick in them the past few days. -- Amanda (aka DQ) 00:55, 9 January 2021 (UTC)
  • Bruteforcing is a highly ineffective way of trying to compromise an account, practically technically infeasible. If you have a long, non-reused, random password (example: "8hCTEwQ,~SV=95ACnas8zDuWqB(JfFCp" using a password manager, or something memorable like "juicy-firework-pineapple-green-horse"), the account will almost certainly not be compromised by bruteforce. 2FA is helpful as a reassurance, but not necessary. Consider that API keys for taking sensitive actions on many sites are about the same length, or shorter, than a long password here. ProcrastinatingReader (talk) 01:45, 9 January 2021 (UTC)
      • Meh, I’m not sure using 2FA to obscure otherwise bad security practices (ie, those resulting in one ending up with a keylogger on their computer) is a good idea. Besides, if you have malicious software on your computer 2FA won’t help; your cookies could just get stolen. ProcrastinatingReader (talk) 09:48, 9 January 2021 (UTC)
  • From a comment I recently left elsewhere: There is no need to change your password, assuming it wasn't bad and preferably was not on list of common passwords (that is the useful page from the "Password Blacklist library" at m:Password policy). Wikipedia's advice is at WP:SECURITY. However, it is essential that you do not use a password for Wikipedia or for the email account associated with Wikipedia that you have ever used at any other website. That's because other websites are often hacked and lists of username/password are published that hackers can access, and they might try using any such combinations here). Johnuniq (talk) 02:33, 9 January 2021 (UTC)
  • I've been getting these all day, too. Normally, I'd get one or two a week from a certain someone, but today it has been 8 hours of non-stop targeting. Seems like someone badly wants to crack and admin account - Alison ❤ 09:32, 9 January 2021 (UTC)

Maybe they're going for people with short names? Or common words? I got one too .... on both this account and Lollipop. —Soap— 09:40, 9 January 2021 (UTC)

Who knows but one likelihood is that the attacks are what has happened before, namely someone is trying to match leaked username/password combinations from aggregation websites that list literally millions of hacked accounts. It's likely that many people have called themselves "Alison" or "Soap" when logging in to some minor website which was later hacked and their poorly defended password list stolen. The attacker might have 100 combinations for each of you (Alison + password2, Allison + 1234, etc.) and they have a program that tries them all. As I mentioned above, any decent password would be adequate to deal with that. Johnuniq (talk) 09:47, 9 January 2021 (UTC)
Sorry to contribute to the split discussion but anyone interested in this might like to see some information I found here at WP:VPT. There is definitely a large attack underway. Johnuniq (talk) 10:13, 9 January 2021 (UTC)
@Dank: If your password is strong and unique (you have never used it or a variant of it on any other service) you should be OK (if it isn't - change it to fix that!). I had to turn off that notification before, as there isn't really anything you can "do" about it. Regarding cookie re-use, if you manually log-off it will void all your sessions on all devices to all WMF sites. 2FA will not stop someone from guessing your password, but will help stop them from actually getting logged in as you. 2FA is also helpful against password-recovery attacks (where someone gains access to your email and uses it to reset your account) - as are extra controls on your email (many email providers have robust supported 2FA solutions as well). — xaosflux Talk 10:42, 9 January 2021 (UTC)
  •  Request withdrawn per above discussion, anyone may certainly ask for a desysop for any (or no reason) - but securing your account is normally sufficient. — xaosflux Talk 10:42, 9 January 2021 (UTC)
  • 2FA is really something all admins should be using (not policy, just my personal advice). Long randomized passwords protect against some kinds of attacks, but not all. For example, I would assume that any machine you use in a public location has a keylogger installed; 2FA is a good defense against that. -- RoySmith (talk) 22:17, 9 January 2021 (UTC)
    Never logging into an admin account from a public computer is even better :-) Boing! said Zebedee (talk) 22:25, 9 January 2021 (UTC)
This. I only use my admin account from my desktop at home. I think most experienced admins are careful and use a separate non-admin account when away from home. If an admin is using their admin account on their phone, even with 2FA, they are taking a risk as 2FA is no protection if someone picks up your unlocked phone with the 2FA on it. I would say that, provided you have a unique and decent password, not using your admin account on your phone, and not using it away from home is a much better protection than having 2FA and feeling you can use your phone away from home. SilkTork (talk) 04:35, 10 January 2021 (UTC)
SilkTork, Just to clarify, I don't suggest people log into public terminals with their admin accounts. I was just using that as an example of one kind of attack 2FA protects you against. I use 2FA on my own (admin) account on my laptop. I have a second (non-admin) account which I use on my phone, because I know my phone is much more likely to get lost or stolen.
Other kinds of attacks 2FA protects you against include shoulder surfing, and plain old accidentally typing your password into the wrong window (we've all done that). If my LastPass account were ever to be compromised, it would protect against that too. Although to be honest, if that happened, the security of my wiki admin account would be very low on the list of things I'd be freaking out about. -- RoySmith (talk) 03:01, 11 January 2021 (UTC)

Me too, FWIW --Dweller (talk) Become old fashioned! 18:11, 10 January 2021 (UTC)

  • Last time I tested it our 2FA system was half-baked. I don't recommend it. As for password compromises, the way to avoid them is to use a password manager and let it choose a unique random password for each account. Your risk is that somebody compromises the end point and steals the password from your computer or the service. Something like SRP protocol can help prevent passwords from being stolen from the service endpoint because they avoid sharing the password. Even if the service hashes passwords, it's not that hard to find collisions (a password with the same hash which will also work). What Wikipedia ought to do is implement automatic blocking of IP addresses, for a finite duration, after they are involved in threshold number of failed login attempts. This would slow down brute force attacks. Another thing Wikipedia could do is download the HIBP database of compromised credentials and automatically disable any credentials found on the list. Jehochman Talk 14:35, 11 January 2021 (UTC)
    I have not had any issues with the 2FA system. (And I was hesitant to enable.)
    Wikimedia does already pull either the top 10k or 100k compromised phrases and forces a change for those passwords for old people trying to login and forces new accounts to avoid those. --Izno (talk) 17:24, 11 January 2021 (UTC)

Resysop request (Ivanvector)

Resysop granted. Consensus remains that a 24-hour hold is required for resysop requests, although ideas for further clarifying or rewording that requirement can always be had on the appropriate policy page(s). No additional desysop/resysop cycle is required. Peace and love to everyone. 28bytes (talk) 03:37, 19 January 2021 (UTC)

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

Requesting restoration of my administrator privileges, following an incident last week. I've taken all the steps I think I can to ensure my account's security (logged out, changed passwords, and same on my password manager and recovery email account), and verified with checkusers to the extent possible that there don't seem to have been any attempts to access my account.

Thanks to everyone who has reached out with messages of support, both on- and off-wiki. They are greatly appreciated. Cheers. Ivanvector (Talk/Edits) 19:32, 13 January 2021 (UTC)

  • No concerns, standard 24-hour hold for restoration of sysop access. — xaosflux Talk 20:01, 13 January 2021 (UTC)
  • Given this was a security removal and not a resignation, I don't see the need to wait the standard 24 hours, and we can let Ivanvector get back to their good work.  Done -- Amanda (aka DQ) 20:56, 13 January 2021 (UTC)
    I don't see where policy allows for any exception, regardless of circumstances. Being that this was security related, if anything, would make it more important such that time is allowed for comments and can be considered before handing back the bit. Dennis Brown - 2¢ 22:30, 13 January 2021 (UTC)
    Wikipedia:Bureaucrats#Restoration_of_permissions and Wikipedia:Administrators#Restoration_of_adminship seem to be pretty clear that this hold is expected. So what to do now? On the one hand, absent any actual complaints I don't see the practicality of continuing to flip flags on Ivanvector's account. I do feel that @AmandaNP:'s action was a bit rogue though, even if in good faith. Can't see any reason to drag this to ArbCom - but will float the idea of an informal admonishment to the other crats here. Any thoughts from the rest of our cohort? — xaosflux Talk 00:12, 14 January 2021 (UTC)
    Just thoughts from crats? --Floquenbeam (talk) 00:40, 14 January 2021 (UTC)
    @Floquenbeam: not trying to quell discussion from anyone else, just floating some idea; - as I said above, I'm assuming good faith here and can't see any serious proposal to issue other remedies being helpful. Also, policies and policy interpretations can change - and if this is reflection of a new community norm we can document it. — xaosflux Talk 00:45, 14 January 2021 (UTC)
    OK, then for what it's worth, I think Amanda's quick resysop was fine for this particular set of circumstances, for the reason that she gave. I don't see it as a mistake. But I'd hope that, at absolute worst, if this view is in the minority, that this discussion is refocused as "what do we as crats want to do next time", rather than any kind of "informal admonishment". Crats seem to get along as a group better than most other groups on WP. I'd hate for that to change and see informal admonishments become a thing. --Floquenbeam (talk) 00:55, 14 January 2021 (UTC)
    (ec) The link to the permissions restoration policy is clear that a minimum of 24 hours is required. If I recall correctly, the discretionary portion of the resysopping procedure was added in order to be more conservative rather than more liberal. Turning the bit back off to return to the status quo would probably be just a formality, and, in fact, I'm not even certain that that can technically be done within policy, barring WP:IAR, which isn't something I'd be prone to invoke in a bureaucratic capacity, so I will decline to flip it back. While I do agree with Dennis Brown's statement, I have no comment on Xaosflux's floated idea. As a rule, I stay out of that sphere. Useight (talk) 01:02, 14 January 2021 (UTC)
    Going to agree on multiple points. Unless there is a substantiated concern in the next... 18(ish) hours, flipping the bit just for the formality of it is pointless (and for what it's worth the CUs and Arbs are fairly convinced the account has not been compromised). Should this sort of thing happen in the future? Likely not, even in clear cut cases such as this (and given the general feedback in this discussion). I would also say that there is little point in going through any formal process w.r.t. Amanda for doing said action; if anything it gives us the opportunity to discuss the matter. Primefac (talk) 01:54, 14 January 2021 (UTC)
    My primary reason for mentioning it wasn't to change the status or raise a stink, but to insure it didn't happen again in the future. I was a bit taken aback that a Crat would do that, seeing that Crats have a reputation for being very conservative about applying policy. I know Amanda reasonably well and respect her, but felt it was necessary to point out the mistake, regardless of who did it. Dennis Brown - 2¢ 00:49, 14 January 2021 (UTC)
    I'm not too big on bureaucracy or policy adherence, but from a security viewpoint and as with future cases in mind, it would make sense to give the REAL Ivanvector (as opposed to the community) the chance to offer an objection to a potential compromise by an imposter. Hence I think a delay would be appropriate even in these particular circumstances, next time. For now, we'll just have to keep an eye on Ivan :) -- zzuuzz (talk) 01:25, 14 January 2021 (UTC)
  • The risk of someone at his former place of work who is not Ivanvector finding BN, learning how to wikilink to the resignation, and also take his somewhat distinct cadence of writing in order to get admin flags is, to be blunt, practically non-existent.
    Ivanvector was right to resign the tools as accidental compromise of sensitive accounts is probably the biggest risk. Once someone has access to an account they find has special buttons they might do something damaging. That’s a real risk. One of his former coworkers caring this much to impersonate him really isn’t. The policy calls for 24 hours, so if you want to yell at AmandaNP for that, I guess you can. There’s no real security risk here, though. Human nature and motivations are as much a part of IT risk assessment as the technical measures that we like to focus on. TonyBallioni (talk) 06:29, 14 January 2021 (UTC)
  • As above — not an issue here, clearly good faith, probably shouldn't happen again. Someone gets a little trout for dinner, nothing more. ~ Amory (u • t • c) 11:54, 14 January 2021 (UTC)
  • It's done, so it's done, but I hope that it doesn't happen again, particularly in a case where there have been security concerns and the community may wish to see that several 'Crats are satisfied that those security concerns have been checked and cleared. 'Crats are here to uphold consensus and not push the envelope on what is and is not permitted. There was no imperative involved here which would justify not waiting the standard 24 hours. I don't know what we do if it happens again, or a 'Crat pushes the envelope too often. I suppose we have a 'Crat chat and issue a formal warning? And if it happens again after a formal warning, we request an ArbCom case? SilkTork (talk) 15:19, 14 January 2021 (UTC)
  • On User:Xaosflux's request to gather thoughts on an informal admonishment - I think by default an informal admonishment is already occurring. I should think by now Amanda would have taken on board this was an action that has provoked discussion, and I doubt if Amanda will do it again. I don't think we need go any further than that. However, the community may wish to consider if it may be appropriate to draft a formal process to outline what happens when a 'Crat is making decisions which cause concern. Is it just 'Crats who can issue informal or formal admonishments to a 'Crat? Because of the "get along as a group" aspect to 'Crats, perhaps 'Crats really aren't best placed to be the ones to judge or admonish a fellow 'Crat. How would the community feel about a 'Crat acting out of consensus, and fellow 'Crats shrugging and saying that's OK, because it appears we don't want to upset the group camaraderie? I'd welcome the community discussing the issue of a 'Crat making decisions which cause concerns, and drafting a proposal for a route to resolve such matters. I should think that any user could take a 'Crat to ArbCom if they felt that 'Crat was making serious errors of judgement. But what about minor errors of judgement which are eroding confidence in that 'Crat? SilkTork (talk) 15:51, 14 January 2021 (UTC)
    @SilkTork: not sure the best way - I think this was a bad execution, but I don't think it needs a corrective action; I do think it should be discouraged from reoccurring baring new community standards emerging. If this was a similar admin action I'd say WP:TROUTing would be in order - but that seemed a bit wrong. I suggested admonition in the sense that I think that this was an inappropriate action and that we would would oppose future occurrences of the same. We are a unique group in that there are a few special processes that rely on the consensus of only crats, also related to the administrator of administrators. — xaosflux Talk 16:04, 14 January 2021 (UTC)
"oppose future occurrences of the same". Agree - both in the sense of Amanda acting out of consensus again (which I truly doubt she would), and of any 'Crat resysopping without waiting 24 hours again (which I also truly doubt would happen). However, where I'm not sure is how that opposition would take place. Is there, for example, any precedent for a 'Crat reversing a 'Crat action? How do we get consensus for reversing a 'Crat action? Are 'Crats the ones best placed to issue admonishments, given that we are such a small group and some may not wish to create tension within the group. Indeed, in this issue, where a 'Crat has clearly and deliberately flouted consensus, we are tip-toeing around it and saying it was done in good faith, that it doesn't matter, that it was a minor incident, etc. On the other hand, given the nature and circumstances of the incident, it was relatively minor, and I can't see the community really wanting to take this particular incident any further. It's not serious enough for an ArbCom case; it is, as you say, just an incident which requires a trouting - an informal, even friendly, reminder to the individual to take more care in future - particularly where there are security concerns. And I think in this discussion we have done that. As such I don't think this particular incident needs to be taken any further. But I do feel there is room for the community to look into how we deal with such incidents in future. And I don't think it is our place to decide that alone. It has to be a community decision. SilkTork (talk) 17:52, 14 January 2021 (UTC)
I think it is even more simple than this, although I don't disagree with your logic. The community has already spoken when it wrote the policy (something I was actually quite involved in). Amanda's actions were counter to the policy, but I have to assume it was an innocent mistake as I can see no malice, nothing to be gained by Ivan or Amanda by the move. A non-Crat (me) was the first to point it out. Several people have spoken out about it and more or less agree, so this discussion is already creating a consensus that confirms the original consensus, that there should always be a 24 hour wait. Understandably, Amanda hasn't replied, waiting for the smoke to settle, but really there isn't any need for smoke or fire. It was a mistake, nothing was broken, the discussion confirms that the policy should be taken very literal. I would oppose ANY action to sanction or make an Arb case from it, as it would be overkill for this singular incident. For me, the best outcome is it being closed at the appropriate time with a statement that "The community agrees that the policy should be strictly viewed when it comes to the 24 hour wait to resysop. No further action is needed". Amanda needs to be informed, but not trouted or admonished. Dennis Brown - 2¢ 18:14, 14 January 2021 (UTC)
Is there, for example, any precedent for a 'Crat reversing a 'Crat action? Only around Floq and the Fram incident, but I think most of us would agree that was a rather crazy situation. That did end up before ArbCom (mostly as an add-on to the case) but we were just given a slap on the wrist for wheel-warring over Floq's Fram's perms. Primefac (talk) 18:18, 14 January 2021 (UTC)
Wasn’t there an RfA closed by a Crat who voted and so another crat had to reclose it, Xeno I think? ProcrastinatingReader (talk) 18:26, 14 January 2021 (UTC)
Pretty sure that's not what SilkTork was getting at. Additionally, that's a re-close, not any sort of reversal. Primefac (talk) 18:29, 14 January 2021 (UTC)
No, but I think some of the same questions as SilkTork mentions were discussed (eg whether a consensus of crats, or even the crat themselves, can reverse a crat action if it involves desysopping), I suppose for the event that the reclose was no consensus. I may be misremembering, and can't check since I don't remember whose RfA it was being discussed (it'll be in the archives here, though). Perhaps someone else remembers. ProcrastinatingReader (talk) 21:10, 14 January 2021 (UTC)
Ah, here it is, and it was for this RfA. ProcrastinatingReader (talk) 21:13, 14 January 2021 (UTC)
@Primefac: just for posterity's sake - and not to reopen any old wounds - but I think you're slightly misremembering. No Crats wheel-warred over my perm. WJBscribe reversed a ThePowersThatBe desysop, but he didn't reverse a Crat, and no Crat reversed him. --Floquenbeam (talk) 18:34, 14 January 2021 (UTC)
You're right, I don't why I thought it was you; we did wheel-war over Fram's bit being restored. I've updated my statement above. Primefac (talk) 18:49, 14 January 2021 (UTC)
  • I'm disappointed to see this characterized as a mistake. I understand that the 'crats owe greater care to security removals and restorations, but this was well scrutinized before I posted here. I explained in much more detail on private email lists (from a known email which was not exposed) and also confirmed with stewards/checkusers that there had been no attempts to access my account. Amanda and several of the other functionaries who have commented here are on those lists (and the thread was also copied to Arbcom) but I think the users who have called this a "mistake" would not have seen those discussions. Of course I can't say if that factored into Amanda's decision to restore my userright before the standard hold (and wasn't expecting it), all I'm saying is there was nothing careless about any of this. So please hold off on the admonishments. Ivanvector (Talk/Edits) 18:43, 14 January 2021 (UTC)
    The problem is that it was a mistake. Policy is crystal clear on this, and doesn't allow for exceptions, regardless of circumstances. This doesn't mean admonishments are required, but an acknowledgement that it was an honest mistake would be welcomed. Dennis Brown - 2¢ 19:59, 14 January 2021 (UTC)
    @Dennis Brown: Alright, fine. If exceptions are not allowed, then policy is crystal clear that I have been re-opped in error and against policy. You must remove my sysop flag, and wait 24 hours for community input before restoring it. I'll wait for the notification that the flag has been removed again. Ivanvector (Talk/Edits) 18:14, 15 January 2021 (UTC)
    I've already said I was against that, and no one is blaming you. I pointed out a mistake and said we should not repeat it in the future. Anything more made of it isn't on me. Admins are expected to get bold from time to time, Crats are not. Their reputation and standing depends on them not doing so. Dennis Brown - 2¢ 21:53, 15 January 2021 (UTC)
    Even if they wanted to do that, purely as an academic exercise, there doesn't seem to be a provision at Wikipedia:Bureaucrats#Removal_of_permissions for crats unilaterally removing a sysop flag given in error? ProcrastinatingReader (talk) 18:20, 15 January 2021 (UTC)
  • I can't say I agree with Floq that often, but I agree with Floq's statement above. This debate gets at the heart of what bothers me the most about the role of 'crats: these are people who have received an overwhelming amount of community endorsement...in order to follow the rules exactly as they're written, without an inch of deviation (except for 'crat chats, at which point they're suddenly allowed to have opinions). In this case, Amanda applied IAR, which happens to be a fundamental principle of Wikipedia. Per Ivanvector's comments above, the security of their account was amply confirmed to functs and ArbCom, and so their self-requested temporary desysop is no longer necessary. No damage has been done. All I see here is arguing over bureaucracy for the sake of bureaucracy. SubjectiveNotability a GN franchise (talk to the boss) 18:32, 15 January 2021 (UTC)
    I can't say I agree with Floq that often... :o !! --Floquenbeam (talk) 18:37, 15 January 2021 (UTC)
    They are bureaucrats after all. Do we really want crats using their judgement to make IAR decisions? Seems to be a one way street to controversy. The next logical step would be that a SNOWing consensus of community support, 100 votes and 0 opposes for example, in favour of removing a sysop bit means that removal of the bit should be actioned by crats[1] ProcrastinatingReader (talk) 18:50, 15 January 2021 (UTC)
    I am wholeheartedly in favor of 'crats using their judgment when necessary. I can't speak for anyone else (and frankly, not sure if I can even speak for myself - I don't know if I've ever voted in an RfB), but if I were to !support someone in an RfB, that means I trust them to make decisions involving the crat bit, including ignoring rules when necessary. Your scenario is not at all a "next logical step," it's a slippery slope argument. Here, Amanda skipped one part of a community-consensus rule (admins who resign the bit may have it back on request after a 24-hour hold) in a case where that rule clearly applied but had what I would consider mitigating factors (self-requested desysop due to security concerns, security concerns have been dealt with and apparently verified by functs, I can see literally no reason why Ivanvector should not have the bit back immediately). What you're suggesting, though, is inventing new 'crat powers out of whole cloth, which is not at all the same thing. SubjectiveNotability a GN franchise (talk to the boss) 19:12, 15 January 2021 (UTC)
    I do think it’s a bit of a slippery slope. After all, what inherently makes one IAR application any more legitimate than another? If it could be decided in advance, it would be a PAG, not IAR. ProcrastinatingReader (talk) 19:14, 15 January 2021 (UTC)
  • Oh wow, we're still on this? If you want crats to unthinkingly follow the letter of policies, you should check out this aptly named policy and this 19 year old policy. Now obviously crats shouldn't go around flipping the sysop bit willy-nilly, but why appoint them if we don't trust them to use their brains? As Tony explains, the risk of Amanda's action was outrageously low and absolutely nothing bad happened because of the effort CUs and Ivan put into making sure the account was secure before making the request; most unblock requests pose a greater threat to the encyclopedia than this resysop request did. I'm opposed to precess for the sake of process, especially in cases like this where it is so obviously pointless. If you want a policy citation for that opinion, see my links above or check out WP:SNOW. — Wug·a·po·des​ 21:56, 15 January 2021 (UTC)
  • I think Dennis summed it up well. Crats are expected to follow the letter of policy. The only time past that might be extraordinary situations, which this certainly is not. IAR does not apply as there was no big need to help the encyclopedia that could not wait 24 hours. Policy is explicate here, wait 24 hours. I am also pretty sure Amanda acted in good faith and that she won't do this again. All that said I don't think there is anything to do here. PackMecEng (talk) 22:25, 15 January 2021 (UTC)
  • I obviously did not think I would be making that controversial of a decision flipping Ivanvector's bit back on, and obviously I didn't think it would be disruptive enough to warrant the procedural request below this. For those of you who are wondering "what the fuck was she thinking" at the time, it basically follows on what Wugapodes said. Wikipedia is not a bureaucracy and IAR. I thought those two ideas were strong enough to skip the language (I had only read WP:CRAT at the time) of the requirement. Beyond that, Ivanvector's account was not compromised and this was a precautionary measure, which was good on Ivanvector to take. Even if the account did turn out compromised (which I agree with Tony's comments on the very very very low likelihood, it wouldn't be something a 'crat would have to deal with, it goes to a steward for a global lock at that point, who are much faster than our slow "need a discussion" butts. Beyond that, I don't think we've had (if ever) a person in a long time that has taken this security precaution, and I'm not sure it was taken into account when the policy was written requiring the hold. I don't think the community needed an excessive amount of grilling Ivanvector about account security when they took the upmost precautions himself. If the community wants to trout me for this action, I'll take it and not do it again, though I do think the reasoning is still solid. -- Amanda (aka DQ) 01:27, 16 January 2021 (UTC)

Moving forwards

Arguing over whether this was a mistake or a good application of IAR isn't helping. Can we just agree a way forward for the future?

I suggest that a 24 hr wait is a very small price to pay for community scrutiny, which is valuable. I propose we strengthen the point in RESYSOP about the delay by adding "in all cases" or "without exception" or something. It won't prevent a future mistake (us Crats are human, I've heard) but it will clearly tell Crats not to IAR on this. --Dweller (talk) Become old fashioned! 11:35, 15 January 2021 (UTC)

I don't know if we need to clarify the language; I've added emphasis — it is required that a minimum of 24 hours elapse — in order to make that point clear. Primefac (talk) 12:01, 15 January 2021 (UTC)

Procedural desysop request - Ivanvector

Per the discussion above, and per the bureaucrats information summary page (I didn't know that was a thing but it's explicitly not a policy), I am formally requesting removal of my administrator permission. Again.

There was absolutely no need to have made a big deal over this, but since some users felt the need to make it a big deal anyway with my and Amanda's names attached, let's undo all of these "mistakes" and go back to the start, doing things exactly to the letter of policy. While you might think I'm doing this only to make a point, understand my position here: as a functionary I work in highly sensitive areas and do things that tend to make people angry. I don't need to be exposed to the inevitable harassment that any admin actions I make are illegitimate because my rights were restored out of process. I'm not going to be Wikipedia's poster child for deviations from bureaucrat procedures; I get enough crap as it is.

@AmandaNP: I'm very sorry that your kind and rational (and policy-supported) decision has led to this course of action. Ivanvector (Talk/Edits) 23:59, 15 January 2021 (UTC)

I am going to clerk this section as a 'crat, and remove any non-crat (or non-Ivanvector) posts. This is a 'crat decision to make and we don't need the peanut gallery chiming in. I am also declining to enact this request (per the "may" in the procedures). Primefac (talk) 00:04, 16 January 2021 (UTC)
As this is a rather WP:Pointy request I for one am not going to carry it out. We are all volunteers here, and are not obliged to do anything we don't wish to. SilkTork (talk) 01:32, 16 January 2021 (UTC)
Ivanvector, I would actively decline this request. (Per my colleagues above, but going further as an active decision) People say pointy, I say pointless. This is a molehill, that can be sorted with words, not actions - I for one accept Amanda's reasoning, but also ask that she (and other crats) do not skip that 24h in future. I don't think anyone is asking for more (except Dennis who wanted the word mistake, but I don't think that's necessary).
I also appreciate the chance to genuinely decline a self desysop! Since the rules state that resignation can be for any reason - look, I'm IARing as a crat! WormTT(talk) 08:46, 16 January 2021 (UTC)
(EC) The 24 hours has more than expired, and we now have the edits to evaluate whether the person currently controlling the Ivanvector account is the same person as the one we know as Ivanvector and not some random non Wikipedian work colleague usurping it. Please count my declining this desysop as the equivalent of my performing a resysop after the 24 hour wait and a comparison of their most recent edits with older ones. ϢereSpielChequers 18:25, 16 January 2021 (UTC)
I don't know if this is formally needed, but you can count myself as a decline per my above explanation. -- Amanda (aka DQ) 01:00, 19 January 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Wikipedia:Inactive administrators/2021#February 2021

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

  1. Hiberniantears (talk · contribs · blocks · protections · deletions · page moves · rights · RfA)
    Last admin action: Aug 2019
— xaosflux Talk 00:15, 1 February 2021 (UTC)

Request desysop (only)


Hi.... After something like 12-15 years of Wikipedia, I'm retiring and requesting removal of my sysop rights to prevent any issues down the road. Thank you! only (talk) 18:05, 2 February 2021 (UTC)

 Done. Happy trails. Primefac (talk) 18:34, 2 February 2021 (UTC)
Much obliged. only (talk) 18:36, 2 February 2021 (UTC)

Archive deletion discussion

Pages restored. Primefac (talk) 19:47, 2 February 2021 (UTC)

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

[[re:Only}} Unless there's a particularly good reason, your user talk page archives shouldn't have been deleted per WP:DELTALK. I won't undelete until I hear from you that there aren't extenuating circumstances (since you now can't undelete them yourself!). 12-15 years is a good run, thanks and good luck with everything. --Floquenbeam (talk) 18:46, 2 February 2021 (UTC)
@Only: Sorry. My continued incompetence regarding pinging (and previewing) is unbearable for myself and everyone else. --Floquenbeam (talk) 18:47, 2 February 2021 (UTC)
If you must, you must. But I went on the belief that "generally not" means it can happen, and deleted them as to reduce my digital footprint that dates back to 2005. While the archives don't, I believe, reveal personal information, my handles here were doxxed (as were many other admins by internet "sleuths" many years ago) so I delete them as one fewer scrap of connection. only (talk) 18:55, 2 February 2021 (UTC)
I guess it's not a question of must; if there's even a hint of a privacy question, I'll just defer to the Crats. But I do know that many people use {{db-user}} on their talk pages on their way out, and I've never seen an admin do it for them. Similarly, I've occasionally seen a retiring admin do it, and the pages always get undeleted. Frankly, I think everyone should probably be able to do this, and DELTALK is kind of dumb, but if non-admins aren't allowed to do this, I think an admin doing it for themselves should have a good reason. I'll leave it to the Crats on whether this counts as a good reason or not. --Floquenbeam (talk) 19:01, 2 February 2021 (UTC)
@Floquenbeam: Page deletion isn't a 'crat issue. If anyone would like this admin action reviewed, WP:AN is down the hall. — xaosflux Talk 19:16, 2 February 2021 (UTC)
Ugh. I'm not going to take anyone to that cesspit, especially a retiring editor in good standing who put in their 15 years. I know it isn't specifically a Crat issue, but "Crat" is roughly equivalent to "long term editors who are almost universally trusted". I'll just wait to see what happens, and if the deletions stick without anyone else complaining, I'll simply start ignoring DELTALK from now on, and accept any {{db-user}} requests I see on user talk pages of any editors in good standing who are leaving. Either both of us will get away with it, or neither will. I hope we both do. --Floquenbeam (talk) 19:21, 2 February 2021 (UTC)
Floq, I had the same thought you did when this first popped up on my watchlist (why is BN on my watchlist again?). Should not have been done per DELTALK, but I am not fighting anyone to reverse it or dragging someone to AN over it. — The Earwig talk 19:29, 2 February 2021 (UTC)
One of the ways we try to keep BN from becoming a cesspit is by keeping the plumbing working here :) — xaosflux Talk 19:39, 2 February 2021 (UTC)
I have reversed the deletions as a pseudo-decline of the "U1 request" purely as an admin action (i.e. not acting in any other capacity), as I agree with Floq's assessment. To follow on from xaosflux's comment (re:keeping the noise out of BN), any further discussion can take place at User talk:Primefac since I was the one that made the decision. Primefac (talk) 19:47, 2 February 2021 (UTC)
I created the talkpage again (didn't undelete it though). I created it to say bye to only. I believe creating it is alright as it wont reveal anything; which was the reason for deletion. —usernamekiran (talk) 19:44, 2 February 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Desysop request for Lear's Fool

I've been retired as an editor for a long time and there's no prospect of me returning to regular administrative duties in the near future. Probably time to resign the tools. Lear's Fool (current rights · rights management · rights log (local) · rights log (global/meta) · block log)   -- Lear's Fool 00:57, 6 February 2021 (UTC)

 Done. Primefac (talk) 01:03, 6 February 2021 (UTC)
Thanks.  -- Lear's Fool 02:46, 6 February 2021 (UTC)

Happyme22

To track this and other pending removals see WP:INACTIVE, certainly let us know if we ever miss someone though! — xaosflux Talk 16:36, 13 February 2021 (UTC)

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

Why does Happyme22 (talk · contribs) still have the admin rights? They haven't edited in a full year. Or made log actions, for that matter (Thunderboltz, Verrai, Deathphoenix, AA, etc.) 🐔 Chicdat  Bawk to me! 12:54, 13 February 2021 (UTC)

Oh, now I see that their rights will be removed on March 1. 🐔 Chicdat  Bawk to me! 12:55, 13 February 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Wikipedia:Requests for comment/Desysop Policy (2021)

I have opened an RfC at Wikipedia:Requests for comment/Desysop Policy (2021) to discuss establishing a community based desysop policy. All are invited to comment. TonyBallioni (talk) 20:48, 20 February 2021 (UTC)

proposed alternate request for de-bureaucratship / de-adminship / de-intadmin process

Thank you for the link TonyBallioni. It looks like the bureaucrat tasks being proposed are:
  • confirming that a given request for desysop / de-bureaucrat / de-intadmin has been certified as prescribed;
  • transcluding the certified request, should the discussed rightholder not do so as prescribed;
  • (knock-on) tending to notice threads placed at BN upon initiating and transclusion of requests;
  • (presumably) clerking on ongoing requests;
  • closing expired requests; those with 60% in support of removal result in removal of affected privilege; removal of Sysop necessitates removal of bureaucrat* and intadmin;
  • (where applicable) request bureaucrat removal at m:SRP in absence of local ability.
The surface for bureaucrat discretion seems minimal. Did I miss anything? –xenotalk 02:34, 21 February 2021 (UTC)
xeno, I think you have it. There’s some discussion as to if there should be a discretionary range for removal, but unless there is a groundswell for that, it is not included in the current proposal. The roles for bureaucrats in this proposal are mainly ministerial. TonyBallioni (talk) 02:46, 21 February 2021 (UTC)
Who determines whether the original noticeboard closures resulted in the necessary censure? –xenotalk 17:37, 21 February 2021 (UTC)
  • Notably, while the page title doesn't include it, this is also a de-bureaucrat process. — xaosflux Talk 04:49, 21 February 2021 (UTC)
    How so? –xenotalk 04:58, 21 February 2021 (UTC)
    @Xeno: the last line of the proposed policy addition (which I think has other problem unrealted to this) includes Users may additionally initiate this request to remove ... bureaucrat permissions. — xaosflux Talk 05:03, 21 February 2021 (UTC)
    Thank you, I updated the list. –xenotalk 17:49, 21 February 2021 (UTC)
    I added this as there was concern expressed by Rschen7754 that stewards would not recognize a request to remove bureaucratship without an explicit policy basis (see case on the talk page.) So if someone is desysoped, they will be de-cratted automatically. Someone could also initiate this against a crat if there was concern, but I don't think we've ever had a case of someone explicitly only asking for crat rights to be removed, and I doubt they would start now. I disagree with Xaosflux's implication here that this is sneaky hidden somehow, since it was an afterthought added literally to make it clearer for stewards. TonyBallioni (talk) 05:06, 21 February 2021 (UTC)
    Ah, it was added after. You should probably notify the 22 people that had supported it when the addition was made, as it changes the proposal. (Oh, you did)
    It’s late, but wouldn’t this mean that less people are needed to remove a bureaucrat than installed them? –xenotalk 05:16, 21 February 2021 (UTC)
    Yes, but that's consistent with the process proposed for admins as well, and also consistent with the current process of having the same body remove +crat as would remove +sysop (AC). Anyway, as you say, it's late. TonyBallioni (talk) 05:27, 21 February 2021 (UTC)
    I updated the list, please double check. TonyBallioni: Since this expands the scope of the request could we make it more clear in the original notifications that it applies and can be used exclusively for the two other permissions also? –xenotalk 17:37, 21 February 2021 (UTC)
    If it passes, we might think about finally having bureaucrats be able to withdraw the bureaucrat privilege. The "crat gone rogue" scenario isn’t as scary as it used to be. –xenotalk 05:36, 21 February 2021 (UTC)
    I don't think it was "sneaky" - just making sure it was clear to the audience of the Bureaucrats' noticeboard that a new process that can be used for community removal of bureaucrats has been proposed. — xaosflux Talk 05:18, 21 February 2021 (UTC)
    So many edit conflicts. Was changing the word there to hidden. All's good here and no hurt feelings :). TonyBallioni (talk) 05:27, 21 February 2021 (UTC)

Desysop again please (Boing! said Zebedee)

I took back the admin tools last year to help with the demands brought by the Covid-19 pandemic, which was putting pressure on existing admins. The need appears to have eased off since then, and I've performed very few admin actions in that area in 2021 (just a couple of blocks that were promptly addressed and reversed). I also have important personal priorities over the next few months, and removing all those Covid pages from my watchlist would greatly reduce the distraction. So please disable my admin tools again. Boing! said Zebedee (talk) 09:22, 25 February 2021 (UTC)

Done - thanks for your work Boing! said Zebedee WormTT(talk) 09:40, 25 February 2021 (UTC)
:-( Ritchie333 (talk) (cont) 19:12, 25 February 2021 (UTC)
what Ritchie said ^^ :-( — Ched (talk) 21:07, 25 February 2021 (UTC)

Compromised sysop account - DYKUpdateBot

Hello, I just locked DYKUpdateBot as compromised. This account holds local sysop permissions, so I decided to inform bureaucrats in case they wish to take any local action. Best, Martin Urbanec (talk) 19:58, 25 February 2021 (UTC)

@Shubinator: please review and reply about this situation. ArbCom can review the WP:LEVEL1 situation. — xaosflux Talk 20:02, 25 February 2021 (UTC)
Ya I saw nothing in crat policy to tell us to desysop, so i'll leave that to ArbCom. I blocked the account at least for local accountability before the account is restored. Also blocking DYKHousekeepingBot (talk · contribs) per stewards saying it's out too. -- Amanda (aka DQ) 20:05, 25 February 2021 (UTC)
Forgive me for being dense, but a quick look through the contributions doesn't reveal anything that would mandate an obvious emergency. I assume there's something else going on here that I don't get. Ritchie333 (talk) (cont) 20:07, 25 February 2021 (UTC)
@Ritchie333: there is a private tech report about this that a sysadmin acted upon. — xaosflux Talk 20:12, 25 February 2021 (UTC)
I didn't, just realized and took it back off. I don't see anything obvious either through local CU, but I'm assuming something on the steward end triggered it. -- Amanda (aka DQ) 20:08, 25 February 2021 (UTC)
Yeah, if this is WP:BEANS then that's fine by me - I just think it's worth spelling it out because a lot of people submit DYKs and won't necessarily be up to speed on what stewards do. Ritchie333 (talk) (cont) 20:11, 25 February 2021 (UTC)
This is a BEANS situation for sure. Bush's baked honey maple flavored, I think. CaptainEek Edits Ho Cap'n!⚓ 20:13, 25 February 2021 (UTC)
Somewhat ironic that Xaosflux linked to a private report, which is the very definition of BEANS Ritchie333 (talk) (cont) 20:21, 25 February 2021 (UTC)
Tickets like this have limited access, and only members of the correct ACL can see it. But agree, posting the link was unwise, or at least ironic. QuiteUnusual (talk) 20:39, 25 February 2021 (UTC)
Meh. We rely too much on security through obscurity. --In actu (Guerillero) Parlez Moi 20:41, 25 February 2021 (UTC)
The report number was already publicly posted, I'll remove it from above since others are concerned though. — xaosflux Talk 20:42, 25 February 2021 (UTC)
Note: It's me who published the ticket ID for the first time (see the lock reason). Alone, the ticket number does not provide any information, unless you are a member of the correct Phabricator group. --Martin Urbanec (talk) 21:00, 25 February 2021 (UTC)


Level 1 desysop of DYKUpdateBot

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

Supporting: Barkeep49, Bradv, CaptainEek, Maxim, Worm That Turned

For the Arbitration Committee, Barkeep49 (talk) 20:23, 25 February 2021 (UTC)

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

Restoration of privileges to DYKUpdateBot

DYKUpdateBot (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 · ev · fm · mms · npr · pm · pc · rb · te)

DYKUpdateBot (talk · contribs) is granted administrative permissions on the English Wikipedia following the securing of its passwords by the operator.

For the Arbitration Committee, – bradv🍁 23:18, 26 February 2021 (UTC)

Discuss this at: Wikipedia talk:Arbitration Committee/Noticeboard § Restoration of privileges to DYKUpdateBot
 Done Permissions restored. -- Amanda (aka DQ) 23:30, 26 February 2021 (UTC)
meta:Special:Redirect/logid/40270399 (note of GUNLOCK). — xaosflux Talk 23:31, 26 February 2021 (UTC)
The violent imagery surrounding global locks is always interesting (glocked, gunlocked). ProcrastinatingReader (talk) 23:45, 26 February 2021 (UTC)
Or, possibly, a meaningless coincidence. Beeblebrox (talk) 23:49, 26 February 2021 (UTC)

Interface Admin for AmandaNP & DeltaQuadBot

AmandaNP
AmandaNP (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 · ev · fm · mms · npr · pm · pc · rb · te)

Hi all. I have had requests from a few people over time for an easy way to update js code on Wikipedia while still having a proper bug/code review/versioning system behind it. I just filed Wikipedia:Bots/Requests for approval/DeltaQuadBot 9. But to be able to edit other user's JS files, the bot will need interface admin permissions.
Policy also requires that I have the Int admin flag myself. I have assisted users with diagnosing and slightly modifying js/css code before, but I'll admit, I can't directly code in JavaScript. That being said, that wouldn't be my use for it. As a bot developer that solidly knows python and PHP, I can still clearly read JS and know what I'm screwing around with before I do it. I would not intend to edit any sitewide scripts or ones that affect a large amount of people. Just to assist getting this bot up and standard diagnosing of users having issues with scripts and their JS files. I'm also happy to answer any questions. -- Amanda (aka DQ) 23:03, 24 February 2021 (UTC)

Standard 48-hour hold for new IADMIN flags. @AmandaNP: this access requires that you have WP:2FA enabled on your account, do you have this yet? — xaosflux Talk 00:07, 25 February 2021 (UTC)
Yes, have had it on for a long time now. -- Amanda (aka DQ) 05:03, 25 February 2021 (UTC)
 Done. Primefac (talk) 18:26, 27 February 2021 (UTC)
DeltaQuadBot
DeltaQuadBot (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 · ev · fm · mms · npr · pm · pc · rb · te)
 Not done @AmandaNP:, your bot request will need to pass WP:BRFA first. We won't need another 48 hour hold for the bot assuming your primary account has access. You will need to enroll your bot account in WP:2FA as well. — xaosflux Talk 00:07, 25 February 2021 (UTC)
Oh ok, figured that still required it's own discussion here. No worries. -- Amanda (aka DQ) 05:03, 25 February 2021 (UTC)

Wikipedia:Inactive administrators/2021#March 2021

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

  1. Alexandria (talk · contribs · blocks · protections · deletions · page moves · rights · RfA)
    Last admin action: Dec 2017
  2. Happyme22 (talk · contribs · blocks · protections · deletions · page moves · rights · RfA)
    Last admin action: Jan 2011
— xaosflux Talk 00:20, 1 March 2021 (UTC)
@Xaosflux for Happyme22's last admin action Special:Redirect/logid/34097119 is from January 2011. DannyS712 (talk) 00:04, 2 March 2021 (UTC)
Thanks for note, corrected above - missed it in the sea of move logs. — xaosflux Talk 00:23, 2 March 2021 (UTC)

Voluntary Admin Removal \ WGFinley

I gained my bit in a much different time on WP and it appears the community has changed greatly during that time and I have lost touch with it. Therefore, I'm requesting that my access to admin tools be removed. --WGFinley (talk) 11:41, 20 February 2021 (UTC)

I've done that for you WGF. Thank you for your time as an admin. Noting here, for the record, the discussion at ANI: [2]. SilkTork (talk) 13:11, 20 February 2021 (UTC)
SilkTork, please provide a permanent link or it doesn't do much for the record. Your link is already dead. Bishonen | tålk 09:48, 25 February 2021 (UTC).
this should do ϢereSpielChequers 09:55, 25 February 2021 (UTC)
That was a sad read, more than anything else. :( Acalamari 11:13, 25 February 2021 (UTC)
Yeah. This started with deprotecting The Lincoln Project. As the original author of that article, I follow it and was thus aware of this little tempest, but didn't realize it had gotten as far as AN. As mentioned by others in the WP:AN thread, I think this whole thing went off the rails, with a relatively minor error getting amplified by over-reactions. I didn't see anything specifically mentioned about WP:CLOUD, but I'm assuming it doesn't apply here and WGFinley will be able to regain the bit simply by asking for it. I hope that at some point he'll be willing to get back into editing. -- RoySmith (talk) 18:36, 2 March 2021 (UTC)
Cloudiness is always determined when the bit is rerequested. Thryduulf (talk) 19:48, 2 March 2021 (UTC)

Adminship term length RFC

I have opened an RfC at Wikipedia:Request for comment/Adminship term length to discuss adding an term length to adminship, and what to do at the end of an admin's term. WormTT(talk) 10:34, 9 March 2021 (UTC)

Question from user

Thread retitled from "El C".

No bureaucrat action required.

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

Hello Bureaucrats. I hope you are well. The admin El_C has topic banned me from editing or discussing anything to do with the post-1992 American politics topic area (WP:AP2) for 6 months, broadly construed. I know you're not the ones to come to request a change to this or even to the policy. However, I have come to you today because the enforcing admin is now refusing to answer reasonable questions on my talk page. I tried contacting them on their talk page, but they called it "bordering harassment". So now I can't actully talk to the person who blocked me, what do I do? The admin even said, "You are also free to contact me on my talk page if anything of the above is unclear to you." I feel I should be able to scrutinise. I was of the understanding that it is Wikipedia policy to respond to reasonable questions. I would have brought this to someone at a lower level, but the only other place seems to be a arbitration page. I am not asking at all de-admin this user, but I do not know where I else I should go for help in this matter. I must stress, This is not a request to change sanctions and it is not a request to have adminship removed. Kind regards J.Turner99 (talk) 17:50, 12 March 2021 (UTC)

J.Turner99, please stop pinging me, anywhere, and otherwise forgo all required notification procedures. I am not interested, still. Not in your questions, not in anything about this. I've explained myself in more than enough length. The point is that your appeal was declined at WP:AE, in record time, which means that uninvolved admins have effectively ratified my action. You don't get to appeal a second time the next day, be it informally or in any other way. I am not obliged to answer endless questions (many of whom are irrelevant and/or faulty) from you about this. You appealed, did not succeed, and now it's a done deal. I'd tell you that I don't think you're doing yourself any favours with all of today's morphing-into re-appealing efforts, but I'm starting to doubt you'd listen to me, anyway. Well, at least I through it out there. El_C 17:56, 12 March 2021 (UTC)
(edit conflict) This is very obviously not the right forum (and crats, feel free to remove my comment when you get rid of this thread), but I'll answer. Where does it say you have the right to violate freedom of speech laws? Is Wikipedia a publisher, or a platform? is not the type of question that falls under WP:ADMINACCT. Admins have the right to impose sanctions, and your appeal at WP:AE demonstrated that there is support for those sanctions at this time. Your choices now are to agree to accept them and demonstrate good behavior elsewhere, to leave the project, or to be disruptive and get sanctioned more. power~enwiki (π, ν) 17:58, 12 March 2021 (UTC)
J.Turner99 Though I would recommend you take some time for consideration and reflection before you do so, appealing this result needs to be done at WP:ARCA (or by email to the committee if blocked) per Wikipedia:Arbitration Committee/Procedures#Standard provision: appeals and modifications #3. As there is no action for bureaucrats to take, I've archived this thread. –xenotalk 18:11, 12 March 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

technical query

Accidental rollback, solutions given to hopefully avoid it in the future. Primefac (talk) 13:20, 14 March 2021 (UTC)

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

Thread retitled from "remove permissions".

Maybe I made some weird mistaken edit with a screen open that I...I don't know. I don't think I was anywhere near TRM's user talk, and I don't know what this is. I think remove permissions until someone figures it out? —valereee (talk) 20:47, 12 March 2021 (UTC)

You likely accidentally clicked rollback without realizing it. It's not something to worry about; I've done it several times myself! Acalamari 20:55, 12 March 2021 (UTC)
Particularly easy to do from your watchlist.-- P-K3 (talk) 20:56, 12 March 2021 (UTC)
If that was indeed the case, this Rollback confirmation script might help. Blablubbs|talk 20:57, 12 March 2021 (UTC)
or pasting .mw-special-Watchlist .mw-rollback-link { display: none; } to commons.css, this only removes the rollback links from the watchlist. (Somebody has shown me this years ago, but I forgot who that was).--Ymblanter (talk) 21:00, 12 March 2021 (UTC)
@Ymblanter, I see a User:Valereee/common.js? —valereee (talk) 21:05, 12 March 2021 (UTC)
It should be User:Valereee/common.css--Ymblanter (talk) 21:17, 12 March 2021 (UTC)
Currently, you are I believe blocking all rollback links, from any page. May be this is also fine with you.--Ymblanter (talk) 21:18, 12 March 2021 (UTC)
You mean I can't use rollback at all? That would be fine. :D I really don't think I need it. —valereee (talk) 21:33, 12 March 2021 (UTC)
@Blablubbs, thank you so much, I think that would be a good idea, but I'm having a hard time even reading all the instructions right now because OMFG lol...is there an 'Install' button I can just click somewhere? —valereee (talk) 21:02, 12 March 2021 (UTC)
valereee, maybe just hiding outright is fine too, but for the record, if you enable "Install scripts without having to edit JavaScript files" in your gadgets, you can just go to User:Mr. Stradivarius/gadgets/ConfirmRollback.js (or any other script js page) and hit the "install" button at the top. By default, it only asks for confirmation on your watchlist, but you can add text to User:Valereee/common.js to customise it. My personal preference there is
ConfirmRollback = {
  watchlist: "hide",
  contributions: "confirm",
  recentchanges: "confirm",
  relatedchanges: "confirm",
  history: "confirm",
  diff: "allow",
}
which hides the button on the watchlist and asks for confirmation everywhere except when looking at diffs, but one can customise as needed. Best, Blablubbs|talk 21:33, 12 March 2021 (UTC)
I'm an idiot, missed the big button at the top of the page. —valereee (talk) 21:35, 12 March 2021 (UTC)
  • valereee: I think your account is probably not compromised, so I re-titled the thread. I also hide rollback links in certain contexts! –xenotalk 21:26, 12 March 2021 (UTC)
    Thanks, sorry for the freakout —valereee (talk) 21:29, 12 March 2021 (UTC)
    Don't worry about it! I accidentally rollback something at least once per year. But as I look through my own contributions almost as often as I check my watchlist, I usually spot it quickly and re-rollback. Incidentally, as the German Wikipedia gave rollback to all reviewers (anyone who can accept pending changes), and many of them were unaware and were then annoyed at having links of such an unfriendly and destructive nature appear all over their watchlists and contributions links, disabling single click rollback was pretty high on a list of technical requests a few years back. So you are far, far from alone :) —Kusma (t·c) 21:37, 12 March 2021 (UTC)
    The freakout was that I rolled back an edit on a user talk! Of someone whom, while I like quite a lot, I've had disagreements with! :D If it had just been some random page, okay, although I'm now unsure what my reasoning was, maybe I just forgot that I made that edit? But this was an unfortunate place to discover this problem. :D —valereee (talk) 21:43, 12 March 2021 (UTC)
    Not to fret - I didn't even have to go more than 500 revisions to find my last misclick. –xenotalk 21:51, 12 March 2021 (UTC)
    I think you can go back one edit behind mine on this very page to see one. Not sure if Floq was being humorous, or it was a true accident, but he reverted you, Xeno. Dennis Brown - 2¢ 22:04, 12 March 2021 (UTC)
  • Accidental rollbacks are so common—I wish the confirmation script was just a standard part of the user interface. {{u|Sdkb}} talk 22:07, 12 March 2021 (UTC)
    The confirmation script makes rollback useless - one can just use the undo button. Most of the accidental rollback probles come from the watchlist, because scripts load too slow. I would only recommend hiding rollback links everywhere or using the confirmation everywhere if one normally does not use rollback at all.--Ymblanter (talk) 22:30, 12 March 2021 (UTC)
    I normally don't. I'm wondering if this is just because it was a page on which I'd normally never revert anything that it even came to my attention, and that I've done this multiple times and never noticed. shudder... —valereee (talk) 22:49, 12 March 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Wikipedia:Arbitration/Requests/Case/RexxS closed

As part of the final decision in the RexxS case, the Arbitration Committee has passed a remedy to remove the administrative rights of RexxS (talk · contribs · blocks · protections · deletions · page moves · rights · RfA). The passed remedy can be viewed at Wikipedia:Arbitration/Requests/Case/RexxS § RexxS desysopped and an announcement has been made at ACN to announce the closure of the case and the remedy to remove RexxS's administrative rights. Would a bureaucrat please remove RexxS's administrative rights at their earliest convenience. For the Arbitration Committee, Dreamy Jazz talk to me | my contributions 23:37, 26 March 2021 (UTC)

Done. –xenotalk 23:56, 26 March 2021 (UTC)
Speaking as an editor here and not as a bureaucrat...damn. :( Acalamari 10:26, 27 March 2021 (UTC)
I think that 'crats and others active or interested in adminship matters would find it insightful to read through some of the case pages, the RfA, and the 'crat chat that followed it. UninvitedCompany 14:55, 31 March 2021 (UTC)
My first thought was that the "RfA" was not particularly relevant, but (outside of the specific wording) I do think that the Wikipedia:Arbitration/Requests/Case/RexxS § ArbCom and RfA is worthy of note. Just to be clear, I'm saying specifically that I don't think the crats should be blamed for any of this. (although other have stated otherwise) — Ched (talk) 15:46, 31 March 2021 (UTC)
I suppose, that you are, referring to my comments. I apologize for coming on too strong in words, but I still hope it does not come down to "blame" per se, but rather more like, 'after action analysis'. And I also would hope the focus is not on any individual crat, but on Crat process. The responsibilities seem too important, and consequences seem too painful or upsetting to too many, to not think about. Alanscottwalker (talk) 16:04, 31 March 2021 (UTC)
I haven't really been following this case, but from a quick look at the findings-of-fact etc. it seems that the desysop has resulted from specific breaches of WP:ADMINACCT, and not from some nebulous idea that RexxS wasn't suitable for adminship in the first place. Which is correct - I think that for ArbCom to imply that either the community who elected him, or the crats who interpreted that RFA, were incorrect in their reasoning would be a gross overstep of its sphere of authority. The conclusion from this must not be that the crats need to approach closures differently in future. IMHO they should take their direction in that respect from the community only.  — :::Amakuru (talk) 16:11, 31 March 2021 (UTC)
I see no reason to ascribe to Arbcom any overstep of any sphere of authority, nor any such implication that Arbcom is telling the Crats something. The community has instructed Crats about consensus gathering to some extent, but that's only part of it, the Crats process their own internal consensus gathering. -- Alanscottwalker (talk) 16:31, 31 March 2021 (UTC)
And just to be clear about Arbcom, beside ADMINACCT, there was also WP:ADMINCOND issues. -- Alanscottwalker (talk) 16:59, 31 March 2021 (UTC)
Alanscottwalker, (after ec) No, I wasn't referring to you at all, or any individual actually. There are/were a multitude of people who fell/felt that the 'crats were to blame the catalyst which set the situation in motion. Some even attempted to lay the blame causation at the feet of an individual crat. Personally I consider that to be extremely faulty logic. — Ched (talk) 16:17, 31 March 2021 (UTC)
I supposed wrong -- apologies. -- Alanscottwalker (talk) 16:39, 31 March 2021 (UTC)
A sad tale, to be sure. Of the whole chain of actions/decisions, by RexxS and others, that got to this conclusion, I'm not sure why to single out 'crat decisions at the RFA. I opposed at the RFA, but think the crats did a decent job trying to divine whether there was consensus in a situation where it was right on the edge. Unfortunately, it ultimately didn't work out, but it was worth trying. I know emotions are raw, but I'm also sad at the lamenting and criticism of Arbcom, who reached a fully defensible decision given the circumstances. I do hope RexxS comes back, and will be happy to support him at a future RFA after he shows Dr Jekyll has banished Mr Hyde. And crats, may you continue to do your best in even the tricky cases; just as you did in this situation at the time. Martinp (talk) 23:37, 31 March 2021 (UTC)
Well, I don't think it is singling out, it's a chain, as you say. But desyssop is still rare, and more pertinent, this was relatively swift from that link in the chain to this. Among other things, maybe placing them into a divided community made the chain very short. -- Alanscottwalker (talk) 00:50, 1 April 2021 (UTC)

Wikipedia:Inactive administrators/2021#April 2021

The following inactive administrator is being desysoped due to inactivity. Thank you for your service.

  1. Enchanter (talk · contribs · blocks · protections · deletions · page moves · rights · RfA)
    Last admin action: Dec 2006
— xaosflux Talk 01:57, 1 April 2021 (UTC)
There are usually no comments on these desysops purely for inactivity but 14+ years without an admin action and still being an admin has to set some kind of record. Talk about not using the tools. Liz Read! Talk! 18:47, 3 April 2021 (UTC)
I looked yesterday as I was not familiar with this admin, and it immediately became clear why that is. Not the 'crats problem, but I have long felt the activity policy is overly lax. Beeblebrox (talk) 18:53, 3 April 2021 (UTC)
You can use the tools without generating a log entry, such as reviewing deleted or revdel information, although that is more for the benefit of your editing than mopping up. Even AE actions are considered "admin actions" but often do not create a log entry. So in many cases I don't get excited if someone hasn't blocked or deleted anything in a year or two, although to go 14 years without a single logged event, you have to be actively avoiding it. That is the problem with making the rules too strict, a lot of good admin work doesn't create a log entry. Dennis Brown - 2¢ 00:50, 4 April 2021 (UTC)
There is indeed plenty of admin work that does not get logged. Logs are one metric, but one would have to actually look through a user's contributions to search for admin activity that doesn't get logged. That's not unrealistic. I went back a decade in this user's contribs and didn't see anything that could be construed as "unlogged admin activity". It took a couple minutes. You can tighten the rules without equating "admin activity" to "logged admin activity"; we already do this for crats and it's still very lenient. But I don't particularly buy the argument that we can't do so because someone could be viewing deleted content without any evidence of admin activity. I don't think an inactive admin should retain the bit by virtue of viewing deleted content and nothing else. ~Swarm~ {sting} 04:12, 4 April 2021 (UTC)
I agree with that, I just wanted to be clear that you can't look only at the logs. I wouldn't want to see the pendulum swing too far in the other direction, but yes, if you're going to have the bit, you should use it more than your own editing convenience. Dennis Brown - 2¢ 11:25, 4 April 2021 (UTC)
Support desysop per standard practice, and even more so because of the cogent analysis by Swarm. A person who is not now contributing to the administration of the encyclopedia should no longer retain the right to view deleted content. Cullen328 Let's discuss it 04:23, 4 April 2021 (UTC)
While there's no need to vote, if you want to discuss improving the inactivity policy you can check Wikipedia:Requests for comment/Change to sysop activity requirements. User:力 (power~enwiki, π, ν) 05:01, 4 April 2021 (UTC)
Wow, what a terrible page. ~Swarm~ {sting} 06:37, 4 April 2021 (UTC)

just to circle back around to the logged actions, yes there are many things an admin can do that do not generate a logged action. The current standard, (which I proposed because it seemed achievable), is that you only need to make one logged action every five years, and to not go more than one entire year without making an edit of any kind to retain the tools forever. We need't be nearly as strict as the functionary activity guidelines, but if you are actually doing admin work, you're going to need the tools more than once every five years. Viewing deleted content is a good example. If you're doing that, for five years, and don't find a single opportunity to restore a page or block someone for an edit that was recently deleted, what the heck are you doing? Beeblebrox (talk) 20:03, 4 April 2021 (UTC)

  • I am looking at the list for next month and wondering, is it an exception or a sign of things to come. Usedtobecool ☎️ 06:56, 4 April 2021 (UTC)
    12 is high, it was only 10 the same month last year, and that was a heavy month. But last August it was 13, so this is not a record. As usual one expects that most of them will do an edit or two this month and come off the desysop list for another year. If we changed the rules to also desysop admins with fewer than 100 edits or logged actions in the last 6 years we would either lose several of these or see them become a little more active. ϢereSpielChequers 14:05, 4 April 2021 (UTC)
    Looks like four of them have not used tools in five years or more, so they already are not really admins. Factor that in and it's less alarming. The overall number of permanent desysops via the five year rule seems to be trending down, but that's a bit of a spike. Beeblebrox (talk) 20:06, 4 April 2021 (UTC)
    I've mentioned this on a few talk pages, but you probably have 50 people doing the majority of the admin work at any given time, and another 150-200 who are involved to some degree in admin-type work either through commenting on boards, working in niche admin areas in addition to content, etc. The groups are somewhat fluid, but we're doing absolutely fine in keeping up the core number of people and replacing people in those group via RfA as attrition occurs. Anyway, these type of discussions usually lead to handwringing that we're losing so many people and RfA isn't replacing them, but when you look at it through a lens of "are we replacing the number of active people who we are losing?" The answer is very likely "Yes". TonyBallioni (talk) 20:21, 4 April 2021 (UTC)
    I agree with Tony's point about how many active admins we have at a given moment. However, his analysis that we're doing just fine is, I think, incorrect. 50 admin doing all the work is a bit misleading because it's not like they're all doing a bit of everything. Most admin work an area or two. Many processes are working only because we have 1, maybe 2, admin doing all the necessary work there and if that were to stop it's not at all immediately apparent that one of the 150-200 semi-active admin would be able to just step into the breach. Adding more admins don't cost us anything and provide us needed spare capacity. Best, Barkeep49 (talk) 21:36, 4 April 2021 (UTC)
    I don't disagree that adding more admins is a good thing. I just don't think that the usual fear over large amounts of inactivity desysops points to anything other than the 750 or so admins who aren't doing much anyway decreasing. TonyBallioni (talk) 22:08, 4 April 2021 (UTC)
    • The institutional memory concern you bring up is definitely worth consideration. I think it's most acute with bot operators, where losing a single editor often leads to unmaintained bots that die and cause problems. Part of the solution needs to be improving documentation, so that when an editor goes away another can more easily pick up the baton. As for the "cost" of having more admins, it's mainly that it reduces security and opens the door for abuses if we set the bar too low. But more generally, I agree we could invite more editors to be admins and still be fine. {{u|Sdkb}} talk 22:13, 4 April 2021 (UTC)
    The point when we desysop an admin for inactivity is not the moment when that admin ceased to be active. If we are going to measure the core group that Tony talks of that is a smaller group than Wikipedia:List_of_administrators/Active as that is a list of admins who have made 30 edits in the last two months - The vast majority of admin actions in the last two months will have been done by a subset of that group. But to address Beeblebrox's point, the problem is not when someone goes 12 months without an edit. The problem comes at least 12 months earlier when an active admin moves on to another hobby, and though the overall editing community is slowly growing, we aren't recruiting enough admins to replace those we lose. At about twenty new admins a year we would need the average admin to be active for 25 years to maintain a cadre of 500 active admins. I don't see that happening. ϢereSpielChequers 22:51, 4 April 2021 (UTC)
    @Usedtobecool: it is normal for a new list to have many names on it, for example in Feb there were 7 admins (and a bot) listed, only 1 admin ended up getting removed. The rest made at least one edit or action that stopped the removal process. — xaosflux Talk 20:38, 4 April 2021 (UTC)

Arbitration case closed by motion (Carlossuarez46)

Carlossuarez46 (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 · ev · fm · mms · npr · pm · pc · rb · te)

The Arbitration Committee has, by motion, temporarily removed the administrative rights of Carlossuarez46 (talk · contribs · deleted contribs · logs · filter log · block user · block log). The announcement of the motion was made at ACN here. Please remove Carlossuarez46's administrative rights at your earliest convenience. For the Arbitration Committee, GeneralNotability (talk) 02:41, 8 April 2021 (UTC)

Done, per ArbCom motion. SilkTork (talk) 08:37, 8 April 2021 (UTC)
Noting that the motion calls for this temporary measure to become indefinite after 20210708T02:04 if the case is not resumed, if converted to indefinite will require a new RfA. — xaosflux Talk 09:40, 8 April 2021 (UTC)
The wording is perhaps a little unclear in that it says "temporary" but it also says at the end: "Carlossuarez46 may regain the administrative tools at any time only via a successful request for adminship." Not sure what the actual intention is, but this appears to be a dysop "under a cloud" - though the community prefer us to discuss that at the time of requesting the tools back, rather than now. SilkTork (talk) 10:07, 8 April 2021 (UTC)
It is clear to me that while the case is "suspended" it is not closed, such that the current desysop is being actively enforced, preventing a summary self-restoration request from being available. The oddity is that they could return, ignore the case, and just go to RfA which would lead to drama if passed. — xaosflux Talk 10:42, 8 April 2021 (UTC)
In theory, but based on the ANI report that lead to the Arb case, the RfA itself would be eventful, but brief. Dennis Brown - 2¢ 10:48, 8 April 2021 (UTC)
Indeed, I suppose it leaves available the "arbcom got it all wrong!" community argument. — xaosflux Talk 10:52, 8 April 2021 (UTC)
I'm wondering if the wording should be "provisional desysop" rather than "temporary". In the sense that, as User:Xaosflux says, the desysop is ArbCom enforced, preventing a BN self-restoration request, and so avoiding any discussion and doubts about clouds on the horizon; but the desyop is pending on the return of Carlossuarez46 and outcome of the case, which may be to admonish but not to desysop. SilkTork (talk) 11:11, 8 April 2021 (UTC)
The community don't like us to discuss clouds and re-sysopping at this point, but I'm wondering what the position would be, theoretically, if Carlossuarez46 did return, the case was held, and ArbCom did not decide to desysop, and either ArbCom or Carlossuarez46 requested we give the tools back. This has all the appearance of a cloud to me, and I don't see how we could give the tools back on request. I'm not seeing anything provisional or temporary about the desyopping. SilkTork (talk) 11:18, 8 April 2021 (UTC)
So many conditionals is why we don't normally try to figure out what would happen in advance. — xaosflux Talk 13:19, 8 April 2021 (UTC)
My understanding of the motion is as follows (note that I am speaking as me right now, not on behalf of the Committee, and I have no "insider" knowledge about the Committee's intent):
  • ArbCom has directed Carlossuarez to be desysopped, effective immediately.
  • If Carlossuarez requests a case within the next three months, a case will be held, though they will not get +sysop back automatically.
    • If the outcome of the case is "The initial motion was correct, Carlossuarez should not have +sysop," they will remain desysopped (until and unless they successfully RfA again).
    • If the outcome of the case is "The initial motion was wrong, Carlossuarez should have +sysop," ArbCom will ask that the desysop be reversed.
  • If Carlossuarez does not request a case within the next three months, the desysop becomes permanent (again, until and unless they successfully RfA).
  • Nothing in ArbCom's motion prevents Carlossuarez from going straight to RfA.
SubjectiveNotability a GN franchise (talk to the boss) 13:20, 8 April 2021 (UTC)
GN's reading of the situation is correct; the only way that Carlos will get the bit back without a new RFA is if he returns, requests we perform a full case, and ArbCom determines the actions leading up to the filing were insufficient to merit removal of the mop. Primefac (talk) 16:29, 8 April 2021 (UTC)
  • SilkTork - add me to the list of people who prefer "provisional". If we are shooting for precision, that seems to work since it means it might change. "Temporary" seems to imply it is very likely going to change, which has never been the case with these. Dennis Brown - 2¢ 19:20, 8 April 2021 (UTC)
    I read the word "temporarily" as grammatically redundant to the preceding "during which time". Practically speaking, an RfA during those 3 months would most likely be unsuccessful, and a bureaucrat restoring the bit based on a request here would be out of order. – bradv🍁 20:28, 8 April 2021 (UTC)
  • While we should always be aware of unintended consequences of the phrasing of rulings, I think this is sufficiently clear and the possibility of Carlos returning and expecting to just get the bit back is low enough that we probably don't need to be overly concerned. "Provisional" can be considered for future decisions of this nature though. Beeblebrox (talk) 22:23, 8 April 2021 (UTC)

Periodic bureaucrat activity review

Hello, the annual-ish crat activity review has been completed. The report can be seen here: Wikipedia:Bureaucrat activity. No follow up actions are required. Best regards, — xaosflux Talk 14:57, 3 May 2021 (UTC)

Wikipedia:Inactive administrators/2021#May 2021

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

  1. Husond (talk · contribs · blocks · protections · deletions · page moves · rights · RfA)
    Last admin action: Apr 2019
  2. MattWade (talk · contribs · blocks · protections · deletions · page moves · rights · RfA)
    Last admin action: Aug 2013
  3. MJCdetroit (talk · contribs · blocks · protections · deletions · page moves · rights · RfA)
    Last admin action: Apr 2019
  4. Carioca (talk · contribs · blocks · protections · deletions · page moves · rights · RfA)
    Last admin action: May 2018
  5. Vague Rant (talk · contribs · blocks · protections · deletions · page moves · rights · RfA)
    Last admin action: Oct 2016
  6. Kingboyk (talk · contribs · blocks · protections · deletions · page moves · rights · RfA)
    Last admin action: Apr 2020
  7. Thunderboltz (talk · contribs · blocks · protections · deletions · page moves · rights · RfA)
    Last admin action: Apr 2020
  8. Gwen Gale (talk · contribs · blocks · protections · deletions · page moves · rights · RfA)
    Last admin action: Sep 2015
  9. AniMate (talk · contribs · blocks · protections · deletions · page moves · rights · RfA)
    Last admin action: Mar 2018
— xaosflux Talk 00:07, 1 May 2021 (UTC)
Xaosflux, Two had actions 12 months ago, which is understandable. The others were more than 12 months, Why weren't they picked up earlier? Am I missing something obvious? S Philbrick(Talk) 00:20, 1 May 2021 (UTC)
Checking again. — xaosflux Talk 00:22, 1 May 2021 (UTC)
@Sphilbrick: I'm sorry, I'm not seeing what you are referring to here? If you referencing a "page created" action, that is already considered an "edit". If we are missing something else can you please give me a specific example? — xaosflux Talk 00:27, 1 May 2021 (UTC)
If you mean, why weren't these admins marked inactive earlier? We only consider admins inactive if they have 0 actions AND 0 edits for 12 months, we note the admin actions here for consideration against the lengthy inactive admin 5 year rule - should they ask for restoration. — xaosflux Talk 00:29, 1 May 2021 (UTC)
Xaosflux, My mistake, I read the rule too quickly, I thought it was 12 months since last admin action. Edits that are not admin action count toward tolling the period. Sorry. S Philbrick(Talk) 00:31, 1 May 2021 (UTC)
@Xaosflux: What are you listing as admin actions? Eg for Husond, their April 2019 log show a few page moves, but those don't appear to have been "admin actions" in the sense of needing admin rights. The last "admin action" I see is Special:Redirect/logid/84414989 deletion in July 2017 (unless you count moving without leaving a redirect, but since page movers can do that, does that count as an admin action?). Likewise, what was MJCdetroit's admin action in April 2019? There don't appear to be any log entries. Can I suggest linking to what you have labeled the last admin action for each user, so that its clear and easier to find? Thanks, --DannyS712 (talk) 07:59, 2 May 2021 (UTC)
@DannyS712: This is more of a "last logged action by the admin", as referenced in the report linked in the header above and is not prescriptive; a discussion on if certain actions qualify or not would be reserved for if it becomes necessary. There is somewhat of a grey area between actions afforded to (all users) and those solely available to sysop's - especially when there is overlap with other groups. — xaosflux Talk 08:36, 2 May 2021 (UTC)
Closing an WP:AE discussion is a good example of an unlogged admin action. I take the "last action" in these lists as informative approximations, not lines in the sand, and subject to review if someone is on the cusp and comes back requesting the bit. We can't expect you to go digging for every unlogged action when making this list, and I assume the onus would be on them to demonstrate unlogged actions within time limits if they are requesting the bit back. 99% of the time, it is moot, so the approximation in the list is good enough. Dennis Brown - 2¢ 11:25, 2 May 2021 (UTC)
We've had this discussion before, a few times, but I would once again say that if you been "doing admin stuff that isn't logged" and somehow haven't found a reason to use a single admin tool in five years, what are you doing, exactly? It's more or less impossible to do things like closing AE discussions and never run across a single reason to use the tools while doing so. I still think the standards are laughably lax, and not using the tools for five years should lead to desysopping even if they are otherwise still editing, for the manifestly obvious reason that the user already is not an admin, but so long as we insist on coddling them with piles of notifications even that rule would be ridiculously easy to game to keep the tools forever. Beeblebrox (talk) 22:45, 2 May 2021 (UTC)
Gaming is way too easy in the current system: See the case of the perpetually inactive bureaucrat and admin who has been active for a few years now and is reaffirming his availability once a year to keep the tools but not really doing much in the way of adminning or cratting or even editting . ( Their last 50 edits go back 6 years. ) They just recently narrowly avoiding getting their tools removed in this inactivity update, in fact. Jackattack1597 (talk) 00:56, 3 May 2021 (UTC)
Ah, User:Cecropia? You'll be glad to hear that we'll be seeing more of them in future; so far, with ~200 edits in 12 years, we see more of Halley's Comet. ——Serial 11:56, 3 May 2021 (UTC)
Should User:Cecropia bureaucrat role be removed? As per Wikipedia:Bureaucrats: "If a bureaucrat does not participate in bureaucrat activity for over three years, their bureaucrat permissions may be removed." -- WOSlinker (talk) 12:17, 3 May 2021 (UTC)
WOSlinker: The current bureaucrat activity requirements include commenting as a bureaucrat at any venue including WP:BN/RFA/RFB/RFBAG/BRFA ... or signalling that they remain actively engaged and available for bureaucrat tasks. They've minimally qualified (though seem to have had several false starts on resuming active engagement). –xenotalk 12:50, 3 May 2021 (UTC)
(edit conflict) Wikipedia:Bureaucrats'_noticeboard/Archive_43#Cecropia_wants_to_remain_an_available_bureaucrat + Wikipedia:Village_pump_(policy)/Archive_157#RfC:_Bureaucrat_activity. I think under current policy, a crat saying they want to remain a crat counts as activity. ProcSock (talk) 12:57, 3 May 2021 (UTC)
Yes, see Wikipedia:Bureaucrat activity - we had 2 'crats that were hitting the 3 year mark last year, as they both commented that they want remain crats here at BN it pushes any further review on them up 3 years from then. — xaosflux Talk 13:39, 3 May 2021 (UTC)
... although the other of them actually returned to activity as an editor and went on to perform a logged bureaucrat action (the flagging of a bot) 2 weeks later. * Pppery * it has begun... 14:08, 3 May 2021 (UTC)
I mean, there's not exactly an overwhelming pile of crat activity for Cecropia to do, isn't there? If we get three crat chats next month and he's nowhere to be seen, we can start wondering what he's got a wrench for. Perhaps we should be pushing borderline candidates into RfA. I overall can't really feel broken up about "inactive crats"; there are nineteen crats, there's no urgent need to trim the ranks. Vaticidalprophet 16:56, 3 May 2021 (UTC)
As a counterexample, one admin edited once a year for five years to keep the bit, and then upon resuming editing became one of our most active administrators. -- Tamzin (she/they) | o toki tawa mi. 01:27, 3 May 2021 (UTC)

long-term semi-inactivity

  • The situation is that the community are concerned that long term inactive admins become out of touch, and may use the tools inappropriately; while long term inactive admins who feel they may wish to return to active editing at some point are concerned that if they are desysopped that they'll have to go through another RfA. I think we'd all be happier if inactive admins were desysopped and were unable to game the system by making token edits once a year. And we'd all be happier if RfA were still rigorous but less stressful. One possible solution would be to be much firmer on desysopping inactive admins in return for a less stressful Returning from Inactivity RfA which would be held without comments and with a secret ballot. Perhaps have a pool of "admin knowledge" questions from which could be randomly generated three questions per year of inactivity. So an admin inactive for three years would have to answer nine questions randomly selected from the pool by the bot setting up the RfA. The rationale behind the questions being randomly generated is so that returning admins are less able to game the system by cribbing from previous answers. The main stress in an RfA is reading negative comments - by not having comments, there would be less reluctance to going through an RfA. A blind ballot should also encourage more honest voting and inhibit potential cronyism. SilkTork (talk) 07:53, 3 May 2021 (UTC)
    SilkTork, I think "out of touch" is just part of the concern (and most out of touch admins that start using their tools inappropriately have been quickly desysopped). I think the other issue is a deep feeling of injustice: they say it is extremely difficult to pass RfA these days, while legend has it that it used to be a walk in the park. Many current admins appear to be less worthy of adminship than many of the super high experienced non-admins. Your proposal addresses the injustice a bit, but it still sets up a two-class system of users who have been admins before and users who haven't, so I'm not sure it would succeed. (Mind you, I don't have a much better idea: in my head the problem goes away if we just +sysop hundreds of extra people, say, by requiring RfA from anyone who has held more than four permissions for over a year.) —Kusma (t·c) 13:22, 3 May 2021 (UTC)
    Not sure about forcing those users into an RfA, but exploring the idea of allowing such users to be converted by way of a process akin to Wikipedia:Tool apprenticeship might lead somewhere. –xenotalk 13:36, 3 May 2021 (UTC)
    @Kusma I'm not sure about that. It isn't as if RFA was rejecting lots of well qualified candidates. We have just had two consecutive months without a new admin, and very few candidates this year but the few we get usually pass by acclamation. If there are lots of super high experienced non admins, why don't some of them submit RFAs? ϢereSpielChequers 17:11, 3 May 2021 (UTC)
    I don't know. One of my unscientific observations at RfA is that highly experienced non-admins tend to have very high standards for adminship, and may have contributed to the very high standards we have now. I'd just like to change the expectation a bit: any experienced Wikipedian (ok, only those who can control their temper) should be expected to apply for adminship, and the vast majority should get it. Anyone who has collected a handful of the other rights should consider adminship. —Kusma (t·c) 18:32, 3 May 2021 (UTC)
    Or just be given +sysop if they have used a bunch of other advanced permissions for a while and not broken anything. —Kusma (t·c) 19:18, 3 May 2021 (UTC)
    Funny you should say that... Primefac (talk) 00:44, 4 May 2021 (UTC)
    @WereSpielChequers, ultimately I think there is no agreement on what's broken at RfA. I have collected 10 different reasons I've seen people say RfA is broken (plus the idea that RfA isn't broken). If the premise that there are highly experienced non-admins who aren't running (and I will tell you that I think there are as my offers to nominate editors are turned down far more often than they're accepted - roughly 6 times as many as editors have turned me down as accepted) it could be for reasons including that admin is undesirable, it's too much like a vote (what SilkTork posits above), or there are too many questions. Best, Barkeep49 (talk) 18:41, 3 May 2021 (UTC)
  • Honestly, it would be far more productive if effort was put into actually changing the activity requirements for admins. Right now, it's tedious and achieving nothing by re-hashing this topic on this noticeboard every time someone takes issue with the activity of someone with permissions. Acalamari 11:27, 3 May 2021 (UTC)
    Wikipedia:Requests for comment/Change to sysop activity requirements. There's also many who believe it's mostly a non-problem. IMO, for any issues with the composition and addition/removal processes of sysops, inactive sysops come in near the bottom of the list as, at worst, mostly harmless. ProcrastinatingReader (talk) 11:46, 3 May 2021 (UTC)
  • But how much has really changed in the last 5-10 years? I'll admit that I miss the WP:UPDATE that Dank used to roll out for us (ty by the way for that). But really truly meaningful changes in policy? Not changing words like "can" to "may", but what has changed in any meaningful way? Admins are elected on a platform of trust to do the right thing when it comes to our project. IMO, just about the biggest change is that we can block disruptive editors from individual pages now. Even those pesky WP:ACDS were around 10 years ago.
    Even if various WP:ACE may arbitrarily interpret how to apply things like WP:INVOLVED or WP:COI, the concept is still the same. If User:AdminA was trusted in 2015 or even 2010, who really thinks that if they don't edit for a year or two that they're going to waltz in and cause a huge disruption in 2021?
    Gaming? IMO it's more gaming a way to remove a mop from 'old-timer' editors who were considered trustworthy. I know of one admin who followed without contributing, and when they had time to return, did so in a most positive way. The "Gaming" IMO is more from editors who seem to be saying, "well maybe you trusted user:xyz 10 years ago, but I wasn't here then, so I can't trust them now."
    The two biggest uses of the mop may be: 1. If an editor is being disruptive, and has ignored the warnings and policies - then block them. 2. If a page has become disruptive by multiple editors, then protect it. Granted it's a bit of an over-simplification, but it is pretty "nutshell". /end frustrated post. — Ched (talk) 17:36, 3 May 2021 (UTC)
  • Mostly what Acalamari said, this has been rehashed atleast a few thousand times before and I think we have generally come around to the conclusion that almost-inactive admins and crats have not and will not manage to delete Wikipedia off the face of the earth. I think that's an acceptable compromise. --qedk (t 愛 c) 17:44, 3 May 2021 (UTC)
  • Although I commented above, it is true that bringing this up here again and again is never going to accomplish anything. The 'crats enforce the policy, they don't make it and can't change it. Beeblebrox (talk) 17:48, 3 May 2021 (UTC)

T&S and interface admins

Tracked in Phabricator
Task T282624

T&S has apparently decided without any consultation whatsoever that stewards only should be able to grant int-admin. See phab:T282624. There is also no particularly obvious rationale why.

(Why T&S is making decisions like this is not obvious to me. I am not particularly sure they are the correct internal group to do so, much less without any consultation.) Izno (talk) 23:48, 11 May 2021 (UTC)

Maybe they've just been busy being involved with that WMF UCoC stuff? IDK. — Ched (talk) 00:00, 12 May 2021 (UTC)
There is a legitimate reason for this: 1) nothing is making bureaucrats check to make sure 2FA is enabled for interface admins before granting 2) bureaucrats also are not required to have 2FA at present. That being said, I agree about the concerns re communication. --Rschen7754 00:03, 12 May 2021 (UTC)
If those are the reasons, then the software should enforce 2FA before granting and should enforce either a) that the granting bureaucrat has 2FA or b) that all bureaus locally have 2FA.
(Don't worry, I have other suggested changes to implementation path depending on rationale, the majority of them without punishing wikis that do a good job managing the permissions of interest.) Izno (talk) 00:10, 12 May 2021 (UTC)
I think enforcing 2FA on bureaucrats would probably be a more sweeping change, especially in countries where 2FA is not possible for legal reasons. --Rschen7754 00:19, 12 May 2021 (UTC)
Also note that enforcing 2FA on granting is one of the things that are easy to say and hard to do. For instance, one can easily disable it after the check. Of course, software can also automatically demote, but that has also some implications (notably, regenerating scratch codes requires disabling 2FA for a while).
Of course, the current system is far from perfect, I just wanted to point out that requiring 2FA on granting IA can easily turn out to be a pretty big project. Martin Urbanec (talk) 01:05, 12 May 2021 (UTC)
I think this is a sensible change. If crats aren't required to have 2FA, then requiring it of intadmins is 100% pure security theater. But yeah, the "because we said so" style of communication is hardly going to encourage support of this change. Suffusion of Yellow (talk) 00:34, 12 May 2021 (UTC)
  • For "paperwork" updates for our procedures etc, feel free to join in the discussion at Wikipedia:Interface_administrators'_noticeboard#Local_impacts. — xaosflux Talk 01:06, 12 May 2021 (UTC)
  • I've said we should get rid of bureaucrats completely and move all their functions to stewards, so I support this. TonyBallioni (talk) 01:11, 12 May 2021 (UTC)
    • What, you don't support the traditional tar-and-feather round for T&S? More seriously, this has exactly the same odor as FRAMBAN. Someone in a smoke-filled room made a decision, and rammed it down Wiki's throats. That caused months of drama last time. Whether the decision is the correct one isn't the issue, it's being arrogant to the point of making it clear they make the decisions and the peasants don't need to be notified, let alone be consulted. Tarl N. (discuss) 03:26, 12 May 2021 (UTC)
  • So superprotect is back? —Kusma (t·c) 05:04, 12 May 2021 (UTC)
    • Not sure how this has anything to do with superprotect, even metaphorically. As Suffusion of Yellow says, the 2FA requirement for intadmins is pointless if the people who assign the permission aren't required to have 2FA themselves; this change certainly makes sense from a security standpoint. It's of course not very diplomatic of the devs to make this change without consulting the communities, but realistically, there's no good alternative or objection to be made (other than extending the 2FA requirement to 'crats, which would be even worse, or eliminating the 2FA requirement altogether, which would never fly for several reasons), so any discussion they might have started about it would be pointless, since it couldn't possibly affect the outcome. Overall, this is definitely not the hill I'd choose to die on. Writ Keeper ⚇♔ 05:22, 12 May 2021 (UTC)
      Well, intadmin does pretty much the same as superprotect did. The difference was that granting the flag was a matter for the local community. Now we're back to having no local control. Whether that is a problem we'll see next time we need to use intadmin to disable some unwanted WMF "innovation". —Kusma (t·c) 07:00, 12 May 2021 (UTC)
      This is just procedural, though, right? Like are stewards planning on enforcing new requirements here? Or is it like other things they handle, where someone with local authority to do something (ArbCom for ±CU/OS, 'crat for -crat, admin for bigdelete) makes a request and a steward actions it as long as all procedural requirements have been met? -- Tamzin (she/they) | o toki tawa mi. 07:09, 12 May 2021 (UTC)
      Pretty much. The stewards would check that both local and global policies were followed, and assign the flags if they were (for instance, 2FA for int. admins and confidentiality agremeent for CU/OS). Martin Urbanec (talk) 12:05, 12 May 2021 (UTC)
      @Kusma: Well, intadmin does pretty much the same as superprotect did. Nnnnno, it really doesn't. I mean, in the absolute most simplistic of terms, I guess, in that it involves pages that admins can't edit. But the whole point of superprotect was that it was a level of protection that a) could be applied to any page as the WMF Office saw fit and b) once applied, only the WMF Office could edit the page. Neither of those things are true for intadmin: it's not a level of the protection tool that can be applied to a page but a very specific control that is only active and can only be active on interface pages (i.e. pages that are .js or .css pages). It can't be applied to non-interface pages, including anything in mainspace. It's also not mediated by WMF Office; intadmins are (with a couple of dev exceptions) all community members, and since stewards are also all elected community members, nothing about this is changing anything about that. Superprotect is not a useful comparison, especially given its fraught history. Writ Keeper ⚇♔ 16:07, 12 May 2021 (UTC)
      The whole point of superprotect was to prevent this edit. —Kusma (t·c) 16:41, 12 May 2021 (UTC)
  • You know, I have been wondering for a while whether bureaucrats not being required to have 2FA despite having the permission to grant 2FA-requiring rights made sense from a security perspective. So this makes perfect sense to me. I wouldn't worry about it being a return to superprotect, from what I know stewards are not known for interfering with local projects overmuch and the steward elections I've seen have been very unforgiving with folks who are too intervention-happy. Jo-Jo Eumerus (talk) 08:28, 12 May 2021 (UTC)
  • This is how I read it - it's purely a procedural thing, which makes total sense from a security standpoint. I have no concerns either about stewards "interfering" in local processes, as all the stewards I know would abhor such a thing. The communication of the change however was, as usual, abysmal... ƒirefly ( t · c ) 08:29, 12 May 2021 (UTC)
  • I think Tony has a point. Would the remaining 'crat work (essentially approving bot tasks and closing the odd RfA) be too egregious for the stewards to take on? Let's separate out what the message was (a fair comment) from how it was delivered (badly). Ritchie333 (talk) (cont) 09:36, 12 May 2021 (UTC)
    I'm happy to have our bureaucrats return their bits if we can have five admins in exchange for each. —Kusma (t·c) 09:50, 12 May 2021 (UTC)
I guess bitcoin is out of the question? Ritchie333 (talk) (cont) 09:55, 12 May 2021 (UTC)
  • More seriously, we ought to have enough work for our bureaucrats. That we don't have enough RfAs for them to close has been true for 10 years, but it sure isn't good (speaking as one of the 34 admins promoted in April 2006). —Kusma (t·c) 10:09, 12 May 2021 (UTC)
    I am not sure, are stewards qualified to take a decision whether to promote or not to promote an admin on say the Russian Wikipedia? Or are they only supposed to take the crat tasks of the English Wikipedia?--Ymblanter (talk) 09:56, 12 May 2021 (UTC)
    crats don't approve bot tasks. They flag bots, but that role seems mostly ceremonial. As it should be, since a bot can be flagged indefinitely after a basic Task 1 and later file a more controversial Task 2 which would not require another flag (since the bot is already flagged from its Task 1). I don't think stewards are going to take over crat chats, and apparently closing RfCs on meta by stews takes long enough. ProcrastinatingReader (talk) 11:03, 12 May 2021 (UTC)
    Where consensus is clear in an RfA (like the two we've had in 2021), I suppose handing the task to stewards wouldn't be too problematic. But in edge cases in the discretionary range, I think bureaucrats get their credibility because they are locally chosen and are intimately familiar with how the English Wikipedia works. I wouldn't be a fan of handing the bureaucrats' tasks over to stewards; it's not like they're being overworked. Sdrqaz (talk) 12:23, 12 May 2021 (UTC)
  • The way I am reading this is that WMF are concerned regarding the security risks attached to the int-admin rights, and feel that when those rights are granted, that a check is made to ensure the user has 2FA enabled. So far, so good. The next step is the one that concerns me. Instead of consulting the communities to discuss the best way of implementing the changes, the WMF spoke to some stewards in the basement of the planning department on Alpha Centauri and made their own decision. Instead of considering the possibility of enabling 'Crats to check if a user has 2FA enabled, it was decided, without consultation with the communities, to take autonomy away, and allow just stewards to flick the switch, without consideration of the process. Under the current procedures there is a 48 hour discussion, and a 'Crat makes the decision. Is that process still to take place? But when the 'Crat makes the decision they then need to ask a steward to flick the switch? Or is the intention that requests go straight to stewards, and the local community is by-passed? The wording is "the granting of the interfaceadmin permission should be performed exclusively by Stewards", which sounds like the local communities are being bypassed.
I'm slightly angered at the arrogance, insensitivity, inelegance, and prejudice displayed here. The WMF have made a decision to reduce the autonomy and self-governance of local communities without either consulting or even notifying those communities. WMF acts as though they are an authority over the communities rather than the trust which helps us to run. The better approach would have been a consultation with the major communities to raise the issue and seek solutions - the obvious one being that 'Crats with 2FA are enabled to make the 2FA check. Simples. SilkTork (talk) 10:26, 12 May 2021 (UTC)
The flagging of IAs has always been security theatre, but then a lot of community norms on 'security' are. Even with the check of 2FA status this doesn't work because 2FA can be disabled later. The smart thing to do is the WMF codes up something so that the software enforces this requirement and automatically deflags if 2FA is removed, requiring a crat/stew to manually take action to reinstate the flag (eg if the IA is changing 2FA devices). ProcrastinatingReader (talk) 11:20, 12 May 2021 (UTC)
ProcrastinatingReader, if we trust intadmins not to go rogue, we should be able to trust them not to suddenly allow others to take over their account. There are probably a couple hundred more urgent tasks for developers to do than technically enforcing something that is based on trust in a person doing the right thing. —Kusma (t·c) 11:52, 12 May 2021 (UTC)
I'm not saying it should be done, I'm saying if the WMF wants to go down this road then the change which lets only stews flag IA (because only they can check 2FA status) just doesn't make sense for the aforementioned reasons. If the WMF wants to enforce the restriction, it should be technically enforced by the software, as that's the only reasonable way to enforce it. ProcrastinatingReader (talk) 11:55, 12 May 2021 (UTC)
Or is the intention that requests go straight to stewards, and the local community is by-passed? Per Martin's above response to me, it seems that everything will work the same in terms of the decision to +IA, except that a 'crat will have to request at SRP rather than assign the bit themself. Same as how decratting currently works. -- Tamzin (they/she) | o toki tawa mi. 12:46, 12 May 2021 (UTC)
ProcrastinatingReader - that makes sense to me, and is an example of one of the ideas this community could have come up with if the WMF had consulted us. SilkTork (talk) 12:49, 12 May 2021 (UTC)
  • For me this is a 3 or 4 on the "how much does this WMF action upset me" on a -10 to 10 scale (i.e. -10 means I'm THRILLED with a foundation action while a 10 would be in FRAM territory). I'm of the mind that project security is a legitimate foundation function. I think consulting with the stewards is also a reasonable enough step though also maybe consulting with the communities whose crats are impacted seems like a no brainer. I'm curious why they didn't. That said, if Stewards are going to be consulted in cases like this I wish they would have supplied the "Maybe you should talk to the communities" feedback we're giving now. I'm guessing they gave feedback more in the realm of "we have capacity to do this work" rather than taking on the role of ambassador. Perhaps they didn't sign up to be ambassadors but if the foundation is going to treat them as such they either need to no do it (i.e. not provide feedback in situations like this) or to make an attempt to represent the projects on whose behalf they're speaking for. Best, Barkeep49 (talk) 15:28, 12 May 2021 (UTC)
    Apparently it is T&S's position that private communication with stewards constitutes community discussion. It'd certainly be surprising if stewards didn't realise the optics aren't great of the WMF unilaterally "moving quickly" to remove granting and removal permissions from local communities without any notice/discussion. ProcrastinatingReader (talk) 15:59, 12 May 2021 (UTC)
    I actually think that this is a reasonable position for the foundation to take in matters of sensitive information - such as project security. That's why I think it's incumbent on the stewards to actually represent the community that the foundation is having them represent and why I posted a version of these thoughts on the Stewards' noticeboard. Best, Barkeep49 (talk) 16:05, 12 May 2021 (UTC)
    I think the concern is process and optics. If one offers a discussion period possibly there'd be better approaches raised (or not, but consultation isn't binding of course and then it could then said folks were allowed room to raise their concerns). But when one tries to push it thru via Phabricator and Gerrit - obscure boards, relatively speaking - the optics are different. It's been like this for so long that waiting another month for discussion seems harmless, and avoids unnecessary criticism if nothing else. ProcrastinatingReader (talk) 16:15, 12 May 2021 (UTC)
    I think we largely agree? To be clear I think a reasonable chain of events would have been: 1)Foundation decides this is a security risk that needs addressing 2)Comes up with the idea they did here 3)Present idea to stewards 4)Stewards say "sure we can do it but you should let the communities who have crats who do this know" 5)Foundation lets communities know 6)Feedback is given 7)Revised plan made 8)Revised plan implemented. Best, Barkeep49 (talk) 16:25, 12 May 2021 (UTC)
    Stewards aren't a GovCom and are only elected to carry out community consensus. It got us (I was a steward at the time) in trouble during the process where renames were shifted away from bureaucrats to stewards and their delegates and it's still not okay now. --Rschen7754 18:07, 12 May 2021 (UTC)
  • I don't see this as a big deal. If I understand the situation correctly, we will still be able to decide for ourselves who is granted int. admin rights, stewards will simply be the ones flipping the switch. This has been true for CU and OS rights for quite some time and it has never been a problem. It's true that 'crats don't have much of a workload, but for the few tasks that do remain in their remit, I would rather have them doing it than stewards. Beeblebrox (talk) 20:07, 12 May 2021 (UTC)
    • Indeed, my guess is that stewards will most likely be rubber-stamping all requests from enwiki. What might be affected are requests from smaller wikis where minimum vote requirements, for example, might be enforced. --Rschen7754 00:05, 13 May 2021 (UTC)
  • Good change for security reasons the community cannot overrule, the Foundation has to enforce either 2FA for bureaucrats, or move the permission to grant INTADMIN to stewards. Furthermore, the Phabricator ticket says "Communicate with projects" is part of their plan. The outrage about a "lack of communication" is a misunderstanding of how open organizations work. Should the ticket have been kept secret until after the communication is done? User:力 (power~enwiki, π, ν) 20:11, 12 May 2021 (UTC)
    A ticket titled: "Decide what to do about bureaucrats granting IA" with text laying out the whys and wherefores and especially the which and why nots speaking to the problem rather than the solution is good bug reporting practice. So no, keeping things secret was never a necessity. Izno (talk) 20:20, 12 May 2021 (UTC)

Arbitrary break

Without commenting on the mishegas, I'll note that the task was updated to say Note: We are putting this on hold for a little while to work on a communications plan., with further notes at phab:T282624#7083246. ~ Amory (u • t • c) 20:36, 12 May 2021 (UTC)

A welcome development. —Kusma (t·c) 20:51, 12 May 2021 (UTC)
  • Grumpy McGrumpface has only 2 comments:
    1. I'm surprised, after all previous drama, that WMF in general and T&S in particular hasn't taken to heart the simple, respectful, and obvious 8-step checklist Barkeep posted above (16:25 UTC). Steps 6, 7, and 8, in that order, are important, even if nothing ultimately changes, and no matter how reasonable the proposal. Otherwise, it's just one more reason for the lack of trust. How is it possible that this checklist has not been put on a post it note and stuck to the monitor of everyone who works for WMF/T&S?
    2. 2FA still seems like security theater to me. I'm dreading D-day, when 2FA becomes mandatory for admins, because by D+3 I'm going to have locked myself out of my account. I'm an idiot, of course, but Jehochman (who isn't) has commented about this a while back, and I'll try to find a link.
      Easier to find than I thought: here. And pinging @Jehochman: as a courtesy. --Floquenbeam (talk) 21:44, 12 May 2021 (UTC)
--Floquenbeam (talk) 21:40, 12 May 2021 (UTC)
It is actually even worse, I am a Wikidata crat, and nobody cared to tell me anything. If I did not have this page (and a crat page of Commons) on my watchlist (and I do not even remember why I got these pages on my watchlist), I would not even know about the development.--Ymblanter (talk) 21:53, 12 May 2021 (UTC)

If 2FA is such a big deal, I'm sure the WMF could have tweaked the code so that any crat who doesn't yet have 2FA enabled was unable to set it. But no matter, it has happened now. On a broader note, yes we don't get to do much as crats - in recent years there have been far more desysops than closing RFAs. However, despite a decade of disappointment I still hope the day will come when RFA turns a corner and we get a new generation of admins coming forward. Call me an optimist, but remember there are lots of editors on Wikipedia who could easily pass RFA if they ran. ϢereSpielChequers 21:55, 12 May 2021 (UTC)

Hahahahahah. That is possibly the funniest thing I have read on this board, WereSpielChequers. The WMF 2FA is ridiculously below even the basic industry standards, it is not owned or maintained by the WMF but by a few volunteers, it was written specifically for very high level developers who all knew each other and is now being crammed down the throats of people who don't have any English language skills or developer buddies, it actively cannot be used in certain geographies. In other words, it is worse than security theatre. This is not a safe bit of software, and if it was written today instead of many years ago when only root admins needed it, it would have failed every security test. The WMF knows this. They have done absolutely nothing to change this. Risker (talk) 01:04, 13 May 2021 (UTC)
@Risker: Seen a couple of comments that 2FA can't work based on the geography of the client for some reason? Is there a ticket open on this? I'm having a hard time reconciling why I would even need to be on the planet at all to use it, as long as my clock was synchronized? RFC 6238 doesn't seem to mention any such limitation. — xaosflux Talk 02:12, 13 May 2021 (UTC)
My understanding, from a couple of users in a heavily censored country, is that there are significant difficulties in ensuring constant access to supporting apps. It's not a Wikimedia problem, per se; as I understand it, it's a censorship issue that doesn't directly relate to 2FA. It's been over a year since I was told this, so things may have changed. Since it's not a problem I've personally experienced, it never occurred to me to look for a phab ticket. Risker (talk) 04:00, 13 May 2021 (UTC)
There's potential issues with the encryption - whether a US-based company can export an app containing the encryption to a different country or not - or whether the other country will allow the app into the country. I could also see Google Authenticator, for example, being banned in a country that bans most Google products. It is probably something that should be researched more thoroughly. --Rschen7754 04:32, 13 May 2021 (UTC)
I'll note in addition that a surprisingly large number of users in those censored countries use easily available VPN services, most of which have built-in 2FA software, which I assume should work if the VPN software works. (I know this because I do a lot of IPBE work.) If they're using 2FA through that service, it's likely to meet higher standards than the comparatively unsupported system attached to MediaWiki. Risker (talk) 05:21, 13 May 2021 (UTC)
I'm likely in the minority based on past discussions about 2FA, but I don't understand the distrust or dislike towards implementing a more rigorously implemented 2FA system, at least for admins+. 2FA is never going to be the be-all-end-all of account security, indeed if someone has reached the stage where they need a 2FA code, you're likely screwed in other respects. However, I don't think those that oppose widespread 2FA appreciate its value. It's known that people reuse passwords, and it would be a stretch to everyone to stop doing that, more so than asking people that are dedicated to the website (admins+) to download an application to make sure that you don't get compromised and accidentally deface the 13th biggest website globally. Risker mentioned above that there are significant difficulties in ensuring constant access to supporting apps, though I slightly disagree.
While it is true that the Google Authenticator app could be removed from the app store, there are multiple alternatives. For mobile, you can download Authy, a password management service that includes the ability to sync authentication codes between devices (I don't know if this is behind a paywall, though I'm fairly sure that the stock-standard authentication service is free). For desktop, there are a range of options. WinAuth is open source and hosted on GitHub, so if GH is blocked someone can fork it and send it to you. There are also in-built browser add-ons, like Authenticator. I've not used this and I can't vouch for its security, but it's another option. It should also be noted that an internet connection is not required to generate codes, so you don't even need a VPN. The best option though would be to have the WMF spend some of their millions of donation money on improving the Wikipedia app to include an in-built proprietary 2FA system, like Steam or Battle.net that generate codes but require you to be logged in, or like Google, which doesn't give a code but rather forces you to have two devices on hand (this one may not be as good for our purposes). That only really leaves concerns like Floquenbeam's, but perhaps having auth codes on the same device that you log in on may alleviate some of the possibility of losing the codes. Anarchyte (talk • work) 06:04, 13 May 2021 (UTC)
Thank for the notes, so there doesn't seem to be any "where you are" technical constraint, but there could be political constraints - though that hardly will apply to only the TOTP protocol we use. I agree that "customer service" for WMF accounts is abysmal, and even more so for the 2FA components. But again, customer service to our userbase for all things technical is pretty sad - and the fix requires hiring a lot more IT staff. — xaosflux Talk 10:26, 13 May 2021 (UTC)
I accidentally locked myself out of my account with Wikipedia's 2FA a few times. The integration is really poor. I managed to get back in because there's a bypass to disable 2FA as long as you're logged in somewhere (normally it forces you to reconfirm with the device to disable it IIRC). Never used the functionality again, though. ProcrastinatingReader (talk) 09:08, 13 May 2021 (UTC)
  • I would echo SilkTork above and extend it to say it seems like a gradual power grab. Every since FramGate, they keep upping the ante. Eventually, they will just hand pick the admins and anyone that doesn't like it to go suck lemons. Of course, they will deny this, until they properly conditioned the community to just shut up and write pretty words for free, the one thing most of them can't do. Dennis Brown - 2¢ 13:02, 13 May 2021 (UTC)
    • I could see this as a power grab if the WMF reserved the right to assign intadmin for themselves, but the stewards aren't the WMF. It's absolutely fair to criticize the deployment plan for this, and fair to disagree with the change itself, but I really don't think this merits the level of vitriol that we're displaying here. Writ Keeper ⚇♔ 13:57, 13 May 2021 (UTC)
      • I'm not blaming the stewards, they had no role in the decision. And the level of vitriol is appropriate given the sequence of events with the Foundation chipping away at the autonomy of the project, thank you. This is not an isolated incident, it is merely part of a disturbing pattern that appears to be accelerating. Constantly imposing their will without even discussing the changes with the community. Like VE, FramGate, CoC, they continue to impose rather than engage. Dennis Brown - 2¢ 19:12, 13 May 2021 (UTC)
    • As a steward for several years I can say that we are definitely not the WMF and just as reluctant as anyone here at WP to become in fact or by action part of the WMF. Most stewards are very reluctant to get involved anywhere where we don't have the support of the local community to do so. QuiteUnusual (talk) 14:42, 13 May 2021 (UTC)

Impersonation attempt

Imposter is blocked, GLOCK request created, nothing else to do here. — xaosflux Talk 14:54, 25 May 2021 (UTC)

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

Thread retitled from "Sysop request ".

I've created this alternate account of User:Xeno for added security when editing from public locations. Requesting sysop rights for this account too. –xeno (alt)talk 06:58, 25 May 2021 (UTC)

I'd expect the real Xeno to know that "Only one account of a given person may have administrative tools. The only exception is administrators may own bots with administrative access. See WP:ADMINSOCK", and to countersign from their main account. I'll block the alt as an impersonation 'til shown otherwise. Cabayi (talk) 07:14, 25 May 2021 (UTC)
Also it kind of defeats the point of having a WP:PUBSOCK to give it administrative rights too. Sdrqaz (talk) 07:31, 25 May 2021 (UTC)
Thanks Cabayi; it's not me: if I wanted an adminsock I'd just make it myself. –xenotalk 14:16, 25 May 2021 (UTC)
I'm sure WP:ROUGECRAT must redirect to WP:RUGRAT  :) ——Serial 14:22, 25 May 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

User:Electionworld

Nothing for bureaucrats to do here. Admin inactivity is avoided for any logged actions or edits in the last year; as noted by the OP - edits are present in the last year. We process removals once a month so as to streamline the process, with pending removals tracked at WP:INACTIVE for those interested. Changes to this rule would require amending the admin policy and may be discussed at WT:ADMIN or elsewhere. — xaosflux Talk 10:57, 27 May 2021 (UTC)

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

This admin has not edited since June 2020, and has only 4 edits since August 2019. Unless I'm reading their log wrong, they haven't performed an admin function since September 2018 when they deleted a test page in their own user space, and before that in June 2015 when they moved some pages. [3]

My question is the obvious one: why does this person still have the bit?

Beyond My Ken (talk) 05:15, 27 May 2021 (UTC)

Just to be clear, I have no complaint about Electionworld's editing or other behavior (not that there's been any to speak of), I simply came across them by happenstance and wondered what the story was. Beyond My Ken (talk) 05:18, 27 May 2021 (UTC)
  • What? They still have the bit because they have not gone a year without any edit or logged action. You said so yourself, they edited in June 2020. Ben · Salvidrim! ✉ 05:40, 27 May 2021 (UTC)
  • What Salvidrim said. They'll get desysopped on 1 July if they don't return to editing. Sdrqaz (talk) 07:33, 27 May 2021 (UTC)
  • We are a volunteer community, people are free to come and go. If someone goes for less than a year we assume that things have not changed so much that they can't resume where they left off, more than a year and we desysop them for inactivity. If you don't like the policy, and want to change it to something like "or desysop if they have less than 200 edits and admin actions in the last five years", this is not the venue to change that policy, as we apply the community policy on this, we don't create or amend it. ϢereSpielChequers 07:51, 27 May 2021 (UTC)
  • Can we stop calling out individual admins by name when they’re being insufficiently active? I feel like it creates more problems than it solves. —pythoncoder (talk | contribs) 10:50, 27 May 2021 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Wikipedia:Inactive administrators/2021#June 2021

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

  1. Eliz81 (talk · contribs · blocks · protections · deletions · page moves · rights · RfA)
    Last admin action: Oct 2009
  2. ThaddeusB (talk · contribs · blocks · protections · deletions · page moves · rights · RfA)
    Last admin action: May 2015
  3. Who (talk · contribs · blocks · protections · deletions · page moves · rights · RfA)
    Last admin action: Mar 2011
  4. Vianello (talk · contribs · blocks · protections · deletions · page moves · rights · RfA)
    Last admin action: Mar 2020
  5. Mulad (talk · contribs · blocks · protections · deletions · page moves · rights · RfA)
    Last admin action: Feb 2010
— xaosflux Talk 00:19, 1 June 2021 (UTC)

Four out of five subject to the five-year rule. That seems like it might be a first. Beeblebrox (talk) 21:21, 1 June 2021 (UTC)

The "five-year rule" being .. have to go through RfA again and can't ask here at WP:BN? — Ched (talk) 22:36, 1 June 2021 (UTC)
Correct. P-K3 (talk) 22:37, 1 June 2021 (UTC)
Can't remember where we bumped heads, but ThaddeusB is a name I recognise. Shame. 22:58, 1 June 2021 (UTC) — Preceding unsigned comment added by Serial Number 54129 (talk • contribs)
Sad to see Eliz81 on here. Another of my fellow 2007 class gone. :'( Acalamari 08:09, 2 June 2021 (UTC)
Impressive that three of the five would be subject even if it was a 10 year rule.Jackattack1597 (talk) 16:58, 2 June 2021 (UTC)
Side note: I wonder if it would be a good idea to extend the five year rule to the inactivity policy, because they already aren't much of an admin if they haven't used the tools for five or ten years.(IE: if an admin has not used the tools in five years but has edited recently they can be desysopped for admin inactivity. )Jackattack1597 (talk) 17:06, 2 June 2021 (UTC)
If anyone would like to follow up on that, please do so at WT:ADMIN, not here. — xaosflux Talk 17:27, 2 June 2021 (UTC)
Agreed. As I've said before, we don't need to keep having a discussion here about the inactivity requirements every time we have desysoppings for inactivity. Acalamari 19:11, 2 June 2021 (UTC)
Yep. I was only intending to make an observation, not initiate a debate. Beeblebrox (talk) 20:10, 2 June 2021 (UTC)

Desysop request (AGK)

Not currently using my admin rights, so please remove them. Thank you. AGK ■ 07:04, 18 June 2021 (UTC)

 Done. That's been done for you AGK. SilkTork (talk) 07:46, 18 June 2021 (UTC)

Request for IADMIN rights: Ragesoss

Ragesoss (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 · ev · fm · mms · npr · pm · pc · rb · te)

I'd like to get interface-admin rights again, as I have some updates to make to the Wiki Education guided tours. (I've had them several times before, but I don't tend to use them often enough to avoid having them removed for inactivity.)--ragesoss (talk) 16:05, 28 June 2021 (UTC)

@Ragesoss: do you currently have WP:2FA enabled on your account? — xaosflux Talk 16:08, 28 June 2021 (UTC)
@Xaosflux: yes, I have 2FA enabled.--ragesoss (talk) 16:13, 28 June 2021 (UTC)
 Done no hold time as prior removal was only for inactivity, welcome back. — xaosflux Talk 16:35, 28 June 2021 (UTC)

Wikipedia:Inactive administrators/2021#July 2021

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

  1. Nickshanks (talk · contribs · blocks · protections · deletions · page moves · rights · RfA)
    Last admin action: May 2018
  2. Ultraexactzz (talk · contribs · blocks · protections · deletions · page moves · rights · RfA)
    Last admin action: Jun 2020
  3. Schissel (talk · contribs · blocks · protections · deletions · page moves · rights · RfA)
    Last admin action: Apr 2009
  4. Kees08 (talk · contribs · blocks · protections · deletions · page moves · rights · RfA)
    Last admin action: Mar 2020
— xaosflux Talk 00:26, 1 July 2021 (UTC)
Note that Schissel's inactivity which led to their desyssopping was due to locking themselves out of their account due to losing 2fa code access. See their talk page posts https://en.wikipedia.org/wiki/User_talk:Schissel#Hrm._Bye_soon_:) and their new account https://en.wikipedia.org/wiki/User:ELSchissel . Really don't think there's any way this can be fixed at this point, but I wish Schissel had posted here as it may have been resolvable. Jackattack1597 (talk) 20:54, 6 July 2021 (UTC)
@Jackattack1597: note that the "new account" posted that we should "feel free to remove privileges" a month ago (diff). — xaosflux Talk 21:25, 6 July 2021 (UTC)
And Schissel having made no admin actions for over 9 years and only 16 admin actions total has nothing to do 2FA * Pppery * it has begun... 22:08, 6 July 2021 (UTC)
The rules don't currently require any rate of admin actions, though, so using a that as a reason for desysopping on a 2FA glitch isn't very fair. And unlike some, who just pop back once a year to reclaim the bit, this is actually still a reasonably active editor. It seems like there's no harm no foul here, as the editor isn't bothered by losing the bit, but let's not pretend it has anything to do with the last logged admin action, unless you want to make that a requirement for everyone.  — Amakuru (talk) 06:39, 7 July 2021 (UTC)
It's worth bearing in mind that admin rights are given to accounts not to people. If there is a technical problem with an admin account that is held by a person who also has a non-admin alternative account, the admin rights cannot be transferred to the non-admin account without going through a RfA. Admin rights are removed from an account not from a person (so admin rights can be removed from an admin bot, but left with the admin operator, and vice versa). If a person has shown they no longer hold the trust of the eng.wiki community, then admin rights will be removed from all accounts they hold on en.wiki, though not from accounts they may hold on other wikis. However, site bans, including global actions, are applied to people, not just accounts. In this instance there is no question of distrust, site bans, or global actions - the account (not the person) is merely being desysopped because of inactivity of the account in line with community consensus. User:ELSchissel may apply for the tools via RfA at any time. SilkTork (talk) 09:50, 7 July 2021 (UTC)
@SilkTork: Wikipedia:Former_administrators/reason/renamed lists a number of cases where an admin transferred their bit to an alternate account, for a variety of reasons including at least one account lockout. Has there been some change in policy since the most recent instance in 2017? -- Tamzin (she/they) | o toki tawa mi. 10:26, 7 July 2021 (UTC)
That's a good question. "Admin rights are given to accounts not to people" seems a very odd state of affairs, given that for other purposes (community bans etc) we assume it's the person who's the principal agent... If I die and leave my Wiki password to someone in my family, can they pick up the reins and carry on adminning away in my stead, on the grounds that it's not really me who's the admin but my account?  — Amakuru (talk) 11:04, 7 July 2021 (UTC)
Thanks for that Tamzin. Well, as there is some precedent for transferring rights from one account to another on request, then - if they had not fallen foul of the five year rule (their last admin edit was over five years ago) - it seem we could have considered allowing User:ELSchissel that privilege if they had requested it. They have done nothing wrong, merely got caught in a technical problem. They would have needed to satisfy queries that they were the person behind the User:Schissel account. And it would have made sense to have a Crat Chat if they had requested the mop back. But other than that, you are right, it does seem that the community would have allowed it. For a renaming of an account I understand (because it's the same account, just a different name), but transferring rights from a main account to an alternate account is not something I expected to see, as the rights were transferred to an account that had not passed RfA. But as the community allowed it then it can be done again - unless there is a change in policy to prevent that happening. SilkTork (talk) 11:15, 7 July 2021 (UTC)
SilkTork, I strongly disagree with this statement. From my point of view, the admin user-right is given to people, not accounts. A person may only have one admin account. In certain circumstances - i.e. when there is a confirmed link between the accounts and the individual has good reason, admin user-rights can be transferred without a fresh RfA. Regarding Admin bots - they do not need to have a fresh RfA. So, overall, no - the role is associated with a person and assigned to one account (or multiple for adminbots). WormTT(talk) 11:18, 7 July 2021 (UTC)
Amakuru - it's one person per account, but one person can have more than one account. Rights acquired by one account are not normally transferred to other accounts, and I assumed that was standard. However, there is at least one case of admin rights being transferred not to a renamed account, but to an alternate account, so it seems that rights can be transferred. Or, at least, that there is no policy which prevents it. As such, it appears us 'Crats would need to seriously consider such requests if they come our way. Unless the community make clear that they don't wish rights to be transferred. SilkTork (talk) 11:27, 7 July 2021 (UTC)
User:Worm That Turned. The relationship between a person and an account is nebulous. Many accounts are anonymous, and we don't require to know who the person behind the account is. As such we are giving the rights to the account, but on the understanding that only one person uses that account. So are we actually giving the rights to the person, or to the person behind that particular account? And if that person is behind another account, created to edit in a different area of the project, could they successfully ask a Crat to apply admin rights to that account as well, because they are the same person? SilkTork (talk) 11:36, 7 July 2021 (UTC)
SilkTork, I'd much prefer the situation where the question of "can we prove these two are the same person" leads to transferring an account, than to desysopping due to use of multiple admin accounts! Anonymous or not, a person behind the account exists. If the admin remains anonymous, then it is unlikely they will be able to transfer the right. WormTT(talk) 11:45, 7 July 2021 (UTC)
For what it's worth, I am absolutely of the opinion that RfA grants adminship to the person behind the keyboard, which is then implemented by granting +sysop to the main account (and limited by WP:ADMINSOCK to only that account). When I am on my public-computer account, I'm not going to tack {{nac}} onto everything I say and have no problem with using the "social" powers of an administrator, because I am an admin...just not currently on an account with +sysop. This does not, of course, answer the question of whether we can verify that Scissel/ELSchissel are in fact the same person, just a commentary on the distinction between accounts and the person operating those accounts. GeneralNotability (talk) 20:04, 7 July 2021 (UTC)
@Worm That Turned: Surely an administrator can remain anonymous and have their rights transferred over due to a use of committed identities? Sdrqaz (talk) 15:02, 8 July 2021 (UTC)
To me the underlying stuff looks simple. The rights are approved for a person even if we don't know their real world name. The mechanics are that only one account (of theirs) has the mop. Everything else is merely about safely administering that. When consistent with the latter, the person can decide which account that is. The referred to "given to" statements are just just unnecessary vague semantics and not a basis for deriving anything from. Sincerely, North8000 (talk) 17:50, 8 July 2021 (UTC)
Sdrqaz, I said unlikely, not impossible. There are a few other ways it might happen - if needed. WormTT(talk) 19:10, 8 July 2021 (UTC)
@Amakuru: the notation of the last detected admin action on the chart above is just a reference that can help determine if the 5 year rule would be a factor during any subsequent restoration request, alone it is not a consideration for inactivity removal. — xaosflux Talk 10:20, 7 July 2021 (UTC)
  • I don't see it as controversial if it is publicly known that both accounts are controlled by the same person and they want to move the bit from one account to the other, think Bishzilla/Bishonen. Both accounts publicly confirming the transfer request should suffice for that. I'm less confident where it is a declared alt account declaring that their main account has been compromised. Taking a couple of hypotheticals, what do people think of the scenario where an admin I know through the London meetup or some similar real life context, they lose their password and ask me to shift the bit to their new account? Or when an admin does a clean start, but asks a crat to transfer the bit from their retired account to the new one - perhaps by emails from both accounts. I don't see a problem with the first of those scenarios, with the second at the least the crat would need to check that the admin making a clean start was not under a cloud. ϢereSpielChequers 13:47, 7 July 2021 (UTC)
    I don't think "clean starting" former admins should get +sysop without a new RfA, and Wikipedia:Clean_start#Requests_for_adminship seems to support that. — xaosflux Talk 14:01, 7 July 2021 (UTC)
  • Perhaps the language at Wikipedia:Administrators#Procedural_removal_for_inactive_administrators should be changed from "administrators" to "administrator accounts" as the admin Schissel/El Schissel has in fact been active for the last year.-- Pawnkingthree (talk) 14:15, 7 July 2021 (UTC)
    ... but we didn't desysop or decrat Useight * Pppery * it has begun... 14:19, 7 July 2021 (UTC)
    You're right, I just remembered about WP:USEIGHT. The admin account retained its permissions while the alt was the only one active.-- Pawnkingthree (talk) 14:23, 7 July 2021 (UTC)
    If Schissel had requested transfer of rights at the time they were being locked out of the Schissel account and creating the alternative El Schissel account I do think, given the circumstances, and that there is community acceptance for transferring admin rights between publicly linked accounts, it likely we could have transferred the rights. But, even if El Schissel wished to have the rights, given that a year has passed, I doubt that such a transfer would now be uncontroversial. SilkTork (talk) 17:05, 7 July 2021 (UTC)
  • It seems we are comfortable in some situations (where both accounts are publicly known and linked, or where an account is changing names), less comfortable in others (perhaps where there has previously been no link between accounts - such as the new account being created after the previous one has closed), and reluctant if the link between accounts has only been made known to ArbCom, and is concealed from the community. I still remain personally uncertain about the notion of transferring rights from one account to another without explicit consent from the community; though, as we have unchallenged precedent, I accept that the principle is acceptable to the community. So, in such a case as this where a person gets locked out of their admin account for technical reasons, then, after being convinced that it is the same person in the new account, I would agree to a transfer of rights. SilkTork (talk) 16:51, 7 July 2021 (UTC)
  • Has anyone asked this editor what they want to happen? --In actu (Guerillero) Parlez Moi 17:30, 7 July 2021 (UTC)
    I do not see a confirmation that this is the same person to start with--Ymblanter (talk) 17:36, 7 July 2021 (UTC)
    @Guerillero and In actu: I linked to their own response above, from: Special:Diff/1026264478, "...Feel free to remove privileges.". — xaosflux Talk 18:05, 7 July 2021 (UTC)
    I have notified him of this conversation. Sdrqaz (talk) 19:10, 7 July 2021 (UTC)
  • This seems like a lot of fuss over someone who doesn't seem to care if they are an admin. Also, claiming to be the person who operated the previous account is not the same thing as proving it (although if they were an impersonator they would probably explicitly ask for the tools on the new account). Beeblebrox (talk) 21:13, 7 July 2021 (UTC)
    I really don't think this is an impersonator, an impersonator would probably care a little bit more about getting the tools back. Also, the editing style on the accounts is pretty similar, though that could be faked. ( Both accounts are interested in music articles, and both accounts use a similar style of edit summaries.)Jackattack1597 (talk) 01:44, 8 July 2021 (UTC)
  • Given the Useight case, which determined as far as I can tell that the inactivity policy applies to people, not accounts, I think that if it can be established that Schissel is in control of the alternate account, they should get the admin bit back as the inactivity removal would have been counter to policyJackattack1597 (talk) 01:38, 8 July 2021 (UTC)
    That is my understanding as well - that the inactivity rules were applied to a specific person, not a specific account. To be clear, I would not suggest re-adminning the locked-out account but rather the currently-used account. However, the voluntary request to remove the privileges would render the case moot, until/unless the new account retracted that and requested the tools and it was sufficiently established that both accounts were that of the same individual. However, assuming the two accounts are the same person, the five-year rule applies, if I recall correctly, only in the case of an inactivity removal, not in the case of a voluntary removal. Therefore, it should be determined if the loss of the admin tools was due to inactivity or due to resignation, in order to know if the five-year rule would apply in the event that the user requested the tools restored. Useight (talk) 16:45, 8 July 2021 (UTC)
    The tricky thing is that while the user said feel free to remove tools, the tools were not actually removed until the inactivity removal, so the loss of the tools was due to inactivity by the administrator account. The five year rule would apply if the user re-requested, then, BUT if the two accounts are the same person, the desyopping was in error. The question is: would policy permit reversing the desysopping if that was the case?Jackattack1597 (talk) 00:29, 9 July 2021 (UTC)
    I definitely agree that it would be pointless to readmin the locked out account.Jackattack1597 (talk) 00:29, 9 July 2021 (UTC)
  • So was this the meeting room for the People's Front of Judea, the Judea People's Front, or the Coalition for a Roman Free Judea? Or did I walk into the Globe Theater for their Much Ado About Nothing production? The Blade of the Northern Lights (話して下さい) 02:45, 8 July 2021 (UTC)
    "Completely new motion, that there be immediate action!" "Ah, once the vote has been taken." "Well, obviously once the vote's been taken. You can't act on the resolution till you've voted on it!" Sdrqaz (talk) 03:07, 8 July 2021 (UTC)
    I mean, you can't really be surprised about unnecessary bureaucratic discussion going on on the Bureaucrats noticeboard.Jackattack1597 (talk) 11:21, 8 July 2021 (UTC)
  • [Bishzilla smirks at finding herself appearing on the list of renamed admins as if she was the original owner of Bishonen's admin rights.] Not exactly correct. But pleasing! bishzilla ROARR!! pocket 16:04, 8 July 2021 (UTC).
    Heh, left column just means that's who got desysopped, not that's who had the bit originally. The matching desysop for User:Bishonen isn't listed since that account isn't a "former admin" (although, back to SilkTork's point, I suppose you the individual are both an admin and a former admin... or a human and dinosaur jointly posing as a single person who is both an admin and a former admin). I imagine if WP:FORMER in 2009 had had its same level of attention to detail as it does now, it would have listed User:Bishonen for the same reason it now lists User:Bishzilla. Both of y'all are at WP:RESYSOPS, though... Although I'm not entirely sure why in your (Bishzilla's) case, as you were only ever sysopped once. -- Tamzin (she/they) | o toki tawa mi. 16:29, 8 July 2021 (UTC)
    Bishzilla better admin, anyway, and User:Rdsmith4 best 'crat. Thank you User:Tamzin. bishzilla ROARR!! pocket 17:30, 8 July 2021 (UTC).
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Bureaucrats%27_noticeboard/Archive_45&oldid=1138384955"