Loading

  • 21 Aug, 2019

  • By, Wikipedia

Wikipedia Talk:Requests For Adminship

Early start by an hour?

Moved from Wikipedia talk:Requests for adminship/DreamRimmer, since it quickly became unrelated to the RFA itself. Primefac (talk) 11:03, 30 May 2024 (UTC)[reply]

@SchroCat, why did you do this? – robertsky (talk) 09:19, 30 May 2024 (UTC)[reply]

I suspect because of time zone things. Anyone on UTC+1 will see "starts at 10:02" and potentially forget that "10:02" their time is really 09:02 UTC. Primefac (talk) 09:26, 30 May 2024 (UTC)[reply]
Like DST offsets not accounted for? That makes sense. – robertsky (talk) 09:30, 30 May 2024 (UTC)[reply]
(edit conflict) Indeed. I forgot that we in the UK are currently on BST, rather than UTC. - SchroCat (talk) 09:37, 30 May 2024 (UTC)[reply]
Oh well. The milk has spilled, and it is just an hour off. I don't think much can be faulted on this. A pedantic me would request you to re-sign the vote after 20 minutes from now lest others seek to invalidate the early votes in a toss-up, if it happens. If this 2-day thing becomes a permanent thing, we can look into solutions to warn people not to vote early if they do so mistakenly. – robertsky (talk) 09:47, 30 May 2024 (UTC)[reply]
I have always though that a tool to lock sections of a page would be beneficial, rather than locking the whole page. That would be useful in these situations too. Alternatively, not having the voting sections in place until the kick-off time would also help. - SchroCat (talk) 10:04, 30 May 2024 (UTC)[reply]
Prior to the note being added, that was my thinking as well (hiding them entirely, that is) much as we do with the auto-close code. Something to discuss at WT:RFA though, not necessarily here. Primefac (talk) 10:10, 30 May 2024 (UTC)[reply]
The conditional statement that would have automatically opened up the voting at the right time didn't help much here because it was manually removed an hour early. If that conditional contained the entire voting section, it probably still would have been manually removed an hour early. Not that this was a big deal, but there's probably not much we can do about people removing code because they think the code is broken, don't understand what it is, or don't notice it's there. I don't think the problem is with the code. Maybe add to the hidden comment something that alerts people that the code will automatically open the voting at the right time? Levivich (talk) 10:18, 30 May 2024 (UTC)[reply]
How about The code below will automatically "open" the voting by hiding the notice at the correct time? See Special:Diff/1226653241. —⁠andrybak (talk) 01:22, 1 June 2024 (UTC)[reply]
I was thinking that maybe we can explore using an edit filter to warn editors to not vote if they make modifications in the voting section early. – robertsky (talk) 10:20, 30 May 2024 (UTC)[reply]
Edit filters are loaded on every single edit page on the entire wiki, so in general should be useful on a large number of pages to justify the performance overhead. –Novem Linguae (talk) 13:53, 30 May 2024 (UTC)[reply]
Could this be done by transcluding the section from another page (say, Wikipedia:Requests for adminship/DreamRimmer/Vote), and locking that page? Chaotic Enby (talk · contribs) 10:57, 30 May 2024 (UTC)[reply]
Yes, but that makes things complicated. A {{hide until}} call (or something similar) would actually hide the text/sections entirely so there would be no reason for anyone to be editing it unless they were editing the entire page and didn't then notice the code saying that it was hiding the voting. The other option, as Levivich says, is to possibly indicate that the "this isn't open yet" code also contains a note that the code disappears when the time is right. Primefac (talk) 11:02, 30 May 2024 (UTC)[reply]
It might look like I'm going to fall out with SchroCat over footnotes and pages +n, etc., in the near future, but he's one of the best editors we've got and is trustworthy as hell. That's for the record. ——Serial Number 54129 11:32, 30 May 2024 (UTC)[reply]
No need to do this, and should be reminded that all times in Wikipedia are in UTC and not your local time. Just a random Wikipedian 06:49, 4 June 2024 (UTC)[reply]
UTC+00:00 (UTC for short) is also known as Greenwich Mean Time. SchroCat above says they live in the United Kingdom, which confusingly isn't always on Greenwich Mean Time, "despite having Greenwich". —⁠andrybak (talk) 08:08, 4 June 2024 (UTC)[reply]

Asking two questions

I have eliminated the parameter for the second question number from Template:Rfa-question, as it should always be the first question number plus 1. So, if you want to ask two questions, then you should use {{subst:Rfa-question|first question number|question 1|question 2}} rather than {{subst:Rfa-question|first question number|question 1|second question number|question 2}}. GTrang (talk) 14:13, 3 June 2024 (UTC)[reply]

Discussion of off-wiki commentary

I don't know if we should do this here or maybe at the village pump or yet another RFA reform RFC but it seems clear we have a problem in this area. It's clearly not going to sink the current RFA, but there are some questions that need to be resolved:

  • How are we to evaluate accusations based on off-wiki evidence that apparently cannot even be named, yet alone directly linked to, on-wiki? Only users already in the know of these specifc discussions even know what is being discussed.
  • Is there a difference between off-wiki criticism forums as opposed to the en.wp dischord?
  • Is emailing links of the relvant off-wiki evidence to the arbitration committee even relevant, as ArbCom is in no way in charge of RFA?

Seems like we need to clarify this stuff. Just Step Sideways 19:36, 4 June 2024 (UTC)[reply]

