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

My administrative permissions were suspended due to inactivity, but I'm now back. Please restore them. Thanks, Jackmcbarn (talk) 21:13, 26 July 2020 (UTC)

Summary of bureaucrat positions

Resysop

WereSpielChequers, WormThatTurned, Dweller (with assurances?), SilkTork

Decline

Nihonjoe, Useight, Xaosflux, bibliomaniac15

No consensus

Xeno

Discussion

• It appears at first glance that Jackmcbarn has gone over two years without an edit prior to today and is not eligible to be automatically resysopped. -- Dolotta (talk) 21:28, 26 July 2020 (UTC)

  The message that I got at the time said I'd be eligible for 3 years, which haven't yet elapsed. It seems that we changed that between when I was desysopped and now. Does the new rule apply to me anyway? Jackmcbarn (talk) 21:38, 26 July 2020 (UTC)

Dolotta is correct that the current rule is one year of inactivity since being desysoped, though at the time you were desyoped the rule was two years. SilkTork (talk) 21:43, 26 July 2020 (UTC)

@SilkTork: Do you mean 2 years and 3 years, rather than 1 year and 2 years? Jackmcbarn (talk) 21:47, 26 July 2020 (UTC)

My thinking at the moment is that you meet the requirement for being resysopped according to the criteria at the time you were desysopped. I have had a look at the discussion which led to the change, and there was no comment on those who would be caught in your situation, and without an explicit guideline, I don't think that those taking part would have considered moving the goalposts. We can either take the rules as they stand right now, or the rules and terms given to you at the time. It seems fairest to me that we apply the rules that were emailed to you. SilkTork (talk) 21:56, 26 July 2020 (UTC)

You've used the admin tools within the past five years: [1], and you have started editing again within two years of your desysop, so you meet those two requirements which were in place at the time you were desysopped. As it has been nearly three years since you last edited, there may be some security concerns as to if it is the same person behind the account. Given your edits here, I feel comfortable that it is the same person. I'd be inclined to resysop, though am interested what others think. SilkTork (talk) 22:02, 26 July 2020 (UTC)

WP:ADMIN is not a policy subject to 'interpretation'. A month and a half short of three years of no edits is well over the two year limit. It was shortened precisely to prevent the process-gaming like showing up just before the time limit is up to keep tools. Only in death does duty end (talk) 22:05, 26 July 2020 (UTC)

The current WP:ADMIN might not be open to interpretation, but the question here is which chronological implementation should apply. I agree with SilkTork that the version in effect at the time of the desysop should be applied. If we think about legal matters, it's the law as it applied at the time of any alleged crime that applies, not subsequent changes to the law. I know there are many good reasons why legal analogies might not apply to Wikipedia's policies, but in this case I think that's exactly how we should treat this policy change. Boing! said Zebedee (talk) 15:15, 27 July 2020 (UTC)

• I get there’s some question of how we should apply the new resysop standards (and I think this is the first test case) I get the arguments on both sides, but as I think there’s some question here, it’d trigger the new requirement that a resysop not occur without bureaucrat consensus. TonyBallioni (talk) 22:08, 26 July 2020 (UTC)

The requirement for bureaucrat consensus was put in to allow for not resysopping when policy required it, but the crats were not comfortable with it. Not for resysopping where policy doesn't allow it but the crats think they should. That would make a mockery of even having requirements at all. Only in death does duty end (talk) 22:43, 26 July 2020 (UTC)

My reading of policy is that a resysop should not occur. I was saying that at the very least, a resysop shouldn't occur exactly at 24 hours if someone wants to per that bit of policy. TonyBallioni (talk) 22:49, 26 July 2020 (UTC)

My reading of policy matches you Tony, no grandfathering was intended, especially given the consensus at RfC 1. However, I think OID is correct that the requirement for a cratchat is merely limited to cases concerning the suitability. Best, Barkeep49 (talk) 23:19, 26 July 2020 (UTC)

My interpretation of that phrasing was that if there's a concern that someone might not meet the policy to be resysoped, they shouldn't be resysoped unless there is consensus among crats. At least that's what I understood I was supporting in the RfC. I don't really know what concerning the suitability would mean otherwise. The only suitability requirements that I can see are laid out at WP:RESYSOP. TonyBallioni (talk) 23:41, 26 July 2020 (UTC)

When I first read it, I understood the crat chat clause to mainly involve assessing whether someone resigned "under a cloud" or not. At least, at the time, it was the only scenario I could think of that seemed "gray" enough to me to warrant that. bibliomaniac15 00:16, 27 July 2020 (UTC)

The wording of Wikipedia:Requests_for_comment/2019_Resysop_Criteria_(2)#Statement 7 by Amorymeltzer made no mention of grandfathering admins desysopped before the creation of the new policy, so there is no reason to think that they should be grandfathered. This request should be denied. * Pppery * _{it has begun...} 23:11, 26 July 2020 (UTC)

I do recall a brief discussion somewhere about whether we should grandfather folks, but it certainly wasn't enacted. As Barkeep and TB and yourself note, the policy was changed and is (intentionally) clearcut. ~ Amory (u • t • c) 00:01, 27 July 2020 (UTC)

• Since grandfathering wasn't even discussed (aside from one tangent by Carrite), it would appear that the new rules did nothing to change any previous consensus on grandfathering. Until an RFC changes or establishes a rule on grandfathering, we have to look at what we did before the changes, as that would be the established consensus. Did we do any grandfathering before this RFC? That is what I would think should guide us, as that would be the consensus view. I don't know the answer, but it would seem this is the proper procedure to take, rather than trying to second guess the comments (intentions) on an RFC that didn't mention it. Dennis Brown - 2¢ 00:10, 27 July 2020 (UTC)
  • I recall that the 2012 policy change did allow grandfathering up to a certain date, but that was because the bureaucrats sat down and made an explicit determination to do it. --Rschen7754 00:17, 27 July 2020 (UTC)
    • Addendum: they then went around and messaged all the affected former admins the new rules and the deadline to be grandfathered in. But - this was definitely controversial especially as the number of former and minimally active admins showing up was in the dozens. --Rschen7754 00:45, 27 July 2020 (UTC)
      • They would need links, but that sounds like the precedent I was looking for. What they will do with this is up to the Crats, but reviewing past actions and considering those methods now would seem to be the closest thing to following policy and consensus to the letter. Dennis Brown - 2¢ 00:48, 27 July 2020 (UTC)
        • Dennis Brown, the more recent (and conflicting) precedent was after when Beeblebrox proposed the 5 year rule. There was no grandfathering period allowed then, and it was/is applied retroactively. In other words, we had two different ways of dealing with this in the past. TonyBallioni (talk) 00:55, 27 July 2020 (UTC)
        • (edit conflict) It's too late to retroactively decline to enforce a October 2019 policy change in July 2020. The time to bring that up would have been in October 2019, but it wasn't brought up then, and thus the policy change that was actually made in 2019 should be implemented, which unambiguously denies this request. Granting this request would render that policy change meaningless until October 2021, which I do not think is what was intended then. * Pppery * _{it has begun...} 01:01, 27 July 2020 (UTC)
        • The associated discussions were at Wikipedia:Bureaucrats' noticeboard/Archive 26. However, I think it would be controversial to do this now - especially if bureaucrats have declined similar requests in the intervening months. --Rschen7754 01:12, 27 July 2020 (UTC)
        • I'm not saying he should or shouldn't be resysoped, I'm only speaking as to procedure. To be fair, we have to apply the current policy, but we should also apply the outstanding consensus on applying it, if there is one, as the RFC didn't do anything to change grandfathering in any way. There is some question as to what the consensus is, and I don't have the answer, but balancing those two factors (including researching the grandfathering) would seem to be the Crat's duty here. Dennis Brown - 2¢ 10:44, 27 July 2020 (UTC)
• IMHO I agree with SilkTork. The editor has applied the rules that they were told to apply. There is no room for doubt here, they must be resysopped, assuming the account is not compromised. It's fine for us to implement new policies, but users who've been desysopped under particular conditions must have those conditions honoured. Cheers  — Amakuru (talk) 00:28, 27 July 2020 (UTC)
• Support grandfathering. If a proposed change was going to affect specific users, overriding previous instructions that were given to them, I would have expected at the very least a courtesy email / talk page post. Since that was not done, I don't think it's fair to pull the rug underneath such people. -- King of ♥ ♦ ♣ ♠ 01:33, 27 July 2020 (UTC)

•  Bureaucrat note: The current admin policy specifically calls out that In the case of an administrator desysopped due to a year of inactivity, only one year of continued uninterrupted inactivity (no edits) from the removal due to inactivity is required before a new WP:RFA is necessary. In regards to those elements:
  1. The requester was desysoped for a year of inactivity on 01-OCT-2018
  2. The requester has uninterrupted inactivity from 01-OCT-2018 to 26-JUL-2020

Policies change, it is the nature of the project - I'm not seeing that the current policy supports this request, will hold open for other 'crat viewpoints - but I'm inclined to refer the requester to the standard request process. — xaosflux ^Talk 02:12, 27 July 2020 (UTC)

Is this creteria meet "Before restoring the administrator flag, a bureaucrat should be reasonably convinced that the user has returned to activity or intends to return to activity as an editor." Now the editor has edited only for 1 day yesterday 26th July 2020 after 9 September 2017 as per this. Is one day of editing sufficient ?Pharaoh of the Wizards (talk) 02:28, 27 July 2020 (UTC)

Leaning on WP:AGF, their assertion that they have returned goes a long way. — xaosflux ^Talk 02:31, 27 July 2020 (UTC)

