Wikipedia:Bureaucrats' noticeboard

To contact bureaucrats to alert them of an urgent issue, please post below.
For sensitive matters, you may contact an individual bureaucrat directly by e-mail.

You may use this tool to locate recently active bureaucrats.

Click here to add a new section

The Bureaucrats' noticeboard is a place where items related to the Bureaucrats can be discussed and coordinated. Any user is welcome to leave a message or join the discussion here. Please start a new section for each topic.

This is not a forum for grievances. It is a specific noticeboard addressing Bureaucrat-related issues. If you want to know more about an action by a particular bureaucrat, you should first raise the matter with them on their talk page. Please stay on topic, remain civil, and remember to assume good faith. Take extraneous comments or threads to relevant talk pages.

If you are here to report that an RFA or an RFB is "overdue" or "expired", please wait at least 12 hours from the scheduled end time before making a post here about it. There are a fair number of active bureaucrats; and an eye is being kept on the time remaining on these discussions. Thank you for your patience.

To request that your administrator status be removed, initiate a new section below.

Crat tasks
RfAs	1
RfBs	0
Overdue RfBs	0
Overdue RfAs	0
BRFAs	10
Approved BRFAs	0

Requests for adminship and bureaucratship update

RfA candidate	S	O	N	S %	Status	Ending (UTC)	Time left	Dups?	Report
Graham87	117	133	9	47	Open	10:11, 24 November 2024	4 days, 6 hours	no	report

It is 03:23:58 on November 20, 2024, according to the server's time and date.

Resysop request (Euryalus)

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.

---

Moved from WT:BN

