Wikipedia talk:Administrators

External videos
Wheel warring

Australia flag

Moved to Talk:Anthony Albanese § Australia flag

Special Circumstances Blocks

ArbCom gave an announcement today which updates/clarifies some previous announcements linked to in the special situations section of this policy. Barkeep49 (talk) 21:08, 8 August 2022 (UTC)

Special circumstances blocks needs updating

Given the recent close of Wikipedia:Village_pump_(policy)#RfC:_Updating_BLOCKEVIDENCE combined with the announcement above, I would suggest that the special situations should be updated. Normally I'd draft something as a starting point but would guess that some editors would be uncomfortable with that owing to my being a sitting Arb who helped pass the announcement in question. But I think the consensus has changed and this policy needs updating. Barkeep49 (talk) 21:38, 23 September 2022 (UTC)

Concerns about the article https://en.wikipedia.org/wiki/Khimo_Gumatay

Hello admins, I have concerns about the article that I have created today (October 27, 2022). Prior to the creation, there was an article of the same name (created by another author) that has been deleted last September 18, 2022, I am aware of that and since no article have been created after that I have decided to make new. Now, my concerns is that when I save the article, the note of the previous article remains and it says like this

"This article was nominated for deletion on September 18, 2022. The result of the discussion was speedy delete."

My question is, is the note have been added in the article would affect the newly created article? Thank you. Troy26Castillo (talk) 11:56, 27 October 2022 (UTC)

Only if the newly-created article is identical to the old one, or does not deal with the issues presented in the AFD. Primefac (talk) 12:00, 27 October 2022 (UTC)

Additional, the note or the template was added by AnomieBOT, is it automated in relation to the old article that has been deleted since it has the same name? Troy26Castillo (talk) 13:11, 27 October 2022 (UTC)

Yes. Primefac (talk) 13:49, 27 October 2022 (UTC)

Or just a reminder that previously there was an article of the same name that has been deleted? Troy26Castillo (talk) 13:13, 27 October 2022 (UTC)

Yes. Primefac (talk) 13:49, 27 October 2022 (UTC)

Thank you Troy26Castillo (talk) 14:21, 27 October 2022 (UTC)

Clarifying 5 year rule

In Wikipedia:Administrators § Restoration of adminship, should the policy regarding Over five years since administrative tools were last used... for restoration of adminship be interpreted as:

1. Five years prior to the desysop
2. Five years since the last tool use, regardless of whether the five-year mark falls before or after the desysop
3. Five years since the desysop, regardless of when the tool use occurred before the desysop

20:28, 18 November 2022 (UTC)

Background

A 2018 RFC proposed by Beeblebrox set out to determine if any admin who has not used their tools in five years and is subsequently desysopped for total inactivity would no longer be able to simply ask for them back, to which there was general support. WP:ADMIN was subsequently updated to add this language. However, it was later inadvertently changed, with the "and is subsequently desysopped" clause removed from the statement (making it essentially "Option 2" above). Meanwhile, WP:RESYSOP (point 6) currently states what can be interpreted as "Option 1" above (a period of five years or longer at the time of their last administrative rights removal), leading to a discrepancy in our policies and guidelines. This RFC is being asked to bring both ADMIN and RESYSOP into sync with each other and also to determine (slash reconfirm) the community consensus on the matter. Primefac (talk) 21:19, 18 November 2022 (UTC)

Survey

• 2. When Beeblebrox proposed the RfC that led to this wording, I think the intent was for #1. But the way it has ended up in ADMIN is #2 and that is also my preferred interpretation. This came up in regards to a conversation on IRC about whether someone Tamzin knows would be eligible for reysosp (and thus eligible to use the -admins channel on IRC) and it was noticed that the ADMIN policy contradicts WP:RESYSOP and that the original RfC and closing don't provide exact clarity on this issue either. Hence this RfC. Barkeep49 (talk) 20:28, 18 November 2022 (UTC)
  • This RFC could do with a little TLC before people start commenting, to make it clearer. For example, for no. 2 - how can there be tool use after a desysop? Or maybe excerpt a little more of the text you're trying to change, at least the whole sentence; right now it doesn't make sense to me. I could probably puzzle it out with a little research, but it's less efficient to make everyone do their own research when you could do it once for them. (There's threaded discussion allowed here, right?) --Floquenbeam (talk) 20:39, 18 November 2022 (UTC)
    • @Floquenbeam: I think the intended meanings here—and, @Barkeep49, feel free to put these in the description if you agree, although I understand if you'd rather keep things succinct—is 1) An ex-admin who was desysopped for inactivity, and has made no admin actions in the preceding 5 years, cannot be resysopped without a new RfA. 2) An ex-admin who has gone more than 5 years since their last admin action cannot be resysopped without a new RfA. (I think "before or after" means "regardless of whether the 5-year point was passed before or after desysop".) 3) An ex-admin who was desysopped more than 5 years ago cannot be desysopped without a new RfA. -- Tamzin^{[cetacean needed]} (she|they|xe) 20:44, 18 November 2022 (UTC)
      • I have made a slight tweak to try to clarify it's about the entire sentence but yes I was trying to keep the statements concise. Barkeep49 (talk) 20:55, 18 November 2022 (UTC)
        • Background added, wording tweaked. Primefac (talk) 21:42, 18 November 2022 (UTC)