The point is that the policies changed without notifying the affected users, who may believe that the most recent information they were told as of their desysopping is still accurate. Absent a consensus at the RfC to intentionally withhold this information, I view it as a duty to inform affected users of the change to give them time to react, and failure to inform them invalidates its applicability to existing cases. -- King of ♥ ♦ ♣ ♠ 03:07, 27 July 2020 (UTC)

The onus is on the individual to be aware of changes made to policy in their absence. A former admin being unaware of such a massive RfC and returning just in time to make their triennial set of edits is the very reason why that RfC existed in the first place. There was no mention of grandfathering anyone in, which is something that would have been added to the current policy if it were agreed upon. The current policy lacks such a clause, so making exceptions is not line with policy. Nihlus 04:19, 27 July 2020 (UTC)

It was in Wikipedia:Administrators' newsletter/2019/12, which has become the de facto way of providing notice for changes to WP:ADMIN. It was around for all of 2017, and was well received during thar time frame as well. That someone didn’t subscribe to what’s become the equivalent of a paper of record for this type of stuff doesn’t change the fact that reasonable notice was given via inclusion in it. TonyBallioni (talk) 04:25, 27 July 2020 (UTC)

I agree with Nihlus and TonyBallioni here. While absent as an admin, it is stil necessary to keep up with inactivity policy requirements through the normal channels, which in this case is the admin newsletter. In my view, the required notification was made. Nothing against Jackmcbarn personally, but I think this request should be declined and a new RfA required. Boing! said Zebedee (talk) 06:59, 27 July 2020 (UTC) (see below - Boing! said Zebedee (talk) 08:08, 27 July 2020 (UTC))

While I think that it would have been more fair to have done a grandfathering in period - if it were to be done, it should have been determined when the policy changed. I think that ship has unfortunately sailed and to instate it now after a request has been made and several months after the policy change would be problematic, outside due process, and would lean towards reading an opinion into interpretation of policy. --Rschen7754 07:11, 27 July 2020 (UTC)

• Hmm, I've just re-examined the timings of this. The key RfC result was...

"Change second bullet of WP:RESYSOP to Over two years with no edits. If an editor has had at least two years of uninterrupted inactivity (no edits) between the removal of the admin tools and the re-request, regardless of the reason for removal, the editor will need to instead request through the WP:RFA process. In the case of an administrator desysopped due to a year of inactivity, only one year of continued uninterrupted inactivity (no edits) from the removal due to inactivity is required before a new WP:RFA is necessary." This rule change was introduced in December 2019.

Jackmcbarn was desysopped in October 2018 under the "inactive for one year" rule. When the resysop rule changed in December 2019, Jackmcbarn had already been desysopped and inactive for more than a further year. It seems this made it impossible for him to comply with the rule change and regain the admin tools, even if he'd been watching and seen the rule change immediately. Or have I misunderstood the timing here? If I'm not mistaken, this negates the argument that he should have been watching for rule changes. Boing! said Zebedee (talk) 08:11, 27 July 2020 (UTC)

• Tricky. No one is expected to enforce a policy they disagree with, but a resysop would be in contradiction of bad policy. I'm not convinced by the argument that absent former admins should keep abreast of policy; absent is absent, the expectation is that little will have changed in the time an admin is absent, and that a returning admin will refresh their knowledge and catch up on any changes. The policy is clear, but flawed if it is applied retrospectively and overrides commitments made to admins who went inactive in the three years prior to Nov 2019. If we do decide not to resysop Jackmcbarn then an effort should be made to contact admins desysopped for inactivity who went inactive between late July 2018 and November 2019 to tell them about the change in rules. If we decide to resysop without an RFC on retrospective rule changes then we upset a few people and create a precedent against retrospective rule changes. If we decline to resysop then we set a precedent in favour of retrospective rule changes. We could encourage the community to start an RFC on the principle of retrospectivity, but in the circumstances it would likely be over focussed on the current case. But the simplest, fairest and neatest solution would be to treat the Nov 2019 rule change as not being retrospective, though that would create the odd situation between late 2021 and late 2022 when some former admins were entitled to resume the mop after more than two years and up to three years while others who had become inactive after the rule change were caught by the two year rule. ϢereSpielChequers 09:26, 27 July 2020 (UTC)

  Re: "contact admins desysopped for inactivity who went inactive between late July 2018 and November 2019". It's already to late for anyone desysopped under the 1-year inactivity rule between July 2018 and July 2019, because they've already been inactive for a further year. Boing! said Zebedee (talk) 09:35, 27 July 2020 (UTC)

  Policy changes have been never been indivially communicated by talk page messages to all users including former admins.They are made after they are advertised in WP:CENT .A resysop request was declined here after only a fortnight week had passed since the change was made.Pharaoh of the Wizards (talk) 09:44, 27 July 2020 (UTC)

  Hi Pharoah, I have gone through Wikipedia:Bureaucrats' noticeboard/Archive 42 which I think covers the first couple of months after that change was made and I'm not seeing a declined resysop. Can you tell me which archive you were looking at? ϢereSpielChequers 10:33, 27 July 2020 (UTC)

  The User was Andrew C and his request was declined due to 5 year rule in March 2018 Wikipedia:Bureaucrats' noticeboard/Archive 37 .Note the RFC was passed on 3rd March 2018 and he asked back for his tools on 18th March 2018.He too was not informed about the rule change in his talk page here.Pharaoh of the Wizards (talk) 10:50, 27 July 2020 (UTC)

  Ah, yes, the previous change in the rules. When you said "the change" I assumed you were referring to the Nov 2019 change that this thread is about. ϢereSpielChequers 10:59, 27 July 2020 (UTC)

  @Boing! Yes, that's why I wrote ""contact admins desysopped for inactivity who went inactive between late July 2018 and November 2019"." Any admin whose last edit was on the 29th July 2018 would have been desyopped in August 2019 and could uncontentiously return today. ϢereSpielChequers 10:16, 27 July 2020 (UTC)

  Ah, got you. I misread "went inactive" as "were desysopped". Boing! said Zebedee (talk) 10:24, 27 July 2020 (UTC)

  The fairest way is: 1) Do the present resysop as a one-off. It does not set a precedent against retrospective rule changes, but rather sets a precedent for notifying people if we are going to do retrospective rule changes. 2) Notify everyone desysopped September 2016 through November 2018 at the beginning of August 2020 of the rule change and give them a grace period to request restoration (if they would have been eligible under the old rules) until August 31, 2020. (September 2016 is the earliest possible desysopping we'd consider, as the rule is five years with no admin activity and they must have been inactive for one year before desysopping; it's possible, for example, for them to have edited in May 2018 and still think they're good. At the other end we don't need to re-inform people who were already told of the new rules at the time of desysopping.) -- King of ♥ ♦ ♣ ♠ 13:49, 27 July 2020 (UTC)

• I feel it's a grey area because the situation regarding those admins caught between the two rules wasn't discussed at the time the new rule was being voted in so a clear decision wasn't made either way. If a user was returning in good faith and appeared to be an asset to the community, and met the criteria, I wouldn't hesitate to press the switch once all checks had been made. If, however, I felt that a returning user was applying for the return of admin tools purely for shits and giggles, or there was some security risk, then I wouldn't be the one to volunteer to press the switch, even if it were within the letter of the law. I think it is important for us to consider the reason we have a rule. We don't have rules for rules sake. The rule on resysopping is there to prevent a security risk and to prevent people claiming back a tool which they may misuse. I don't think that applies here. Following the spirit of the law rather than the letter of the law, this user's contributions since returning indicates someone whose return as an admin would be an asset to the community: [2]. Given the circumstances: that this is a grey area, that Jackmcbarn was not aware of the new rule (and so would not have been prompted to make a token edit last year to satisfy the letter of the law), and that Jackmcbarn appears to be a user who would be an asset to the community as an admin, inclines me toward thinking that the community did not intend for such users to be caught out. It would be interesting to hear from other 'Crats on this matter. At the moment we have one in favour, and one not in favour, which defaults to Jackmcbarn not automatically getting the tools back, as I certainly wouldn't flick the switch in the current circumstances. SilkTork (talk) 12:03, 27 July 2020 (UTC)

@SilkTork: Re: "Jackmcbarn was not aware of the new rule (and so would not have been prompted to make a token edit last year to satisfy the letter of the law)". As I pointed out above, it was already too late for him to do that anyway, as he had already been inactive for more than an additional year when the rule change was decided. Boing! said Zebedee (talk) 12:11, 27 July 2020 (UTC)

Thanks for that. SilkTork (talk) 13:01, 27 July 2020 (UTC)

How do you know what Jackmcbarn knew ("was not aware")? Did you ask?Also, being not aware of current policy, is, among other things, why the rule exists, is it not? -- Alanscottwalker (talk) 13:29, 27 July 2020 (UTC)

He couldn't have been aware at the time he needed to be aware (ie October 2019), because the rule change hadn't happened yet. In order to have been aware and made an edit to avoid the one-year inactivity rule, he would have had to be aware of *future* policy. Boing! said Zebedee (talk) 13:38, 27 July 2020 (UTC)

Well, any admin or former admin, editor or not editor, could have been aware that from 20 July to 5 October 2019 [3], that the issues around activity or lack thereof were publicly being mooted. Alanscottwalker (talk) 13:48, 27 July 2020 (UTC)