Euryalus (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'd like to request a return of admin tools, which were voluntarily resigned here. -- Euryalus (talk) 14:11, 26 July 2020 (UTC)

Excited to see this. TonyBallioni (talk) 14:42, 26 July 2020 (UTC)

Looks good by the numbers, standard hold is of course in place. Primefac (talk) 17:01, 26 July 2020 (UTC)

 Done Useight (talk) 15:54, 27 July 2020 (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.

Resysop request (Jackmcbarn)

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.

---

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.

longish metaphor from my real life

To make an imperfect comparison: in 2016 I became a volunteer voter registrar. (I can't think of what it was that suddenly made me think more people needed to vote in 2016... it was something... what was it?) Anyhoo, I would show up at various events and either work the crowd or have a booth with all my clipboards and forms neatly arrayed, and a big sign that said "Register to Vote" here. I wound up getting like 1,000 comments along the lines of "thanks so much for doing this, it needs to be done, but I'm already registered" and after several events had only managed to register like three people. I concluded that the problem was not so much registration as apathy and election fatigue, and stopped doing it. Like eight months later I was informed by the state that my registrar status had been revoked for lack of new registrations. I didn't actually know that was a rule, but it seemed reasonable enough to me, I wasn't doing it, I wasn't making any real difference with it, and it was only a volunteer position.

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

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.

Resysop request (Kaisershatner)

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.

---

Kaisershatner (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)}

Hello colleagues,

Respectfully requesting restoration of my privs, removed due to inactivity. I have lapsed, not departed. Thank you for your consideration.

Sincerely,

Kaisershatner (talk) 15:33, 27 July 2020 (UTC)

You appear to be ineligible for restoration of adminship since you have made no admin actions since 2013. * Pppery * _{it has begun...} 15:35, 27 July 2020 (UTC)

• Desysoped on 2020-04-01 due to inactivity; Last admin activity was in March 2013; appears to not meet the five year rule. @Kaisershatner: have you reviewed the admin policy on restorations - and if so, do you think you have satisfied the conditions? If not, you may still of course re-request adminship using the standard process. — xaosflux ^Talk 15:37, 27 July 2020 (UTC)

I see - thanks for your consideration.

Cheers,

Kaisershatner (talk) 15:50, 27 July 2020 (UTC)  Request withdrawn

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.

Inactivity messages

Discussion split from the withdrawn resysop request for Kaisershatner. Primefac (talk) 23:21, 27 July 2020 (UTC)

Reading the inactivity messages Kaisershatner was sent, this seems like very poor communication. The most recent messages on his usertalk didn't mention three year inactivity, and the old one that did (waaay back in 2015) implied any activity was sufficient:

"If you wish to have these permissions reinstated should this occur, please post to the Wikipedia:Bureaucrats' noticeboard and the userright will be restored per the re-sysopping process (i.e. as long as the attending bureaucrats are reasonably satisfied that your account has not been compromised, that your inactivity did not have the effect of evading scrutiny of any actions which might have led to sanctions, and that you have not been inactive for a three-year period of time). If you remain inactive for a three-year period of time, including the present year you have been inactive, you will need to request reinstatement at WP:RFA."

This is really poor stuff, Wikipedia. --Dweller (talk) Become old fashioned! 16:11, 27 July 2020 (UTC)

@Dweller: the most recent messages are at User_talk:Kaisershatner#Pending_suspension_of_administrative_permissions_due_to_inactivity. We normally use a standard message for these notices and subsequent removal, from Template:Inactive admin - which links to the current policy. Improvements to that template are always welcome. — xaosflux ^Talk 16:21, 27 July 2020 (UTC)

IMO this is perhaps a policy that should be revisited. Basically, certain users are immediately ineligible for resysop at the time of desysop. To avoid edge cases where a single edit or admin action makes the difference (feels a lot like WP:LAWYER to me), we should instead make the requirements something like 500 edits and 100 admin actions in the last 5 years. If you fail to reach either threshold in 4 years, you get a warning to increase your activity in the next year. -- King of ♥ ♦ ♣ ♠ 16:41, 27 July 2020 (UTC)

@King of Hearts: changes to the inactivity policy have been quite contentious, but feel free to start a discussion at WT:ADMIN. — xaosflux ^Talk 16:43, 27 July 2020 (UTC)

One benefit of this is that it is very difficult to game. Currently, an admin can avoid desysopping entirely by making one token edit every 11 months. Under my system, let's say an admin is mostly inactive for 4 years, and they get the warning. If their understanding of policy is no longer in touch with the community, they will likely make plenty of mistakes in their 100 requisite actions, and that alone would be grounds for desysopping for cause. If an admin manages to show up once every 5 years to marathon 100 actions and actually gets them right, I really wouldn't mind them staying on as admin. -- King of ♥ ♦ ♣ ♠ 16:53, 27 July 2020 (UTC)

Xaosflux, I saw the most recent messages, thanks. I'm not sure why we dropped the mention of the three year stipulation at some point since 2015, but it was a poor decision. The whole point of these messages is to encourage admins to return to adminning, not to play "Gotcha". It [well, a more accurate version] should be reinstated immediately.

There is a wider problem. That you'll be dropping warnings on people's talk pages that they cannot actually respond to as the three year period they previously were wrongly informed about, and then not informed about, has now expired. That's a policy problem. But the problems stem from the same place: lack of focus on what should be the prime aim, which is getting admins to edit again. --Dweller (talk) Become old fashioned! 16:44, 27 July 2020 (UTC)

@Dweller: UninvitedCompany updated that in 2018 with the rewording that was encouraging inactive admins to "to rejoin the project in earnest". — xaosflux ^Talk 16:51, 27 July 2020 (UTC)

Regarding the warning notes, if during the time we send at least 2 talk messages and 2 emails (unless they disable email) the inactive admin does any edit or action, the clock resets for at least a year already. — xaosflux ^Talk 16:53, 27 July 2020 (UTC)

Dweller, you do not need sysop tools to edit. Nihlus 16:55, 27 July 2020 (UTC)

• People are getting upset on behalf of the OP, but I note they seem to have graciously accepted that the rules changed while they were taking an extremely prolonged break from doing admin work and barely participating in the project at all. Beeblebrox (talk) 20:42, 27 July 2020 (UTC)

  Indeed; I've split this discussion from that to keep them separate. Primefac (talk) 23:21, 27 July 2020 (UTC)

The rationale behind removing the specifics of the resysop criteria and replacing them with a link was as follows:

• The criteria had become complex enough that no short summary would be accurate in all situations, and including the text would give undue weight to the mechanical aspects of re-sysopping
• The criteria are subject to change. Including the specifics in the talk page note created a perceived obligation for the project to restore adminship under the terms of the re-sysopping rules in place at the time adminship was lost due to inactivity.
• The focus, then as now, should be on encouraging people to re-engage with the project or stay engaged with the project, rather than make token edits. There are extensive examples of admins making token edits and token administrative actions, when facing the end of the inactivity window, and only a tiny handful of people who have left the project then genuinely rejoined.

I have in the past made a concerted effort to get former contributors to re-engage and sent out over a dozen individually written emails and talk page messages. Of these, I received one reply, from a person who opted to voluntarily resign rather than lose adminship for inactivity, and was ignored in all other cases, even though in some cases the editor in question returned long enough to make a token edit. I have concluded that it simply isn't realistic to try to get people to rejoin. People go through life changes, they graduate, they get jobs, they have kids, whatever the case may be -- and move on to other interests. UninvitedCompany 15:57, 29 July 2020 (UTC)

• I've tried following up with admins that come off of the monthly Wikipedia:Inactive administrators list, welcoming them back - but when it is one that is just here to make their annual token edit my messages were ignored so I gave up. — xaosflux ^Talk 17:12, 29 July 2020 (UTC)

• I'm of the view that inactivity messages or policy changes don't need to be to delivered at all. As a courtesy, I don't mind definitely - but old or inaccurate information (if any) being sent should have no bearing on the actual outcome, as the onus is on the administrator and not whoever is sending out the communication to remain aware of policy. --qedk (t 愛 c) 17:25, 29 July 2020 (UTC)

Uh, I think QEDK nails it here. With the best will in the world—and notwithstanding, or criticizing, the appeal to retain old hands—it's not, wasn't, and can never be our responsibility to make editors active; stop them being inactive, or ensure that they retain institutional knowledge when they change from one status to the other. It's theirs. Our courtesy note is just that—a courtesy—but if it's become, basically, an advisory note on how to retain the tools without practical reengagement then I don't really see what good is being done by it.

I suspect that the effort that goes into attempting to retain legacy admins might be better spent on recruitment. With minimal exceptions, I can assure you that anyone who successfully goes through the mincing machine nowadays does not just become an admin: they become an active one. If it's about where to devote our resources (that is, or personal energies), I think the latter, rather than the former, provide more bang for our metaphorical buck.

Our efforts should go into recruiting new admins; old admins should look to themselves. ——Serial 17:45, 29 July 2020 (UTC)

Like +1 PackMecEng (talk) 17:50, 29 July 2020 (UTC)

I think you're only partly right here Serial. I think one of the best pools of new editors we have is re-engaging people who had edited productively in the past. That's because the pool of people who are mission aligned and competent (or have the ability to be competent) is not huge to begin with. Looking at the results of edit-a-thons it's not hard to get people to make an edit or two but the longterm benefits from there seem unclear to me from the data I've seen. So I agree we shouldn't be attempting to retain legacy admins. But I do think we should expend effort to get legacy admins (and other previously active and productive but now dormant editors) to re-engage and setting up supports (and welcomes!) when they do. Best, Barkeep49 (talk) 17:54, 29 July 2020 (UTC)

Almost every current and former admin has been an active admin at some point, and some of our oldest admins, those from about fifteen years ago, include some of our youngest admins in real life. In forty years time I will be long gone, but some of our admins who were adolescents fifteen years ago will be pensioners with time on their hands. Of course we need to engage newbies and I would like to see lots of people who joined in the modern era run RFAs, ignoring bots, we currently have 9 admins who first created their accounts in 2017 or 2018, none from the class of 2016, and I'm sure there are plenty from that era who would pass RFA if they ran. But longterm retention of volunteers is part of how most real life voluntary organisations succeed. If Wikipedia is going to be around for the longterm we need to keep an open door both for returning oldtimers and for complete newbies, especially those young enough to take breaks for relationships, qualifications, careers and kids. ϢereSpielChequers 19:05, 29 July 2020 (UTC)

I think it is clear we have already engaged whomever we could engage, except for a (pretty little) influx of young people who several years ago just could not be editing. Yes, sure, we can have get somebody from underrepresented groups here and there, may be, but we are nmot in 2007 when it was not uncommon to find somebody who has never heard about Wipkipedia. We will not engage new people without some structural changes. And without engaging new editors we are not going to have new admins.--Ymblanter (talk) 19:58, 29 July 2020 (UTC)

@QEDK: The inactivity messages are required by policy. There was a consensus at the time the inactivity policy was adopted that it would be petty to remove adminship without sufficient notification. The goal was to give the editor in question an opportunity to remain an administrator by making some edits. Attempts to change this and other aspects of the policy have been contentious. UninvitedCompany 22:08, 29 July 2020 (UTC)

@UninvitedCompany: Yes, I'm aware of the policy, I was simply stating my perspective. Also, as far as I'm aware, the removal notifications sent now are only for procedural removals and as such are only to notify inactive admins of the same - there is no imposition to inform about 3-year inactivity (but we do include that in good faith) and ask them to contribute if they wish to retain the rights. I really don't think that as long as notices are sent out at all, that the onus can be on the person delivering the notice, seems like too much responsibility for good-faith courtesy. --qedk (t 愛 c) 09:58, 30 July 2020 (UTC)

FWIW, these are mostly delivered by a bot, using a template - so if we want to have the notices include something new please put it in to Template:Inactive admin. — xaosflux ^Talk 11:47, 30 July 2020 (UTC)

On Gaming Admins, Crats, and Dispute Resolution

There has been some talk on this page of Gaming Admins (I take it something like, a small number who annually make a few edits once a year, maybe there are other scenarios). There has also been talk of the Crats notice, and for some commentators, it has been claimed that the Crats notice raises a kind of shield for the missing/inactive (something like, 'do the minimum and your golden, nothing can touch you' or 'we are making a promise to you'). I take it, the last para of RESYSOP was added in the most recent major overhaul, to try get Crats to address some of the Gaming Admins issue in some cases.

Tying these threads together: Is there anything, right now preventing WP:Dispute Resolution: going to the talk page of the admin (who may or may not at some point have gotten a Crats notice) who is suspected of gaming, asking pertinent questions, seeing if the discussion is compliant with AdminACT, etc. expectations, and running it as far as it may need to go, including Arbcom? If this is feasible, wouldn't this be a better way to proceed then try to do another major overhaul of policy, or is there some policy/practice change that is needed to make such DR feasible? -- Alanscottwalker (talk) 10:07, 28 July 2020 (UTC)

• To be honest, I'm not sure that they'd need to do much more than point to WP:VOL at this point. On the assumption they didn't wildly confess of course :) ——Serial 10:44, 28 July 2020 (UTC)

  Perhaps but if people are going around resenting 'gamers', and tying the project up in long discussions because of 'gamers', some might expect good faith admins to take seriously the issues and be thoughtful and open about it, rather than respond, 'you can't touch me' -- and gaming, if true, is a serous lapse that needs some resolution. At any rate, someone who is concerned has to try to address it directly, or we just have to stop talking about it, and redoing policy and redoing policy. Maybe the thing is to open the discussion with the admin and see where it goes, and whatever policy issues or changes to policy issues will become clearer. -- Alanscottwalker (talk) 11:12, 28 July 2020 (UTC)

I don't say you're wrong, ASW, not at all—just that, every time a policy change is proposed wrt to inactive admins it's like pulling teeth to achieve anything; I guess this would probably go the same/a similar way. ——Serial 12:49, 28 July 2020 (UTC)

The policy sounds fine, and the least of the problems regarding admins. And I wouldn't assign a negative word like "gaming" to an inactive admin just doing what is logical...the minimum to keep the tools. Probably the most whacky thing is the notices you are giving inactive admins reminding and encouraging them to "game". Only the most detached and inactive admins need a notice like that so you are working against a policy that seems well designed to let those folks self-select out. Sincerely, North8000 (talk) 13:12, 28 July 2020 (UTC)

Once again, I ask what the underlying problem is that we are trying to address. I think that the principle should always be encouraging people to return to activity and any steps we take that could be part of that should be encouraged, not decried. --Dweller (talk) Become old fashioned! 14:59, 28 July 2020 (UTC)

What don't you get about intro laying out the problem? There are people going around talking about admins who are, in the telling, in serious 'bad faith;' and there have been efforts to rejigger policy. That is clearly damaging to admins, to crats and the project, who look completely untrustworthy (as as group) or boobs for trusting people others don't trust.

(As for encouraging return (which seems largely off-topic in this section - we are discussing the terms of return, and every Crat should already know there are terms of return and Admin standards, whether they approve or not) fine, but the idea that any Crat would reject the terms of return for the community's administrators, is in total breach of Crats good-faith and abusive by Crats.) Alanscottwalker (talk) 15:22, 28 July 2020 (UTC)

Ultimately, except for the minority who would have supported intentionally not notifying people in November 2019, we messed up as a community. In the end we have to choose between two unpalatable alternatives, betraying the trust of the RfC !voters or betraying the trust of ex-admins to whom we had promised would receive the tools back on request under certain conditions. There is a legitimate debate over which option is less bad, but don't pretend that there is no debate to be had. -- King of ♥ ♦ ♣ ♠ 15:42, 28 July 2020 (UTC)

I'm sorry but, there is another section on this page and at VPP to debate that. This section is about the future of handling this.

(As for the community messing up -- I think that is wrong on several levels, and the attempt to somehow blame people who put in the work and the time to achieve a consensus the project asked them to achieve on behalf of the community is the farthest thing from encouraging people to continue to participate). Alanscottwalker (talk) 15:54, 28 July 2020 (UTC)

I believe that in the future, we should change the inactivity policy so that we no longer desysop admins with a conditional promise to return the tools upon request. Under my 500/100 rule proposed above, a desysopped admin would be ineligible to ask for the tools back starting day one. If a system without conditional resysop had been in place at the time of the November 2019 RfC, and people agreed to shorten the inactivity threshold from three to two years, there's no way the RfC would have concluded without considering the fate of the admins who would fall out of compliance. (Do we desysop them immediately? Give them a grace period? etc.) -- King of ♥ ♦ ♣ ♠ 16:56, 28 July 2020 (UTC)

Fine. It's evident that there are many 'good ideas' for the pedia from many people, all the time -- but the rubber hits the road in the hard work of making consensus.

When one thinks about the number of people needed to be involved over many months (sometimes years) from different Engvars and life experiences (who necessarily fret over commas, clauses, small picture and big picture), policy making consensus to adopt even a single sentence that is just-so, is a bit of a minor miracle. Alanscottwalker (talk) 19:29, 29 July 2020 (UTC)

King of Hearts, I will point out again that the claim we did not notify people isn’t accurate. This was included in the admins newsletter, which has been the standard way to notify people of changes to WP:ADMIN for going on three years. That the community has a standardized distribution list for these changes instead of relying on a special one anytime there’s a change isn’t a bad thing. TonyBallioni (talk) 20:54, 28 July 2020 (UTC)

The affected users were informed of the resysop policy at the time of desysop via their talk page and email. Anything which overrides those instructions should follow the same notification procedure. -- King of ♥ ♦ ♣ ♠ 21:02, 28 July 2020 (UTC)

I disagree. There’s a standard notification procedure for these type of changes now. We don’t need to create a ton of work when there’s a streamlined process for this. TonyBallioni (talk) 21:13, 28 July 2020 (UTC)

Dweller, I appreciate that point of view, but the entire a major problem here is that for non-sysops it feels incredibly unfair that people who do NOTHING -- like, literally nothing for ten years, sometimes -- get this flag that like it or not confers at least the appearance of authority. Some may think they shouldn't feel that way, but the fact is they do, and it's a morale issue, and their feelings need to be respected and not dismissed.

And honestly I don't want someone who hasn't edited in ten years or even 3 to be doing really much of anything adminny of any importance for at minimum months while they learn what's changed. So, no, I don't want people to 'return to activity' without a solid period of contributing and relearning. I do not see it as harmful to anyone to expect that, if they really do intend to start editing again. The only people it even affects are those who would either not actually start editing again or start crashing about like a bull in a china shop. So they have to go six months without the flag. To me this does not seem like a big deal. —valereee (talk) 16:56, 28 July 2020 (UTC)

Valereee, the thing that is incredibly unfair is that fifteen years ago, good editors were quickly given +sysop, and now this no longer happens. And back in the day, policy changed a lot more and a lot faster than it changes now. I don't actually think an admin leaving for three years will miss much. At the same time, Wikipedia is so vast that even for active users there will be areas they haven't touched in years. Having said that, I would prefer a model of "be away as long as you like, and then be eligible for the tools six months after your return" to our current model of giving back the sysop flag to some people immediately, and to other people never. —Kusma (t·c) 22:11, 28 July 2020 (UTC)

Kusma, fifteen years ago most people bought into the idea that adminship was no big deal. That was a really nice ideal, but it was never true, and thinking has changed. I don't think it's unfair that wp's sysopping requirements have changed as a result. I agree with your proposed model. —valereee (talk) 23:46, 28 July 2020 (UTC)

@Kusma: I like the idea of your proposed model in general, but I think there should be a provision for short-term absences. Say something like: immediate restoration if you have been away less than six months and last admin action within 12 months, and restoration after 3 months if the absence was between 6 and 12 months and last admin action within 12 months, restoration after 6 months if absence longer than 12 months and last admin action within 3 years. RFA in all cases with no admin activity within 3 years (all with the standard 24 hour wait, crat consensus, etc. as now). Thryduulf (talk) 10:33, 29 July 2020 (UTC)

@Valeree I don't agree with you that but the entire problem here is that for non-sysops it feels incredibly unfair that people who do NOTHING -- like, literally nothing for ten years, sometimes -- get this flag that like it or not confers at least the appearance of authority If that was the case there wouldn't have been such resistance to the resysop that was requested a few days ago by someone's whose last 1500 edits go back a lot less than ten years. The problem in my view is that we are conflating several different problems - a security one, with a known risk of accounts being compromised and good reason to think that long inactive accounts are more vulnerable than most; A concern that longterm admins are at risk of drifting away from community norms (peak desysopping doesn't come in an admin's early years, it comes after they have been an admin for several years, and that was true even before we started desysopping the inactives); A concern that adminship should be a volunteer role that one does when one can but which can be set temporarily aside when life calls you elsewhere, versus a view I consider would only make sense if we offered admins a salary; a concern that RFA is broken and that only through a steady trickle of returnees are we able to maintain the admin cadre, and the counterview that you express that RFA is broken and it seems unfair that those who passed when it was easy are still the core of our admin cadre. That probably isn't all of them, but the entire problem is much more complex than any one of those factors. One thing that might help would be a bit of research, what proportion of the current admin workload is taken up by people who have taken a break of 12 months or longer since their RFA, and what proportion by people who would have been desysopped under another proposal, and what proportion by admins who have consistently remained active since their RFAs. ϢereSpielChequers 15:52, 29 July 2020 (UTC)

WereSpielChequers, I’ll back off on ‘the entire problem’ to ‘a major problem.’ But this request would have been a problem. Yes, their last 1500 edits go back less than 10 years, but that’s a pretty low bar for someone who started editing in 2013. If you remove the last few days’ edits, their last 10 edits go back to 2017 and their last 20 to 2016. They haven’t been meaningfully engaged here in years. I am not arguing this means they shouldn’t be able to contribute and start using admin tools again. I’m arguing it's not outrageous to ask people to show us they do indeed intend to actually contribute. —valereee (talk) 18:55, 29 July 2020 (UTC)

And FTR, my primary concern isn't that RfA is so broken. It's that non-sysops perceive resysopping of inactive editors as inherently unfair. —valereee (talk) 19:07, 29 July 2020 (UTC)

valereee I think that is now being covered by WP:RESYSOP #7, no? –xeno^talk 18:57, 29 July 2020 (UTC)

Xeno, yes, I do think it's covered by that. For me -- and this is just me, and it's also not a commentary on any decision any bureaucrat has made -- is how does a bureaucrat make that assessment? I'd like to see bureaucrats saying, "Hey, welcome back, We'd love to resysop you but I'd like to make sure you're really back. Can we put this on hold for a few months?" —valereee (talk) 19:12, 29 July 2020 (UTC)

(EC) Thanks Valeree. I suspect that a compromise policy is possible, something like "two weeks of active editing for each year of absence/inactivity" that would balance Wikipedia's need for admins with the desire of some people to restrict the mop to active editors. One interesting bit of research that might shift people one way or the other would be to look at our last fifty resysops and see how active those people subsequently were. ϢereSpielChequers 19:31, 29 July 2020 (UTC)

WereSpielChequers, I actually went through the most recent sysops at a previous recent discussion. The analysis is here. Of 18 resysops I looked at, about 1/4 were very productive, another 1/4 had resumed minimal activity, and half weren't editing really at all. To me this is worth encouraging -- 25% returning to editing is excellent, IMO -- but that 1/2 who are just goldbricking? That's what causes infuriation. —valereee (talk) 20:02, 29 July 2020 (UTC)

There's a very clear pattern in the data you linked to. Namely, every admin (on that list) who was originally sysopped after/including 2010 was significantly active after resysop. Jack, above, is looking to follow this pattern (although not resysopped). Most pre-2010 admins that were resysopped were not active afterwards. ProcrastinatingReader (talk) 16:51, 30 July 2020 (UTC)

@Valereee: The new procedure is less than a year old - how many requests have we had since the implementation that turned on this rule? (I found this one, where SilkTork's response is pretty much what you're hoping for.) –xeno^talk 15:49, 30 July 2020 (UTC)

Xeno, yes, that's exactly right. The question of course is whether the editor in question would have started to contribute again if they'd been resysopped, but was upset about it and that's why they haven't. It's unknowable. ProcrastinatingReader, oh, very interesting! Though actually there are three resysops who aren't on that list (because the resysoppings had been so recent, I didn't think it was useful data.) Those three were all originally sysopped by 2007. One is regularly making up to 1000 edits per month, one is averaging 75 edits per month, and one hasn't edited since October. —valereee (talk) 17:41, 30 July 2020 (UTC)

Based on that data I think there's some strong negative correlation between admins who passed after Wikipedia became more well known / RfA got tougher, and low activity levels after returning from activity. And this correlation makes sense, I suppose. I'm in the middle with this whole inactivity thing. The gaming admins need to be kept far away from the hats they wish to retain (for whatever reason), and the honest and competent admins who return from a break should be allowed to regain tools to help them keep the wiki going, without having to go through the RfA process. (sidenote: that people in WT:RfA were saying they're planning to nominate people in September (ie 3 months away, at the time) shows an issue with the process: it shouldn't be like a campaign)

It may seem unfair, but an inactivity policy which can address that correlation in data is probably more likely to achieve the goal of keeping good returning admins, whilst not giving the gamers their hats back. It might have some false positives, sure, but we already have false positives (eg the case of Jack above) - they can always re-run at RfA for community approval. Nothing against old admins, many are great, but that data would suggest the returning ones (at least the ones that basically became inactive before 2010, regardless of sysop year) don't tend to stick around, and were confirmed under a much weaker vetting process anyway. Some returned with questionable admin actions. Fairest method is maybe by judging how active they were before they became inactive, irrelevant of year. ProcrastinatingReader (talk) 18:03, 30 July 2020 (UTC)

• The current system is easy to game, but my experience has been that it is actually very few admins who really blatantly do so, and without exception they are old-school pre-2007 admins from the "no big deal/cowboy admin" era, and even most of them have by now finally realized that there is little point in making edits once a year for no reason other than to retain tools you don't use. The five year rule was at first taking about 2 admins out of play each month, as time has gone by that number has gone down to about one every two months, so I would say that has proven to be effective in thinning the ranks of "admins in name only" from the bad old days. I do think we could stop the notifications entirely at this point as the basic standard that you must at least edit once a year has been policy for nine years now and we expect admins to be aware of that by now. Those very few who may remain purely to game the system would have to rely on themselves to remember to do so instead of being prompted to. Beeblebrox (talk) 17:41, 28 July 2020 (UTC)

  Right, as this was my original intention in the previous discussion. If you send one mass notification to every current administrator, and former administrators on the bubble of not being able to re-sysop, that the policy has changed then you've covered the entirety of everyone who needs to know and you could stop with notifications all together, as everyone has been informed at least once. — Moe Epsilon 07:35, 29 July 2020 (UTC)

  As an aside, given that I have been mentioned in these discussions substantially, I want it to be known I have read all these comments. My own comment is reserved. Jay(Talk) 09:38, 29 July 2020 (UTC)

  Yes, I told you about being mentioned here. You retorted by calling me a long-term sockpuppet. - Sitush (talk) 10:15, 29 July 2020 (UTC)

  Please reply on my talk page. Jay(Talk) 10:34, 29 July 2020 (UTC)

  Let's keep this discussion on-track, please. Primefac (talk) 11:20, 29 July 2020 (UTC)

I'm an admin who was inactive for many years. When I was dealing with two little kids and a thesis I only made very occasional edits. Then, in 2019, I had more time for this again and was happy to be back. One of the things that pulled me back in was that I still had the admin bit - a reminder that I was at one point asked to help out around here so I feel some sense of obligation to try to do a little bit of that when I can. Helping to pull old veterans back in might be a net positive, even if we're sometimes embarrassingly rusty... Haukur (talk) 21:47, 30 July 2020 (UTC)

Resysop Request (SQL)

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

Things are calming down a lot at work, and I have time available for the project again. SQL^{Query me!} 20:43, 30 July 2020 (UTC)

I don't think I can support this request because SQL has problems with tables. —CYBERPOWER (Chat) 21:13, 30 July 2020 (UTC)

I don't think I can support this request because I just don't like SQL, and besides what would User:MongoDB think of me. --qedk (t 愛 c) 09:42, 31 July 2020 (UTC)

Related concern. I don't think SQL is eligible for resysopping.a bureaucrat should be reasonably convinced that the user has returned to activity or intends to return to activity as an editor; this user is actually, to quote our article "a domain-specific language used in programming". Otherwise I'm very excited to have them back. Best, Barkeep49 (talk) 21:47, 30 July 2020 (UTC)

Would it not be a good idea to look at the query execution plan first? Ritchie333 ^{(talk) (cont)} 10:14, 31 July 2020 (UTC)

Looks like most of us at User:Radiant!/Classification of admins would be in big trouble then. bibliomaniac15 02:08, 31 July 2020 (UTC)

update sql set admin = 'Y'; Hawkeye7 (discuss) 10:40, 31 July 2020 (UTC)

A table per user? Sounds like SQL abuse. ProcrastinatingReader (talk) 10:46, 31 July 2020 (UTC)

I'm glad to see SQL is joining the inner ranks again. GeneralNotability (talk) 14:06, 31 July 2020 (UTC)

Excellent news! GorillaWarfare (talk) 21:17, 30 July 2020 (UTC)

So am I. Welcome back, SQL! I'm glad my nudging came true --TheSandDoctor ^Talk 06:05, 1 August 2020 (UTC)

Everything seems in order, standard 24 hour hold. — xaosflux ^Talk 21:48, 30 July 2020 (UTC)

Very nice! Reaper Eternal (talk) 18:41, 31 July 2020 (UTC)

• Adminship restored. welcome back ϢereSpielChequers 22:29, 31 July 2020 (UTC)

Wikipedia:Inactive administrators/2020#August 2020

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

1. Philg88 (talk · contribs · blocks · protections · deletions · page moves · rights · RfA)
2. Just Chilling (talk · contribs · blocks · protections · deletions · page moves · rights · RfA)
3. Viajero (talk · contribs · blocks · protections · deletions · page moves · rights · RfA)

   Last admin action: 2006

— xaosflux ^Talk 00:05, 1 August 2020 (UTC)

I hope Just Chilling is okay. He was very active until literally one day he stopped. TonyBallioni (talk) 00:08, 1 August 2020 (UTC)

Me too. He did take a year off between 2013 and 2014, so it's not unprecedented. P-K3 (talk) 01:19, 1 August 2020 (UTC)

Desysop request (Angela)

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

Hello. I don't imagine being active here in the near future so I would like to request my admin rights be removed. Thank you. Angela (talk) 23:17, 1 August 2020 (UTC)

 Done. Primefac (talk) 23:19, 1 August 2020 (UTC)