Speaking only to the second point, I think there's a pretty clear difference between participating at off-wiki criticism forums vs participation on one of the unofficial Wikipedia discords. I think it's at least relevant that the en-wiki Discord server is moderated mostly by Stewards and en-wiki admins. Hey man im josh (talk) 19:42, 4 June 2024 (UTC)[reply]
Speaking of criticism forums, I really like the quote on your user page Criticism may not be agreeable, but it is necessary. It fulfils the same function as pain in the human body. It calls attention to an unhealthy state of things. — hako9 (talk) 21:52, 5 June 2024 (UTC)[reply]
At the end of the day, they're both 'off-wiki' forums for on-wiki activity. It is impossible to separate the two. The stewards and admins of Wikipedia perform very different functions on Discord; naturally so, as they are not subject to community oversight. ——Serial Number 54129 19:57, 4 June 2024 (UTC)[reply]
That makes sense SN. Lightburst (talk) 05:24, 7 June 2024 (UTC)[reply]
It is impossible to separate the two. – I disagree, unless you were just referring to the idea of treating all off-wiki communication platforms the same. One is specifically tailored towards criticism and, ahem, other things. The community Discord however is meant to facilitate the work that goes on on-wiki in a positive way. Whether we always succeed in doing so is debatable (there is a genuine effort there from what I see), but the intent and purpose of the two are very different. Hey man im josh (talk) 20:07, 4 June 2024 (UTC)[reply]
I think there is a big difference in any random place off-wiki and the Discord, which is managed and moderated by Wikipedians and where you have to actually authenticate yourself to participate (or to see anything there). We've been down the road of treating "off-wiki" by semiofficial wateringholes as verboten to talk about, and that did not work out well. Treating Discord as a place where you cannot be held to account on-wiki but which everyone can see is not a winning combination. Der Wohltemperierte Fuchs 20:03, 4 June 2024 (UTC)[reply]
I'm just reading along from my watchlist and not planning to deep dive into this discussion (yet), but to clarify: The Discord server does not require authentication, though almost all long time users do so. Everything (but the noted admin area, similar to the IRC admin channels) is visible without doing so. Note this is specific to the main Discord. Some language projects (i.e., not enwiki) DO require authentication. -- ferret (talk) 20:09, 4 June 2024 (UTC)[reply]
I want to comment about the third bullet point in JSS's opening post, about whether it is appropriate to email ArbCom. In a general sense (separate from RfA specifically), community practice is to email private evidence of wrongdoing to ArbCom (or in some cases, Functionaries), with the exception of evidence about COI, where we now have a dedicated email queue. I doubt that we need ArbCom to establish another email system for RfA (although if recent events become a trend, eventually we might). Given that, and given that ArbCom does have a specified role for admin wrongdoing, I see nothing wrong with expecting that such evidence must be submitted privately to ArbCom when brought up in RfA discussions (although perhaps we need an RfC to make that a requirement). The problem I see with that is that there is generally a need for a prompt response during an RfA, and ArbCom tends not to be prompt. --Tryptofish (talk) 21:44, 4 June 2024 (UTC)[reply]
This, to me, is the crtux of the issue we are seeing before our eyes right now. A few users are opposing based on a few completely inncuous comments at an off-wiki site, basically because "admins can't do that, at all, ever, no matter what it is they say, and if they do they are complicit in literally everything else that goes on in the entire forum". I feel like this is an attempt at creating a chilling effect where users are meant to be afraid to be critical on these forums, or to comment in them at all. How are RFA particpants to judge this opposition when, currently, we apparently can't even say where it is? Just Step Sideways 22:05, 4 June 2024 (UTC)[reply]
I doubt that this is something that is causing worthy RfAs to go down in failure. We've always had opposes at RfA that happen, cause angst, but don't sink the candidate. Editors familiar with what happened elsewhere can say whether or not they think there was a real problem, and other editors can decide for themselves who to believe or not believe. That's what I did in my support: [1]. (Where I also used a three-letter acronym, uh-oh!) --Tryptofish (talk) 22:12, 4 June 2024 (UTC)[reply]
As a seperate issue, I have just filed an WP:ARCA request for the committee to clarify some policy points related to how or even if we are allowed to discuss these things on-wiki. Just Step Sideways 22:47, 4 June 2024 (UTC)[reply]
Of course we can discuss things in general. A specific outing of someone is not appropriate. But if they have outed themselves, then they gave away the right to that privacy. But the committee can make their own pronouncements. Graeme Bartlett (talk) 00:21, 5 June 2024 (UTC)[reply]
I wanna link to the snotty thing JSS just said about me at that other site. --Tryptofish (talk) 21:53, 19 June 2024 (UTC)[reply]
The obvious solution is to drop the charade. If Wikipedia editors are talking about Wikipedia, on a public forum, devoted to commentary of Wikipedia, using an account that is clearly linked to their Wikipedia account, then we should be able to discuss it openly here on Wikipedia. It's not outing, not "logging", not a copyright violation, or any of the other ridiculous, self-serving excuses that people have come up with for this taboo over the years. ArbCom has no role to play: their remit isn't "off-wiki evidence", it's matters unsuitable for public discussion, and what we're talking about here is already under "public discussion", by definition. – Joe (talk) 07:50, 5 June 2024 (UTC)[reply]
@Joe Roe: Perhaps I'm missing something, but I don't believe there's any authentication between that other forum and on-wiki unless it's admitted on-wiki, since we can't exactly trust that someone is the same person on that site just based on the user name alone. The community Discord however does have a bot that authenticates you as an on-wiki user. Hey man im josh (talk) 13:22, 5 June 2024 (UTC)[reply]
To my knowledge there's never been an example of someone impersonating an editor on Wikipediocracy to get them into trouble on Wikipedia. If that ever did happen, I imagine the matter would be very quickly resolved by the target saying "that's not me". Otherwise, I think it's safe to assume that people are who they say they are, authentication process or not. – Joe (talk) 13:27, 5 June 2024 (UTC)[reply]
I was impersonated on Wikipediocracy on January 2, 2024. A thread was started by someone with the same name as me impersonating me. It may be more common than you think. –Novem Linguae (talk) 15:47, 5 June 2024 (UTC)[reply]
That assumes that the target keeps up with all the many sub-"forum" pages on WPO, which surely at most only a handful of people do, and they wouldn't be the ones to be impersonated. Johnbod (talk) 16:15, 5 June 2024 (UTC)[reply]
Just to note one other thing - some active participants on Discord (including myself) don't have a Wikipedia account to link, so there's no way to tell for sure that the person behind this IP at the moment is the same person named Tarlonniel over on Discord, beyond taking my word for it. 57.140.16.48 (talk) 21:17, 6 June 2024 (UTC)[reply]
1. So long as the current consensus on Discord chat logs remains in force, mention of them must be avoided entirely instead of using an actual live RfA's !oppose section to re-litigate it by bringing up veiled accusations that stick to the letter of the Discord Logs RfC but not its spirit, no matter if one thinks it's just a charade, or ridiculous, or self-serving, or any such adjective one can think up. Any change to that consensus should be sought in a new RfC.
Personally I will disclose any of my Wikimedia Discord messages to whoever asks, and I won't be opposed to being able to link to messages on the server so long as the users are authenticated. But that is me. Community consensus is that people would rather keep their Discord comments private. Change that first.
2. Yes lol, the English Wikimedia Discord server enforces enwiki's own civility rules far more actively than enwiki itself. Blocked users aren't allowed to harp on their blocks and How Much They Hate Wikipedia day in and day out, unlike WPO where that is the express purpose.
3. If community consensus is something worth respecting, then given the current consensus, emailing ArbCom is the only way to bring up problematic Discord messages. Of course, if consensus shifts to allow Discord logs to be posted publicly, this will be moot.
Wilhelm Tell DCCXLVI (/my edits) 09:56, 5 June 2024 (UTC)[reply]
Let's say I send you an email, out of the blue, saying Hi Wilhelm Tell, I think you're stupid, but please don't tell anyone else. Best wishes, Joe. And then some years later, you're asked to be on a committee to decide whether I should be given the Friendliest Wikipedian Award. Are you not going to mention the email, because I would "prefer to keep it private"? Oh and remember you can't just vote against me without saying why, because if you try the other members will accuse you of malfeasance and argue for you to be ejected from the committee. – Joe (talk) 10:08, 5 June 2024 (UTC)[reply]
Isn't this what Arbcom is for? You can just email your evidence of off-wiki harassment, then disclose the fact that you emailed them when explaining you vote? Because, in this specific situation, to prove that the person said what they said (and that you didn't just lie) you'd have to give out some pretty private information that would have to go through Arbcom anyway. GreenLipstickLesbian (talk) 10:15, 5 June 2024 (UTC)[reply]
But what is ArbCom supposed to do with it? Wilhelm Tell is upset with my vote here. I could have appended "which I've notified ArbCom of" to the first clause (because, as a matter of fact, I have, several times), but what difference would it have made? – Joe (talk) 10:30, 5 June 2024 (UTC)[reply]
ArbCom will evaluate the nature of the comments then? And they can decide whether or not to block the editor based on the evidence of offwiki abuse, thus preventing their election...? Also, I'm not upset, I only think community consensus should be respected in both letter and spirit, even if you think it's stupid. I reiterate that I will be fine with the Wikimedia Discord being linkable, I don't think we're disagreeing there. Also, if you did send me such a mail, I would be quite amused. You can try it out now ~ Wilhelm Tell DCCXLVI (/my edits) 10:47, 5 June 2024 (UTC)[reply]
@Wilhelm Tell DCCXLVI In the context of a time-limited RFA, it seems pertinent to note that ArbCom moves at a very slow pace. Mach61 13:10, 6 June 2024 (UTC)[reply]
This makes me wonder - what was the timeline of Icewhiz/Eostrix being blocked during his RfA? Was Arbcom informed or someone else? Wilhelm Tell DCCXLVI (/my edits) 13:34, 6 June 2024 (UTC)[reply]
Someone should correct me if I'm wrong, but my recollection is that ArbCom enacted the block during the RfA, but ArbCom had been in the process of investigating the Eostrix account for some time prior to the beginning of the RfA. --Tryptofish (talk) 20:16, 6 June 2024 (UTC)[reply]
You're mostly right; we had flagged the account earlier in the year as a potential sock, but the RFA was really the impetus for finally making the connection. Primefac (talk) 20:33, 6 June 2024 (UTC)[reply]
If, hypothetically, the account had not been flagged earlier, but was flagged right around the beginning of the RfA, would ArbCom have been able to work it out within the time-frame of the RfA? --Tryptofish (talk) 20:41, 6 June 2024 (UTC)[reply]
Probably, especially if we asked for assistance from the CU team. Primefac (talk) 20:49, 6 June 2024 (UTC)[reply]
Decide whether or not the candidate violated the specific policies you named in your vote? It's not perfect, but it's the best system we got. I always did prefer the story about the giant bug to the one about the court, anyway. GreenLipstickLesbian (talk) 10:47, 5 June 2024 (UTC)[reply]
@Wilhelm Tell DCCXLVI and GreenLipstickLesbian: there is a rather large gulf between 'something that stops me supporting an RfA' and 'off-wiki harassment meriting an ArbCom block'. Unlike user conduct forums—which is where the 'send it to ArbCom' rule comes from—you don't have to point to a specific policy violation or disruptive behaviour in an RfA. Editors are perfectly entitled oppose a candidate because they just don't think they'll be a good admin, don't like them, and/or get bad vibes – whether that's based on interactions on- or off-wiki. – Joe (talk) 11:44, 5 June 2024 (UTC)[reply]
I have no interest in your vote, and nor have I expressed one. You asked a question about a hypothetical scenario. I answered. I am beginning to suspect that the question was rhetorical. Was it? GreenLipstickLesbian (talk) 11:55, 5 June 2024 (UTC)[reply]
I'm not talking about my vote specifically, I'm talking about RfA in general. My hypothetical question was supposed to be an analogy for RfA, because this is a discussion about RfA on WT:RFA, but sorry if the use of a counterfactual scenario confused things. (It was also, incidentally, directed specifically at Wilhelm). – Joe (talk) 12:09, 5 June 2024 (UTC)[reply]
I'll freely admit I don't know of an effective way to oppose the Discord logs consensus in the oppose section of an RfA. But I do know you shouldn't be opposing the Discord logs consensus by breaking it. It appears to me the better course of action would be a fresh RfC. Wilhelm Tell DCCXLVI (/my edits) 12:32, 5 June 2024 (UTC) P.S. A wise person once said if something seems systemically broken on Wikipedia, that may be on purpose, to prevent you from doing what you wanted to do in the first place.[reply]
Caveat: I speak only in terms of WP:Discord, and not in general of usage of Discord outside of that specific server. Community consensus is that people would rather keep their Discord comments private. I don't think this is the consensus at all. It's certainly not why I !voted the way I did in the RFC, and anyone who believes that their Discord messages are private is very very sorely mistaken. Joe can call it ridiculous, self-serving excuses if he likes, but I based my position on my reading of the policies and community expectations as I understood them at the time. However, the Discord server has long stated up front (prior to the RFC), both on it's project page and its Server Guide / Info channel, that the messages posted are public and can be read by anyone that joins. The RFC is a silly result that comes from how our policies/guidelines are written. I've noted this in the ARCA as well, but some people take OUTING so far as to suggest mentioning personal details on the userpages of an editor on another Wikimedia project is forbidden. That's obviously silly as well, in the post-SUL world at least. My personal hope is some guidance at ARCA results in some clarification that can then be channeled to a new RFC, that at least takes the Discord question out of this equation. I have no comment on WPO. -- ferret (talk) 14:39, 5 June 2024 (UTC)[reply]
I should clarify by "private" I meant that community consensus seemed to be that people didn't want Discord chat logs linked here. Obviously anyone can click on the invite and see every message since 2016. Wilhelm Tell DCCXLVI (/my edits) 16:15, 5 June 2024 (UTC)[reply]
speaking to question 2: i'm very active on the discord, and i've found some of the comments at Elli's RfA about the discord to be really far out of whack with what it's actually like on there. the moderators are, to their credit, very proactive in shutting down even a hint of misbehavior, to the point where it can even be a bit over-bearing occasionally. the abundance of caution on the part of the moderation team, especially where eg canvassing is concerned, is in part a reaction to what the server used to be like, as well as the history of off-wiki shenanigans that have landed at ArbCom's doorstep over the past 2 decades.
for those not on the discord or not aware of the rules there, one is generally not allowed to even neutrally link an ongoing RfC/XfD/etc or even discuss an active RfA at all. doing such is usually shut down by whoever's active in the chat at the time, whether moderators are there or not - in other words, the discord community does a good job of self-moderating against canvassing (or even the appearance of canvassing) without the moderators needing to enforce it themselves. the prohibition of discussing ongoing RfAs is particularly well-enforced in the wake of Vami_IV's passing, and some of the very difficult RfAs that members of the server have gone through previously. basically, the discord community wants to avoid adding more stress to an already stressful process.
now, i'm not active on WPO and never have been, but this to me seems like basically the exact opposite. ... sawyer * he/they * talk 20:32, 5 June 2024 (UTC)[reply]