(EC) Yes it was already too late by the time the policy was amended for Jackmcbarn. As Jackmbarn's last edit was 9th September 2017, they were desysopped a year later, and by the policy at the time, had 2 more years - which would be 9th September 2020. When it was amended in October 2019 down to two years inactivity, Jack was already past that 2 year point. In order for them to not automatically be inelgible for resysop due to inactivity, there would have had to have been a discussion at the RFC (here for quick link) about those users in that bracket. There was none. Nor was there any hint from reading that RFC anyone would want to make an exception in the circumstances, on the contrary, there are plenty of comments (including in the prior RFC) about specifically reducing the amount of time inactive admins can be away. The suggestion that somehow in both those RFC's the community has given bureaucrats the discretion to allow significantly more time is not one I am entertaining. Silktork's suggestion that Jackmcbarn should be given the time allowed in the policy at the point he was desysopped (policy at time) is not within the community expectations of bureaucrats. Its certainly against the clear community consensus that admins inactive for 2 years should go back to RFA. And there is no suggestion anywhere that bureaucrats should be allowed the discretion to deviate from community-derived policy in that drastic a manner. Only in death does duty end (talk) 13:23, 27 July 2020 (UTC)

My suspicion is that when we discussed the rule change, we simply didn't think about ex-admins who would be caught in this situation - I know I didn't. Something along the lines of "A year from desysop, or from the date of this rule change, whichever is later" would have been a fair way to go. Did we actually not want that, or did we just not think of it? And what, if anything, should we do about it now? I'm honestly not sure what the answer is, but I really don't like to see someone caught up in unintended bureaucratic outcomes with no chance of having been able to avoid them. Boing! said Zebedee (talk) 13:41, 27 July 2020 (UTC)

My suspicion, which I suspect is a significant degree more suspicious than yours, is that those who did think about it, didnt want it. Given the discussion and complaints over admins turning up just to keep their tools, and the timing of this request is just short of the 3 year limit Jack *thought* they had, without an RFC on the subject talking about 'well maybe we should have done this' is irrelevant. As is concepts of 'fairness'. The policy is the policy. 'Its not fair' is not a valid reason for ignoring it on the basis of subjective opinion. Jackmcbarn had 2 years, which the community has decided was a 'fair' amount of time for them to avoid having their tools removed permanently. Only in death does duty end (talk) 13:49, 27 July 2020 (UTC)

Fairness is not merely subjective opinion; it's about something that they were told when they lost the tools, it's a social contract. If the community can modify that willy-nilly without notifying the user, then the community loses a great deal of credibility. -- King of ♥ ♦ ♣ ♠ 13:53, 27 July 2020 (UTC)

So, the October 2019 policy change may have been unfair. That does not mean that bureaucrats can retroactively annul it 8 months later. * Pppery * _{it has begun...} 13:58, 27 July 2020 (UTC)

Exactly, and it's worse than "without notifying the user" - even if Jackmcbarn had been notified, it was still already too late for him to do anything about it. Boing! said Zebedee (talk) 14:00, 27 July 2020 (UTC)

Which is why I would have suggested a grace period of a month to allow affected users to "do something about it". See my proposal above to retroactively "make it right". -- King of ♥ ♦ ♣ ♠ 14:14, 27 July 2020 (UTC)

I'll add that yes, "Jackmcbarn had 2 years, which the community has decided was a 'fair' amount of time for them to avoid having their tools removed permanently". The problem is that it wasn't decided he only had 2 years until more than 2 years had lapsed. Do people really not think that's wrong? Boing! said Zebedee (talk) 14:06, 27 July 2020 (UTC)

It doesn't matter whether it is wrong, because it is what the community enacted in October. * Pppery * _{it has begun...} 14:08, 27 July 2020 (UTC)

"It doesn't matter whether it is wrong" - I think that's a sad attitude to take to anything. We might not be able to put it right now, but it *does* matter if something is wrong. Boing! said Zebedee (talk) 14:14, 27 July 2020 (UTC)

What I really meant was something like For the purpose of deciding whether to grant or deny this request, it doesn't matter .... * Pppery * _{it has begun...} 14:17, 27 July 2020 (UTC)

In that case, yes, we might indeed be in a situation where we can't do anything about something being wrong. But it makes the way we treat people smell bad. Boing! said Zebedee (talk) 14:19, 27 July 2020 (UTC)

Why would that be wrong?. It was decided that admins as a group should only have 2 years. It was not decided "admins as a group, except for this one, this one, oh and Dave over here, he can have 3". The entire point was to prevent admins who have been inactive for 2 years from regaining the tools. So no, in no way do I think that an admin who has been inactive for nearly 3 years not getting their tools back is 'wrong'. The notifications to their userpage in order to prompt re-engagement, not a binding contract. While Silktork may be willing to ignore the community decided policy citing 'fairness' (despite hypocritically actively participating in one of the most unfair events in wiki-history) I am not happy with seeing bureaucrats decide if they dislike a policy as it is written it can be ignored. Which in order to resysop Jackmcbarn here, is what will have to happen. No admin/crat can be made to perform an action they disagree with, but they also cannot perform actions the policies explicitly do not give them leave to do. Only in death does duty end (talk) 14:25, 27 July 2020 (UTC)

No, it's not "an admin who has been inactive for nearly 3 years not getting their tools back" that I'm suggesting is wrong. What I'm suggesting is wrong is changing the rules on people when they can't do anything to fit in with the new rules. In this case Jackmcbarn had his 3-year window cut to a 2-year window when he had been inactive for 2 years and 2 months and was fully in line with the rules as they had been at the time. Boing! said Zebedee (talk) 15:05, 27 July 2020 (UTC)

I don't think this is the place to fill in the gaps that the original RfC may have left. It seems clear that the community did not want to grandfather anyone in. If you see that as an error, then only an additional RfC could really alter that (although it would be relatively pointless at this stage). Making a decision on this page contrary to that consensus would be problematic. Nihlus 14:27, 27 July 2020 (UTC)

Well, as the proposer, I did. My intent there was the clearest possible tightening, changing only the numbers in the policy, nothing else in how it was applied. While I agree it would have been more fair to grandfather folks in, that also means a de facto delay of the policy for an entire year. That certainly wasn't approved, but "grandfathering in" is equivalent to "delay the RfC for a year." We could make the same arguments about only applying crat discretion regarding activity for those desysoped after the implementation, but that's clearly not the case (and it has already been applied). Restoring the bit here (full disclosure: I want Jack to be a sysop) would mean delaying the implementation of the RfC, going against prior precedent of following the RfC results (the first item). ~ Amory (u • t • c) 13:55, 27 July 2020 (UTC)

I think it's more subtle than simply "delaying the implementation of the RfC". It would be a rolling delay on a case-by-case basis for those caught up in the impossible task of having to make edits in the past. I don't see why that would be a problem. And it's already nearly the end of July, so we'd catch up in only another four months. Boing! said Zebedee (talk) 14:09, 27 July 2020 (UTC)

I mean, that's delaying the implementation of the RfC. It may not have much of an effect, but that it isn't a regular occurrence is beside the point, especially when there have been no concerns over the return-to-activity discretion, which is even more widespread. Indeed, were the same standards applied to that — no one desysoped before its implementation is subject to crat discretion on activity — that would effectively mean two policy outcomes indefinitely: one for folks desysoped before or and one for after. ~ Amory (u • t • c) 14:29, 27 July 2020 (UTC)

We didn't have to delay implementation by a year - if only we had bothered to notify people properly. Because that was not done, I think we should just allow this one through as a special case and work to notify everyone affected, better late than never (see my suggestion above). -- King of ♥ ♦ ♣ ♠ 14:12, 27 July 2020 (UTC)

No! Notifying people would not have helped, because it was *already too late* for them to do anything about it. Boing! said Zebedee (talk) 14:15, 27 July 2020 (UTC)

See my comment above about a grace period. -- King of ♥ ♦ ♣ ♠ 14:18, 27 July 2020 (UTC)

OK, but isn't a grace period the same as a rolling delay offered to those affected by varying timescales? Boing! said Zebedee (talk) 14:20, 27 July 2020 (UTC)

Let's forget this case, and suppose we implemented the notifications correctly in November 2019. Also assume that anyone desysopped in this example makes no subsequent edits through the time of the RfC. There are three options for a grace period: 1) No grace period. Someone desysopped in January 2019 would only have until January 2020 to resume editing, and someone desysopped in January 2018 is just plain SOL. 2) Grandfather everyone in under their original terms of desysopping. Someone desysopped in October 2019 would have until October 2021, but someone desysopped in November 2019 would only have until November 2020. 3) Move everyone to the new rules, and allow a grace period to anyone who would immediately become ineligible under the new rules. Someone desysopped from December 2017 through November 2018 would have until November 30, 2019, to resume editing or request restoration. Someone desysopped from December 2018 through November 2019 would simply have their allowance shortened with proper notification. I believe option 3 is the fairest outcome that balances out the interests of the ex-admins and the RfC !voters. -- King of ♥ ♦ ♣ ♠ 14:47, 27 July 2020 (UTC)

Option 3 is pretty close to what I meant by a rolling delay - see my "A year from desysop, or from the date of this rule change, whichever is later" further above. But I don't think you have your dates right. "Someone desysopped from December 2017 through November 2018 would have until November 30, 2019, to resume editing or request restoration" wouldn't work when the rule change didn't happen until December 2019. Boing! said Zebedee (talk) 15:01, 27 July 2020 (UTC)

I see. I think what I'm saying is quite similar, but I would only give a month from the rule change rather than a year, so that by January 2020 we will be operating under the new rules, no exceptions. -- King of ♥ ♦ ♣ ♠ 15:04, 27 July 2020 (UTC)