• (edit conflict) So, in terms of what was actually intended in the previous RfC, I think the answer is clearly Option 1: an admin who is desysopped for inactivity, and has made no admin actions in the preceding 5 years, cannot be resysopped without a new RfA. As Barkeep says, that appears to be what Beeblebrox intended, and the RfC was closed in favor of his proposal. That was only changed in policy by UninvitedCompany in this edit which, per the edit summary, was not intended to be a substantive change. So, if there is no consensus in this RfC, the default should be to revert that part of UC's edit. (And to be very clear, UC, I understand that that was an entirely good-faith edit.)
  With that said, in addition to affirming the existing consensus for Option 1, I would support Option 3 with one-year grace period, as some users may have resigned adminship under the understanding that they had indefinite right-of-resysop, and should have the chance to do something about that. Oppose Option 2 as it creates a perverse incentive to game the system by making some token admin action on one's way out the door. Somene who U1s a userpage right before resigning at BN is not more entitled to a resysop 4.9 years later than someone who doesn't. -- Tamzin^{[cetacean needed]} (she|they|xe) 20:40, 18 November 2022 (UTC)

  This presumes that people are mostly stepping down voluntarily. I think most are losing sysop under the inactivity policy so they're not likely to be gaming this standard in the first place (else they'd be gaming to keep the bit). And if someone is stepping down voluntarily why should I care if they make a token admin action before doing so in order to give themselves a longer time period to decide to resysop? As Thryduulf notes below, doing an admin action demonstrates the competence for continued admin tool use. Best, Barkeep49 (talk) 21:32, 18 November 2022 (UTC)

• (edit conflict) I haven't done the research to form an opinion about what was intended, but I believe it should be option 2. That is, an admin who has made no logged admin actions within the last 5 years should not be eligible for resysopping without a new RFA. I don't think it matters at what point the desysop happened, because only by making admin actions that are accepted as correct are you demonstrating familiarity with polices, etc. This means that my last demonstrated competence as an admin was yesterday when I deleted Dr. Hernando Perez. Thryduulf (talk) 20:58, 18 November 2022 (UTC)
• Option 1 is what was intended, and I believe this is how this rule has been consistently applied for nearly five years now. Beeblebrox (talk) 22:02, 18 November 2022 (UTC)

  I should clarify that I very deliberately set the bar as low as I could imagine when proposing this, as tightening the activity requirements had been near-impossible before this. Part of the intent was to demonstrate that, like all of our policies, the activity requirements were meant to evolve over time and were not a finished, perfect set of rules when first enacted in 2011. In other words, it was always personally my intent that this would be the first, not the last, modification of those rules. Beeblebrox (talk) 18:46, 19 November 2022 (UTC)

• I suggest it would be helpful to clarify that options 2 and 3 are only relevant for cases where an editor relinquished administrative privileges before a five-year period of non-use had occurred. Reading through the original RfC, I feel most people supporting the change did so because they felt five years without administrative actions meant that the editor should be re-obtain the community's approval. I believe this still holds even if the admin in question voluntarily gave up their privileges part way through, and so think option 2 is most consistent with the expressed views (and consistent with the evaluation of consensus in the closing statement). I disagree with option 3; it will soon be five years since the change and I do not feel any grandfathering needs to be introduced. isaacl (talk) 22:25, 18 November 2022 (UTC)

  I also don't think option 1 is what was intended in the original RfC in the case of someone voluntarily giving up their administrative privileges. I don't think the intent was to allow an editor to stop the clock by ceasing to have administrative privileges before five years of non-use occurred. isaacl (talk) 22:32, 18 November 2022 (UTC)

  @isaacl Maybe not the intent of participants, but we have the person who formulated the wording saying above that was exactly the intent. Best, Barkeep49 (talk) 22:39, 18 November 2022 (UTC)

  My apologies; for conciseness I elided "consensus intent". isaacl (talk) 22:47, 18 November 2022 (UTC)

• 2 is what I think is best, it closes some timing collisions/etc that were not explored well initially. Keep in mind that none of this prevents precludes anyone from requesting access via the standard method. — xaosflux ^Talk 23:01, 18 November 2022 (UTC)
• Option 2. Dysysop for inactivity plus five years of not using the admin tools should automatically result in an RfA to see if the community still has trust and faith in the user before restoring tools. If Option 2 passes, then emails to be sent out to all admins, and a grace period of one month allowed before implementing the rule, in order not to catch people out unawares, and to perhaps encourage some experienced admins to come back and engage once more with the project. SilkTork (talk) 06:12, 19 November 2022 (UTC)

  Some stats were run in 2018, and I think it would be reasonable to do a similar check, to even see how many former admins would be affected by this; no point in sending out hundreds of messages if only a dozen folks will be affected. Primefac (talk) 08:26, 19 November 2022 (UTC)

I do not believe it is to the benefit of the project to allow people to automatically regain adminship after such a lengthy period of non-engagement as would result from five years of disuse of the admin tools combined with sufficient ongoing inactivity as to result as loss of adminship per policy. In reality, there are few cases where these nuances come up, and fewer still where a formerly active admin returns to regular and sustained activity. When I made the change to the policy years ago there were no objections. Realize that there may have been many who reviewed the edit contemporaneously and did not object before concluding that it lacked support for the minor mechanical changes it introduced. UninvitedCompany 02:39, 20 November 2022 (UTC)