Sdkb RfA debrief

Hi all! I wrote a debrief of my RfA from February and have added it to the debriefs page. You can read it at User:Sdkb/RfA debrief. Cheers, Sdkb  22:38, 4 June 2024 (UTC)[reply]

Some additional conversation at User talk:Sdkb § RfA debrief. Sdkb  16:48, 5 June 2024 (UTC)[reply]

Clovermoss RfA debrief

Sdkb's debrief above reminded me that I really should get around to writing mine. It can be found here. Clovermoss🍀 (talk) 13:04, 7 June 2024 (UTC)[reply]

Floq's RFA debrief

What a wonderful procrastination opportunity. I'm just self-important enough to think that a third one would be useful too. I assume there's some central repository to link to these? Anyway, it's here. --Floquenbeam (talk) 17:23, 7 June 2024 (UTC)[reply]

Wikipedia:Requests for adminship/Debriefs. Firefangledfeathers (talk / contribs) 17:25, 7 June 2024 (UTC)[reply]
Thanks! Floquenbeam (talk) 17:25, 7 June 2024 (UTC)[reply]

Are admins automatically CUd?

I thought all candidates were ran through checkuser, however I cannot find written mention of this and don't want to hallucinate something that happened one time to be procedure. L3X1 ◊distænt write◊ 18:02, 18 June 2024 (UTC)[reply]