I think we're probably even closer than you think ;-) My "A year from desysop, or from the date of this rule change, whichever is later" would have everyone under the new rule without exception by January 2020 too. Boing! said Zebedee (talk) 15:21, 27 July 2020 (UTC)

• Would it not just be simpler all round if Jackmcbarn took note of the issues raised here and realised that any automatic restoration of admin privileges would be tainted? It isn't difficult to start a new RfA, although I suspect they would fail without first putting some hours in and certainly it would be more stressful than usual if they didn't put those hours in. - Sitush (talk) 14:01, 27 July 2020 (UTC)

  That's the issue. Too many admins here act as if they're afraid of the voters. If Jackmcbarn is legit, he'll pass another RfA. The community consistently increases the restrictions on inactivity because of exactly this shameful behavior. You guys keep riding your lifetime appointments and eventually the community will start to require votes of confidence every few years. Chris Troutman (talk) 14:16, 27 July 2020 (UTC)

  That seems like a good idea, iff we can change the current week-long walking on hot coals and replace it with a "please submit your ballots here" assessment similar to steward confirmations. --qedk (t 愛 c) 15:50, 27 July 2020 (UTC)

  @Sitush: Yeah, I definitely plan to spend a few weeks or so editing as a non-admin again before going through with a second RfA (which at this point, it seems almost certain I'll need to do). Jackmcbarn (talk) 20:46, 28 July 2020 (UTC)

• I think it is clear that this case needs consensus of crats (an analog of cratchat). This is what we have elected you guys for.--Ymblanter (talk) 14:28, 27 July 2020 (UTC)
  • Some of the crats we elected because of their technical skills around things like renames. I agree it is what we elected more recent crats for. Best, Barkeep49 (talk) 14:37, 27 July 2020 (UTC)
  • I can't remember for sure, and wouldn't know where to check, but I think the 'crats were in a bit of a tangle with the resysop of Master Jay a year or two ago. Eventually, one of them sort of did a unilateral resysop and everyone fell into line ... but several were unhappy about the situation. So getting consensus (certainly WP:CONSENSUS) is likely to be a problem here, too. - Sitush (talk) 14:38, 27 July 2020 (UTC)

    We had a crat discussion on my own resysop request two years ago, so this one is clearly not going to be an exception.--Ymblanter (talk) 14:43, 27 July 2020 (UTC)

    • Wikipedia:Requests for comment/2019 Resysop Criteria (2)#Statement 3 by Hasteur was passed to address just this sort of situation. I'm sure I'm not the only person commenting in there that had the Master Jay debacle specifically in mind. —Cryptic 14:59, 27 July 2020 (UTC)
      • The point of statement 3 (in relation to Master Jay) was to allow crats the discretion to not return tools when policy allowed it. Certainly anyone recalling the Jay debacle as you put it would be thinking along those lines. I will happily wager no one was thinking it was put there to allow crats to return tools when policy explicitly disallowed it. Only in death does duty end (talk) 15:43, 27 July 2020 (UTC)
• The outcome in this decision will, either way, be unfair. We will either be unfair to Jack, (LATER EDIT: and others with similar inactivity patterns), who was told one thing and then had the rules changed on him without a meaningful opportunity to remedy. Or we will be unfair to the participants of the two RfCs who felt that rules should be tightened - especially those participants who supported statement 14 in the second RfC. So it becomes a judgement call about who we should be unfair to - I have my opinions but I do think it would help those on both sides to acknowledge that the other side has a case for their position being the "fair" one. Best, Barkeep49 (talk) 14:37, 27 July 2020 (UTC)

  Oh, I agree totally. We've managed to get ourselves into a situation where there's wrong whatever happens. Boing! said Zebedee (talk) 14:40, 27 July 2020 (UTC)

• I'm reserving judgement for the moment, as I am interested to see how some of the above discussions play out, but I notice that Jackmcbarn hasn't actually been pinged to any of the above discussions. I would like to draw his attention to (at the very least) the comment/semi-question made by Sitush three bullet points above this one (starts with Would it not just be simpler...). Primefac (talk) 14:45, 27 July 2020 (UTC)

Arbitrary break 1

• Are Crat's actually being asked to find that the community is unfair? Is asking the community for tool access unfair? Everything the community did over multiple months last year was done in public, in multiple public requests. Why can't the community decide that in every such case, going to the community for access is fair enough? -- Alanscottwalker (talk) 14:42, 27 July 2020 (UTC)

  I think what the crats are being asked to decide is which version of the rule should apply - the version when the "crime" was committed, or the current version after subsequent changes. Boing! said Zebedee (talk) 15:24, 27 July 2020 (UTC)

  The community has already decided that. Nihlus 15:27, 27 July 2020 (UTC)

  I'm not sure we have, and I think that's where the problem lies. Boing! said Zebedee (talk) 15:28, 27 July 2020 (UTC)

  Thats just saying 'I dont agree with the policy as it is written'. WP:ADMIN is not a discretionary policy that can be ignored because you dont think its fair to an individual. Only in death does duty end (talk) 15:34, 27 July 2020 (UTC)

  In my view, since we have previously promised ex-admins that they would get their tools back under the old rules, absent a specific consensus to purposefully withhold notification from them (a valid point to make, though one I would strongly disagree with and one that would have needed to be made at the RfC), notifying affected ex-admins of a change that could affect them is a requirement, and failure to do so invalidates the applicability of the new rules to those users. -- King of ♥ ♦ ♣ ♠ 15:40, 27 July 2020 (UTC)

  Again, notification alone would not have made any difference in this case. Boing! said Zebedee (talk) 15:43, 27 July 2020 (UTC)

  Yes, by notification I mean notification + grace period. If only this issue had been discussed at the RfC, we wouldn't be in this mess. -- King of ♥ ♦ ♣ ♠ 15:45, 27 July 2020 (UTC)

  Indeed. Boing! said Zebedee (talk) 15:51, 27 July 2020 (UTC)

  Except we did notify them: the admins newsletter. Now, Boing! makes a good point that it wouldn’t have had any impact in this case, but notice was given, and we’re over 6 months since the policy change. That seems like a reasonable notice and grace period to me. TonyBallioni (talk) 16:41, 27 July 2020 (UTC)

  Except that there wasn't *any* grace period at all. The new rules made him instantly disqualified from regaining the tools without RfA. Boing! said Zebedee (talk) 16:48, 27 July 2020 (UTC)

  No it isn't ;-) In any rule system there's the written rules themselves, and procedures which govern how those rules should be applied. Like the law, where an act is unambiguously defined as criminal, but anyone who committed that act before it was made criminal would not be liable to prosecution. Boing! said Zebedee (talk) 15:47, 27 July 2020 (UTC)

  They are either applied as they are explicitly written or they are not. Arguing that the core policy which governs how admins recieve and lose their tools should be procedually not applied in the exact situation it was written to cover, despite a quite clear consensus as to exactly what it means, is beyond silly. You could use that argument for ignoring any policy whatsoever, and if you are going to do that, just cite WP:IAR and have done with it. Oh and dont argue Ex post facto law - its actually allowed to a lesser or greater extent in the major English-language countries and a common misconception its prohibited in all cases. Only in death does duty end (talk) 15:52, 27 July 2020 (UTC)

  This is the whole textualism vs. originalism debate. Of course Wikipedia is not a court of law, but if anything textualism is very much not how things work here. -- King of ♥ ♦ ♣ ♠ 15:59, 27 July 2020 (UTC)

  Well put. Boing! said Zebedee (talk) 16:17, 27 July 2020 (UTC)

  There is no crime. It's at most, a term of use, in a project that is, by its very well-known, un-hidden nature, exceedingly dynamic. -- Alanscottwalker (talk) 15:36, 27 July 2020 (UTC)

  That's why I used quotes - the "crime" to which I refer is the failure to make a qualifying edit within the mandated period (when that period was then changed to make it impossible). Boing! said Zebedee (talk) 15:42, 27 July 2020 (UTC)

  The period was not changed to make it impossible for this user to regain tools. There is nothing in the rule preventing this user from applying to regain tools, and regaining tools, but the method of regaining is in the community's hands. Alanscottwalker (talk) 15:54, 27 July 2020 (UTC)

  What I meant (and I thought it was obvious, sorry) was that the period was changed to make it impossible for him to regain the tools without RfA and that he could do nothing to change that - and that is undeniably true. Boing! said Zebedee (talk) 16:05, 27 July 2020 (UTC)

  Of course, he could have done something to change it, as could have you. The primary rule of consensus since forever is show-up. Everyone was invited to find consensus, including he and you. Consensus is not something easily arrived at, nor is it a short process, it is open to all, and we don't discard policy except by explicit rule making because policy consensus is so hard to come by. Some individuals don't want the rules and decisions the community comes to, that happens all the time, and the only fair remedy is, be there, and change it, if you think it matters, just like everyone else who showed-up and put in the time. -- Alanscottwalker (talk) 21:20, 27 July 2020 (UTC)

  All the same, can we avoid using that word as it is a poor analogy? "Going inactive" is a fine phrase. isaacl (talk) 16:00, 27 July 2020 (UTC)

  Fair enough, though it wasn't the going inactive that was the key event. The key event was the one that didn't happen, of Jackmcbarn not making the edit that would have retained his ability to regain admin tools without RFA under the new rules (when the new rules made it instantly impossible for him to then do so). Boing! said Zebedee (talk) 16:15, 27 July 2020 (UTC)

  Your comment was regarding applying the version of the rules that existed earlier. Assuming for the sake of argument that this is agreed upon, then personally I think the reasonable version to consider is the one when the administrator became inactive. Thus if the rules changed subsequently from version A to versions B then C, creating milestones Mb and Mc, even while looking at the consequences of milestone Mc, I think version A should still be examined. isaacl (talk) 18:37, 27 July 2020 (UTC)

  That would be September 2017, the rules at the time were 3 years inactivity (including the desysop after 1 year of inactivity). Which would be this September. Hypothetically if that was applied, and crats had concerns, they wouldnt even be able to have a crat chat about it as that amendment was placed in the same time the inactivity was shortened. So it would be another Master Jay situation. And I feel pretty firm in saying that doing the same thing here AFTER the various RFCS would cause a bigger shitstorm. "We told you to amend the policy, but even though you have now done that, we are going to ignore it and do the same thing we had you amend the policy to prevent." Only in death does duty end (talk) 19:00, 27 July 2020 (UTC)

  It is the duty of those who wish to make a change to policy to dot the i's and cross the t's. I don't believe the change is effective on people who were told something else at the time of desysop, and were not later notified of the change. -- King of ♥ ♦ ♣ ♠ 19:05, 27 July 2020 (UTC)

  The policy was changed after a well attended RFC. 2 RFC's in fact. Closed appropriately and the policy change enacted. The time to complain about that was at the point it was done. If you think it should now be changed, I am going to echo the bureaucrats as they told the community repeatedly previously when the resysop procedures of some admins were questioned "This is not the place to change the policy". Only in death does duty end (talk) 19:08, 27 July 2020 (UTC)

  Unfortunately, the RfC did not discuss the terms under which it would go into effect. Therefore there is a legitimate dispute over whether it was intended to affect already desysopped users or only newly desysopped users. Repeating "this is what the policy currently says" doesn't change that fact. -- King of ♥ ♦ ♣ ♠ 19:42, 27 July 2020 (UTC)

  Then feel free to start an RFC or two to discuss those issues. I look forward to seeing the notification shortly. Only in death does duty end (talk) 20:27, 27 July 2020 (UTC)

  I actually might start an RfC to propose my 500/100 rule below; this will help retain admins who are a long-term net positive and weed out those who do the bare minimum to meet the technical requirements. -- King of ♥ ♦ ♣ ♠ 20:34, 27 July 2020 (UTC)

Arbitrary break 2

• I notice that almost everyone commenting here up to now is not a crat. Presumably most of the crats are reading, listening, and keeping their options open. (My own non-crat opinion: this kind of situation, where a user/sysop has been effectively a non-participant at Wikipedia since December 2016 [4] and shows up only when necessary to renew their tools, is exactly the kind of thing the RfC was intended to stop.) This discussion and research has been thoughtful and valuable, and has laid out the various issues and considerations clearly. But it's clear that this is eventually going to require a crat-only chat. At some point the crats, and they alone, are going to have to figure out what to do. More power to you, folks. That’s why you get the big bucks. 0;-D -- MelanieN (talk) 15:32, 27 July 2020 (UTC)

  Good point - might be worth some sectioning for the 'crat comments. Worm^TT(talk) 16:04, 27 July 2020 (UTC)

  However you all want to handle it. I know for RfA crat-chats you create a whole sub-article, so that you can talk among yourselves without us non-crats getting in the way. (We are the cheering section on the talk page.) -- MelanieN (talk) 19:00, 27 July 2020 (UTC)

  Completely agree. This is exactly the kind of situation that pisses off non-sysops. —valereee (talk) 16:46, 27 July 2020 (UTC)

• In most setups, new rules only apply to scenarios after they are enacted they don't apply ex post facto. I personally think it's an issue of basic fairness here. The OP followed the protocol they'd been told to follow in their desysop talk page message, and we did not at any time follow up that with another talk page message informing them that the rules had changed. They are a self-admitted lapsed editor who wants to become more active, so expecting that they would have read things in WP:CENT or anywhere else is also unreasonable. Realistically this user is not going to go crazy and do anything to harm the project, they've been vetted and proven as an admin-calibre individual in the past, and will probably do more good than the numerous admins who just write one sentence every year to keep their bit going. We'd do best to stop arguing, WP:AGF, and give them back the bit rather than some of the WP:Wikilawyering seen here IMHO.  — Amakuru (talk) 15:40, 27 July 2020 (UTC)

  Re: "we did not at any time follow up that with another talk page message informing them that the rules had changed". Again, even if we did, it would have been too late for him to do anything about it - unless a change was also made to allow some sort of grace period. Boing! said Zebedee (talk) 15:52, 27 July 2020 (UTC)

• Maybe in these cases we could put the request on hold for say six months to allow the person to show that, yes, I really am back and really do have need for the tools. That would be fair to them and would adhere to the spirit of the change, so would not be unfair to the RfC participants. —valereee (talk) 16:06, 27 July 2020 (UTC)

• Personally, I have no problem implementing this resysop request. I understand that there is some vocal dissent complaining about the consensus formed last year, but this was not a situation that was actively discussed in the RfC. As such, we don't have a strong consensus on what we should be doing here - instead we should be interpreting policy and general principles of fairness.
  From a policy standpoint, we should ask "why do we desysop inactive admins". There's a number of reasons from lack of knowledge of updated policy to inflation of numbers to only having adminship as a status symbol. All well and good, not major issues on a case by case basis, but a large issue for the wider good of the encyclopedia.
  From a "fairness" standpoint, we are volunteers and absence happens. If things change while absent that affect you, it is reasonable to understand that you would not be aware of that change, and from a fairness point of view, you should be able to expect either a "grandfathering" or a decent attempt at notification so that you can protest the change. Wikipedia has done grandfathering in the past - for example through usernames, we dropped that "@" symbol a few years ago, but those who already had @ symbols were allowed to keep them.
  I see no reason to think that Jackmcbarn would be abusing the tools, indeed by resysoping we may well have another admin to help out. Worm^TT(talk) 16:04, 27 July 2020 (UTC)

"Personally, I have no problem implementing this resysop request" - in the Master Jay discussion you refused to implement the policy-based and allowed resysop because you disagreed with it. Now you want to resysop despite the policy explicitly disallowing it. Tell me, what hoops would the non-admins in the community have to jump through in order to get you to actually do what the community written policy says you should when it comes to granting tools? Only in death does duty end (talk) 16:33, 27 July 2020 (UTC)

This is not policy but just my opinion: crats should have some discretion on what stays true to the intention of the desysop criteria. Any admin making token edits to retain sysop is, frankly, gaming the system - a point that was noted in that BN discussion too. It's blatant contempt for the community. Any admin making token edits over a long period of time to retain adminship should be desysopped, but it's near impossible to make a codified policy (which is also fair) to do this. Jack doesn't seem to be that; he has highly trusted permissions (like +2), has had great and broad contributions, and made no attempt to game the system to retain his adminship (although he could have, by making some token edits and one token administrative action every few years). There should be some respect for that. I don't think Jack is trying to game the system, if he says he's planning to return I have a feeling he's not lying. I don't feel like Jack's case is a textbook case of what the community wants to avoid, but this is. Anyway, this isn't the venue to decide that, I suppose. ProcrastinatingReader (talk) 21:23, 27 July 2020 (UTC)

• WTT, as was made very very clear in the RfC that preceded the RfC that made this rule, there's a perception among non-sysops of unfairness, and a deep divide between sysops and non-sysops on this question. Non-sysops made it very clear that the primary question is not just 'will this person abuse the tools?' —valereee (talk) 16:41, 27 July 2020 (UTC)

  WTT, I agree with valereee. I appreciate that you're trying to be fair to Jack. That's important - I think it speaks well of a community that attempts to do right by individuals and not just the majority. But I think it's important to look at this through the non-sysop point of view as well. People were told "Don't like the toolkit being returned to people? RFC is that way". So people went there. Participated in two RfCs. At the second RfC a specific statement passed reaffirming that non-sysops in particular view this as an actual problem that needs addressing. The idea of saying "sorry because not all edge cases were considered so the policy isn't implemented for this set of people" seems at odds with that consensus. Best, Barkeep49 (talk) 17:33, 27 July 2020 (UTC)

  I'll add my agreement to what has been said above by valereee and Barkeep. The purpose of these policies is to remove the tools from admins who have not been sufficiently active, and the present scenario fits that description. I don't think anyone is doubting Jackmcbarn's sincerity or good faith, but he simply hasn't met our requirements for activity. As a non-admin, my opinion is that there are already too many loopholes as it is without the addition of a grandfather clause that lacks community supports. LEPRICAVARK (talk) 18:11, 27 July 2020 (UTC)

• I could have sworn that someone brought up the case of existing inactive admins at the time and getting some vehement responses, but I can't find it now, and it's quite possible it was actually in one of the many other discussions regarding other, related matters. Regarding the general principle, I don't think we should over-interpret precedent. If some additional critical security-related restriction had been introduced, for example, I suspect the community would agree with retroactive enforcement. The community ought to take the opportunity now to decide how it wishes to handle interim cases. isaacl (talk) 16:12, 27 July 2020 (UTC)
• I agree with what Worm said (and also with the suggestion of there being some Crat space). I'd top it off by asking the user (not just this one, any caught like this) to make some kind of commitment that they will use the tools. Yes, it couldn't possibly be binding, but people do have principles and those who have passed RfA in the past have previously demonstrated they have the trust of the community. It would help. --Dweller (talk) Become old fashioned! 16:16, 27 July 2020 (UTC)

  @Dweller: Perhaps you are thinking of unilaterally doing so? I advise against it. remember the last time. ——Serial 16:26, 27 July 2020 (UTC)

  Wikipedia:Rouge bureaucrat is a redlink for good reasons. --Dweller (talk) Become old fashioned! 16:40, 27 July 2020 (UTC)

  Nothing wrong with bringing a little colour to the cheeks, Dweller  ;) ——Serial 16:51, 27 July 2020 (UTC)

  The era of unilateral grantings of resysop requests came to a close with Wikipedia:Requests for comment/2019 Resysop Criteria (2)#Statement 3 by Hasteur * Pppery * _{it has begun...} 16:32, 27 July 2020 (UTC)

  That passed me by; cheers, Peppery. ——Serial

  Dweller, the crat space should be considering whether it's credible that this person is actually "back". —valereee (talk) 16:56, 27 July 2020 (UTC)

  Valereee That's why I made a proposal for 500 edits and 100 admin actions below. I would repeal all of our current resysop requirements and replace them with the 500/100 requirement. The policy will go in effect immediately at the 4-year phase, and all current and former admins are notified so that they can get their activity up in the next year (and request the bits back on BN if they need to perform admin actions). -- King of ♥ ♦ ♣ ♠ 17:02, 27 July 2020 (UTC)

  King of Hearts, this isn't the place to relitigate or draft policy. Nihlus 17:03, 27 July 2020 (UTC)

  It matters to the present case, though. We could accept the current resysop request, and instead of a vague commitment by one user to become more active (whatever that means), put all admins under the same requirements, and give them a full year to comply with them. -- King of ♥ ♦ ♣ ♠ 17:07, 27 July 2020 (UTC)

  Crats don't have the power to impose new policy requirements on admins. Only a Community RfC can do that. Boing! said Zebedee (talk) 17:22, 27 July 2020 (UTC)

  Oh, of course I'm not suggesting crats making policy by fiat. However, if we do pass such a rule, then Jackmcbarn would be without a doubt eligible to request restoration under such a rule, and be in danger of losing his tools in 2021 if he doesn't actively return. -- King of ♥ ♦ ♣ ♠ 17:30, 27 July 2020 (UTC)

  King of Hearts, I'm actually not as concerned about whether admins are actually logging actions. There are many useful edits that require admin permissions but don't count as admin actions. I'm more concerned that they just aren't here in any meaningful way. My interpretation of the overwhelming feeling among non-admins wasn't that they were pissed about admins who didn't do enough adminny things but that these folks simply weren't even HERE. We resysopped a user with 1600 total global edits, only 30 of which were within the past ten years. That infuriated people. —valereee (talk) 17:24, 27 July 2020 (UTC)

  The counting methodology definitely needs to be refined (e.g. include main page edits). We would use some automated tool to determine the numbers, but if the requesting user is able to demonstrate use of the tool 100 times in the last 5 years by their own analysis, that will also be accepted. -- King of ♥ ♦ ♣ ♠ 17:30, 27 July 2020 (UTC)

