Wikipedia:Bureaucrats' noticeboard

Bureaucrats' noticeboard archives

1, 2, 3, 4, 5, 6, 7, 8, 9, 10 11, 12, 13, 14, 15, 16, 17, 18, 19, 20 21, 22, 23, 24, 25, 26, 27, 28, 29, 30 31, 32, 33, 34, 35, 36, 37, 38, 39, 40 41, 42, 43, 44, 45, 46, 47, 48, 49

This page has archives. Sections older than 5 days may be automatically archived by Lowercase sigmabot III.

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	0
RfBs	0
Overdue RfBs	0
Overdue RfAs	0
BRFAs	13
Approved BRFAs	0

Requests for

bureaucratship update

No current discussions. Recent RfAs, recent RfBs: (successful, unsuccessful)

It is 12:25:27 on April 27, 2024, according to the server's time and date.

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 · fm · mms · npr · pm · pcr · 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)[reply]

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

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

 Done Useight (talk) 15:54, 27 July 2020 (UTC)[reply]

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

• 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)[reply]

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

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

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

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

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

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

]

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

]

• 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)[reply]

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

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

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

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

]

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

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

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

• 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)[reply]
  • 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)[reply]
    • 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)[reply]
      • 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)[reply]
        • 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)[reply
          ]
        • (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)[reply]
        • 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)[reply]
        • 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)[reply]
• 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)[reply]
• 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)[reply]

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

]

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

Leaning on

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

]

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

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

It was in

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

]

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

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

• 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)[reply]

• 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)[reply]

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

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

  ]

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

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

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

  @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)[reply]

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

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

• 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)[reply]

@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)[reply]

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

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

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

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

(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)[reply]

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

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

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

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

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

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

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

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

"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)[reply]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 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)[reply]

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

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

• 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)[reply]
  • 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)[reply]
  • 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)[reply
    ]

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

    • Cryptic 14:59, 27 July 2020 (UTC)[reply
      ]
      • 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)[reply]
• 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)[reply]

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

• 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)[reply]

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

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

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

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

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

  ]

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

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

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

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

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

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

  ]

  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 is exceedingly dynamic. -- Alanscottwalker (talk) 15:36, 27 July 2020 (UTC)[reply]

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

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)[reply]
• In most setups, new rules only apply to scenarios after they are enacted they don't apply
  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)[reply
  ]

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