@L3X1: no, they aren't. This has been proposed and rejected before. Elli (talk | contribs) 18:04, 18 June 2024 (UTC)[reply]
I think it has also been something of an "urban legend" type belief that this actually is done but kept quiet. If it is kept quiet, it is being kept so quiet that even arbcom aren't aware of it. There was this RFA, in which the committee was made aware of a suspiscion that the candidate was a sock of banned troll, and a subsequent investigation produced evidence that this was the case. Basically there has to be an actual reason to CU an admin candidate, or to use CU in any other capacity. Just Step Sideways 22:18, 18 June 2024 (UTC)[reply]
thanks for the link, that's the rfa I had in mind. L3X1 ◊distænt write◊ 03:54, 19 June 2024 (UTC)[reply]

If there's any doubt that we need more admins...

...I've made a graph comparing stats across English projects. Active users per admin is in blue. Cremastra (talk) 20:20, 18 June 2024 (UTC)[reply]

That could instead just be showing that those other projects have more admins than needed. The ones you've chosen are all also kind of niche projects. It still wouldn't "prove" anything, but I'd be more curious what the ratios are like for German, Spanish, French, Hindi, Japanese, etc. etc. Wikipedias. We may very well need more admins (pending a good definition of "need"), but this graph doesn't prove it. Floquenbeam (talk) 20:55, 18 June 2024 (UTC)[reply]
My understanding is that eswiki has a more dire admin shortage than we do but that's just an offhand impression I've received from talking to people from other projects. It's possible I'm misremembering what was said. Clovermoss🍀 (talk) 20:59, 18 June 2024 (UTC)[reply]
To me this is a more stark demonstration. ScottishFinnishRadish (talk) 21:09, 18 June 2024 (UTC)[reply]
So you would actually be looking for a number of users per number of admins willing to wade into AE ratio. That's gonna be much higher. Floquenbeam (talk) 21:13, 18 June 2024 (UTC)[reply]
I'm not concerned about ratios, I'm concerned about important tasks going undone. ScottishFinnishRadish (talk) 21:18, 18 June 2024 (UTC)[reply]
That must be why Wikinews has such high quality standards and so little vandalism. Spicy (talk) 21:10, 18 June 2024 (UTC)[reply]
Wikinews is a weird case - it has many inactive admins and relatively few active users. So the stats don't follow. * Pppery * it has begun... 21:26, 18 June 2024 (UTC)[reply]
News articles there have been fully protected (in some sort?) after days of being approved and published, preventing any further vandalism on those articles. Well, vandals might seek other pages to mess around, but then what else is there for vandals? George Ho (talk) 17:55, 19 June 2024 (UTC)[reply]
Commons would be an interesting comparison. Commons is in quite dire need of administrators. Some backlogs there stretch back months, even almost a year at one point. --Hammersoft (talk) 22:28, 18 June 2024 (UTC)[reply]
Per commons:Special:Statistics, they have 203 active users per administrator. Cremastra (talk) 22:50, 18 June 2024 (UTC)[reply]
I'd be interested to see a graph showing admin backlogs over the last few years. Levivich (talk) 22:51, 18 June 2024 (UTC)[reply]
Would also be interested in this...... what we need is to unbundle some of the features so that editors not interested in being admins can do some tasks.... as we did with "template editor" many years ago. Moxy🍁 23:00, 18 June 2024 (UTC)[reply]
That's handy, but it's not the whole story, and doesn't capture the more difficult admin tasks. Average time to close, admins commenting, and reports archived without closure at AE would be good. Similar data for ANI threads, too. Backlogs at AIV/UAA/PERM/etc generally don't get too bad because they're fairly easy to clear. ScottishFinnishRadish (talk) 23:05, 18 June 2024 (UTC)[reply]
I'm not sure I'd say the same about PERM. It's not uncommon for requests to be unanswered for days and I've seen some that go unanswered for weeks. I've pitched in there a bit. I've also been taking a break from it lately for reasons that are difficult to explain. My heart just isn't in it as much and I'm a volunteer. I don't exactly have much experience with this... but I'm assuming it's normal for admin motivation to ebb and flow? Sometimes I feel the same way about new page patrolling. I'm trying not to overdo it, pace myself, and chip in where I can. But I admit there is some level of inner guilt that makes me feel like I should be doing more when I hear about backlogs. Ideally everything would just get evenly dealt with across the board but humans are complicated. It's also a bit intimidating to consider all these areas you couldn't help out in before and you don't want to mess up by just waltzing in. It's easier to avoid areas like AE for that reason. Clovermoss🍀 (talk) 00:10, 19 June 2024 (UTC)[reply]
Unbundling is just a band-aid and won't solve the underlying problem; lack of administrators. If the situation were static, it might help some. But, things are getting worse over time. Over the last year, we've gone from 471 active admins to 434, a ~8% drop. --Hammersoft (talk) 01:06, 19 June 2024 (UTC)[reply]
I entirely agree; the issue is an insufficient proportion of experienced editor effort going toward administrative tasks, made somewhat worse (IMO) by some editors who are willing in principle being deterred by the atmosphere of RFA. Vanamonde93 (talk) 03:36, 19 June 2024 (UTC)[reply]
Honestly, this is just average users per admin or average edits per page. The graph doesn't fully explain which admin is active on Wikipedia and how many active editors per active admin have been there. Of course, how about inactive editors per active admin? And what about bureaucrats? George Ho (talk) 18:02, 19 June 2024 (UTC)[reply]
The number of active editors (defined as at least one action in the last 30 days) is 117,283 (Special:Statistics). There are 436 active administrators (30 or more edits in the last 2 months) [2]. Thus, about 268 active editors per active administrator. --Hammersoft (talk) 18:11, 19 June 2024 (UTC)[reply]
Hmm... I'm unsure still whether the graph tells the full story. Still doesn't fully explain which editors have been reported to ANI and then chided, blocked, or whatever. Still doesn't fully explain which editors have been taken to ArbCom, but such cases have become infrequent recently. Still doesn't fully explain which were taken to 3RR notice, which pages were requested for protection, and so forth. Well, it's not as if an active admin wanna monitor each of 268 active editors all day and pages that such editors have been editing, right? George Ho (talk) 19:53, 19 June 2024 (UTC)[reply]
If you want to define active editor more restrictively, we have 5,032 editors who have more than 100 edits this month. [3] Clovermoss🍀 (talk) 20:40, 19 June 2024 (UTC)[reply]
This graph is comparing stats between the largest of the Wikimedia projects by far and several much smaller projects with different design goals - it's a bit like comparing the energy use of an ocean supertanker with a Honda Civic. Do one comparing English Wikipedia to large foreign-language Wikipedias, that would be a more enlightening comparison. Ivanvector (/Edits) 18:07, 19 June 2024 (UTC)[reply]