• My understanding is that, barring a specified grandfathering, current policy prevails. Yes, this requires an inactive admin who may want to return in the future to keep an eye on WP:CENT for inactivity-related RFCs so as to not inadvertently became ineligible for tool restoration, but that falls right in line with the purpose of the inactivity policy - that is to say, inactive in terms of not editing typically goes hand-in-hand with not keeping up with policy changes. Therefore, if Person A became ineligible for tool restoration because Person A didn't see the RFC in progress that was about to render Person A immediately ineligible and perform the edits/action/etc that the RFC was going to require, then that was the kind of situation that the inactivity policy was specifically enacted for. However, with this train of thought, it effectively makes the inactivity policy into "you were inactive during the wrong week of the year and missed the RFC", which is unfortunate, but also kind of the point. In this particular scenario, I would go with current policy and not resysop. That being said, that train of thought doesn't really account for the spirit of the resysop policy, which is to get formerly-inactive admins to reengage. Either way, it's a decline to resysop from me. Useight (talk) 17:16, 27 July 2020 (UTC)

  If this user truly re-engages, they could probably RfA in six months. I would argue there's no harm to them. —valereee (talk) 17:27, 27 July 2020 (UTC)

  Agreed. Useight (talk) 17:34, 27 July 2020 (UTC)

