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, 50

This page has archives. Sections older than 7 days may be automatically archived by .

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

Shortcuts

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	15
Approved BRFAs	0

Requests for adminship and bureaucratship update
No current discussions. Recent RfAs, recent RfBs: (successful, unsuccessful)

It is 07:57:04 on December 28, 2024, according to the server's time and date.

Side discussion on waiting periods

Note that this discussion was split from #Desysop request (TheresNoTime)

I think bureaucrats should consider implementing the 1-day waiting period for resignation self-requests that Stewards implemented a while back so we can allow for cooler heads to prevail in situations like these. :( Legoktm (talk) 16:02, 1 November 2022 (UTC)[reply]
I agree. Worm^TT(talk) 16:05, 1 November 2022 (UTC)[reply]
I generally third this (prob implies policy change, etc.), but given that nearly every time there's a request with even a slim chance of weather we do this same dance for a dozen comments or so, I don't foresee a world where a waiting period helps that aspect. ~ Amory (u • t • c) 16:16, 1 November 2022 (UTC)[reply]

I considered that, but decided our current protocol serves the user and Wikipedia better. If someone is here requesting tools to be removed, they may be in an emotional/unhappy/angry/depressed state, and may, under provocation, do something they regret with the tools. I feel we should honour the request as soon as we see it. If there is no cloud, the user can gain the tools back on request. Granted, they have to wait 48 24 hours for the tools back, but better to have that wait than to regret having deleted something or blocked someone in anger. Some people may feel the burden of the responsibilities of the tools at sensitive times. I would personally regard acting promptly to remove tools on request was something more vital for mental health and security reasons than, say, closing an RfA on time. SilkTork (talk) 16:32, 1 November 2022 (UTC)[reply]

@Legoktm the major difference is if you go to SRP and resign, it is a one-way path; regaining access via SRP requires a new showing of community support. — xaosflux ^Talk 16:51, 1 November 2022 (UTC)[reply]

That waiting period was explicitly not wished for, and then also not taken. [1] ~ ToBeFree (talk) 19:34, 1 November 2022 (UTC)[reply]
I've ... shall we say "requested desysopping in less than perfect circumstances" (i.e. many would say "ragequit") a couple of times, and in my own case, not doing it right away would have increased my anger and stress. I asked TNT to wait a little, but once they make the decision and request a desysop, I think the respectful thing to do is honor their wishes right away. --Floquenbeam (talk) 20:02, 1 November 2022 (UTC)[reply]
I've always supported the 24 hour period to desysop for volunteer situations, it just isn't an issue that often. Require a request, then a 2nd request at least 24 hours later, this is how I would do it, with it automatically resulting in a voluntary desysop after 72 hours, say. This way if they don't come back, they aren't in limbo. This may seem like a burden, but it really isn't. It's not like you must use your bits during that period. Dennis Brown - 2¢ 11:03, 2 November 2022 (UTC)[reply]
I disagree there's an issue here to be solved. Whilst I'm not happy when someone wants to give up the tools - it's their right to do so. It's not a one way street - if someone did ask for their bit to be removed, if they did want it back then under our current rules they would get it back unless it was under a cloud. This way prevents potential disruption. I can see someone who was adamant they didn't want the tools anymore intentionally using them poorly to expedite the issue. Lee Vilenski ^{(talk • contribs)} 11:26, 2 November 2022 (UTC)[reply]
^This. --SarekOfVulcan (talk) 14:01, 2 November 2022 (UTC)[reply]
I had pondered for a while if this was a good idea. But I think Amory's point above should not be lost: a 24 hour waiting period could, not infrequently, turn into 24 hours of attention towards a person who probably doesn't want it at that moment. Barkeep49 (talk) 15:13, 2 November 2022 (UTC)[reply]
I also do not support this idea. Cloudiness is a discussion for when they ask for the tools back. If it s a trulyt voluntary desysop, it should just be actioned with no further fuss or ...(sorry) bureaucratic red tape. Beeblebrox (talk) 19:02, 2 November 2022 (UTC)[reply]
@Beeblebrox I think the positive case for a 24 hour wait is as a cooldown for someone who is rage quitting not about CLOUD. Obviously CLOUD discussions are part of what I reference in my comment. Best, Barkeep49 (talk) 19:19, 2 November 2022 (UTC)[reply]
Immediate desysop on request and then a 24 hour wait for resysop both felt right for me last time I laid down my tools. Please keep as is. —Kusma (talk) 19:16, 2 November 2022 (UTC)[reply]
In my experience, people generally do not make these decisions lightly, and an additional wait time will not bring any particular relief, and may generate additional frustration. Also, I don’t think this is subject to discretion, so it would need to be implemented by RfC. –xeno^talk 20:54, 2 November 2022 (UTC)[reply]
Acting on a request immediately isn't mandatory, so bureaucrats are free to use their discretion on whether or not they want to check in with the requestor first before complying with the request. I think leaving the process to bureaucrats' discretion may be the best way to adapt to each specific circumstance. isaacl (talk) 22:13, 2 November 2022 (UTC)[reply]
isaacl: it’s true bureaucrats have a pocket veto in WP:NOTCOMPULSORY, however there would be no way for a single bureaucrat to prevent all others from acting on a request without a community-approved process for delaying. –xeno^talk 22:22, 2 November 2022 (UTC)[reply]
xeno I think the reverse is more likely - that most/all other crats would want to sit and a single crat does what is asked. Best, Barkeep49 (talk) 00:48, 3 November 2022 (UTC)[reply]

I assume if one bureaucrat posts a response saying they're checking in with the requestor, the others will defer and not choose to short-circuit the discussion. isaacl (talk) 01:24, 3 November 2022 (UTC)[reply]

There are exceptions. IIRC I briefly rage-quit sometime around 2006; Raul654 (talk · contribs), bless him, sat on my admin resignation request for a little while until I'd calmed down. It wouldn't have been under a cloud or anything like that, but I reflect on that small act of kindness and understanding from time to time. I wouldn't want to see a bureaucrat's hands bound in either direction. Mackensen (talk) 14:38, 3 November 2022 (UTC)[reply]
I don't think any mandated waiting period is necessary. Leave us the discretion. --Dweller (talk) Old fashioned is the new thing! 13:25, 3 November 2022 (UTC)[reply]
I think 'crats having the discretion to implement immediately or not seems to be working just fine, and seems to be what both crats and those who have requested desysop in the past want, so I see no benefits to changing it. Thryduulf (talk) 16:26, 3 November 2022 (UTC)[reply]

RfAs should now be automatically placed "on hold" after 168 hours

Per the closing statement at the recent RfC, RfAs should be automatically placed "on hold" 168 hours after their starting time. The closer indicated consensus seemed to favour this being done in some automagic fashion. –xeno^talk 00:15, 6 November 2022 (UTC)[reply]

An open question is whether this also applies to RfBs. (I'd lean not.) –xeno^talk 00:21, 6 November 2022 (UTC)[reply]
The discussion didn't refer to RfBs so maybe this does not apply to RfBs, but maybe RfBs may be changed to sync with RfA procedures? Thingofme (talk) 01:35, 6 November 2022 (UTC)[reply]

I suppose it doesn't really change any thing we do (since we don't close early). Suppose if anything it could cause drama of the "you participated late and I reverted you" type. — xaosflux ^Talk 01:05, 6 November 2022 (UTC)[reply]

A way to implement this change is to use a edit filter after the time of voting it disable any edits to the RfA pages except for administrators and bureaucrats to close the RfA, and bots to fix technical errors afterwards. Thingofme (talk) 03:09, 6 November 2022 (UTC)[reply]

Not sure about the edit filter idea (expensive to run on every page on the wiki, unable to isolate transclusion date). And doing it via template might have purging issues. Bot might be the way to go here. –Novem Linguae (talk) 05:19, 6 November 2022 (UTC)[reply]

However a title blacklist addition, like Commons' Pictures of the Year voting maybe useful. Maybe a script for voting on RfA: Support/Oppose/Neutral with reasons like stewards election? Thingofme (talk) 06:15, 6 November 2022 (UTC)[reply]

@Thingofme and Novem Linguae: Please bring technical implementation discussions of this to Wikipedia talk:Requests for adminship#RFA max time holds - technical implementation. — xaosflux ^Talk 12:27, 6 November 2022 (UTC)[reply]
Seems to be rather pointless to me, but okay. I never understood people complaining that an RFA wasn't closed immediately (down to the second). Some people have lives outside of Wikipedia, after all. ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 23:54, 7 November 2022 (UTC)[reply]
Agreed, but The People have spoken. I'm trying to make the change as unobtrusive (and as painless for us) as possible. Primefac (talk) 07:37, 8 November 2022 (UTC)[reply]
Obviously I haven't seen it in action yet, but it doesn't feel like there would be much, if any, functional difference for closing RFAs. As long as the confusion of "Oh, it's on hold? I guess some other bureaucrat is currently examining it, so I won't" is avoided. And that would, I suppose, only happen if the would-be closer didn't know that a bot was automatically putting the RFAs on hold. Useight (talk) 18:02, 8 November 2022 (UTC)[reply]
See the linked thread above at WT:RFA, but my implementation idea adds a switch to {{rfah}} that changes "put on hold by a 'crat" to "automatically put on hold", so it should be fairly obvious which route has been taken. Primefac (talk) 18:32, 8 November 2022 (UTC)[reply]

Resysop request (Euryalus)

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, last January I handed in the admin tools for Euryalus (current rights · rights management · rights log (local) · rights log (global/meta) · block log) to focus on studying. My last exam was today, and so am re-requesting the mop to return to various janitor tasks. -- Euryalus (talk) 05:46, 8 November 2022 (UTC)[reply]

Removal request: Special:Permalink/1064590698. I see no issues, standard hold is in place. Primefac (talk) 07:34, 8 November 2022 (UTC)[reply]

Agree, seems fine. Welcome back Euryalus. — xaosflux ^Talk 10:21, 8 November 2022 (UTC)[reply]

Agree. Respected user. No concerns. SilkTork (talk) 11:55, 8 November 2022 (UTC)[reply]

I see no concerns. ···日本穣 · 投稿 · Talk to Nihonjoe · Join WP Japan! 16:43, 8 November 2022 (UTC)[reply]

Hello young Euryalus! bishzilla _ROARR!! pocket 16:47, 8 November 2022 (UTC).[reply]

Happy to endorse this user's return. Hope the exams went well. Glad to see your datestamp! BusterD (talk) 19:52, 8 November 2022 (UTC)[reply]

And so enacted, Welcome back! Worm^TT(talk) 07:19, 9 November 2022 (UTC)[reply]

Desysop request (RedWordSmith)

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

I am requesting that admin rights are removed from my account, as regrettably I will not have an appropriate amount of time to dedicate to Wikipedia for the foreseeable future. - RedWordSmith (talk) 04:06, 10 November 2022 (UTC)[reply]

That's been done for you. SilkTork (talk) 07:02, 10 November 2022 (UTC)[reply]

		Job Done
		Awarded to RedWordSmith for good services as an admin, and for resigning the tools in a noble manner. SilkTork (talk) 07:02, 10 November 2022 (UTC)[reply]