Extended-confirmed protection

Apologies if this has been brought up before, but as Svampesky suggested here (and as I had been thinking myself), why don't we have a separate page for votes à la the comments sections on The Signpost? The vote page can be extended-confirmed protected and transcluded to the main, unprotected RfA page. This way non-30/500 folks can still comment and ask questions but their votes, by nature of not being able to be cast, won't have to be publicly struck off - what we're doing now is a bit bitey imo. Wilhelm Tell DCCXLVI (/my edits) 05:37, 20 June 2024 (UTC)[reply]

Or perhaps an edit filter that specifically detects edits to the Votes section and disallows non-ECP editors from submitting a vote? Is such a section-specific filter possible? Wilhelm Tell DCCXLVI (/my edits) 05:41, 20 June 2024 (UTC)[reply]
Detecting sections probably not, but detecting votes by non-ECP editors should be easy. Nobody (talk) 06:08, 20 June 2024 (UTC)[reply]
The recent 2024 RfA review voted to prevent non-ECP editors from !voting and it was strongly supported. The closer of that review took the view that the vote was not to make the page ECP protected, but that was their view and I don't think it was properly debated.
It makes no sense that an almost new editor can make comments on an RfA candidate, and ironically, when many of the typical objections are that the candidate does not have experience. At the 2024 RfA review, it seemed clear that there have been instances where the non-ECP/IP editor was an experienced editor trying to disrupt the process and derail the RfA. Aszx5000 (talk) 09:19, 20 June 2024 (UTC)[reply]
The idea of an RfA is for any editor to bring up concerns that can refute the nominator(s)' assertion that the candidate is suitable for the mop. This is why Opposers are badgered if they don't give a rationale, even if they're otherwise respectable editors - let alone a throwaway doing the same thing and disappearing without explanation (which is why I think Kusma used the narrow language that they did while writing up the proposal, of explicitly saying comments were welcomed from all). In my opinion IPs and newbies should be allowed to bring up actual concerns, but if indeed the constructive-to-nonconstructive ratio here is extremely low as Extraordinary Writ said in Support #6, we could probably exclude them from that as well. Would need fresh consensus though ~ Wilhelm Tell DCCXLVI (/my edits) 10:39, 20 June 2024 (UTC)[reply]
Edit filters are run on every single edit page on the wiki, so they have a performance cost, and they are not usually a great choice for restricting very specific pages and sub pages. –Novem Linguae (talk) 11:49, 20 June 2024 (UTC)[reply]
I'm so stupid, I read about this technical cost just a couple days ago. Yea edit filters are off the table –Wilhelm Tell DCCXLVI (/my edits) 14:15, 20 June 2024 (UTC)[reply]
Not a bad idea, but there'd be a cost in terms of making it more awkward to edit and watchlist the voting page, especially for the first few RfAs as people get used to it. I think the simpler option of just applying ECP to the whole page would be fine. Participation by non-EC editors was already very low before they were prohibited from voting, and if the handful that do find their way to an RfA really want to comment without voting, they could do so on the talk page and ask for it to be copied over. I agree that what we do now, making it look like anyone with an account can freely edit and therefore vote in an RfA, then striking the comment—because oops didn't you read down to the sixth subsection of WP:RFA??—is a pretty unfriendly approach. – Joe (talk) 13:11, 20 June 2024 (UTC)[reply]
Right, I've thought up one more approach, so this can be framed as three proposals as below, for further input/consensus-building. In decreasing order of complexity:
  • Option 1: Votes shall be cast on a separate, EC-protected subpage that will be transcluded onto the main, unprotected RfA page.
  • Option 2: RfAs shall be EC-protected after the two discussion-only days. After this, IPs and newbies can bring up further concerns on the talk page.
  • Option 3: RfAs shall be EC-protected altogether. IPs and newbies can bring up concerns on the talk page alone.