• The role of bureaucrats is to act in clearly-defined situations in accordance with community consensus. Judging from the conversation here as well as the recent RfC, this is not one of those situations, and should therefore be referred back to the community – either through an RfA or by means of a new RfC. – bradv🍁 17:29, 27 July 2020 (UTC)

  Bradv, If the role of crats is only to "act in clearly-defined situations", why is there ever a crat chat? Boing! said Zebedee (talk) 17:44, 27 July 2020 (UTC)

• In light of the proliferation of numbers-based rules since the original "desysop if inactive for a year, but ask for them back anytime" policy, I don't really know what to make of this request. What I think would be a more reasonable solution, that perhaps would avoid the once- or twice-a-year BN spectacle, is a combination of (1) codifying broad, possibly qualitative, requirements for administrators with regards to community involvement, (2) a community deadmin process for purpose of defeating "gaming" of such requirements or otherwise capturing cases that are borderline, and (3) no resysops after inactivity.

  There seems to be enough appetite within the community to have some sort of activity requirements for sysops; however, trying to precise quantify who is sufficiently active runs into hard cases (which arguably drive changes to try to deal with them, and spawn more problems while solving earlier ones, i.e. I'm restating that hard cases make bad law). The distribution of work done among the sysop corps likely follows the Pareto principle. We have a *lot* of admins who got their tools in the 2004-2007 era, who generally tinker away on articles, and use tools on rare occasions (typically in a topic area they're interested in - for an example, peruse my last 50 protections, which are generally ice hockey or North Korea related because that's what happens to be on my watchlist). I would therefore argue there is a large proportion of admins who don't do an appreciable amount of admin-specific work; were they no longer admins, the change in workload would be insignificant. There is also a large amount of admins who are functionally inactive but still make enough edits in a years; for example, there's plenty of admins whose last 50 edits go back 5+ years.

  My gut feeling is that there is a fair amount of users who would prefer to see admins who are minimally involved, whether administratively or editing-wise in general, to no longer be admins. A strong counterargument could be that running a project-wide admin review may be a shitty way to treat volunteers, may look like a purge, and leave a bad taste in the mouths of many. Maxim_(talk) 17:37, 27 July 2020 (UTC)

• Looks like I'm very late to the party, but just to comment on the "proliferation of numbers based rules" I think, actually I know, that this is a result of it being so incredibly lax to begin with, and trying to push back against that. That's why I proposed the five-year rule, it seemed like such a very, very low requirement that I couldn't see why anyone would object, and yet it was by no means a slam-dunk unanimous consensus.

• I think Wikipedia rightly expects its administrators to actually do admin work and not just keep the tools out of habit or whatever. Beeblebrox (talk) 18:00, 27 July 2020 (UTC)

•  Bureaucrat note: I agree with the others who've stated that the policy doesn't currently allow resysopping in this case without a new RFA. ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 18:55, 27 July 2020 (UTC)
• Well this is what happens when you try to change the rules and move the goalposts every couple months/years. Wiki has basically brought this on itself. Changing the rules only brings about discontent and bickering (or "debate" depending on your mindset). Of course I'm from a day and age where a person's word was his/her bond; and that's kind of an obsolete concept these days. User:Jackmcbarn, regardless of the outcome here - I personally appreciate your being willing to help out around the place. Thank you. — Ched (talk) 19:08, 27 July 2020 (UTC)

  The community decided that admins must meet some very simple activity thresholds in order to retain the toolset. So when you say that Wiki has basically brought this on itself, I think most of us are completely fine with 'this'. I also appreciate Jack's willingness to help out, and there are plenty of ways in which he can do so as a regular editor. LEPRICAVARK (talk) 19:51, 27 July 2020 (UTC)

• I have to ask since there's a 'crat chat-like table above, is a crat chat required when community mandate already exists? If I may be completely frank, both WTT and WSC's points seems to be out of fairness and not based on policy - I believe for 'crats, performing their mandate comes first and assessing via discretion, second. This is just a question and anyone is free to correct me. --qedk (t 愛 c) 20:42, 27 July 2020 (UTC)

  Because the RfC made no mention of implementation details, it is unclear whether it is meant to apply to already desysopped users or only newly desysopped users. -- King of ♥ ♦ ♣ ♠ 20:49, 27 July 2020 (UTC)

  Where are we drawing that conclusion from? If the policy doesn't have grandfathering, it doesn't. --qedk (t 愛 c) 20:56, 27 July 2020 (UTC)

  Because to assume the former case requires assuming that those who supported the proposal would have supported instantly removing the ability of certain ex-admins to request restoration without a chance the correct the issue. Without this point have been discussed and explicitly approved, to later on say "the wording doesn't say anything about grandfathering" feels like fait accompli to me. (Note the bureaucrat activity RfC, where it is far from clear that those who supported the policy would have also supported having the policy take place ex post facto immediately.) To be clear, had I noticed the RfC I would have supported the change and supported a grace period of a month up to a year (with mandatory notification). -- King of ♥ ♦ ♣ ♠ 21:25, 27 July 2020 (UTC)

•  Bureaucrat note: From a personal perspective, I think that it would be best for returning former admins/crats to take some time to transition into the swing of things, read up on policy and guidelines, and get active in the community again to have their tools restored without a fuss, as a gesture of good faith on all fronts. You put in the effort to refresh on how things work today, and what the heartbeat of the community is, and the community trusts that you remain an able-minded individual capable of being a net positive. However, a crat is bound "only to grant administrator or bureaucrat access when doing so reflects the wishes of the community," and as much as I feel for Jackmcbarn, the consensus in this discussion seems to be that it would be best for you to abide by the standard process as it stands today. I concur with Useight and Nihonjoe about declining in this case.

That being said, Jackmcbarn, I'm really glad that you're coming back from a break that seems to have done you good, and if you need some of the specialized user rights like rollback or template editor (considering your history of technical work), you need only ask. One thing that really helped me coming back to speed after stasis was simply asking a few editors I trust who have been around what changes in procedure, policy, and community outlook you may want to look out for. bibliomaniac15 20:54, 27 July 2020 (UTC)

@Bibliomaniac15: Thanks, that's useful advice. I'll definitely be doing that. Jackmcbarn (talk) 20:48, 28 July 2020 (UTC)

• I experience fatigue coming to this website and it's not from the goalposts shifting — it's from the lack of people here (on Wikipedia) following through with policies and guidelines that consensus forms (from editing disputes, civility, resysopping etc). We basically select administrators based on their ability to be level-headed. Kaisershatner below, was level-headed and acted appropriately to being told no to a re-sysop. I hope they become active again and run for RFA, because I would vote for them. I also assume Jackmcbarn is level-headed as well and will do the same. It boils down to the same argument every time that formed the policy to begin with: the bar is extremely low to keep the tools and their RFA will surely pass if they actually stick around and do something. We need to stop going down these rabbit holes of discussions and actually be proactive
  • Inform those who are currently on the bubble who could potentially return with the same issue and tell them that the policy changed while they were inactive and that they may fall ineligible soon.
  • Inform those who did fall ineligible and tell them that they are, so this doesn't come up again in the future.
  • Future-proof the problem as well by sending a mass notification to every current administrator that policy is changed so if they didn't know, now they know.

  Doing small stuff like this when policies change will retain administrators (and editors) and encourage them coming back more frequently at the bare minimum. This discussion does the opposite. It's time to actually follow through with consensus, find loopholes, close them, and move on with our lives from talking about a large crowd of editors who aren't here anymore. Jack, welcome back, and I hope you stick around and are able to eventually get your tools. — Moe Epsilon 20:57, 27 July 2020 (UTC)

I'm aware this may be an extreme minority opinion, but I disagree and think we over-notify already. The original inactivity policy was put in place in June 2011. Before that it was automatic-for-life, no exceptions unless you resigned or were desysopped by arbcom. So, at that time it made perfect sense to notify those who prior to that could have expected to have it forever regardless. But that was nine years ago. Admins are expected to be familiar with policies governing their position, that's part of the job and the exact reason why we quiz them on policy at RFA. The inactivity policy has evolved over time, and I'm fairly certain each change has been noted in the monthly admin newsletter since it was begun some years back. If they aren't watching the policy, aren't subscribed to the admin newsletter, and haven't taken any administrative action in five years or more, they already aren't an admin. Coddling them with over-notifying them about a policy they are already expected to be aware of is not helpful, and in my opinion actually encourages gaming the system. (Not saying anyone currently discussed did so but there have been some rather obvious cases in the past, including an admin who simply replied to the notification with saying "guess I better make an edit then" on their own talk page and were therefore safe for another year, and an instance right after the five-year rule was passed wherein an admin who would have been subject to it and was otherwise totally inactive simply deleted a subpage in their own userspace and was therefore safe for another five years from that rule.) Beeblebrox (talk) 21:41, 27 July 2020 (UTC)

I agree with Beeblebrox. Part of an admin's role is to keep up to date with whatever policies and norms are in place in the project. If they haven't even kept up with the rules for retaining adminship, then that's (with apologies for the brusqueness) their problem. The problem with trying to make exceptions, or even with the suggestions for adding more numerical constraints, is that we're always going to have exceptions and will end up adding more constraints to the point of ridiculousness. Better to say "sorry, them be the rules" and move on. --RegentsPark (comment) 22:08, 27 July 2020 (UTC)

Which is why I support making the inactivity rules themselves tighter, rather than trying to entrap people with our currently arbitrary and easy-to-game rules. I think it is reasonable to expect admins to perform at least 500 actions in 5 years, of which at least 100 require adminship. Yes, they can game that, but the chances of a slip-up are high. Make one action that shows you are fundamentally unqualified to be admin and you'll be shown the door. So I don't mind people keeping their bits with the minimal amount of activity if it actually demonstrates that they still are up to date on our policies, though of course the intent would be to encourage them to be even more active than that. And if we implement this, I support perpetually notifying admins who are in danger of losing their bit. -- King of ♥ ♦ ♣ ♠ 21:51, 27 July 2020 (UTC)

There's always going to be this kind of conversation if it gets to a certain point. Let's say 500/100 was the policy right now. 2025 rolls around and Administrator A is on the chopping block because he performed 475 actions, 98 admin actions. Then the conversation turns into "well, we have a large enough body of work to base it off of", "what is the extra few edits/actions but a few tokens to check a box", and "this is what bureaucrat discretion is for!" 'Special' cases will happen; It has happened with every rendition of the inactivity policy that has happened so far. Back in 2011 I wanted there to be a higher entry barrier, but in nine years no consensus has changed. If that doesn't change, and no one wants to notify administrators properly to confirm they know, then we'll just end up here talking about it.. again. — Moe Epsilon 22:40, 27 July 2020 (UTC)

This is the paradox of the heap: no matter where you draw the line, in the end you will have results that fall on either side of the boundary despite not being significantly different. But we have these kinds of rules at WP:FPC (i.e. an image is promoted if there are at least 2 supports for each oppose), and everyone accepts it as fair. Again, the most important bit is communication. Any change can be fair game if we make every attempt to inform current and former admins of it. Either someone is gaming the system and they won't mind making a few extra edits to clearly get over the threshold, or they aren't paying attention and we won't have too many cases of people who just happen to be below it. -- King of ♥ ♦ ♣ ♠ 00:45, 28 July 2020 (UTC)

Arbitrary break 3

• I took the bait and posted an RfC at the policy village pump. —pythoncoder (talk | contribs) 22:02, 27 July 2020 (UTC)
• For what it’s worth, if anyone wants the history here: the current changes were a part of a two part RfC seeking to show (at least on my end as proposer) that the community as a whole wanted a more stringent resysop process. It was created specifically in response to a similar thread (See: wikipedia:Bureaucrats'_noticeboard/Archive_41#Resysop_request_(Yelyos).) If you read that thread and the first RfC, you’ll see the mood at the time amongst supporters was that this was a broken process that needed to be fixed. If the fix requires a fix for crats to implement it, it seems like we wasted four months a year ago. Like I said, I get the fairness argument from an empathy perspective, but the history here is pretty clear that the community was trying to prevent situations like this. TonyBallioni (talk) 22:51, 27 July 2020 (UTC)

  but the history here is pretty clear that the community was trying to prevent situations like this Isn't a key difference here that both that request, and Jay's BN basically '07 sysops with only token edits since? Jack was confirmed after RfA got harder, and he has no token edits in his history. He easily could've retained admin if he wanted. It does seem unfair that this application treats admins who game the requirements better than admins who are honest, and don't. Sends the wrong message imo. That we say Jack doesn't qualify anymore, but this and this is OK means something is broken imo. ProcrastinatingReader (talk) 23:22, 27 July 2020 (UTC)

  Speaking only for myself, I wasn’t aware when either Yelyos or Master Jay passed RfA, and I personally don’t really consider it relevant. I’m not big on criticizing people who passed in the easy days. My position is that someone should be connected to the community in order to serve it. TonyBallioni (talk) 23:33, 27 July 2020 (UTC)

  I do agree with Procrastinating that passing RfA in 2014 means he has undergone a much more rigorous community vetting than the likes of Master Jay and Yelyos and is very unlikely to do the project any harm if he is resysopped.P-K3 (talk) 23:37, 27 July 2020 (UTC

  The rules are for sure not perfect. It's still laughably easy to hang on to the bits indefinitely by just showing up once a year for a few minutes. But as of right now, those are the rules, and it wouldn't be fair to start carving out exemptions in either direction. Beeblebrox (talk) 00:07, 28 July 2020 (UTC)

  The rules are laughable either way. It is super easy to game them, but we're then super strict with the people who forget to do so. The real problem is that RfA sucks and is quite hard these days. That is what makes restoration on request seem unfair to many non-admins, and what makes non-restoration on request seem like a punishment to many former or not very active admins. We should really work on being more friendly to potential admins instead of being more unfriendly to former admins who want to return. —Kusma (t·c) 16:31, 28 July 2020 (UTC)

  BTW I agree that the rules don't allow a restoration here. —Kusma (t·c) 16:32, 28 July 2020 (UTC)

• After a long period of inactivity, why rush to request resysoping so soon? Wouldn't it have been better to familiarise yourself with all the policy changes that have occurred in the last 3 years. Maybe you may have even noticed that the resysoping policy had changed and then not even both asking as doing so is showing that you are no longer familiar with the current policies. -- WOSlinker (talk) 23:29, 27 July 2020 (UTC))

•  Bureaucrat note: Jackmcbarn, Evenly divided at the time of writing, it doesn't look like there is a consensus among the opining bureaucrats to restore the userrights at this time - this might change if the RfC linked in this subsection instates a grandfather clause, or significantly more bureaucrats opine in favour of the request. We could add some of the included userrights for now, and it seems that you will have decent support at a potential fresh RfA some time in the future. I'd like to extend my thanks for your offer of service. –xeno^talk 12:36, 28 July 2020 (UTC)

  That RfC appears to be snowing opposition for making special grandfather clauses. — xaosflux ^Talk 20:11, 28 July 2020 (UTC)

•  Not done. While there have been a number of other crat (and non-crat) opinions provided here, I was mainy waiting for a response from Jack so to ensure they were at least aware of this discussion and all it entails. The primary concern here was "which set of rules to use" when evaluating his eligibility for a re-sysop. It was not explicitly discussed in the original RFC, but there were reasonable arguments made on both sides as to whether it was reasonable to "look the other way" so to speak. However, with the latest RFC (which is specifically on grandfathering) nearly holding unanimous opposition at this point, it is clear that the community feels that grandfathering is not on the table (despite my personal opinion being that there is no gaming and Jack should be eligible for the mop). That being said, for someone as active as he is (or at least, was) I see little issue with him passing RFA if and when he chooses to do so. Hopefully the discussion below will result in this sort of situation being avoided for any former admins returning from inactivity in the nex few months. Primefac (talk) 00:19, 29 July 2020 (UTC)

While looking at Wikipedia:List of administrators/Inactive, I came across Thunderboltz (talk · contribs · deleted contribs · logs · filter log · block user · block log), who abruptly stopped editing back in March of 2018 looking at their contribs. Since the admin has been inactive for two years, should they be desysoped? Goose^(Talk!) 22:37, 14 August 2020 (UTC)

They deleted something in April. TonyBallioni (talk) 22:41, 14 August 2020 (UTC)

also, someone else brought this same admin up a few weeks ago. It isn't necessary for people to go hunting for inactive admins, there's either a monthly process (or a bot, can't recall which) for that. --Floquenbeam (talk) 22:43, 14 August 2020 (UTC)

Correct, a bot tends to the pages at Wikipedia:Inactive administrators/2020. Another 'gotcha' people should avoid is the fact that 'thanks' count as activity but do not show up in the default user logs view. –xeno^talk 23:31, 14 August 2020 (UTC)

Xeno are you sure about the thanks bit? I'm reading Wikipedia:Administrators#Procedural removal for inactive administrators and "Administrators who have made neither edits nor administrative actions for at least 12 months may be desysopped." THB I'm not sure how to check the thanks log, and I'm not sure people will be too happy if we were to keep someone as an admin simply for thanking people. ϢereSpielChequers 14:45, 15 August 2020 (UTC)

WereSpielChequers, to find the thanks log, click the User logs link from a page in anyone's userspace, which will take you to Special:Log. Enter their name and use the pull-down menu or check box to select the thanks log. Thunderboltz hasn't used the thank function (scroll down to the Actions section), so it isn't a question in this case. BlackcurrantTea (talk) 15:18, 15 August 2020 (UTC)

I don't think "thanks" counts (or should count) as an administrative action. --qedk (t 愛 c) 18:57, 15 August 2020 (UTC)

@QEDK: it doesn't count as an action for the five year rule, it does count as an action for general inactivity (just as a single white space character edit to a personal sandbox does, or a patrol action, or any other action). — xaosflux ^Talk 20:04, 15 August 2020 (UTC)

@Xaosflux: Hmm, I don't see why there's a distinction, if the intention was to have logs count, it should say logs, not "administrative actions". I would've thought that administrative actions means any administrative action (even a sanction or something that isn't logged by the system). --qedk (t 愛 c) 08:23, 16 August 2020 (UTC)

WereSpielChequers Hmm, the original language said "completely inactive", someone may have inadvertently changed the meaning. –xeno^talk 00:56, 16 August 2020 (UTC)

@Xeno: notably, both version did refer to "administrative actions" - but did not define these as either actions only available to members of the administrators group, or just actions that don't result in a page revision. (e.g. "move" produces an edit, but "patrol" does not - it is purely "administrative" as in a function of administering the encyclopedia, not of being an administrator.) I don't think we've ever had to make an inactivity decision purely on something like a patrol log or thanks log (we HAVE had to for a deleted edit being the only activity though). — xaosflux ^Talk 02:08, 16 August 2020 (UTC)

xaosflux: I remember one case similar to this thread where we (you, I think) pointed out the 'thanks' in the past year. Do you remember that one? –xeno^talk 13:19, 16 August 2020 (UTC)

@Xeno: I can't find it right now, I can't recall that being an action that hinged the decision - maybe was just related discussion such as this one. — xaosflux ^Talk 14:56, 16 August 2020 (UTC)

As a note, Thunderboltz also has some deleted contributions from 2019. Mackensen (talk) 14:55, 15 August 2020 (UTC)

Any oversighted edits? Would they count? Thincat (talk) 16:32, 15 August 2020 (UTC)

They are/were not an oversighter ([5]). 2A02:C7F:BE17:2D00:B8CB:2C8B:6942:A184 (talk) 16:42, 15 August 2020 (UTC)

Ignoring the current case, as I am not an oversighter and only an oversighter would know if someone had oversighted edits; If the only edits someone has done recently have had to be oversighted, I think it reasonable for the crats to ignore them, or at least not check for them when deciding whether to desysop or not. And I say that knowing that some of my own edits are likely to have been oversighted, especially if I have blanked or revision deleted something and then reported it to oversight. ϢereSpielChequers 18:54, 15 August 2020 (UTC)

I would say if somenody's all recent edits have been oversighted, this is a really odd editing pattern.--Ymblanter (talk) 19:28, 15 August 2020 (UTC)

It really depends, though. Sometimes edits are oversighted as a sort of "collateral damage", especially when it comes to frequently edited pages such as AN. That said, unless an entire page has been suppressed, oversighted edits still show up if you look at an editor's contributions. Salvio 20:58, 15 August 2020 (UTC)

Thunderboltz' last edit was on 2019-04-24. There is really nothing else to do here. — xaosflux ^Talk 20:06, 15 August 2020 (UTC)

@Xaosflux: are you saying the administrative action shouldn't count? I thought the policy explicitly includes them. Cheers  — Amakuru (talk) 07:53, 16 August 2020 (UTC)

I think Xaos is saying that since there's an edit, the discussion is moot. --qedk (t 愛 c) 08:23, 16 August 2020 (UTC)

This. I'm mostly in favor of removing trivial activity from counting - but the community has repeatedly not reached a consensus to require more than a token action to maintain sysop access; my read of the current status is that anything that produces a local log or revision "counts" for purpose of access removal for inactivity. — xaosflux ^Talk 14:52, 16 August 2020 (UTC)

Some spam showed up on the Wikipedia for Interlingue (Occidental) today (a page all in French, and upon trying to delete it I noticed that the delete button had disappeared and the sysop privileges along with them. The List of administrators for the Wikipedia now shows no sysops, which means that the other person (Caro de Segeda) has lost them as well. Since we don't have any controversy on our fairly small Wikipedia I can only assume this is a system error - is there any way to rectify it? Without these privileges we have no sysops left for Interlingue/Occidental. Thanks, Mithridates (talk) 05:35, 23 November 2020 (UTC)

@Mithridates: you were granted sysop rights for three months, and those expired. Enwiki 'crats can't do anything outside enwiki, you'll have to ask at m:SRP. Majavah (talk!) 05:53, 23 November 2020 (UTC)

@User:Majavah: Ah, that explains it, thank you. I actually only heard about the rights being granted by Caro de Segeda and never saw that they were originally given for three months. Mithridates (talk) 05:57, 23 November 2020 (UTC)

Please remove sysop for now. Thanks, Guy (help! - typo?) 09:00, 26 November 2020 (UTC)

JzG, I've done that for you Worm^TT(talk) 09:40, 26 November 2020 (UTC)

Readers will note I made no mention of a cloud in my response. I was providing a link to a current discussion that may have impacted this desysop request. Interested parties can now easily go check this discussion in the event of a resysop request and judge for themselves if there are any clouds without having to dig through page histories using old dates as guidance. I thought it was an involved action, others disagreed, but it will be for bureaucrats to decide in the future. There’s no need to shut this discussion down. Mr Ernie (talk) 21:44, 27 November 2020 (UTC)

Yes, there is, because this happens every time an even remotely controversial resignation happens. Primefac (talk) 21:45, 27 November 2020 (UTC)

Potentially controversial resignations need to be looked at. Especially if one admin makes a habit of it. Are you able to quickly check the events behind JzG’s last desysop request? It’s actually kind of hard to find. Mr Ernie (talk) 21:50, 27 November 2020 (UTC)

Wikipedia:Under a cloud#When and how a determination is made --AntiCompositeNumber (talk) 21:57, 27 November 2020 (UTC)

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

I just got a warning email for next month and I can't figure out why I would be eligible for next month? I've made edits over the past year and performed administrative actions. Is the bot being overly broad? --Cyde Weys 14:41, 1 January 2021 (UTC)

Cyde, I think it's for Cydebot which has not operated since 12 January 2020. Maxim_(talk) 15:04, 1 January 2021 (UTC)

Followed up on user talk. — xaosflux ^Talk 23:39, 1 January 2021 (UTC)

(bot operator) The email was for Cydebot. — JJMC89 (T·C) 07:44, 2 January 2021 (UTC)

Cyde is Cydebot's inactivity permanent? --Dweller (talk) Become old fashioned! 18:54, 2 January 2021 (UTC)

Ahhh yes that makes more sense then. Feel free to remove Cydebot's admin access; I don't have any immediate plans to resume using it and I can't imagine it'll be controversial to ask again for the admin access to resume the previously approved tasks, should I ever decide to. --Cyde Weys 21:09, 3 January 2021 (UTC)

 DoneDone. Please pass on the community's thanks to your bot. ϢereSpielChequers 22:39, 3 January 2021 (UTC)

That'll do, Bot. That'll do.--WaltCip-(talk) 13:42, 4 January 2021 (UTC)