Contents

Wikipedia:Bureaucrats' noticeboard/Archive 45

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

Archive 40

←

Archive 43

Archive 44

Archive 45

Archive 46

Archive 47

→

Archive 49

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)

• About the long password thing, even random long non-reused passwords can be less secure without 2FA. If you don't think that's a possibility - one compromised user recently told me that their computer had a keystroke logger. Yes, 2FA is useful as a security measure. It's not for everyone, but please do consider it. -- zzuuzz ^(talk) 08:36, 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)

• Ivanvector (current rights · rights management · rights log (local) · rights log (global/meta) · block log)

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)
• OnUser: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)

• If nothing else, I'm kind of impressed with Wikipedia's unshakeable ability to reliably turn the tiniest of molehills into mountains. --Floquenbeam (talk) 18:18, 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} _{aGN 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} _{aGN 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 will note the section below to make a point, seems unhelpful. PackMecEng (talk) 00:06, 16 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! Worm^TT(talk) 08:46, 16 January 2021 (UTC)

• Decline. I appreciate the intention though. Can we just move on now please? --Dweller (talk) Become old fashioned! 18:18, 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.

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)

• only (current rights · rights management · rights log (local) · rights log (global/meta) · block log)

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

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

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.

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)

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.

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

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 Worm^TT(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)

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)

• Arbcom emailed to review the situation. — xaosflux ^Talk 20:04, 25 February 2021 (UTC)
• @AmandaNP: Did you mean to enable autoblock? The bot runs on toolforge. Suffusion of Yellow (talk) 20:06, 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)

• Can confirm, legitimate concern. ArbCom is examining the issue. CaptainEek ^{Edits Ho Cap'n!}⚓ 20:12, 25 February 2021 (UTC)
• Thanks for the ping User:Xaosflux. Who should I talk with to get this resolved? I'm working on replying to a Cloud Services email, not sure if I also need to talk with ArbCom. Shubinator (talk) 06:36, 26 February 2021 (UTC)
  • @Shubinator: while the sysadmins w/ Cloud Services may unlock you - you will need to contact ArbCom about getting sysop access restored. They will generally want to discuss with you security practices related to WP:SECUREADMIN. — xaosflux ^Talk 11:05, 26 February 2021 (UTC)

    See WP:RETURN for more details. Regards SoWhy 11:08, 26 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

•  Bureaucrat note: -sysop per LEVEL1 request completed. — xaosflux ^Talk 20:26, 25 February 2021 (UTC)

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)

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)

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)

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)

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. Worm^TT(talk) 10:34, 9 March 2021 (UTC)

Thread retitled from "El C".

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

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)

• For the record, I've accidentally rolled back an edit 3 times that I know of, in the last 15 years. One was at WP:ANI. It's not hard to do. Dennis Brown - 2¢ 21:10, 12 March 2021 (UTC)

  Okay. I created a .css, added code there. Thanks, all. —valereee (talk) 21:17, 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! –xeno^talk 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. –xeno^talk 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.

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

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. Cullen³²⁸ 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)

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} _{aGN 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)
  • FWIW I wrote "provisional" in my notes about this user in the former admins pages (e.g. Wikipedia:Former administrators/chronological/2021) to avoid confusion with actual temporary desysops ... which are rare, but have happened; also see many of the resysops made by arbcom decision in this table. SlimVirgin's temporary desysop (linked above) was the first that came to mind for me but certainly not the only one. Graham87 07:25, 9 April 2021 (UTC)

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)

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