Is there a place for this to be proposed? RFA2024? Wilhelm Tell DCCXLVI (/my edits) 14:23, 20 June 2024 (UTC)[reply]
Should consider adding an "Option 4 - No change / status quo / strike non-EC votes" if you end up RFCing this. –Novem Linguae (talk) 14:31, 20 June 2024 (UTC)[reply]
If these options are being considered, we could also consider making the watchlist notice visible only to extended-confirmed accounts. DanCherek (talk) 14:29, 20 June 2024 (UTC)[reply]
I don't think using subpages will be an issue for adding comments. Wikipedia:Arbitration/Requests is set up with subpages and editing each section happens transparently. If desired, a link could be added to the top of the section to watchlist the subpage. An extra step would be required to create the subpage. isaacl (talk) 18:39, 20 June 2024 (UTC)[reply]
  • Why are we trying to solve a very minor problem with a long RFC discussion and new technical processes? I'd prefer Option 0: Just leave it as is, and any votes by non-EC people can quickly and easily be struck by, you know, humans. Who can leave a short message on the user's talk page. I understand the use of templates and bots and protection and edit filters for stuff that's overwhelming the humans, but this isn't. If anyone else agrees with me, perhaps they can better articulate this vague feeling I have that this increasingly common approach is the Wrong Direction. --Floquenbeam (talk) 14:41, 20 June 2024 (UTC)[reply]
    I think there's a common belief that restrictions on new/unregistered users that rely on undoing/striking are more WP:BITEy than ones that technically prevent users from editing restricted spaces. I generally agree, but I don't think the trade-off is worthwhile if it inconveniences experienced editors and if the vast majority of participants are experienced. That's the case here; I'd prefer not to have a whole RfC about this, and if it does happen, I'm likely to vote Option 0, or what Novem is calling Option 4. Firefangledfeathers (talk / contribs) 14:55, 20 June 2024 (UTC)[reply]
    Well it needn't be long if we can simply find consensus right here, and these technical processes are hardly new. Most RfA regulars must be familiar with the Signpost approach and they'll be fine with whatever's up next. EC-protection is not complicated at all. The reason I am opposed to the current approach is purely because of how striking out the votes of newbies and IPs is BITE-ey. Consider their POV - they walk in, they find a community process they may be interested in, participate in it (because it seems to be allowed)... then bam, their vote has a black line through it and there's a senior editor on their page telling them they're not allowed to do that. In contrast, if they just see a blue lock right from the beginning, there won't be any hard feelings. This is pushing me towards Option 3. Wilhelm Tell DCCXLVI (/my edits) 14:57, 20 June 2024 (UTC)[reply]
    Thanks for explaining the motivation. I guess I just really disagree; having a human come and explain why they can't vote yet seems much less bitey to me. I doubt anyone who isn't allowed to vote knows what a blue lock means, so they're going to try. I think all the system message says is something to the effect of "you can't edit this page", without explaining why. Floquenbeam (talk) 15:05, 20 June 2024 (UTC)[reply]
    On desktop, the system doesn't say a thing, they simply don't get the option to edit (only to view the source). On mobile, they get "this page has been protected" or similar. Wilhelm Tell DCCXLVI (/my edits) 15:10, 20 June 2024 (UTC)[reply]
    Well, they can state a support/oppose opinion from a technical perspective; they're just not permitted to do so from a process perspective. If a human would pop up at the moment they tried to edit the page, sure, that would be ideal, but failing that, stopping them from being able to edit the page is, in my view, less confusing. isaacl (talk) 18:45, 20 June 2024 (UTC)[reply]
    Although I think that having a human explain it certainly is non-bitey, having their !vote stay on the RfA page with it struck-through isn't. For that reason, I like Options 2 and 3, because that prevents any embarrassment. There should be (yet another) note to that effect near the top of the RfA page, explaining the protection and pointing to the talk page, in the hopes that some will read it. --Tryptofish (talk) 19:48, 20 June 2024 (UTC)[reply]
  • Comment I was pinged in this. Leave it as is, the striking is okay and I didn't feel bitten. I'd've felt bitten if people got on my case about it, but no one did. I cast a new !vote and didn't reinstate the original one because it's nothing to be embarrassed about. You cast an invalid !vote, it’s not a big deal; good-faith mistakes aren't something that should be swept under the carpet. Svampesky (talk) 15:37, 20 June 2024 (UTC)[reply]
    How about this? Option 5:
    - Wikipedia talk:Requests for adminship/Username - Not protected (for comments)
    - Wikipedia:Requests for adminship/Username/!Votes - ECP protected
    - Wikipedia:Requests for adminship/Username - Not protected, but transcludes both above like The Signpost
    - Wikipedia talk:Requests for adminship/Username/Off-topic - Not protected (for the badgering) Svampesky (talk) 15:49, 20 June 2024 (UTC)[reply]
  • If protection would be too controversial, an alternative would be to have a large bold-faced red message that YOU ARE NOT ELIGIBLE TO !VOTE IN THIS RFA and then use Template:If extended confirmed and its relatives to hide it from anyone who's extended confirmed. A passing mention in the editnotice isn't conspicious enough to be noticed. Extraordinary Writ (talk) 20:27, 20 June 2024 (UTC)[reply]
    This seems like the best idea so far, since it is easy and effective and would not need an RFC. –Novem Linguae (talk) 20:30, 20 June 2024 (UTC)[reply]
    Out of curiosity, is it possible to nest if admin and if extended confirmed given that the latter doesn't hide text from admins? Perfect4th (talk) 20:43, 20 June 2024 (UTC)[reply]
    It is: see User:Extraordinary Writ/sandbox7. Extraordinary Writ (talk) 20:49, 20 June 2024 (UTC)[reply]
    This is actually harder than it looks as long as this and this remain unresolved. I guess the workaround in the current revision of User:Extraordinary Writ/sandbox7 does the trick, but maybe someone more technically minded can think of something better. Extraordinary Writ (talk) 21:40, 20 June 2024 (UTC)[reply]
    Maybe try <div class="extendedconfirmed-show sysop-show">Your message here.</div>. That might work and be a bit neater. –Novem Linguae (talk) 21:58, 20 June 2024 (UTC)[reply]
    Is there an easy way to do the opposite of that (to show it only to non-EC non-admins)? Typically <div class="nonextendedconfirmed-show nonsysop-show">Your message here.</div> would work, but interface admins haven't wanted to add nonsysop-show. Extraordinary Writ (talk) 22:10, 20 June 2024 (UTC)[reply]
    Ah, I forgot about the "else" case. Sadly, I can't think of anything better than what you have in the sandbox. –Novem Linguae (talk) 22:22, 20 June 2024 (UTC)[reply]
    The last thing is that sometimes editors with 500 edits/30 day account get EC removed. Usually it's an accident/side-effect when other roles are edited, like an admin resigning their bit. Is that enough people to add a fix for them? I don't think any template solution has a way to check edit count anyway. Soni (talk) 22:34, 20 June 2024 (UTC)[reply]
    Enacting this seems like the right move, would prevent an unnecessary RFC. As Floq said, this is a pretty minor issue that we shouldn't waste too much time with. ULPS 21:13, 20 June 2024 (UTC)[reply]

Temperature check: Applying for the Researcher right

The Researcher access right allows users to view deleted content, but not to actually delete (or block, or protect pages, or do anything else admin-y that isn't viewing deleted content).

I am one of the more active admins on Commons (and just picked back up admin on Wikidata to better deal with cross-project spam), and it would be useful for me to be able to see user's deleted English Wikipedia contributions in order to better assess whether images nominated for deletion on Commons as spam are, in fact, spam.

However, there really isn't a precedent for applying for this right, as far as I'm aware, so before I went down the path of actually trying, I wanted to do a temperature check to see if such a thing was something this community would even approve of.

Cheers, The Squirrel Conspiracy (talk) 01:36, 21 June 2024 (UTC)[reply]

@The Squirrel Conspiracy: It looks like we have 3 editors with this permission [4]. My gut instinct is to tell you that getting approved for this would be difficult. I wonder what people who are sysops on both projects think of these sorts of situations? There might be viable alternatives. Courtesy ping to Red-tailed hawk who happens to be the only person that I know to be an enwiki and commons sysop (at least off the top of my head). Clovermoss🍀 (talk) 03:19, 21 June 2024 (UTC)[reply]
I don't know of any local process to grant it. My understanding is that the WMF holds that viewing deleted data is something that requires vetting (and requires some RFA-like process or elections for a local wiki to give out a role with that right), so we can't quite give it out ad-hoc.
That being said, I believe that it is theoretically possible to create a local process to grant the right. We just don't have one on EnWiki, and the process would probably need some WMF eyes to actually get approval.
Pinging @Vermont and RAdimer-WMF: Can you confirm my understanding on this is correct? — Red-tailed hawk (nest) 02:38, 22 June 2024 (UTC)[reply]
Red-tailed hawk, thanks for the ping. I've brought this up internally and will get back to you when I can :) RAdimer-WMF (talk) 02:55, 22 June 2024 (UTC)[reply]
@Red-tailed hawk: Any ideas on possible alternatives if this perm doesn't get granted for whatever reason? I'm not sure how common the above scenario described for the use case is. If it's a small scale issue, collaboration with individual enwiki admins might make it unnessecary. It likely wouldn't be all that different from the admins who provide copies of deleted articles to users with reasonable requests. Clovermoss🍀 (talk) 03:44, 22 June 2024 (UTC)[reply]
@Clovermoss: Individual requests might be overkill. When an image on Commons gets tagged for deletion on Commons as spam and is in use in the draft space, I can check out the article and gain a lot of valuable content with just a quick glance - is this an SEO optimizer, someone writing an autobiography, a fan of the subject, etcetera. Being able to see deleted articles would extend this ability to gain said insight into situations where instead of a live draft space article, it's a deleted main space article. Most of the time, the file is going to get deleted as spam, but every once in a while, I catch that it's a fan or other genuinely good-meaning contributor that just doesn't know how to write in an encyclopedia style, and then I convert the speedy tag into a standard-length deletion discussion or outright save the image. That being said, the ratio of non-spam to spam among files tagged for speedy deletion as spam is pretty low, and the volume of such files is decently high, so I'd be doing, say, a lot of pinging admins on Discord to save very few files. The Squirrel Conspiracy (talk) 06:06, 22 June 2024 (UTC)[reply]
There is a lot less friction if one does not have to involve someone else. We needn't use time from two persons to achieve one task when time from one would do quite well. — Red-tailed hawk (nest) 05:53, 24 June 2024 (UTC)[reply]
First, I'm not sure who exactly can assign the researcher right, but I can tell you English Wikipedia admins can't. It looks like it may be a WMF-only thing. Secondly, maybe a friendly neighborhood WMF person (or bureaucrat, if they're capable) can remove researcher from the three people that currently have it? It doesn't seem like it was ever meant to be a permanent right. Finally, TSC, if you have any interest in being an en.wiki admin, I'd welcome an RfA. In addition to the cross-wiki spam you mention, you'd be an asset at WP:ERRORS. Firefangledfeathers (talk / contribs) 03:53, 21 June 2024 (UTC)[reply]
This log does give the impression that these permissions were meant to be a temporary thing [5]. Clovermoss🍀 (talk) 03:59, 21 June 2024 (UTC)[reply]
Only Stewards (and I guess sysadmins and WMF trust and safety but they probably won't get involved here) have the technical ability to assign the right. That fact doesn't really matter much here as I'm sure if whatever the community decides is the process for this is followed sufficiently one of them will be happy to oblige. * Pppery * it has begun... 04:20, 21 June 2024 (UTC)[reply]
This situation also reminded me of Wikipedia:Requests for adminship/lustiger seth. It's rare, but there's definitely precedent for us to RFA someone who's already trusted elsewhere and use adminship in highly technical situations. Not sure how much this applies here though. Soni (talk) 06:08, 21 June 2024 (UTC)[reply]
All three +researcher were performed by the WMF, and the first team at least were intended to be temporary, but never removed. MarcGarver (talk) 10:59, 21 June 2024 (UTC)[reply]
In fact, based on the page at Meta, created by the WMF team, EpochFail and Jtmorgan can have the rights removed without further discussion as they were clearly only granted until 1 September 2011. MarcGarver (talk) 11:10, 21 June 2024 (UTC)[reply]
Well, I tried to do so and am somehow unable. Filed phab:T368577. Joe Sutherland (WMF) (talk) 19:33, 26 June 2024 (UTC)[reply]
As an update to anyone not following phab/meta, all three users had their researcher rights removed. So it's currently an empty user-right. Soni (talk) 23:06, 28 June 2024 (UTC)[reply]
  • Short answer: You'd apply via WMF. This community didn't ask for this permission to be built here, it was forced by the site owners, who control it. — xaosflux 12:20, 21 June 2024 (UTC)[reply]
  • I think the correct way to do this would be to gain consensus that these set of rights can be unbundled, create a new userright with permissions analogous to the current researcher userright and then have it be assigned by bcrats or admins based on a community procedure/vote, all of which are a lot of work for the specific situation you are describing. Regarding the researcher right, I'm pretty sure that (AFAIK) it is only given to peeps who are working on a research project that requires access to deleted edits (say something like Empowering newbies: Investigating Harassment and Safety in Wikipedia), and I would assume that it would have to be assigned after WMF review.Sohom (talk) 14:23, 23 June 2024 (UTC)[reply]
  • I don't think there's community consensus to grant this perm to additional folks. It sounds like the 3 folks that were granted this 9+ years ago were granted it by WMF staff accounts. –Novem Linguae (talk) 03:58, 24 June 2024 (UTC)[reply]
    Exactly right - unfortunately we were a lot less organised that long ago, so there were no logs maintained for the issuance of these rights. I think it's totally fine to remove them, once it's possible to do so. Joe Sutherland (WMF) (talk) 19:35, 26 June 2024 (UTC)[reply]
  • The Squirrel Conspiracy: to get specific answers to questions about deleted content, you can ask at WP:REFUND you could get an opinion, a snippet of content, perhaps a restore as a draft, or an email with the content. So for occasional investigations, this would be far easier than creating a new user group and the procedures to cope with it. Graeme Bartlett (talk) 10:58, 24 June 2024 (UTC)[reply]
    or a RfA. 😁 – robertsky (talk) 11:04, 24 June 2024 (UTC)[reply]
  • I agree with Soni, I think Lustiger seth's RFA is the best equivalent to this. That passed at 77%, but it was in 2008. IMHO, a "view deleted edits only" RFA should pass for the same reason LS's did, but I have no idea what would happen today; community opinion is (for me) harder to predict these days. If you started an RFA with the attitude "if this fails, it will be because of people's opinion on how RFA should work, not their opinion of me specifically, and I will not let it hurt me", I think you might have a decent shot. Especially since I don't think there are currently other workable options. --Floquenbeam (talk) 12:21, 24 June 2024 (UTC)[reply]

WMF reply about userrights

Hey howdy, I was invited to comment by Legal via RAdimer-WMF since it's generally T&S who give out rights to staff. Looks like, as people have noted, this one was provided a long long time ago, before we maintained internal logs and before we had a robust requesting system. (The long-story-short is that we only provide rights to staff when necessary for job actions and only with approvals from their managers and/or our T&S Global Head.) Generally you all can do as you want with the Researcher right, but historical precedent would suggest splitting up the admin tools like this on a larger scale would likely require consensus. Joe Sutherland (WMF) (talk) 20:50, 28 June 2024 (UTC)[reply]

@JSutherland (WMF): you all can do as you want: Are you ... sure? I was under the impression that WMF-legal required that anyone wanting deletedtext rights had to go through an "RFA or an RFA-like process". Has this changed? If a wiki holds an RFC tomorrow, and the outcome is "admins can unilaterally hand out researcher rights to anyone who asks nicely" WMF-legal would not object? Suffusion of Yellow (talk) 21:33, 28 June 2024 (UTC)[reply]
Oh yeah, my bad, that's still technically the stance since I don't think it was ever re-evaluated (meta:Limits to configuration changes, Wikipedia:Viewing deleted content). Both of those stances are at this point thirteen years old in fairness, but yeah, you're right in that they're still current. Joe Sutherland (WMF) (talk) 21:40, 28 June 2024 (UTC)[reply]
@JSutherland (WMF) Could WMF/WMF-Legal clarify if those stances have changed in the last 13 years? Or the more general "What rights can be unbundled from admin without requiring an RFA-like process"?
This question has come up in RFA adjacent discussion for a few years with the WMF's final say being a deciding factor in "We cannot do this". Knowing which are currently considered un-bundleable will help enWiki evauate if any of them will be better off as separated. Soni (talk) 22:52, 28 June 2024 (UTC)[reply]
Seconding this request. I'm generally not in favor of unbundling (and I don't think the community is either), but it would at least be good to know if the options have changed. The Wordsmith 23:00, 28 June 2024 (UTC)[reply]
WMF appears to have actually gotten more lax in the viewdeleted requirements as the years go on, as the most recent stance appears to be that CU/OS can even be handed out without adminship or a community election process, so long as ArbCom allows community feedback. See here. I would be interested to see if the community would be in favor of unbundling these types of rights, though I think the chances probably sit somewhere just above "dead in the water" and below "it's possible?" in regards to actually getting an RFC. EggRoll97 07:41, 1 July 2024 (UTC)[reply]
Fwiw, a bunch of projects have non-admin CheckUsers, and the method of appointment is constrained to elections or ArbCom appointments. Personally, I strongly recommend against projects appointing non-admin CUs; it makes it a lot harder to make blocks based on nonpublic information when the people who have to make those blocks (non-CU admins) can't have that information. Vermont (🐿️—🏳️‍🌈) 17:58, 3 July 2024 (UTC)[reply]
meta:Limits to configuration changes should be updated to meet current standards wrt handing out CU/OS. And personally, I agree. But I also would like clarity on what specifically can/cannot be unbundled (even if it's arbcom instead of elections). It'll let the community decide if anything else is better off as "Arbcom appoints" or even "Crat/admin appointed", even if I cannot currently think of any, offhand.
(I have emailed this question to ca@wikimedia.org per Joe's suggestion) Soni (talk) 18:14, 3 July 2024 (UTC)[reply]
It seems up-to-date to me: stewards handle the technical granting and removal of CU/OS pursuant to the global CU and OS policies. Vermont (🐿️—🏳️‍🌈) 18:20, 3 July 2024 (UTC)[reply]
Ah I was missing that distinction, thank you. Is there a general "Arbcom can request stewards to assign these rights" list somewhere? Or is it just a special exception for CU/OS. Soni (talk) 18:34, 3 July 2024 (UTC)[reply]
All grants for CU/OS are handled on Steward requests/Permissions. When ArbCom seeks to appoint a new CU or OS, they leave a request on Meta and a steward will verify and action it. If a project without an ArbCom elects a new CU or OS, they'll leave a request at the same place with a link to the discussion, and we'll verify it was done in line with policy. Vermont (🐿️—🏳️‍🌈) 20:42, 3 July 2024 (UTC)[reply]
I think this question would need to be emailed to the team for discussion internally (and to track it for metrics etc) - ca@wikimedia.org Joe Sutherland (WMF) (talk) 21:39, 1 July 2024 (UTC)[reply]
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Requests_for_adminship&oldid=1232456872"