Jump to content

Wikipedia talk:Administrator elections/Archive 5

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1โ†Archive 3Archive 4Archive 5Archive 6

This isn't working

I've been mostly away for a bit and missed all of the build up and discussion to this, but I think being an admin is a relatively big deal. There are far too many people running, the vetting for most users is close to the bare minimum, and discussions appear to have closed so I can't flag any concerns. I get RfAs aren't working either, but I'm really unsure how this process is improving the community. SportingFlyer TยทC 02:45, 28 October 2024 (UTC)

I'm not saying the ongoing process is perfect, but I would have thought the potential for improving the community is obvious - new admins join the corps and contribute their time to helping Wikipedia function. Wherever you fall on the WP:NOBIGDEAL spectrum, we as a community need to be more willing to try new things. We won't know for certain whether we've succeeded until we see the elected admins out on the Wiki doing work, but isn't it worth a shot? Or are we so sclerotic that we will let the encyclopedia's cogs and gears clog and stall while we spend hundreds of hours arguing over which grease to use, where to apply it, and precisely how many miligrams are needed? โ€”Ganesha811 (talk) 04:50, 28 October 2024 (UTC)
This. Let's vote, wait, and see. If you have a better idea, out with it, but if not, this is what we've got. TOADSPIKE [Talk] 21:08, 29 October 2024 (UTC)
  • Speaking as someone standing I share some of SportingFlyer's concerns. This is especially when you compare the page-views for the most recent traditional RFA to the candidate pages in this process - it's clear this process so far just hasn't had many eyes on it compared to the traditional RFA (at least on a per-candidate basis) and that the candidates with the most views are those higher up in the list (so people are just clicking on the first few). You also see this in some of the abortive voter-guides where people have apparently gotten part-way through the list and just given up (e.g., this, this, this). Kudos to the ones who did it all the way to the end (e.g., Femke's guide, Asilvering's, Novem Linguae's, Significa liberdade's and Timbo's over at WPO).
    If I had to guess as to why, I'd say it's because there have been a lot of talk-page notifications related to these elections, over a long period, and so some users have mentally tuned them out.
    On the plus side there's been more than 400 votes (no "!") cast, and I have to assume most of those won't be abstains. That's more than we would see in any single high-engagement RFA.
    For me personally, if I pass I can only assume it's because few have a problem with my candidature. But also, if I don't pass then I won't have the first clue as to why not because no-one has raised any objections at all. Keep thinking positive I guess. FOARP (talk) 09:00, 28 October 2024 (UTC)
    Yeah I agree with the above concerns about this - there were too many candidates for this election - as you pointed out, I couldn't finish my public notes in time, "only" reviewing 16 candidates (this was partially due to IRL concerns as well). But this is a trial run, and this is a very useful thing to learn, and a easy problem to mitigate next time - eg. we could stagger the discussion phases so no more than 5 candidates are being discussed at once, or we could make WP:ORCP's a mandatory requirement for candidates (to weed out NOTYET candidates and to get some initial due dilligence prior to the election, and to make running less of a "why not toss my hat in the ring and see what happens" decision). It was definitely a problem this election but it doesn't have to be for the next one. BugGhost๐Ÿฆ—๐Ÿ‘ป 09:30, 28 October 2024 (UTC)
    To clarify: I don't agree with the sentiment that "This isn't working" - regardless of the number of candidates and the fact it was difficult to review them all thoroughly this time round, I think the actual election process was successful in its aims of getting more candidates to step forward and to reduce contention during discussion. BugGhost๐Ÿฆ—๐Ÿ‘ป 09:44, 28 October 2024 (UTC)
    I think it can be improved from where it is, primarily by cutting down the number of candidates for any single election, and maybe extending the discussion period at least over a weekend. At least in the numbers that count (candidates, votes-cast) it may be called a success already. I'm also not sold on a secret ballot system, since I expect there will be opposing votes without any explanation of what they were based on, but I guess that boat has probably sailed already.
    I'm not sure drama will be avoided in the long run. Based on the people who are saying who they are voting for, it looks like anyone who any doubts at all were raised about in the discussion phase may have a hard time passing - the essential issue of people not getting through because minor long-ago issues serve as a catalyst for oppose-voting is still there. FOARP (talk) 11:00, 28 October 2024 (UTC)
    I expect there will be opposing votes without any explanation of what they were based on - this is true, but this is a natural consequence of a new system that attempts to shield candidates from harsh criticism. If you look at the "should voter guides be allowed" discussion from a couple of weeks ago there's a significant amount of people who want this system to prioritise candidate welfare at the expense of more thorough/public vetting. I understand the motive behind that thought but I agree that it might make it harder for candidates in the long run if they are unsuccessful the first time. BugGhost๐Ÿฆ—๐Ÿ‘ป 11:58, 28 October 2024 (UTC)
    I agree this particular point is not a big deal, especially since a candidate can always opt for the traditional process instead. โ€”Compassionate727 (TยทC) 21:05, 28 October 2024 (UTC)
    Three thoughts: 1) yes, if a candidate wants a thorough discussion of all their flaws since they first posted, they can opt for the RfA; 2) if a candidate is unsuccessful, they could always open a discussion on their own Talk page and invite feedback on why they were unsuccessful; 3) It's not like a secret ballot is a new and radical invention. Society has been using them for a long time. Why is a secret ballot viewed with such suspicion on Wikipedia? Mr Serjeant Buzfuz (talk) 13:26, 3 November 2024 (UTC)
    "Why is a secret ballot viewed with such suspicion on Wikipedia?" Perhaps because it's trivially easy to create accounts with pseudonyms and not so easy to create real-world voters? Espresso Addict (talk) 03:47, 4 November 2024 (UTC)
    To make sure I understand the concern on this point, are you worried that the bar for eligibility isnโ€™t high enough, or that it wonโ€™t be possible to enforce? Innisfree987 (talk) 04:12, 4 November 2024 (UTC)
    Innisfree987 I was attempting to give a (somewhat flip) answer to a (possibly somewhat flip) question. It seems very clear, at least to me, that it is easier for those people who wish to facilitate the promotion of corrupt admins (or to prevent the promotion of virtuous editors) to manipulate any secret voting system, than to manipulate an open-commenting system such as RfA. Espresso Addict (talk) 04:40, 4 November 2024 (UTC)
    I've finally finished my voter guide. However, I can say one thing about this process: We need to extend the discussion phase from 3 days to 5, because it is not at all worth exhausting myself just to find relevant information in such a short time. Mox Eden (talk) 20:51, 30 October 2024 (UTC)
I'm really unsure how this process is improving the community. The premise behind admin elections is the RFA process is too toxic/difficult, so we needed a process that is more candidate friendly. By that metric, admin elections has been a success. We had 32 candidates make it to the voting phase, which is more admin candidates than the entire rest of this year. Not saying this to preach. This process has plenty of problems too. But hopefully that answers your puzzlement about how a process like this is expected to help the community. โ€“Novem Linguae (talk) 09:12, 28 October 2024 (UTC)
I'm not puzzled. I'm actively saying that I don't think this new process is very good. SportingFlyer TยทC 17:04, 28 October 2024 (UTC)
Do you think the concept is irredeemable? I feel like with a few parameter tweaks (eg. discussion length, candidate number caps) a lot of your criticisms would be mitigated. BugGhost๐Ÿฆ—๐Ÿ‘ป 18:16, 28 October 2024 (UTC)
With your tweaks it would just become multiple RfAs at once with a ballot instead of a list of votes. I don't think it is irredeemable, but if we're holding the concept of being an administrator to a high standard, I think it might be. SportingFlyer TยทC 21:25, 28 October 2024 (UTC)
That's the whole point though. The vast majority of active admins became admins at the time where there were far fewer eyeballs, less vetting, questioning and toxicity in the process. The reason why this proposal achieved consensus in the first place was because maintaining the status quo and excessively high standards which didn't exist in the past was considered to be a not-so-good idea among a big section of the community. Gizza (talk) 00:05, 29 October 2024 (UTC)
Even if all 32 get the mop, we will still be down on admin numbers. Hawkeye7 (discuss) 02:32, 29 October 2024 (UTC)
I understand why we're trying it. I'm not against trying it. I'm just saying the current format is too much work given that I'm someone who takes voting in an RfA fairly seriously. Perhaps others don't, and that's fine. SportingFlyer TยทC 15:49, 29 October 2024 (UTC)
  • I have to agree that there are too many candidates running. It's overwhelming to look at all of them and most people aren't putting in the effort. Honestly: I opposed any candidate whose name I didn't recognize and only glanced at the other dozen before making my decision. I hope this many candidates is a first-time one-off; if not, there may be a need to limit the number of them. โ€”Compassionate727 (TยทC) 21:02, 28 October 2024 (UTC)
    The way I approached voting was to vote neutral in the four cases where the discussion was insufficient to determine anything and I was unfamiliar with the folks. I don't see much evidence of people supporting whilly nilly, and believe this blind opposing will lead to a worse outcome. The candidates I'm voting neutral on are all active in admin-adjacent areas, which means there will be people out there who can judge them fairly. In terms of voter effort, I can recommend reading User:Significa liberdade/EFA, which has a good summary of strenghts and weaknesses of the candidates, synthesizing the key parts of the discussion and other candidate overviews. โ€”Femke ๐Ÿฆ (talk) 08:14, 29 October 2024 (UTC)
    (ec) I rather hope that's a rare response. But large numbers of oppose votes from people who haven't the time to assess the candidates would be an unfortunate result of this trial, and would leave a number of candidates wondering why people had opposed their RFAs. I have limited time/internet access this week and either may not vote at all, or just support a couple of candidates who I know from multiple interactions, and oppose any where a cursory glance throws up things that are red flags to me. Abstain is an option and I may use it on more than two dozen who I don't have the time to properly assess but who don't have any obvious downside. ฯขereSpielChequers 08:27, 29 October 2024 (UTC)
    I hope very few people default to oppose (or to support); either would be quite unfair, I think, and I agree with Femke and WereSpielChequers that blind opposing would harm this trial for no good reason. I agree that we should limit the size of the pool in future elections, if there are any. Mike Christie (talk - contribs - library) 10:37, 29 October 2024 (UTC)
    Why did you oppose rather than abstain? A lot of people spent a long time vetting all the candidates and people just opposing everyone they don't immediately recognise reverses that effort. A "don't recognise the name, didn't have time to vet properly" oppose !vote at a traditional RfA would be correctly ridiculed. BugGhost๐Ÿฆ—๐Ÿ‘ป 11:39, 29 October 2024 (UTC)
    I'm a little surprised there aren't more people who are doing the same thing. My primary concern when reviewing admin candidates is their temperament, because an admin with the wrong temperament can create tons of drama and additional work. Unfortunately, the optional questions are a poor way of determining someone's temperament. There's really only two options: either you can do a deep dive into their talk and Wikipedia namespace participation, or wait for someone who has had a bad experience with the candidate to appear and say so. In a traditional RfA, there's plenty of time for the former, and the latter seems to happen inevitably. This election has not provided adequate opportunity for either. I'm concerned by that lack of scrutiny. Under the circumstances, I would rather see tons of people fail (which, if it did happen, I think would be blamed on the experiment and not meaningfully hinder their future prospects for adminship) than tons of people pass whose temperament will cause problems later. โ€”Compassionate727 (TยทC) 20:14, 30 October 2024 (UTC)
    I read at least a few AN(I) threads for all the candidates (all of them where they were mentioned by name in a heading), and did not have any concerns that weren't brought up eventually during the discussion phase. I'm not too concerned with temperament for the cohort in general. โ€”Femke ๐Ÿฆ (talk) 21:01, 30 October 2024 (UTC)
    Seriously. I really hope "oppose because I haven't looked into them" isn't a common refrain in this election. PhotogenicScientist (talk) 18:10, 31 October 2024 (UTC)

First, the only way anyone will think this process "worked" is if we get a bunch of admins out of it, so let's see what happens. If we do, let's separate the number of candidates from the process itself in the post-mortem. I agree there were too many to properly consider, but let's say we did a coordinated push where we got the same number of candidates to do a full RfA. We'd still get complaints about the number of candidates, but we wouldn't be saying "RfA doesn't work" (well, we would, but for other reasons). If there's consensus after this that there were too many candidates, here's a fix: limit the number of candidates, then figure out a sensible interval for elections.
What I find most awkward about the process itself is the difficulty of raising potential issues and finding out about them. In a full RfA we typically learn about potential problems (and other perspectives on said problems) after someone posts an "oppose per such and such pattern of behavior via these diffs". Without such a format, it seems awkward for someone to drop a big quasi-"oppose" statement in a discussion section or frame it as a question. Further, as pointed out, it's not even clear people paid attention to the candidate pages. When the first two candidate pages I clicked on only included routine questions and afdstats, with little to no discussion, I didn't even bother opening the rest and instead relied entirely on my own [often cursory] research. I think I had about the same number of supports and abstains, with just a handful of opposes, but in some cases I came across things that I might've commented on if it wouldn't have been the only real comment on the candidate page, and if it weren't already too late to do so. Also worth noting that what I'm complaining about will be seen as a feature, not a bug, to some others.
Last thing: while I was ambivalent about "voter guides" this time (and at every arbcom election), I kind of wished I knew about some here. Spread the effort of getting to know so many users, you know? I think if voter guides came back up, I'd say we should support them/collect them, but create some guidelines/criteria, e.g. "clearly explained criteria/methodology", "not under any topic ban", or "more than a thousand edits". FWIW. โ€” Rhododendrites talk \\ 12:40, 29 October 2024 (UTC)

At ACE we have the official stats-only voter guide, and user-mostly-opinions-guides. Do you think the prior would have helped? โ€” xaosflux Talk 13:49, 29 October 2024 (UTC)
2023's: Wikipedia:Arbitration Committee Elections December 2023/Candidates/Guide. โ€” xaosflux Talk 13:50, 29 October 2024 (UTC)
I feel like a guide like Femke's would work better instead of a guide that is provided at ACE. One that shows edit count, activity, blocks/bans, any big noticeboard mentions about them, permissions, and area of focus. I feel like leaving out quality content because that's not what being an admin is all about. Cowboygilbert - (talk) โ™ฅ 01:21, 30 October 2024 (UTC)
I'm concerned that would create a situation where whoever gets to create a voter guide would become a "gatekeeper." Perhaps this is a one-off and there is pent up demand from users who want to be admins and the next time we do this there will be fewer users running, but I'm concerned about how this would work in practice. SportingFlyer TยทC 05:15, 30 October 2024 (UTC)
I think candidate pages without much activity are good. That means that some folks went digging and didn't find anything negative worth commenting about. If you sample a few more candidate pages, I'm sure you'll notice the busier candidate pages too, and notice why they are so busy.
Personally if I found something negative about a candidate, I asked a question about it. I think certain questions and certain comments took the place of a traditional RFA's "oppose" votes. Although in one case the answer to my question was so satisfactory I changed my planned oppose to support. So that's a nice thing about asking questions. โ€“Novem Linguae (talk) 20:11, 29 October 2024 (UTC)
I don't think this is necessarily the case. I investigated every candidate in moderate detail and was only able to support a few, yet I personally found it too intimidating to write my rationales on the candidate page in the face of the perceived 'wall' of being nice to the candidate. Espresso Addict (talk) 01:22, 30 October 2024 (UTC)
That's not necessarily the case - the page view analysis suggests there was fatigue. SportingFlyer TยทC 05:16, 30 October 2024 (UTC)
  • There was no site wide announcement, was it? I received a couple of news in the admin's newletter, but I think that is hardly enough. I actually don't mind if we suddenly elect 30 or 10 new admins. It should be "easy" to become one. But doing it in "silent mode" seems like a poor test. - Nabla (talk) 12:11, 3 November 2024 (UTC)
    The election was listed at WP:CENT, which is how standard RFAs are advertised. Thryduulf (talk) 12:41, 3 November 2024 (UTC)
    The announcement came up at the top of my Watchlist every day, in advance of the elections starting, and during the voting period. The only way to stop it was to click the "dismiss" button. And it came up separately when I was on my desktop and on my phone, so although I clicked dismiss on my desktop after the voting period, it was still on my phone for a few days. I think there was adequate notice. Mr Serjeant Buzfuz (talk) 13:01, 3 November 2024 (UTC)
  • I strongly support the new process. RfA in my opinion is a vicious process that easily descends into character assassination. Is it any wonder that our number of admins has dropped steadily, when the process to get new admins is so stressful and can involve personal attacks on the candidate? I agree that with this first try, there was a lot of voter fatigue, trying to go through all the information on the 32 candidates, but that's a process issue. Next time, there should be a cut-off point: "Nominations close on X date, or when there are 10 candidates, whichever comes first." But ask yourself: why did 32 people suddenly step forward, when there had only been 14 RfAs all year to that date? Maybe, just maybe, wild thought here, it was because the RfA process discourages people who want to help with the project from putting up their hands. There was a theme to several of the candidate statements: "I want to help." That's the basic requirement for being an admin: someone who is committed to the project and wants to help. Suddenly having a surge of 32 volunteers putting up their hands is great! The last time there were more than 32 RfAs was in 2017, when there were 40. Maybe the numbers for the election process will taper off somewhat, but this is very encouraging.
I'm sure these numbers have been posted before, but I think they bear repeating:
2024: 14 RfA candidates (at the time of the election; 1 since then)
2023: 19
2022: 20
2021: 11
2020: 25
2019: 31
2018: 18
2017: 40
(From https://en.m.wikipedia.org/wiki/Wikipedia:Requests_for_adminship_by_year)
We need more candidates to have more admins. If the RfA process actively discourages candidates, and the new voting process encourages them, then I think it's clear that we need to keep the new voting process. Mr Serjeant Buzfuz (talk) 13:18, 3 November 2024 (UTC)

Thank you

As the polls are about to close, I really wanted to say thank you to all the candidates who made it possible to try out the new system! This seems to me like itโ€™s been a really worthwhile experiment and a much more humane option (not only because multiple candidates dispersed attention on any one, but also because of shifted policies on what kinds of comments could be made) and we only need to balance it with some limit on how many people can stand at once so everyone can get the amount of attention they deserveโ€”I reviewed candidates over several days and still couldnโ€™t properly get through all 30+, so Iโ€™m afraid I may have missed supporting some deserving folks. So if it doesnโ€™t work out in this first slightly chaotic run, please know that for me at least it didnโ€™t necessarily mean I thought you shouldnโ€™t be an admin, only that I ran out of time for reviewing, and thank you again for volunteering to be the ones we worked out those kinks on! Innisfree987 (talk) 21:51, 31 October 2024 (UTC)

+1, agreed. Particular thanks to Novem Linguae for pushing to make this happen throughout this year! I wonder if in the future, there could be an open call for candidates, at any time, and whenever the number of candidates reaches, say, a dozen, an election will be scheduled for, say, 3 weeks later. And the discussion period should be over weekend. And voting should open with discussion. Leijurv (talk) 22:29, 31 October 2024 (UTC)
It's a feature to start discussion before voting opens. That way, people vote with information available. I would support an overlapping period (5 day discussion, and voting starts on day 3 or 4), so that we keep benefits of both options. The open call is interesting. Would we be able to pull this off if voting is hosted locally? โ€”Femke ๐Ÿฆ (talk) 08:31, 1 November 2024 (UTC)
As written, the proposal for the open call seems difficult to meโ€”thereโ€™s a high expectation of availability during discussion phase, but in this scenario candidates would have to commit without knowing which days they needed to be present. Seems more workable to offer a date and then let folks sign up if that date works for them. Innisfree987 (talk) 15:11, 1 November 2024 (UTC)
I agree. Someone should only seek adminship at a time convenient to them, as not answering questions relatively promptly is seen by many as a big red flag even if there is a very good reason (especially as it might not be possible to share the reason on-wiki without disclosing more personal information than you are comfortable with). Thryduulf (talk) 16:47, 1 November 2024 (UTC)
Everyone seems to agree that there were too many candidates this time round and there seems to be consensus for a limit of about 10 if we ever do this again. One issue that would need to be worked out though would be how to deal with it if more than 10 came forward. If it's on a first come first served basis then the time when the call for candidates goes out will affect things and favour editors in some parts of the world over others. 6pm UTC on a weekend would be great for candidates in Europe, but not for any in East Asia, Australia, New Zealand etc when it would be in the middle of the night and they'd wake up to find they'd missed out. Also (and this is probably something for the review process) if there's a candidate limit it would seem sensible to put minimum requirements for standing as a candidate so that spots wouldn't be occupied with those with no hope of election with more realistic candidates missing out. Something like at least 1 year since first edit and 5k edits. No candidate with less than that has a realistic chance but any exceptional candidate would have the standard RFA route anyway.
Also, when are we approximately expecting results? Valenciano (talk) 18:26, 1 November 2024 (UTC)
One option for that issue could be a waitlist-type scenario, where editors who miss out on one election because of the 10-candidate limit are automatically in for the next cycle unless they opt-out. That way they could also have first choice to fill any spots left open if someone withdraws during the call for candidates period.
I think the only info we've got so far for duration is Historically for other elections, scrutineering has taken a few days or weeks โ€” an exact end date is not available. from the main AELECT page โ€“ have any of the scrutineers mentioned a timeframe yet? Happy editing, Perfect4th (talk) 18:41, 1 November 2024 (UTC)
I see the concern that the timing of your election shouldn't be a surprise - you should know when you sign up. Therefore: Perhaps there could be an election scheduled infrequently, let's say yearly by default. Signups would close if/when 10 people put down their name. Discussion would begin on, say, a Friday, voting would open on, say, Saturday or Sunday. If the candidates reached the limit of 10, we would run another election the next month (continuing monthly as long as demand is high). If we didn't reach the limit of 10, we'd wait until the next normally scheduled one (e.g. annually). That way it could scale with demand, but without the "surprise" of putting down your name without knowing when your discussion/voting period would be. Leijurv (talk) 19:08, 1 November 2024 (UTC)
Yes and perhaps we could vary the starting days, for reasons similar to what Velenciano mentions about editor availability in different time zonesโ€”depending on off-wiki obligations (childcare, religious commitments, whathaveyou), while weekends may work best for some editors, they may not work at all for others. It would be nice if we used successive elections to offer different options on that front. Innisfree987 (talk) 19:18, 1 November 2024 (UTC)
Why not just leave nominations permanently open rather than trying to make the start time fair? There will be an initial burst of nominations because of a backlog of need and then it will settle to some steady state rather like the current one off system. With a backstop of shutting it off if it gets flooded with more than 120 on the list at one time to allow the community to decide if the system needs a standard to reduce snowball chance nominations. ๐ŸŒฟMtBotany (talk) 16:16, 3 November 2024 (UTC)
I believe the question of fairness in the start time is best addressed by allowing elections to be more frequent (to allow supply to rise to meet demand, so to speak). For example by scheduling the next election sooner if we hit 10 candidates, and further in the future if not. Having it be permanently open is fine, the only issue I see is what Innisfree987 brought up, which is that there's a high expectation of being available to answer questions, and not knowing when your discussion period is makes it very difficult to make that commitment. Therefore it should probably be scheduled in advance. Meaning, when you sign up as a candidate, you should know exactly the time slot that you're committing to be available to answer questions for. Leijurv (talk) 18:59, 4 November 2024 (UTC)
Also, when are we approximately expecting results? Latest ETA from the stewards: 600 votes shouldnโ€™t take too long. Scrutineering might just take a couple of days if we donโ€™t find anything that needs further investigation and a bit longer if we detect suspicious votesโ€ฆ I will work on it over the weekend. โ€“Novem Linguae (talk) 19:31, 1 November 2024 (UTC)
And to follow up, the latest update from the stewards at meta:Steward requests/Miscellaneous#Scrutineering of enwiki admin election in late October is that they've completed scrutineering and notified WMF T&S to decrypt and tally the results. --Ahecht (TALK
PAGE) 14:20, 4 November 2024 (UTC)
The results have been posted Wikipedia:Administrator elections/October 2024/Results and so far have been certified by 2 of the 3 scrutineers. Thryduulf (talk) 20:06, 4 November 2024 (UTC)

Thank you!

Thanks first to everyone who worked on these elections. We've gotten 11 new admins out of this so by that measure it is a success.

Thanks second (but not in any order of precedence) to everyone who voted. The oppose votes generally greatly exceeded anything warranted by comments made to the candidates indicating that perhaps something was amiss in terms of communication/familiarity/acceptance, but the overall number alone makes this a qualified success.

Thanks third to everyone who ran. To have less than third of candidates pass shows this was far from the cake-walk I think some editors thought it might be. FOARP (talk) 20:23, 4 November 2024 (UTC)

Planning for the debrief phase

I won't go into too much detail yet since we're busy with other phases right now, but my initial thoughts for the debrief phase are 1) do it after the results of the election are posted, so that everyone has a complete picture. 2) Host it on this talk page or a subpage. 3) Divide it into two major sections: feedback from voters and feedback from candidates. 4) Debrief first, RFCs later. โ€“Novem Linguae (talk) 06:09, 23 October 2024 (UTC)

Makes sense. I think hosting it on a subpage (and advertising it widely of course), makes the most sense as this talk page may be too busy. I wonder if we need to structure it further, as I imagine there might be a lot of commentary. โ€”Femke ๐Ÿฆ (talk) 07:18, 23 October 2024 (UTC)
First, I want to say thanks to NL for all the careful work you have been doing on this. I also agree with that general approach. A closely related thing that occurs to me is that, given all the expressed concern about whether there are "too many" candidates, and what kind of effect that will have on who does or does not get elected, is that we should not rush into an RfC, because there may be knee-jerk reactions that might not hold up with the passage of time. For example, I expect that there will be some quick reactions like "some users got elected as admins, but most of us didn't have enough time to vet them". Maybe in the first months after this trial, we will have some new admins who crash and burn โ€“ or maybe in that time we will be very happy with the work of the new admins. That quick reaction that I posited would look very different depending on which of those two possible scenarios might happen. --Tryptofish (talk) 21:52, 23 October 2024 (UTC)
There's some wisdom here, and I want to second your thanks to Novem Linguae. โ€”Ganesha811 (talk) 04:53, 25 October 2024 (UTC)
I will second you on the wisdom, and third you on the thanks to Novem. With all the other election fireworks going on right now (to which we have no choice but to respond speedily), let's give the air time to clear before we start RFCing. BusterD (talk) 14:16, 31 October 2024 (UTC)
I agree with Femke that it should be a subpage. If done on the talk page it could cluttered up with other stuff not necessarily part of the debrief. I also agree that RFCs should come later. Lastly, I thank you Novem for making this process possible. fanfanboy (block talk) 14:25, 31 October 2024 (UTC)
Is a centralized debrief subpage for voters set up yet? I'm certain we'll get different commentary AFTER results are posted. BusterD (talk) 14:16, 1 November 2024 (UTC)
Do you mean, to misquote Sir Humphrey, no one will want to change a system that got them elected. Whereas if you failed to get through? Iz coz the system sucks! :) -- DoubleGrazing (talk) 14:22, 1 November 2024 (UTC)
Not yet. I am planning to wait because I think the debrief would be more useful if done after we know how many and what kinds of candidates got elected. โ€“Novem Linguae (talk) 19:28, 1 November 2024 (UTC)
Now we know. Eleven passed. BusterD (talk) 20:35, 4 November 2024 (UTC)
Wikipedia:Administrator elections/October 2024/Debrief is now open. โ€“Novem Linguae (talk) 20:54, 4 November 2024 (UTC)

Debrief

Hello friends. Now that we have seen the results of the voting, I think we have enough data to start leaving good feedback about how everything went. I have created a debrief page at:

Wikipedia:Administrator elections/October 2024/Debrief

You are cordially invited to leave feedback there. Thank you. โ€“Novem Linguae (talk) 20:44, 4 November 2024 (UTC)

Do we want to allow replies and conversations on the debrief page? Or just pure top level comments? Might be more organized without replies. I'm not sure though. Thoughts? โ€“Novem Linguae (talk) 21:00, 4 November 2024 (UTC)
I think for the voter section, organising by topic might work better? With responses and dialogue. That would give us a good idea of which RfCs to launch when the dust has settled. โ€”Femke ๐Ÿฆ (talk) 21:03, 4 November 2024 (UTC)
I'm going to also say I think place-holders at the top of the order should be discouraged - this is dumping towels on sun-loungers to mark them as "yours" territory. FOARP (talk) 21:55, 4 November 2024 (UTC)

Thoughts on the process from a participant.

Moved to Wikipedia:Administrator elections/October 2024/Debrief
โ€Šโ€“ โ€“Novem Linguae (talk) 22:40, 4 November 2024 (UTC)

Voter guides should've been linked from the project page like ACE does

Voting closed yesterday, and it is only today that I learned about the existence of Category:Wikipedia administrator elections 2024 voter guides. Definitely would've saved some time and effort, had I known about it. โ€”CX Zoom[he/him] (let's talk โ€ข {Cโ€ขX}) 14:12, 1 November 2024 (UTC)

There was a discussion at Wikipedia_talk:Administrator_elections/Archive_3#What_should_the_page_say_on_voting_guides? regarding this. Voter guides were originally discouraged and would not be linked within official pages. But after this election, I'm sure many people (including myself) have changed their minds. fanfanboy (block talk) 14:23, 1 November 2024 (UTC)
Voter guides (and worse) are inevitable. BTW, I was in my county's early voting line last night so I ended up last minute voting for admin elections using my phone (the voting interface worked great). Fortunately I'd done some voter digestion early. Looking forward to the announcement. I hope we get a bunch. I voted for a dozen of the candidates. And then I voted in the US general election. So a productive hour. BusterD (talk) 14:25, 1 November 2024 (UTC)
I find it funny that AELECT and US elections took place around the same time. fanfanboy (block talk) 14:31, 1 November 2024 (UTC)
I distinctly did not find it humorous. Or helpful. But it was coincidental. BusterD (talk) 14:46, 1 November 2024 (UTC)
Somewhat philosophical point: Voter guides become more useful (to voters), the more candidates there are. In an RfA, there's little point in a voter guide, you just go and express your opinion by !voting and hope to persuade others to follow suit. In an election with (hypothetically) 100 candidates, few would plough through them all, so anyone bothering to make a even semi-decent voter guide could expect to be leaned on by a large number of voters. Which may or may not be a good thing, from democracy's perspective. Perhaps this is yet another reason why future elections (if any?) should be limited to relatively small number of candidates, to stop them turning into a 'party system' where a few influencers with their voter guides hold a lot of sway. -- DoubleGrazing (talk) 14:38, 1 November 2024 (UTC)
Guide writers (intentionally or otherwise) influencing people to vote for or against candidates they (don't) like rather than voters doing their own research on candidates based on what matters to them is exactly why I was opposed to (and remain opposed to) voter guides for admin elections. Fewer candidates would discourage both voter guides and lazy voters. Thryduulf (talk) 14:45, 1 November 2024 (UTC)
Slightly off-topic, but I'm nervous about regularly scheduled elections for much the same reason. In the US, continuous campaigning has become its own super-industry. I'd rather just vote on the first ten through the door. And then the next ten. And so on. That would be a nice problem to have. BusterD (talk) 14:54, 1 November 2024 (UTC)
Personally, when reading voter guides, I 100% expect the writer's personal bias to be baked in. And I take that into account with how much credence I give everything I read from them. Their thoughts on the candidate are just that - their thoughts, not the truth.
In any case, I found that having more information and an attempt to increase transparency into the candidates stats/history/what-have-you to be beneficial. PhotogenicScientist (talk) 19:10, 1 November 2024 (UTC)
I 100% expect the writer's personal bias to be baked in. I think there's two styles of voter guide: one that tries to be objective and just focuses on stats/data (example: User:Femke/2024 admin election notes), and one that tries to be subjective and gives the voter's opinion on the candidate (example: User:Mz7/ACE2023#Candidates). Both are useful. The former has less or no bias baked in. The latter is obviously biased, especially if it states who they are voting for. โ€“Novem Linguae (talk) 19:38, 1 November 2024 (UTC)
If weโ€™re having elections, and weโ€™re using secret ballot, then voting guides are inevitable - all youโ€™re going to get by saying theyโ€™re not allowed is pushing them off-wiki on to WPO. I think people will use them even if there are only 10 candidates.
RFA works (to the extent it works) because everyoneโ€™s comments on the candidate are right there to be read by following editors. FOARP (talk) 07:15, 4 November 2024 (UTC)
Balance is key. Too many candidates causes voters to vote without much information, potentially allowing for candidates who shouldn't have the tools to get them anyways and vice versa. Too little candidates will cause too much scrutiny, causing contention and undeserved opposes. fanfanboy (block talk) 14:50, 1 November 2024 (UTC)
I agree. 32 candidates was a bit too many. Elections should be limited to a smaller number of candidates (with an increased frequency of elections if need be). With fewer candidates you wouldn't really need guides because you can make your own decisions by being able to go through their editing history. โ€”CX Zoom[he/him] (let's talk โ€ข {Cโ€ขX}) 14:52, 1 November 2024 (UTC)
In a single RFA, a voter's guide is unnecessary because everyone's opinion is obviously on the page already. It's not a function of the number of the candidates so much as the secrecy of the vote. -- asilvering (talk) 15:47, 2 November 2024 (UTC)
One outcome we need to really guard against is AELECT just cannibalising RFA without even increasing the number of applicants. To be sure of avoiding that, there needs to be a good number of slots open at AELECT - so regular elections, and a cap that is relatively high (e.g., 20) and can be raised when needed. FOARP (talk) 14:29, 4 November 2024 (UTC)
That's going to depend on what the pass rate looks like on elections with smaller numbers of candidates. While the scrutiny and stress in an election may be a little lower, my guess is that the oppose rate will be higher simply because people aren't worried about being badgered for their opposes. --Ahecht (TALK
PAGE) 15:13, 4 November 2024 (UTC)
Speaking of pass rates, it is my opinion that this election had a lot of qualified candidates. If the pass rate is really low, and not enough of these candidates pass, that will be a signal that we need to lower the support threshold. Candidate time/stress and community time should result in a process that promotes the correct caliber of candidate. โ€“Novem Linguae (talk) 18:03, 4 November 2024 (UTC)
If the threshold is dropped, what about the people at this election who would have passed under the new threshold? FOARP (talk) 20:48, 4 November 2024 (UTC)
Based on these results, I think we should go down from 70% to 65%. The 65.00-69.99% range in this election had good candidates. I supported 4 of 5 of them. However, if you're asking if we can do anything retroactively, I don't think that would achieve consensus. They would need to run again. โ€“Novem Linguae (talk) 20:52, 4 November 2024 (UTC)
I'm one of those five in the 65-69.99% range and I would also oppose a retroactive change. We all knew the rules when we stood and we cannot move the goalposts now, that would rightly go down very badly. I'll watch the debrief phase with interest and hope to contribute in the coming days. But overall, I think this has been a success and with some tweaks, could be a regular thing. Valenciano (talk) 22:48, 4 November 2024 (UTC)
It's because those are user created voter guides and not an "official" voter guide like what ArbCom elections have where it's created by the coordinators. Hopefully in the future, if we have chosen or elected coordinators, we'll have official voter guides that are away from opinions but tell the facts about that person in a fast and easy way to understand. Cowboygilbert - (talk) โ™ฅ 20:04, 4 November 2024 (UTC)
ACE also links to unofficial voter guides. IMO the official voter guide is just basic matter-of-facts such as positions running for and the identities of the candidates. Aaron Liu (talk) 20:19, 4 November 2024 (UTC)
Which is better to have because it doesn't show opinions on the editor who is in the election, almost all of the ones in the ACE election are based on opinions. Cowboygilbert - (talk) โ™ฅ 20:22, 4 November 2024 (UTC)
If we're fine with only having 3 columnsโ€”Since, Previous usernames, & Previous runsโ€”then I'd be fine with it. Aaron Liu (talk) 23:06, 4 November 2024 (UTC)

It's not too late to put in a minimum level of support

Sorry folks....but really, we need to put in a minimum level of support for successful candidates; percentage is not enough. We have created a scenario where it would be possible to get adminship with fewer than 15 support votes, and that's just not okay.

I propose the following:

  • Successful candidates will have a minimum of 70 voters either supporting or opposing. Of those votes, 70% must be support votes.

Really, it's not too late. Please let's do this. I really hate that we've created a system - even a trial system - where we have so many candidates that nobody can effectively evaluate them, and thus poorly vetted candidates get adminship. Risker (talk) 03:22, 20 October 2024 (UTC)

It's 100% too late to change the rules or format. You're also nuts if you think anybody would actually get less than 15 supports and somehow still pass here, that's an absurd assumption of low participation. Let's be realistic here. Hey man im josh (talk) 03:43, 20 October 2024 (UTC)
I strongly suspect that we will have much higher levels of participation than on any normal RFA. But in case we don't, and someone truly unvetted and horribly destructive gets through, we can deal with that when it happens. -- asilvering (talk) 03:50, 20 October 2024 (UTC)
If every one of them gets through, we will still have no more admins than we had last year. Hawkeye7 (discuss) 04:42, 20 October 2024 (UTC)
My sense is also that it's very unlikely that there'll be such a low turnout. If that or something else wildly expected happens, I think we have to rely on the bureaucrats to exercise common sense and not flip the bits if this process has failed to produce a sensible result. โ€“โ€ฏJoe (talk) 07:50, 20 October 2024 (UTC)
I agree with the above that it's too late to change the rules here - if there is a low turnout (which, based on the surprise number of candidates, I doubt will happen), then we'll just have to deal with that. The best thing to do here is to vet candidates in advance. I recommend checking out User:Novem Linguae/Essays/2024 administrator election voter guide for a rough overview of the candidates. BugGhost๐Ÿฆ—๐Ÿ‘ป 10:05, 20 October 2024 (UTC)
Having a minimum makes sense as otherwise, the risk is that voters become very defensive in voting and vote no by defaut even where they have spent no time on the candidate, as they might be concerned that low-participation candidates could slip through. Even a 50 de-minimus would be pretty uncontroversial imho and useful for both candidates and voters. Aszx5000 (talk) 10:14, 20 October 2024 (UTC)
(edit conflict) While I agree this would have been desirable, the time to raise this point was during the initial RFC, or during the subsequent discussions, or during the preparation, or (in extremis) during the candidate signup. It is definitely too late to change the rules now. The only thing you can do about this now is to encourage those eligible to vote to do so. You can vote to oppose those you have not evaluated if you are worried they might be appointed with a low number of support votes, but evaluating them is preferable. Thryduulf (talk) 10:21, 20 October 2024 (UTC)
I really hope people do not vote oppose just because they ran out of time to assess some candidates. We're a big community, and it's good to put some trust in each other. โ€”Femke ๐Ÿฆ (talk) 10:27, 20 October 2024 (UTC)
That is why a de-minimus might be helpful (although it would be a late rule-change which is not ideal per the feedback above), and even more importantly, why getting admins to co-nominate (and candidates to accept such co-nominatation) could also be very helpful in encouraging voters to take more risk with this exciting new process. Aszx5000 (talk) 10:32, 20 October 2024 (UTC)
It would certainly not be ideal, especially for the candidates, but it is an option that is open to voters. Thryduulf (talk) 12:13, 20 October 2024 (UTC)
Yes, please don't vote all oppose. That would be damaging to the trial. Please just vote abstain if you're unsure about a candidate. โ€“Novem Linguae (talk) 18:42, 20 October 2024 (UTC)
Those who oppose the process should not be voting all oppose as a protest, that's just inappropriate and disruptive. It's fine to disagree with the process, but the candidates shouldn't feel it as a result. Hey man im josh (talk) 19:23, 20 October 2024 (UTC)
People can literally vote oppose for any reason. Sounds like the process is working as designed. -Fastily 05:05, 21 October 2024 (UTC)
Indeed being able to oppose without having to justify (and potentially be badgered about) your reasoning was one of the reasons proponents gave for having secret voting. Not being convinced of a candidate's suitability for adminship (for whatever reason) is a perfectly legitimate reason to oppose. While the candidate (and others) would likely prefer voters to abstain when that reason is due to not having evaluated the candidate in as much depth as the voter would like, there is nothing in the rules or guidance that requires this. Thryduulf (talk) 10:58, 21 October 2024 (UTC)

I agree that a candidate getting low absolute support numbers but passing due to a high support percentage is a theoretical problem but one which shouldn't happen in practice. The number of candidates putting their name forward is already much, much higher than expected and I think the total voting numbers for each candidate in the admin election will follow suit. Gizza (talk) 08:10, 21 October 2024 (UTC)

  • I've just had a quick skim through the 2007 crop of admins. 2007 averaged more than one RFA a day, and obviously at times when there were lots of candidates some RFAs had few participants. A 70 participants threshold would have lost us a significant proportion of them, including a current admin who was unanimously appointed by 22 participants that year. Not only that but it would have the perverse effect that voting oppose could result in one admin being appointed by 50 supports to 20 while others were narrowly rejected by 50 supports to 19 opposes and clearly rejected by 65 supports to zero opposes. If after this round of elections we decide on a minimum threshold for the future, I suggest either a minimum support threshold (perhaps 20?), or a minimum majority (perhaps 15?) but not a minimum participation level. ฯขereSpielChequers 09:09, 21 October 2024 (UTC)
  • I've already commented on the other version of this over at WT:RFA, but the specific threshold proposed here is unworkable. If 69-0 shouldn't pass, 49-21 definitely shouldn't, but the reverse would be true. If we do this, it should be a minimum number of support votes. โ€”Cryptic 03:19, 22 October 2024 (UTC)
  • It would be useful if those voting oppose had to put down a reason ("not enough experience" "poor answer to Q5" "no time to fully evaluate" etc), and those reasons were anonymously made public after the RfA was over - so what we get is the reasons for the opposes, but not who said what. Oppose reasons are valuable to the candidates if they pass or not, revealing to them the concerns that folks have. It would also help show possible weaknesses in the scheme if too many people were saying that they opposed because they had no time to evaluate. SilkTork (talk) 18:15, 23 October 2024 (UTC)
    I've often said that if candidates can stand failing at RfA once, that the first would hold all of the answers they needed. If you improve based on feedback, and upon the reasons for voters' opposes, you'll stand a great shot at a second RfA. Theleekycauldron did exactly that between her first and second RfA and she came out with the fourth most supports ever a year and a half after her first RfA. Hey man im josh (talk) 18:23, 23 October 2024 (UTC)
    Exactly! She cleaned house. Took advice. Admitted errors. Got better. Theleekycauldron's high activity level at a highly visible board (WP:DYK) between the two processes did tend to paint her as trusted and having an obvious need of tools. Not everyone is as energetic as TLC, but she responded directly to the previous feedback, won over her opposers, and made new friends. All while graduating college. She's a good adult, and we rewarded her with all this responsibility. BusterD (talk) 03:36, 28 October 2024 (UTC)
    One of the original issues with leek was that she was very young. Now she can always look back at crashing THAT glass ceiling, but not in the way she might have liked. BusterD (talk) 03:49, 28 October 2024 (UTC)
    Reasons I've opposed candidates in this election include too great an error rate/volume at CSD, apparently not understanding most admin actions, not having enough experience, inappropriate draftifications, and not participating in areas they want to work in. Reasons I've supported include being demonstrably competent in the areas they want to work in (or more generally competent), and demonstrating an awareness of their strengths and weaknesses (I opposed for a much wider variety of reasons than I supported - three candidates I support have identical comments in my notes, no two of those I opposed do).
    One of the reasons I opposed the election in the initial RFC was because there is no way for the candidates to know why people opposed them and so no easy way to know what they need to improve on in the future, and equally there is no way to learn what people are seeing in the successful candidates that the unsuccessful (and future candidates) can learn from. I could leave 40 individual comments/emails but (a) that's not in keeping with a secret vote and (b) if even a 10th of voters did that candidates would be overwhelmed. Thryduulf (talk) 03:57, 28 October 2024 (UTC)
  • Given that over 600 people voted, several candidates had over 200 opposers and even some of the successful candidates had over 100 opposers, I think we can stop worrying about admin election needing a minimum support threshold. ฯขereSpielChequers 11:55, 5 November 2024 (UTC)

Observation on the value of nominators in this run

11 people passed of the 32 candidates, of those 11...

I think a lot of people leaned on candidates having nominators in this election, possibly due to the number of candidates and having difficulty evaluating that many. I'm also aware that at least a couple candidates had privately been told by people I hold in high regard that they'd be willing to nominate them, but did not take them up on it. Hey man im josh (talk) 20:30, 4 November 2024 (UTC)

I agree that having a nominator is a good idea, and is likely to improve the chances of being elected. On the other hand, I suppose some candidates were attracted to the process because, in addition to having the voting in private, they also did not feel like they would have to approach potential nominators, and perhaps have the risk of being declined. --Tryptofish (talk) 21:30, 4 November 2024 (UTC)
That doesn't address that some candidates chose to run without a nominator though. I also wonder whether this was simply because of the number of candidates and, if limited to 10 candidates, they would have the same value as they did here. I think having someone credible speak on your behalf will always be valuable, but I think because of the number of candidates that those who had them benefited and were given additional weigh as a result. Queen of Hearts did the best after all, and they had offers but ran without any. So I think it's an interesting thing to discuss and consider. Hey man im josh (talk) 22:42, 4 November 2024 (UTC)
TBH, it never occurred to me that nominators were even a feature in this new format (all due to my own ignorance, obvs, and had I thought about it I might have at least looked into or inquired about the matter, but didn't). Even the 'offer to nominate' I had was more "there's an election coming up, would you consider running?" than "...would you like me to nominate you?" I think this could be clarified in the candidate instructions for future elections (if any), especially as it seems to be such a big factor. -- DoubleGrazing (talk) 06:20, 5 November 2024 (UTC)
I was really dismayed by how few candidates ran without nominators, since I thought it would seriously hurt their chances (it seems I was right). Going forward, I think we'll need to make it a bit clearer. But hopefully also people will be more likely to ask for noms, given these results. -- asilvering (talk) 19:58, 5 November 2024 (UTC)
I'm not 100% sure that it's even the fact that some had nominators, or whether that was a side effect of a likely trust of the community in them.
Personally, looking over the list of the candidates that passed the election and had nominators, or offers from nominators, I recognized quite a few names, many more than of the other candidates that didn't, and I'm probably not alone in that observation.
So I think it might be more that, if another admin has felt confident in their candidate to co-nominate them, it is likely a positive signal that the candidate has probably shown prospects with using partial mopping permissions and/or judgement in their respective field of editing, which also likely means that candidate has crossed path with more active editors and thus may also be experiencing confidence by more people from the community.
So I think from my anecdotal debrief/interpretation of that, I think it might be worthwhile to consider the offer of a co-nomination to be a (soft?) criteria for future candidates as it likely yields a (slightly) smaller, but much more likely to pass scrutiny field of candidates and may actually just be the natural selection criteria that could bring future candidacies from 40 to a more manageable 10 (if this initial election can be a rough first indicator). Raladic (talk) 06:32, 5 November 2024 (UTC)

Planning for post debrief

Mini-RFC phase

My idea is to let the debrief phase run for a week or two, then we start a new mini-RFC phase where folks make proposals to modify little pieces of the hypothetical next AELECT. So someone might create a proposal to reduce the pass threshold from 70% to 65%, someone might create a proposal to cap elections at 10 candidates each, someone might create a proposal to have our scrutineering done by 3 enwiki checkusers instead of 3 stewards (since stewards have said they probably can't scrutineer this regularly), someone might create a proposal to link to the voter guide category from the AELECT page, etc. We finish that up, get everything properly closed...

Renewal RFC phase

...and THEN we do one renewal RFC. This order is important. I want the process to be improved (mini RFC phase) BEFORE we do a renewal RFC. Else the renewal RFC will be full of "support only if X is changed" votes, which is a pain for the closer.

We should also give thought to the structure of the renewal RFC. Do we want to ask for 1 additional trial? Do we want to ask for a blanket approval to run elections whenever desired (and then we would de facto run like 1โ€“2 elections a year since that is WMF T&S's current bandwidth, but we might eventually do it more often when Wikipedia:Village pump (idea lab)#Determining who should be an electionadmin is finalized). (Probably ask for blanket approval since overall AELECT has gone well.)

@Theleekycauldron has expressed a desire to have these processes take place under the umbrella of WP:RFA2024 phase 2. So some thought should be given if we should have that process manage these RFCs. (Seems reasonable. We should probably do that.) โ€“Novem Linguae (talk) 19:33, 5 November 2024 (UTC)

Yep :) I think we were pretty much in agreement on your talk page that the renewal RfC should be at phase II and the initial debrief should be here. I would say the proposals at the mini-RfCs should be workshopped at debrief and then voted on at phase II; seems like you were hoping to get some of the changes ratified informally, which I'm also on board with. theleekycauldron (talk โ€ข she/her) 19:45, 5 November 2024 (UTC)
I agree, it will be important to properly workshop the proposals for both mini-RFC and renewal-RFC so we don't get overlapping ones or too many. e.g. there should be exactly one proposal to reduce the support percentage (perhaps with multiple options), and exactly one to change the duration of the consultation phase, etc. Thryduulf (talk) 19:51, 5 November 2024 (UTC)
Good idea. We can create a workshop subpage to draft RFC proposals. Not sure if we should be strict about it when the mini RFCs start, e.g. if someone wants to propose something that wasn't in the workshop that'd probably be OK. But a workshop would probably be helpful to minimize overlapping RFCs. โ€“Novem Linguae (talk) 20:04, 5 November 2024 (UTC)
Wikipedia:Administrator elections/October 2024/RFC workshop is now open. โ€“Novem Linguae (talk) 20:17, 5 November 2024 (UTC)
I agree 100% with Novem that the renewal RfC needs to be after all the mini-RfCs are closed. Things like the support threshold are definitely going to affect how comfortable people are with extending the process, and I don't think it's a good idea to ask people to !vote until it's been settled what exactly they're !voting on. Extraordinary Writ (talk) 20:24, 5 November 2024 (UTC)
I basically agree with other editors that we should get the details worked out before having any sort of up-down vote. I'm speaking as someone who had been very critical of what I have been seeing as a rushed process leading to troubled results throughout the RfA2024 process, but also as someone who is very much in favor of this particular innovation, which I very much want to succeed. Personally, I'd actually have preferred that we allow the Debrief phase to run its course before even starting the RfC workshop, but since that ship has already sailed, I want to put in a plea that we allow plenty of time for that workshop to get all the kinks worked out, before moving on to any next steps. This isn't an emergency, and we shouldn't rush it. --Tryptofish (talk) 22:06, 5 November 2024 (UTC)

Recent RfA template

Should we include {{Wikipedia:Requests for adminship/Recent}} somewhere in WP:AELECT? fanfanboy (blocktalk) 17:25, 7 November 2024 (UTC)

Phase II page.

Theleekycauldron created the Phase II page for AELECT at Wikipedia:Requests for adminship/2024 review/Phase II/Administrator elections. Will this be where the RfC takes place after the debrief phase? fanfanboy (block talk) 15:24, 5 November 2024 (UTC)

We're not ready for that yet, and it may end up not being used at all. Wikipedia:Administrator elections/October 2024/Debrief is the official place to leave feedback at the moment. โ€“Novem Linguae (talk) 19:19, 5 November 2024 (UTC)
We don't actually do "official" on Wikipedia as - other than the WMF - there are no authorities here, just a self-governing and consensual community, but we know what you mean. ;-) SilkTork (talk) 18:44, 7 November 2024 (UTC)

Adding admins to various admin lists

Could someone please add the new admins to Wikipedia:Successful adminship candidacies/2024 and to Category:Successful requests for adminship? And to any other lists where their names should appear?--Diannaa (talk) 15:42, 16 November 2024 (UTC)

No opinion on if we should do this or not. Moving this comment from the debrief page because it's more like an actionable chore than feedback on the process. Thoughts welcome. โ€“Novem Linguae (talk) 10:45, 24 November 2024 (UTC)

Definitely successful election candidates should be added to the first list. The latter I'm not sure, perhaps a new category for successful admin election candidates? Thryduulf (talk) 12:58, 24 November 2024 (UTC)
Agree on the latter, I just created Category:Successful_administrator_election as a sibling category and Category:Unsuccessful administrator election and grouped it under the existing Category:Wikipedia administrator elections tree.
I'll start populating it and interlinking then. Raladic (talk) 15:19, 24 November 2024 (UTC)
Finished the categories.
As for the page you mentioned @Diannaa - it looks like right now it's also specifically tailored to the RFA process, so a lot of the columns don't make sense.
Instead there is already an existing Wikipedia:Administrator elections/October 2024/Results table for the election results, both positive and negative, so I think that maybe we just want to create a sibling table instead of re-working that existing table and co-integrating them instead? Raladic (talk) 16:29, 24 November 2024 (UTC)
Actually on second thought, we just need a few tweaks to be able to integrate them into the table. I'm working on a Template:AdErow that will work like Template:Rfarow to work in the table, but have the right parameters for the table to generate a useful display. Stay tuned. Raladic (talk) 17:13, 24 November 2024 (UTC)
 Done, I added all to Wikipedia:Successful_adminship_candidacies/2024#2024 and Wikipedia:Unsuccessful adminship candidacies (Chronological)/2024 using the new Template I created. Raladic (talk) 18:23, 24 November 2024 (UTC)
The template is a really good idea imo, thanks for that. Diannaa (talk) 19:37, 24 November 2024 (UTC)

Modifying candidate pages to show if they became an admin or not

I think it might be helpful to go back and edit the candidate pages to use a green/red hat instead of a yellow hat, depending on whether the candidate was elected or not. It may also be helpful to add a sentence to the top of each stating whether or not they were elected, and what their percent was. This would 1) provide important information with less clicks (not having to go find the results page to see) and 2) would be in alignment with what RFA does. Is everyone OK with this? โ€“Novem Linguae (talk) 21:50, 7 November 2024 (UTC)

I completely agree, I was just thinking that yesterday after following a link to one of their pages. I think a mention that they passed and the final vote tally, similar to regular RfAs, would be ideal. Hey man im josh (talk) 22:31, 7 November 2024 (UTC)
Yes, that sounds useful and sensible. Thryduulf (talk) 22:46, 7 November 2024 (UTC)
Great. Since there's no objections, does anyone want to start on this? โ€“Novem Linguae (talk) 07:59, 8 November 2024 (UTC)
I'd give it a go, buuuut I'm tentative because I'm not sure who to mark it as closed by. I certainly don't want to be perceived as the closer. Hey man im josh (talk) 13:03, 8 November 2024 (UTC)
Agree. FOARP (talk) 14:31, 8 November 2024 (UTC)
@Primefac you were the 'crat who flipped the bits. Would you object to being the formal closer? Thryduulf (talk) 19:16, 8 November 2024 (UTC)
If it's an election, and thus a straight vote, I would make the argument that no closer is needed. Primefac (talk) 20:21, 8 November 2024 (UTC)
I think it's a matter of semantics at this point. I believe it makes sense to note, at the top of the relevant RfAs, that they were successful. However, typically we have
Final: (200/20/2) โ€“ Closed as successful by whoever.
I guess we could do something like,
Final result: (200/20/2) โ€“ Adminship granted.
Without a signer? Not sure the best approach, but at the end of the day the goal, at least from my POV, is just simply to make it clear they passed and include the vote as we traditionally would. Hey man im josh (talk) 20:26, 8 November 2024 (UTC)
I suppose my point was that on a normal RFA, the 'crat that closes is the closer. On an admin election, hatting the discussion is a formality. In other words, I would support your second suggestion over the first. Primefac (talk) 20:31, 8 November 2024 (UTC)
I'd just put something like Achieved X% in the October 2024 administrator election. Promoted to administrator. or Achieved X% in the October 2024 administrator election. Not promoted to administrator.. You can sign it or not sign it -- that part probably isn't too important. โ€“Novem Linguae (talk) 19:10, 9 November 2024 (UTC)
I like this wording but I'd swap "promoted" for "elected". HJ Mitchell | Penny for your thoughts? 19:19, 9 November 2024 (UTC)
I agree with using elected instead of promoted, due to the connotations of promoted. isaacl (talk) 19:48, 24 November 2024 (UTC)
I agree with Primefac that no formal evaluator of the result is needed. (No one closes arbitration election candidate pages.) Adding a note about the result is a purely ministerial act. I agree with Novem Linguae that it doesn't matter if it's signed or not. There can be a link to the results page, which has the edit that actually released the results. isaacl (talk) 19:48, 24 November 2024 (UTC)

Moving candidate subpage template

I think we should the candidate subpage template from Wikipedia:Administrator_elections/October_2024/Candidate_subpage_template to Wikipedia:Administrator_elections/Candidate_subpage_template, somewhere in the template namespace (this is probably a better choice), or some other place that doesn't include a time period because the current location makes it look as if it was exclusive to this trail run. fanfanboy (blocktalk) 20:57, 11 December 2024 (UTC)

If we move first election stuff out of the first election subdirectory, it could break first election stuff as we iterate on it. But then again, maybe that'd be worth it to iterate on it? Not sure. Let's leave it for now I think. We can circle back to this when it's time to create second election stuff. โ€“Novem Linguae (talk) 22:05, 11 December 2024 (UTC)
I'm fine with leaving it for now as it's really not that important. fanfanboy (blocktalk) 23:32, 11 December 2024 (UTC)

Discussion at Wikipedia:Requests for adminship/2024 review/Phase II/Administrator elections

 You are invited to join the discussion at Wikipedia:Requests for adminship/2024 review/Phase II/Administrator elections. โ€“Novem Linguae (talk) 10:16, 7 January 2025 (UTC)

Next steps

Now that the RfCs at WP:Requests for adminship/2024 review/Phase II/Administrator elections have been closed, the next step would be to hold the Renewal RfC per WT:Administrator elections#Planning for post debrief above. Before we do that, the new rules decided in Phase II should be collected somewhere, so that folks commenting in the Renewal RfC can see them in full. We should probably move the current content of this page, WP:AELECT, to a subpage for the October 2024 election. Then, we can rewrite this page as a general summary of the revised AELECT process. Toadspike [Talk] 05:23, 7 February 2025 (UTC)

Completely agree. I plan to do all that unless somebody gets to it first. I'm leaning towards a copy paste move to the subpage, keeping all the history at Wikipedia:Administrator elections rather than the subpage. โ€“Novem Linguae (talk) 05:42, 7 February 2025 (UTC)
Apologies Novem, I got there first ;) I've added a pretty brief summary of the RFC results to the page, and I've updated Wikipedia:Administrator elections/October 2024 to be about the trial election (it previously was just a redirect to WP:AELECT) - I did a simple copy/paste move like you suggested, and am now editing it down to size. I'll continue tidying up Wikipedia:Administrator elections/October 2024, but the main admin election page should now be free to be just about the process itself, rather than the trial election. BugGhost ๐Ÿฆ—๐Ÿ‘ป 19:00, 10 February 2025 (UTC)
Wikipedia:Administrator elections/October 2024 is now in ok shape, and so I've removed details about the trial election from WP:AELECT (such as the schedule, results page, the list of scrutineers, etc) and placed an {{about}} template at the top to direct anyone who wants info on the trial election, rather than the AELECT process generally. The wording on the rules and implementation needs updating for the proposal. I'm probably going to leave this for tonight, but might pick this up again tomorrow. BugGhost ๐Ÿฆ—๐Ÿ‘ป 20:37, 10 February 2025 (UTC)
This all looks great. Thanks for your help! โ€“Novem Linguae (talk) 09:54, 11 February 2025 (UTC)

Next cycle

If we're going to try to do the next election 5 months after the previous one, are we basically at the point pretty much right now where we should be announcing when the signup period starts? Valereee (talk) 02:07, 11 February 2025 (UTC)

I believe we have to do the full process reauthorization RFC first. Not sure where that would leave the schedule, though. Perfect4th (talk) 02:13, 11 February 2025 (UTC)
@Perfect4th, sorry, I'm clearly missing something...full process reauthorization RfC? Valereee (talk) 02:18, 11 February 2025 (UTC)
Valereee, I don't see anything explicitly stated on WP:AELECT at the moment, but the recent RFC for workshopping election details says This RfC will not discuss reauthorization of administrator elections; that will be decided on in a follow up RFC after the RFCs on this page are all closed. The idea is to improve the process as much as possible first, then later have a straight up and down vote about renewal. Seems to have also been discussed in #Planning for post debrief above (which of course I saw only after I chased more obscure revisions). Happy editing, Perfect4th (talk) 02:23, 11 February 2025 (UTC)
Hm...not actually sure what that even means. @Novem Linguae, can you translate? Valereee (talk) 02:51, 11 February 2025 (UTC)
The 2024 RfA review proposal only resulted in admin elections being approved for a one-time trial run. We need the community to approve it again to make it a permanent feature. Toadspike [Talk] 03:02, 11 February 2025 (UTC)
Good grief. Valereee (talk) 03:09, 11 February 2025 (UTC)
I've got a feeling it will snow-yes, based on the community feedback. Hopefully it won't be much of a timesink BugGhost ๐Ÿฆ—๐Ÿ‘ป 07:51, 11 February 2025 (UTC)
I also think the RFC will pass easily. Hopefully an infinite renewal, not just an additional trial. There's probably multiple blockers for the next election though:
  • renewal RFC
  • WMF needs to make a couple changes to the SecurePoll software, then permit it to be used locally on enwiki (phab:T378287, phab:T384302). WMF recently hired contractors to work on SecurePoll, so I think this will move forward shortly.
Once those are cleared, it should be easy to turn this into a recurring process.
I purposely put the word "ideally" into the RFC question about how often to have admin elections. I think the next election will happen whenever all the blockers are solved, then after that we can try to hit the 5 month cadence a little more strictly. โ€“Novem Linguae (talk) 10:06, 11 February 2025 (UTC)

Renewal RFC planning

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

I think the main administrator election page has now been updated to incorporate the results of the mini RFCs. I'll pause for a day or two to let people copy edit / tweak the page, then I think we should be all set to launch an RFC authorizing future administrator elections.

We can make it a simple yes/no question: "Now that the one time trial is complete, are Wikipedia:Administrator elections authorized to continue indefinitely?" This wording sound OK?

Do folks have any preference on if we should hold the RFC on this talk page, on an AELECT subpage, or on a WP:Requests for adminship/2024 review/Phase II/ subpage? cc @Theleekycauldron. โ€“Novem Linguae (talk) 10:52, 11 February 2025 (UTC)

RFC location

I believe we agreed that Phase II was the best page for the reauthorization RfC, @Novem Linguae :) theleekycauldron (talk โ€ข she/her) 11:25, 11 February 2025 (UTC)
@Theleekycauldron. I don't recall agreeing to having both RFCs be in phase 2, but I dont mind since no one so far has objected. Would you like to create the sub page now and link to it here? Can you please put a notice that says that the RFC is a draft and is not open yet? Thanks in advance. โ€“Novem Linguae (talk) 19:25, 11 February 2025 (UTC)
@Novem Linguae: I'm so sorry, you're totally right! Forgot that the mini-RfCs already went there. Happy to create it there, but if you have a different preference, that works for me too. theleekycauldron (talk โ€ข she/her) 21:47, 11 February 2025 (UTC)
@Theleekycauldron. No worries. Maybe a different (fresh, blank) phase 2 or phase 3 subpage than the mini-RFCs? โ€“Novem Linguae (talk) 22:06, 11 February 2025 (UTC)
Phase 3 subpage seems simple and clearest. Soni (talk) 13:38, 12 February 2025 (UTC)
As soon as Leeky gets a minute to create the page and post a link to it here, I'll fill it in with a draft of the RFC and we can iterate a bit, then launch. โ€“Novem Linguae (talk) 02:01, 14 February 2025 (UTC)
Like Wikipedia:Requests for adminship/2024 review/Phase III/Administrator elections ? Soni (talk) 04:11, 14 February 2025 (UTC)
I defer to @Theleekycauldron for the page title. Would be great to get it created soon though. โ€“Novem Linguae (talk) 05:10, 14 February 2025 (UTC)
Looks good to me! I'll draft some language for the RfC :) theleekycauldron (talk โ€ข she/her) 05:15, 14 February 2025 (UTC)

RFC question wording

I wouldn't have a place to !vote on such a survey. I would be forced to vote no, and I would make a stink about it. P2 has made adjustments, but I'm a firm beta test believer. We clearly didn't get recall petitions right the first time. We haven't tested these major changes in real time, and IMHO we haven't sufficiently foreseen how the system will be gamed over time. Adding an election tempo introduces an election season, for example. Political elements, as another. Ignore this at our peril. I agree that consensuses have been reached, but I do not think we've given sufficient thought to stress testing our changes at this moment in human history. I suggest a third option should be further testing, say, three election cycles before final approval. I'm sure my comment is out of process, but I believe you'll find I'm not the only one who'll object to a yes/no option. If you remember, the advent of political parties in the US was not foreseen by the framers. Further, all this prior process discussion assumed a current US government which acted predictably and within the bounds of law. This is clearly no longer the case. BusterD (talk) 12:19, 11 February 2025 (UTC)
At the very least we should consider the tempo of changes relative to current events. Sustainability. That's my reasonable concern. BusterD (talk) 12:28, 11 February 2025 (UTC)
@BusterD What are your specific concerns about how the current US government or other current events would impact the Wikipedia administrator election process? --Ahecht (TALK
PAGE) 14:02, 11 February 2025 (UTC)
My concern is about the inevitable politicization of the admin request process once this becomes a regularly scheduled !voting process (precisely in a context of incredible external chaos). For my part, I very much enjoyed the outcome of the last admin elections; I think we promoted outstanding new sysops who seem serious and open to feedback. That's great for all of us. But I don't believe we have sufficient data to indefinitely promote this process to elections every 5 months regardless of the need for moppers. My reservation is about the irrevocable nature of the change once we've made it, towards what I view as chosen polarization. I'll work harder to make my case when the question is asked formally. BusterD (talk) 15:03, 11 February 2025 (UTC)
I think bringing US politics into discussions about Wikipedia administrator elections is a bit odd. I wonder if the same arguments can be made in a different way. โ€“Novem Linguae (talk) 19:33, 11 February 2025 (UTC)
I believe I intended to make a point about the dangers of majoritarianism, in the context of what has been happening in the US. I was also referencing very real live threats against our movement. The world's richest man, a man with a competing communications structure, has targeted this project directly. He now has been given virtually unfettered access to Americans' personal data, including many of ours'. By changing wikipedians' societal structure to be more in line with one country's particular political structure (regular elections), we risk weakening our culture of vigorous disagreement. Doing so indefinitely at this precise moment seems the height of folly. BusterD (talk) 13:09, 12 February 2025 (UTC)
The word "indefinitely" in the proposed wording might spook some; it's also quite... ambitious, in purely design engineering sense. (And I'm not arguing about the choice of word here, but rather the concept.) How about proposing as the next stage of the roll-out a finite (and not very large) number of elections, after which another review will be carried out? There are many moving parts in all this, and many factors which have so far only been probed once, with a particular set of parameters. Another, say, 2-3 elections with revised parameters could tell us a lot that we don't yet know about how this thing behaves when released into the wild. -- DoubleGrazing (talk) 14:11, 11 February 2025 (UTC)
I think that would be exercising too much caution - we've already had 2 RFC's about holding a trial (both of which had strong support, the first being declined only on technical grounds), the pre-trial planning and discussion, the trial itself, the debrief, the RFC workshops, and the fleet of post-trial RFC's themselves. In general I think we're already dragging this process out too long, and further trials and discussions could become naval gazing. Tens (if not hundreds) of thousands of words have already been written about AELECT - I think the time has come to just ask whether to accept it or reject it. We can repeal or refine it by RFC later on if there's a need to do so.
Regarding wording, I agree maybe we could soften it - "Should Admin elections be adopted as a recurring process?" or something (I don't feel very strongly about this though). BugGhost ๐Ÿฆ—๐Ÿ‘ป 14:41, 11 February 2025 (UTC)
By convention, all Wikipedia processes are in place until they're modified, so I agree that "indefinitely" isn't required in any question. isaacl (talk) 17:19, 11 February 2025
Agreed, indefinitely is a scary word, and it's implied anyway. My suggested wording: Should Wikipedia:Administrator elections continue as a recurring process now that the trial election is complete? Leijurv (talk) 17:30, 11 February 2025 (UTC)
Requests for comments on broad matters consume a lot of community time in aggregate, so it's a bit of a judgement call on what approach seems more likely to be more streamlined. Does the community feel the process has general acceptance and so is likely to persist, even if needs further modifications; does it think that there may be significant problems that might not be resolved, and so a full re-approval of the process would be more time-effective; or something else? It's difficult to tell, but given that an election process has been sought for many years now, and English Wikipedia editors just seem to like voting in any discussion, my suspicion is that it may be more efficient to follow the usual Wikipedia approach of enacting a process rather than a trial (in this case, extending a trial), and reviewing its effectiveness while it is operational. With the five-month gap between elections, there will be sufficient time for the community to discuss stopping the process if it feels it is desirable. isaacl (talk) 17:32, 11 February 2025 (UTC)
Good idea on the revised wordings. When the subpage is created, we can place one of those wordings in there, and then iterate a little bit more, if needed. โ€“Novem Linguae (talk) 19:36, 11 February 2025 (UTC)
I'm going to make some unsupported assertions. These are my opinions, based on my experience here. I believe the scheduled nature of these elections makes our community more vulnerable. Many nations replace their representatives in free and fair elections which occur when needed. These sorts of electoral processes are inarguably less resource-consuming than those in countries in which set dates are scheduled. These sorts of elections see less grandstanding and less corporate manipulation. Scheduled election dates by definition create election seasons. We shouldn't ignore the risks of giving disrupters advance notice of moments the wikipedia community's attention might be inward facing (as I believe it was during October 2024 elections) instead of outward facing (as we are when we have disasters to cover). Again, all of this is my opinion, based on 20 years of watching this stuff, both here and in RL. BusterD (talk) 13:32, 12 February 2025 (UTC)
BusterD, I've read all of your comments here thus far and I do not know what you're on about. Bringing all kinds of politics into this seems irrelevant and unhelpful โ€“ I'm sorry if that sounds harsh. I realize that Wikipedia faces many external threats, but I do not see how this particular method of selecting administrators makes us significantly more vulnerable to these threats. I understand if you are deliberately obfuscating your worries, but it is not clear if you are.
Perhaps I can clear some things up. The elections will not be regularly scheduled years in advance. Individual editors will do their best to hold elections "approximately every 5 months" โ€“ if there is no interest in doing so, they simply will not be held. If the elections turn out to be a disaster, anyone may open an RfC to end them. Elections do not "dispose of our disagreement-based culture" โ€“ their goal is to make it easier to disagree with candidates (vote against them) without hurting their feelings or being badgered about it. If you would still like to disagree in public, there are discussion pages for that, and the discussion time has been lengthened since the trial. I don't understand where your concerns about polarization, majoritarianism, or dominance are coming from, in a non-competitive process with a passing threshold (70%) far beyond a simple majority, to elect administrators who do not vote like parliamentarians. And since RfA will still be around, I disagree that elections are a "total change in wikiculture" โ€“ it will be at most a partial change. On the other hand, there has long been a consensus (at least since 2015) that change to the RfA culture is needed.
I hope this was in some way helpful โ€“ if you are still concerned, I would be happy to see you voice your concerns more clearly in the RfC, as you have promised. I hope it is clear that I have no hard feelings against you; I am simply having trouble understanding what you want to say. Toadspike [Talk] 19:49, 12 February 2025 (UTC)
I echo the same thooughts as Toadspike, I don't understand your points here. US politics shouldn't have any bearing on WP elections BugGhost ๐Ÿฆ—๐Ÿ‘ป 01:35, 14 February 2025 (UTC)
I understand, but from a different angle. What is probably a concern would be an eventual encouragement of gamification (of sorts) of the elections, where unlike the RfA format, the regularly scheduled elections offer a clearer or easier goal to work towards promoting their "own kind" of editors as admins. In the RfA format, like it or not, the voracity in responses from the the rest is an effective guardrail in this case, making people think twice on supporting or oppose the nominated person because their !votes are public. The only guardrails for the elections are the questions and answers, and nothing is stopping adversarial hijacks of the process if they have a large number of active editors voting silently. In the real world, it can happen, and it had happened before. e.g. Association of Women for Action and Research#Attempted takeover by conservative Christian group (if anyone wants more details, there is a detailed record at fandom). On here, the only few recourse to prevent or defrock the troublesome admins would be through Bureaucrats, Arbcom, and/or the various functions in WMF (T&S, UCOC, etc), and each option will definitely take increasingly longer reaction time as compared to the one before, time which the community may not have if the admin(s) go(es) rogue in the eyes of the community. โ€“ robertsky (talk) 07:13, 14 February 2025 (UTC)
And WP:RECALL, which has (for better or worse) an pretty short reaction time. Thanks for clarifying the main worry though. Since admins, unlike legislators or executive committee members, do not "vote" anywhere or make content decisions, I still believe fears of hijacking to be inapplicable, but I can understand how you may disagree. Toadspike [Talk] 18:07, 14 February 2025 (UTC)

Do we think a lot of people will want a time limited renewal? If so, I suppose we should do an option a option b option c type rfc, and make a time limited renewal one of the options. Thoughts? โ€“Novem Linguae (talk) 19:40, 11 February 2025 (UTC)

What we can do is say that people can specify a number of elections they'd like to reauthorize for (up to indefinite), and the closer can authorize as many new elections as have consensus (assuming that someone who wants 3 new elections would also support having 2 new elections). theleekycauldron (talk โ€ข she/her) 21:48, 11 February 2025 (UTC)

I think it would also be advisable to delete "Now that the one time trial is complete," from the RfC question, and instead, include the fact of that trial having happened in some introductory material on the RfC page. Some editors might be sensitive to the question being non-neutral (even though that would be a stretch), so it's better to avoid any obstacles. I think it would be best to write the RfC question as: "Are Wikipedia:Administrator elections authorized to continue?" โ€“ plain and simple. And again, the invitation to specify, if one wants to, how many elections to authorize, can be stated in the introductory material (with the understanding that if there is no consensus to limit the number, then the elections continue until they don't). --Tryptofish (talk) 22:56, 11 February 2025 (UTC)

I could go along the language "Are Wikipedia:Administrator elections authorized to continue?" yes or no. I could go along with a preliminary schedule of test votes. I cannot go along with a total change in wikiculture with insufficient playtesting. For my part, I want us to find dedicated and qualified new admins as much as anybody. I don't want (in exchange) for the en.wiki community to dispose of our disagreement-based culture in favor of a more political voting one. Our movement represents a different cultural approach to mere dominance. There are moving parts here, and they will never stop moving. We should game this ourselves, and benefit from the experience.
Ahem. Thanks, whoever sub-sectioned this. I feel I have unjustly disrupted a simple technical exchange between two wikipedians I trust implicitly. I am being pointy. I am not normally known for such disruptions. BusterD (talk) 12:56, 12 February 2025 (UTC)
Personally, I don't think the new election process signifies a total change yet, and I think there are ways to safeguard against problems that may arise. The open viewpoint request for administrative privileges process remains in place. Wikipedia's consensus-can-change tradition is also still here and can rein in any abuses, even if they're in progress. English Wikipedia guidance isn't a set of binding laws; the community can agree to cancel an election or put the entire process on hold whenever it wants. isaacl (talk) 16:36, 12 February 2025 (UTC)

RFC draft

Took a whack at a first draft :) feel free to wikify it into something better! theleekycauldron (talk โ€ข she/her) 05:27, 14 February 2025 (UTC)

Looks good. I just went through and made my suggested changes. I think it's looking pretty good. Any thoughts or concerns before we launch the RFC?
Also, do we want to take this opportunity to promote AELECT to a guideline or a policy? Would be pretty easy to insert this wording into the RFC, if we think it's a good idea. Considering we just RFC'd 22 little details of the AELECT page, I think it's safe to say that the AELECT page has a PAG-level of consensus. Although if we skip making it a PAG, that should be fine too. Lots of procedural pages such as WP:RFA and WP:AFD are not PAGs. โ€“Novem Linguae (talk) 07:08, 14 February 2025 (UTC)
Just a thought: I'm leery of the or any other limitations phrase. It seems to invite participants to suggest arbitrary "tweaks". What I'm imagining is a bunch of Option Bs that create a giant mess - contradicting each other. "Authorized to continue for 2 more elections assuming at least X people vote in each" or things of that nature, that would make the RfC impossible to close. I think it is duplicative of the phase II RfCs. If I were writing the RfC, I would put: Option A - No. Option B - Yes, more trial(s) are authorized (please specify how many). Option C - Yes, administrator elections are authorized to occur approximately every 5 months. Leijurv (talk) 19:30, 14 February 2025 (UTC)
Sure, that seems fine to remove. Done. โ€“Novem Linguae (talk) 19:59, 14 February 2025 (UTC)
The draft as it currently stands looks good to me. No edits here. โ€”Ganesha811 (talk) 06:59, 15 February 2025 (UTC)
The wording "with no limitations" feels a bit off to me. Iโ€™m concerned it doesnโ€™t fully reflect the considerable RFCs and consensus and time put into thinking out the process and trying to make it a secure, "safe" admin selection process. Iโ€™d prefer something like B โ€“ Authorize administrator elections to continue for an additional x number of trial elections (please specify x); C - Fully authorize administrator elections, or something of the sort. Perfect4th (talk) 07:14, 15 February 2025 (UTC)
I changed it to Yes, without needing further trials or renewals. Administrator elections are authorized to occur approximately every 5 months. Does that make some progress towards your concern? โ€“Novem Linguae (talk) 08:07, 15 February 2025 (UTC)
Yes, that helps, thanks. Perfect4th (talk) 20:04, 15 February 2025 (UTC)

Mass message

When the RFC launches, any objections to sending a mass message to Wikipedia:Administrator elections/Newsletter list? Will probably use the {{Please see}} template for neutral wording. I do not believe this to be canvassing since the newsletter list is not partisan -- I believe it is all folks that are interested in administrator elections, not just "pro" AELECT or "anti" AELECT editors. โ€“Novem Linguae (talk) 18:54, 14 February 2025 (UTC)

Yes, as advertised and described on the mailing list page, it is to get notifications about the process. Thus not notifying those on the mailing list would be breaking a promise. isaacl (talk) 22:35, 14 February 2025 (UTC)
I think that's fine. โ€”Ganesha811 (talk) 07:00, 15 February 2025 (UTC)
Yep, sounds good to me. Surprised there wasn't one for the mini RFCs, I didn't realise they were happening until near the end BugGhost ๐Ÿฆ—๐Ÿ‘ป 17:27, 15 February 2025 (UTC)
Send it :) Leijurv (talk) 03:11, 20 February 2025 (UTC)

Renewal RFC is live

The renewal RFC is live at Wikipedia:Requests for adminship/2024 review/Phase III/Administrator elections. The MMS bot should be along soon to notify this talk page as well. โ€“Novem Linguae (talk) 06:11, 21 February 2025 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Discussion at Wikipedia:Requests for adminship/2024 review/Phase III/Administrator elections

Administrator Elections | Renewal RFC phase
You're receiving this message because you signed up for the mailing list. To opt-out of future mailings, please remove yourself from the list.

MediaWiki message delivery (talk) 06:21, 21 February 2025 (UTC)

Next election date & list of blockers

Hello all. I got a question offwiki about when the next election date would be. Right now the next election is blocked on two things:

If the renewal RFC closes as option C, I think the date of the 2nd election will be a bit off the 5 month schedule (a bit random and depends on when the blockers are resolved, setup time, etc.), then elections after that will be on the 5 month schedule.

If the renewal RFC closes as option B, same thing, except the potential 3rd election will probably also be off the 5 month schedule.

Hope that helps with advising candidates on whether to wait for AELECT or choose RFA. Happy electing! โ€“Novem Linguae (talk) 20:56, 3 April 2025 (UTC)

Update: The RFC is now closed. If there aren't any forthcoming close challenges, the remaining blocker is now phab:T384302 SecurePoll: Restrict creation of foreign and global elections. I have written two patches that should resolve this ticket. Might take a couple weeks to go through the code review and deployment process, and get signoff from WMF leadership. Getting SecurePoll approved for local use (what this ticket is about) isn't a total blocker, but it allows SecurePoll elections to be held without having to bug WMF Trust & Safety, who are busy. It makes the entire process quicker, more scalable, and able to handle the recommended 5 month cadence. โ€“Novem Linguae (talk) 23:20, 9 April 2025 (UTC)
When those tickets are fully dealt with, we should probably wait a few weeks before having another election. I also think that after the next election is when we start counting the 5 month schedule. fanfanboy (blocktalk) 01:38, 10 April 2025 (UTC)
Yeap. Agreed. I think the steps after securepoll local elections being ready on the technical side is picking some English Wikipedia election admins (scrutineers). This will be our first time doing that so may require some extra time. Then proposing a schedule on this talk page and getting it approved. Then doing a call for candidates. โ€“Novem Linguae (talk) 04:08, 10 April 2025 (UTC)
Would eyeing something like June-July 2025 be feasible for AELECT 2? Or is it too soon to consider without more info on the other blockers? Soni (talk) 11:29, 10 April 2025 (UTC)
Sounds about right. If I had to guess, I think we can get the software stuff wrapped up in one month, then another month for picking scrutineers and planning. โ€“Novem Linguae (talk) 11:35, 10 April 2025 (UTC)
I hope I'm not re-litigating an RfC outcome that took months of time and thousands of words but ... why five months, not six to make it twice a year? HJ Mitchell | Penny for your thoughts? 11:41, 10 April 2025 (UTC)
I think the idea behind the 5 month RFC close was to stagger the elections so that if someone is always busy during certain months, that eventually AELECT would occur in a month where they are not busy. โ€“Novem Linguae (talk) 11:50, 10 April 2025 (UTC)
So that they will drift seasonally, rather than always being at the same times each year. โ€”Ganesha811 (talk) 14:43, 10 April 2025 (UTC)
Fair enough. Thanks for the answers. HJ Mitchell | Penny for your thoughts? 15:55, 10 April 2025 (UTC)
We should probably have an FAQ or similar about the admin elections that prominently includes the answer to this question. Thryduulf (talk) 08:02, 12 April 2025 (UTC)
Thanks for all the work put in @Novem Linguae! Hey man im josh (talk) 13:39, 10 April 2025 (UTC)
+1 fanfanboy (blocktalk) 14:34, 10 April 2025 (UTC)
absolutely Thanks,L3X1 โ—Šdistรฆnt writeโ—Š 16:18, 10 April 2025 (UTC)
Yes, a huge thanks to Novem for all your work! Perfect4th (talk) 16:23, 10 April 2025 (UTC)
absolute +1 charlotte ๐Ÿ‘ธโ™ฅ 21:07, 10 April 2025 (UTC)
Update: My software patches in phab:T384302 were merged and deployed very quickly thanks to Dreamy Jazz. Thanks so much for the quick code reviews. Next step now will be to get sign off from the WMF TSP team (maybe via a post in phab:T301180), and WMF leadership. โ€“Novem Linguae (talk) 00:01, 12 April 2025 (UTC)
Excellent, nice work team. โ€”Ganesha811 (talk) 16:40, 13 April 2025 (UTC)
No problem on the code review. Good to see this moving along. Dreamy Jazz talk to me | my contributions 21:19, 15 April 2025 (UTC)
Congratulations, all AELECT supporters and commenters! Many users, especially User:Novem Linguae & User:theleekycauldron deserve wide praise for demonstrating how an engaged community may adapt to broad input and make informed AND complex decisions about its future. We went to the well of consensus over and over, and those who supported individual elements of the surveys became broader supporters of the entire movement. The model used for acquiring a neutral consensus moving the process forward was well founded and might be used for other longterm issues moving forward. Bravo! For my part, I fully believe in this election process and the steps made to enshrine elections as policy. I thank everyone who participated. BusterD (talk) 13:53, 21 April 2025 (UTC)

Have CheckUsers be in charge of creating/editing SecurePoll polls?

I've drafted an RFC at Wikipedia:Administrator elections/SecurePoll permissions RFC. It is not open yet. Please feel free to give feedback here. Basically we already had an RFC that approved creating an "Election Administrator" user group, but after thinking about it more I think it'd be less messy to just give all the SecurePoll create/edit/scrutinize permissions to the existing CheckUser group. Thoughts? โ€“Novem Linguae (talk) 23:52, 11 April 2025 (UTC)

It feels to me that creating and editing should be one group, and scrutineering should be another. I'm not sure on the technical side of this, but can we not append scrutineering rights to checkusers, and allow the new electionadmin group to just create/edit (but not scrutineer) elections? BugGhost ๐Ÿฆ—๐Ÿ‘ป 00:11, 12 April 2025 (UTC)
When will these RFCs come to an end! But yeah I agree with BugGhost on this one. fanfanboy (blocktalk) 00:21, 12 April 2025 (UTC)
When will these RFCs come to an end? Hopefully soon :) If this change is small enough, maybe I can just post at WP:VPPR with a "does anybody object?" type message. Will give this some more thought, and hopefully some others will chime in too. โ€“Novem Linguae (talk) 00:49, 12 April 2025 (UTC)
We've had a quite a few RFCs, and as there may still be (a rather important) one to come about WP:RECALL, I think there's good merit in the simple message option instead. It still provides an opportunity to raise concerns or even request using an RFC after all if people do want that. Also agree with BugGhost on the scrutineer aspect but I'm really not bothered either way. Perfect4th (talk) 01:25, 12 April 2025 (UTC)
+1. It seems like a problem solvable by a simple well notified discussion than a full RFC. We're fairly deep in implementation land Soni (talk) 10:26, 12 April 2025 (UTC)
+2 agreed, I see no need for a full RfC. โ€”Ganesha811 (talk) 16:40, 13 April 2025 (UTC)
Adding a new role would indeed create needless process / procedure. Bundling it into an existing position is probably the best option. But why checkuser? Checkuser makes perfect sense for scrutineering since they can already view that data. But the task here is more like admin election clerking. To me, it feels more intuitive to give this right to the bureaucrats? Leijurv (talk) 07:25, 12 April 2025 (UTC)
There are only 16 crats - assigning a role to them is likely to put a bottleneck on the process, and we don't have any indication that they want to take on this additional set of tasks, especially if it is working with something complex and niche like securepoll. I think a specialised self-nominating group would be best for setting up elections, even if it means more legwork right now to organise that group. BugGhost ๐Ÿฆ—๐Ÿ‘ป 10:04, 12 April 2025 (UTC)
That is a fair point.
Why not give the right to all sysops? Leijurv (talk) 13:40, 12 April 2025 (UTC)
Something that is complex and niche shouldn't be handed out broadly to people with no need for it and no guaranteed aptitude for it. Rights like this are the entire reason that small usergroups exist, and while there will of necessity be some process and procedure associated with the right, absolutely none of that will be needless and there is no reason it for it to be lightweight. The process and requirements for Wikipedia:Interface administrators seem like a good model for this, although I don't see a need to require 2FA or CSS/JS knowledge. Thryduulf (talk) 14:29, 12 April 2025 (UTC)
The previous RfC to which you linked found consensus to enable the electionadmin right, but did not specify that a specific user group had to be created (An RFC to determine how the new right should be distributed can be launched at any time...). I think there should be more discussion about the details of other potential processes for granting the right than just granting it to the checkusers group (the three basic ways being by consensus agreement on request, by appointment from some group, or by election). Also, given the resolution of Phabricator ticket T377531, there is the ability to separate poll administration tasks from scrutineering tasks, so that's something to consider when deciding how to manage the election admin role. isaacl (talk) 15:34, 12 April 2025 (UTC)
I don't think it would be controversial for CU's to get electionadmin rights in addition to the scrutineering right which was decided in the previous RfC.
I'd say this can be devised as similar to the edit filter manager group, which has rights not included in sysop group by default but can be self-granted by sysops. Reusing the IA requirements seems slightly too restrictive. 0xDeadbeefโ†’โˆž (talk to me) 13:10, 15 April 2025 (UTC)
Though upon further thought, config editing seems outside the job descriptions of CUs.. 0xDeadbeefโ†’โˆž (talk to me) 13:15, 15 April 2025 (UTC)
I think that the best choice is between the model of Wikipedia:Interface administrators and Wikipedia:Edit filter manager. A separate user group makes sense in the absence of explicit consensus to bundle it, but we don't need a heavy-weight process to assign membership. Eluchil404 (talk) 23:27, 21 April 2025 (UTC)

Second draft

Moved to Wikipedia talk:Administrator elections/SecurePoll permissions proposal ยง Second draft
โ€Šโ€“ โ€“Novem Linguae (talk) 17:56, 23 April 2025 (UTC)
The second draft is currently stuck. Wikipedia talk:Administrator elections/SecurePoll permissions proposal#Stuck. Help and new participants in the discussion would be appreciated. โ€“Novem Linguae (talk) 14:20, 28 April 2025 (UTC)
Looks like it's getting unstuck! โ€”Ganesha811 (talk) 18:34, 28 April 2025 (UTC)
We've made some changes and I think the current version is ready for final sign off. Please feel free to give your opinion at Wikipedia talk:Administrator elections/SecurePoll permissions proposal#Survey / Motion to close โ€“Novem Linguae (talk) 15:30, 29 April 2025 (UTC)

SecurePoll notes

Hi all,

Based on the discussions over at Wikipedia talk:Administrator elections/SecurePoll permissions proposal, I realised that there's not a lot of certainty in the community about how SecurePoll's config really works, so I've done some local testing and tried to collate a basic summary of what I've found about it in the hopes to get a bit more community clarity on this. It's available at User:Bugghost/Securepoll notes. It is still a work-in-progress and I plan to add more to it over the coming days. Anyone is free to edit it if they've found anything incorrect, and please let me know if there's anything in particular you'd like me (or anyone else) to test and I'll try to add it to the page. BugGhost ๐Ÿฆ—๐Ÿ‘ป 20:17, 29 April 2025 (UTC)

Fantastic, thank you so much! Assuming we will use an encrypted poll, my question is about the period after the poll is over. Is it possible for a scrutineer who possesses the private key to see who voted for who? For instance, could they view the total tally, then strike someone's vote, then view the tally again to see whose count was decremented, thus learning who that user voted for? Leijurv (talk) 22:02, 29 April 2025 (UTC)
Very good question - from my testing it looks like yes an election clerk or scrutineer can look at the tally, then strike a particular user's vote, compare the tally to see who that user voted for, and then unstrike the vote again to cover their tracks. This can be done on an encrypted poll as long as the election clerk/scrutineer has the correct encryption keys to examine the tallies. There is a public log at Special:SecurePollLog (if logging is turned on), but it looks like it only tracks when tallies are requested (so in this scenario would be twice - before and after the vote strike) - but surprisingly this log doesn't show when a vote gets struck or unstruck. Election clerks/scrutineers can see if a particular vote has been struck/unstruck, but that information is not easily visible, and it is not accessible at all to the general public. Seems like a bit of an oversight here. BugGhost ๐Ÿฆ—๐Ÿ‘ป 17:28, 30 April 2025 (UTC)
That's probably a bug that should be reported on Phabricator, although I'm not sure what could be done about it and even without revealing whose vote was struck/unstruck the multiple unauthorized tallies will leave an audit trail a mile long.
Finally Special:SecurePollLog is not public - only election clerks can access it (it's gated on securepoll-create-poll which is strange). * Pppery * it has begun... 17:49, 30 April 2025 (UTC)
Looks like you're right about SecurePollLog not being public - sorry about that, I've struck the above. I agree that it's not obvious what could/should be done to mitigate this. Maybe a new poll option to specifically only allow one tally to ever be generated? BugGhost ๐Ÿฆ—๐Ÿ‘ป 17:59, 30 April 2025 (UTC)
Or possibly a log entry for votes being struck or unstruck, so the log would read something like:
  • 18:57 30 April 2025 (UTC) Example requested tally for poll #42
  • 18:58 30 April 2025 (UTC) Example struck 1 vote on poll #42
  • 18:58 30 April 2025 (UTC) Example requested tally for poll #42
  • 18:59 30 April 2025 (UTC) Example unstruck 1 vote on poll #42
At the very least that would be cause to ask Example what they were doing and why. If it is possible to leave edit summaries when striking votes then they could be displayed in this log too (if the log is restricted to the same people who can strike and unstrike votes then I don't think that would have any security implications?). Thryduulf (talk) 18:59, 30 April 2025 (UTC)
In the meantime we could put a policy that no one shall click Tally until all scrutineers have publicly declared (ratified) that they are done scrutineering. This is verifiable, and if everyone can be seen to have followed this policy, it is certain none of them used this trick. Leijurv (talk) 19:47, 30 April 2025 (UTC)
Does it ever make sense to strike votes after tallying? Is there some reason SecurePoll couldn't prohibit that operation entirely? * Pppery * it has begun... 21:12, 30 April 2025 (UTC)
I don't think striking votes after tallying should happen in usual course of action. I think that operation could be prohibited, but it would require changing the code. The only downside I could think of is accidentally or maliciously tallying early. If there was no way to strike votes after that, it would spoil the election and I guess everyone would have to re-vote (with new scrutineers). I guess a more ideal solution would be that all (or a majority?) of scrutineers must request a tally before the code actually does it? (Instead of just 1 scrutineer saying they're done, most, or all of them would have to). But this is overcomplicated and shouldn't be considered a blocker for AELECT, because we can just have the scrutineers agree not to tally until everyone has ratified. Leijurv (talk) 21:23, 30 April 2025 (UTC)
Filed phab:T393057. And I agree none of these are blockers for local elections - they're paranoid nice-to-haves. * Pppery * it has begun... 21:35, 30 April 2025 (UTC)
Strikes are logged. The fact that they're logged in a different place than anything else is weird, and may make that sort of chichanery harder to find, but ultimately harmless. * Pppery * it has begun... 21:48, 30 April 2025 (UTC)
Where are they logged at? โ€“Novem Linguae (talk) 22:23, 30 April 2025 (UTC)
(from looking at the code, not tested locally) If you go to the details page for a specific vote it should show the log of any strike/unstrike actions affecting that vote. * Pppery * it has begun... 22:36, 30 April 2025 (UTC)
This aligns with what I've been seeing. I've added a screenshot to the notes page to illustrate. BugGhost ๐Ÿฆ—๐Ÿ‘ป 08:36, 2 May 2025 (UTC)
This sounds like a reason for the encryption key not to be shared with the scrutineers, and thus to have a non-scrutineer electionadmin to be a backup to the electionadmin who created the poll. isaacl (talk) 22:30, 30 April 2025 (UTC)
Just to clarify: any election clerk is able to do the above, regardless of if they are scrutineers - any election clerk is able to request tallies and strike/unstrike votes. From my testing, the only difference between and election clerk and a scrutineer is that a scrutineer can see IP addresses and user agents (ie. browser versions) of voters and an election clerk cannot. BugGhost ๐Ÿฆ—๐Ÿ‘ป 18:45, 1 May 2025 (UTC)
Thanks for the clarification. This means that electionadmins must also be trusted to only strike votes in accordance with community guidance. isaacl (talk) 22:05, 1 May 2025 (UTC)
They have to be added to the election to do anything with it, though. Typically for past Arbcom elections the election comission has been removed from the election on votewiki when it starts, leaving only the scrutineers (and WMF staff) able to strike votes, and we could do the same for local elections * Pppery * it has begun... 04:31, 2 May 2025 (UTC)
At least one electionadmin has to remain in order to tally the results, and for redundancy, there should be at least two. When the vote is run on the WMF voting server, it makes sense to add electionadmins from English Wikipedia in order to manage the poll until voting time, to avoid taking up the time of WMF staff. But when running the poll on the English Wikipedia server, I don't think additional electionadmins need to be added beyond those who must be there to do the tallying. isaacl (talk) 14:55, 2 May 2025 (UTC)
You could also revoke the right just during the election ? (Basically two people get the right, setup securepoll and then have their permissions revoked. The election then runs and once it is over the right is regranted, the votes and struck, counted and the rights are revoked again). It might be a fair bit of bureaucracy but it would sidestep the problem of peeps tallying the vote before the end. Sohom (talk) 15:13, 2 May 2025 (UTC)
The issue is with someone having the ability to strike votes and tally them after the poll ends. (I still don't see a need for extra electionadmins to be assigned who won't be part of the process to tally votes.) isaacl (talk) 15:33, 2 May 2025 (UTC)
Right, my personal opinion is that we should have only two folks with electionadmin at a time (one to actually do the sensitive work and one to perform a oversight/contingency role). We can always assign more folks if we see that there is a need for other contingency folks. Sohom (talk) 16:23, 2 May 2025 (UTC)
Personally I'm OK with users only holding the electionadmin right for the period when they are using it for a specific poll, and with the self-assignment process this is workable with minimal overhead. I appreciate, though, that others don't think it's necessary to be that strict with who currently holds the electionadmin right, as long as the number of users assigned to manage a given poll is tightly managed. isaacl (talk) 17:07, 2 May 2025 (UTC)
I think we don't need to worry too much about who actually has the election clerk rights and when. Personally I would like the election clerk role to be widely adopted so that Special:SecurePollLogs can be watched by a sizable number of people to see if there's any unnecessary tally-generations. I agree the more important issue is deciding who is actually added to a poll at a given time. BugGhost ๐Ÿฆ—๐Ÿ‘ป 18:07, 2 May 2025 (UTC)
This all sounds a bit complicated. Would recommend copying what WMF does and what we did for the first admin election, and have one electionclerk and three scrutineers. The three scrutineers have the same perms as electionclerks, so in theory this gives us four election clerks. โ€“Novem Linguae (talk) 19:04, 2 May 2025 (UTC)
I think there should be at least one backup election clerk who is not a scrutineer with whom the encryption key is shared, so they can trigger a vote tally if necessary. isaacl (talk) 21:09, 2 May 2025 (UTC)

Name of heading for voter eligibility

I know, what an important detail.[Joke] Currently, the name of this heading is "Who can vote" in the present tense and "Who could vote" in the past tense, as seen on ADE and the October 2024 subpage. I don't think we should be changing the name of this heading every time an election finishes, so could we settle on a name with some more permanence? I suggest "Voter eligibility". Aaron Liu (talk) 17:14, 22 February 2025 (UTC)

In general, re-writing pages for past elections to be in the past tense should, in my view, not be done. With a clear indication of the status of the election at the top, there's no need to change the rest of the page as no one will be confused that the election is still ongoing. I think people coming to see the page in future would be more likely to want to see the state as it appeared during voting, and not a reworded page. isaacl (talk) 17:29, 22 February 2025 (UTC)
I was the person who split the Oct '24 details into the separate subpage and turned everything past-tense - just wanted to say that I don't really have much preference on this, it just felt like it made grammatical sense at the time seeing as the page was created after the election had ran (when it run running, details of the trial were just on the main WP:AELECT page). I've got no opinion on what happens in future elections' subpages, and wouldn't object if someone made the Oct 2024 subpage present tense (I don't think it would be worth doing, but I also won't attempt to stop anyone). "Voter eligibility" sounds like a good header to me. BugGhost ๐Ÿฆ—๐Ÿ‘ป 00:32, 23 February 2025 (UTC)
I'll just change it to that, then. My main concern was with link stability. (As for the tense of page content... I have no preference, since it is virtually impossible to be tense-neutral in English.) Aaron Liu (talk) 03:31, 23 February 2025 (UTC)
Do we really need to be this exclusionary? Let's keep it at a name everybody understands โ€”Femke ๐Ÿฆ (talk) 07:27, 23 February 2025 (UTC)
Do you have a tense-neutral suggestion? Aaron Liu (talk) 15:18, 23 February 2025 (UTC)
Present tense feels sufficiently neutral for this, right? โ€”Femke ๐Ÿฆ (talk) 15:20, 23 February 2025 (UTC)
No, because it is present tense and will be changed into the past tense, which breaks links. With ACE also changing content to the past tense I'm not sure if there's consensus to not rewrite into the past tense. This isn't any important enough for me to push it, though, so you're free to change it back if you wish. Aaron Liu (talk) 16:08, 23 February 2025 (UTC)
I don't agree that a verb "will be changed into the past tense", and I don't think this should be a consideration in choosing a heading. That being said, I don't have a problem with using "Voter eligibility". isaacl (talk) 16:38, 23 February 2025 (UTC)
The truth is, people are spontaneously changing verbs to the past tense, as seen at ACE. Aaron Liu (talk) 16:46, 23 February 2025 (UTC)
It happened in 2023 at the arbitration committee elections page, but not in 2024 (yet), and has not happened for all past elections (as of when I checked in 2023). It leads to very stilted language and doesn't bring any particular benefit. If a trend develops, I think determining a practice by consensus would be warranted, but I don't think it's necessary yet. (On a technical point, someone changing a heading could add an anchor to preserve older links. I didn't mention this before because I think the re-writing shouldn't be done anyway.) isaacl (talk) 17:11, 23 February 2025 (UTC)
special:Diff/1262010917. Nothing else was changed 2024 but that's more of an oversight. Anchors can be added, but the editors who spontaneously change the tense are unlikely to realize that. Aaron Liu (talk) 17:15, 23 February 2025 (UTC)
No, not an oversight. I didn't object to that brief change made in the lead sentence, but I will object if the rest of the page gets altered, after having posted my view on this matter in 2023. isaacl (talk) 17:22, 23 February 2025 (UTC)
I have the same position you have, then. (Though I think that all headings should just be tense-neutral.) Aaron Liu (talk) 20:03, 23 February 2025 (UTC)
With little copy edits like this, probably best to just make the change, and anyone that doesn't like it can revert it. Will save us 650 words of discussion :) โ€“Novem Linguae (talk) 17:13, 23 February 2025 (UTC)
I think it was worthwhile to mention the broader issue. I feel what best serves future readers is to preserve the appearance of the page as it was during the vote. Perhaps it would be helpful to have a status banner at the top, similar as with the arbitration committee elections, so the current state of the election is clearly identified. isaacl (talk) 17:18, 23 February 2025 (UTC)
We did have a status banner at the top; it was only removed this month. There was rough consensus to make it just an ombox, and I did make what is now {{Administrator elections status}} based on the ACE status header, but I misconfigured it spectacularly during the trial election; while the misconfiguration has been fixed, I'm not sure if we'll get consensus to adopt that automatically-updating template instead of the manually-updated header template we had. Aaron Liu (talk) 20:08, 23 February 2025 (UTC)
I was referring to the individual election pages. When the next election page is created, it could have a status banner to highlight the current state of that specific election and eventually its results. It wouldn't be a lot different than the current lead sentence at Wikipedia:Administrator elections/October 2024, but some editors like to have that info given additional emphasis. isaacl (talk) 23:10, 23 February 2025 (UTC)
The header is the header for the election pages. Aaron Liu (talk) 00:21, 24 February 2025 (UTC)
That header currently solicits participation in the past RfCs. My suggestion is for a header that just describes the state of the election and which never gets modified again after the election is closed and the results are announced. isaacl (talk) 00:28, 24 February 2025 (UTC)
It seems I read a viable solution: Change it to Voter eligibility and any objections, if any, could be handled at that time. -- Otr500 (talk) 15:30, 6 May 2025 (UTC)
This change has already been made fanfanboy (blocktalk) 15:49, 6 May 2025 (UTC)

Scrutineers

Hello page watchers. Are any of you English Wikipedia CheckUsers that would like to scrutineer the next election in July or August? Looking for 3 English Wikipedia CheckUsers to volunteer. Will start by asking on this talk page, and will post more widely if we need more people.

A steward might be OK too, but we'd need to ask ArbCom if they're willing to grant temporary English Wikipedia CheckUser to facilitate this. Last election I think ArbCom did this but felt a bit surprised and pressured, so this time around we'd need to ask them early and wait for their approval. โ€“Novem Linguae (talk) 01:16, 16 May 2025 (UTC)

We have a pretty large pool of CUs, so I'd wait and see if you get volunteers before getting ArbCom to make special appointments again. I'll post to the list and see if anyone is interested. Primefac (talk) 13:20, 17 May 2025 (UTC)
I'm expecting to have a lot of time by then, so I'd be interested in volunteering as a scrutineer. beef [talk] 13:25, 17 May 2025 (UTC)
If needed, I can help. I would be a bit busier, but probably would have space to do it. Would defer to others if there are other volunteers. Dreamy Jazz talk to me | my contributions 14:23, 17 May 2025 (UTC)
I've been pretty much out of the CU game lately, so I'll be happy to pitch in with the scrutinizing (scrutinization? scrutineering?) if you need me. Now that we've spun up AELECT for real, we really should aim to be self-sufficient and not have to impose on the stewards. RoySmith (talk) 15:27, 17 May 2025 (UTC)
I'll put myself forward. -- zzuuzz (talk) 16:50, 17 May 2025 (UTC)
Sounds like we've got our three then: 0xDEADBEEF, RoySmith, and Zzuuzz. Thank you very much for volunteering. Dreamy Jazz can be the "alternate" in case anyone is busy.  Done. โ€“Novem Linguae (talk) 17:45, 17 May 2025 (UTC)
I can likely serve as an alternate as well. Best, Barkeep49 (talk) 02:04, 19 May 2025 (UTC)
I think a good time to ask this in the future would be when there is a date set for the election, to ask specifically for CUs who can be available at the scheduled end time ("00:00, 32 July 2025 (UTC)") to start checking. I imagine that many candidates will be eager (as was I) to get the result as soon as possible. โ€“ JensonSL (SilverLocust) 05:01, 20 May 2025 (UTC)
+1 To that. Making the process as painless as possible means making it as short as possible (suspense is not fun). Obviously, that shouldn't come at the expense of allowing for scrutiny of the candidates, but ensuring the CUs we choose will be available to scrutinize the votes in an expeditious manner is an easy win.
And before anyone goes there: Being an admin is hard, but "letting candidates feel a taste of hardship" is not kind to the people going through the process. I've been an admin for almost a year, and I have experienced nothing on Wikipedia even coming close to the stress of RfA; my activities in that time included clerking WP:PIA5. HouseBlaster (talk โ€ข he/they) 23:42, 21 May 2025 (UTC)
It may be useful to have some standing documentation on scrutineering. Instructions are available for arbcom elections 2010 - 2024 and maybe other places. WMF elections also have an adequate description page. I guess if securepoll is going to be used more often for other things, a generalised page might make more sense, with specific criteria listed in each election page. -- zzuuzz (talk) 09:51, 23 May 2025 (UTC)
For my part, I'm mostly interested in the community expectations for what justifies a check. My experience is mostly at SPI, where cases are brought with behavioral history which informs a CUs decision to check or not. We won't have that when scrutinizing an election, so guidance along those lines would be a good thing. RoySmith (talk) 11:16, 23 May 2025 (UTC)

Election clerk(s)

What are our current thoughts on who the election clerk(s) for the next election should be?

As a reminder, these are the technical folks who set up the poll, hold the encryption key, configure the eligible voter criteria, things like that. This role is not able to see any confidential data like IP addresses (unless they are also a checkuser). The 3 scrutineers that we pick will also be de facto election clerks (they'll have access to everything an election clerk does) but I do not envision election clerking being the scrutineer's main role.

I'd like to propose myself as the next poll's election clerk. Happy to follow the community's lead though. If selected for this role, I plan to load up SecurePoll on my localhost wiki and set up a test election there, then write a thorough work instruction on how to do it. Then create an enwiki test election and have a couple volunteers vote, and refine the work instruction. Then do it for real the third time. Writing a good work instruction will help someone else be able to take over this role in the future, and practicing a couple times will make sure that the election clerk is experienced enough to avoid something like messing up an encryption key or a voter eligibility configuration during the real poll. โ€“Novem Linguae (talk) 01:10, 16 May 2025 (UTC)

I believe the best way to handle this is by a simple notified discussion on this page. I believe it's best you are election clerk for this election, but will prefer a neutral discussion, just in case. Something as simple as "Who will election clerk for next election" and allow anyone to discuss options. And then crosspost the same/notify the same on WP:RFA and two three other pertinent venues.
Basically I'd like to dot all Ts and crossed all Is, even when I believe you're the best option for facilitating this election. Soni (talk) 05:25, 16 May 2025 (UTC)
While I am a bit hesitant to bother noticeboards about AELECT stuff yet again (I feel like I'm asking for their input on the small details of AELECT perhaps a little more than I should), there's been very little participation in this section, so we might have to. โ€“Novem Linguae (talk) 17:43, 17 May 2025 (UTC)
You being the election clerk makes the most sense, as there isn't documentation yet. โ€”Femke ๐Ÿฆ (talk) 18:22, 17 May 2025 (UTC)
The noticeboards see "There is a pertinent discussion at X place about Y" all the time. It doesn't have to be fancy or all over the place, as long as we inform the main places it would be fine Soni (talk) 19:01, 17 May 2025 (UTC)
Novem is a very good choice for being an election clerk for this election. I think we would need at least one more just for redundancy and to increase our bus factor a bit. BugGhost ๐Ÿฆ—๐Ÿ‘ป 07:05, 18 May 2025 (UTC)
I can be a backup clerk if need be. โ€“ robertsky (talk) 10:36, 20 May 2025 (UTC)
Likewise, though I suspect admin clerks only might be a better solution for the time being. Soni (talk) 11:32, 20 May 2025 (UTC)
Robertsky is an admin. By the way, what do we envision the second clerk doing exactly? Technically the second clerk is actually the 5th clerk because the scrutineers are also election clerks. โ€“Novem Linguae (talk) 14:58, 20 May 2025 (UTC)
Mainly just for redundancy, for example having a copy of the encryption key in case the "primary" election clerk goes missing, and to double check config etc before the election goes live. I agree it's not the most essential role but at the moment having one person responsible for the setup is a single-point-of-failure. I'm happy with any of the scrutineers volunteering to act as an election clerk - I know they technically will have the user right either way, but I assumed scrutineers would be added to the poll after it was configured, and only carry out their roles after the ballot closed. (If people think having extra election clerks is unhelpful I'm happy to back down on this.) BugGhost ๐Ÿฆ—๐Ÿ‘ป 16:26, 20 May 2025 (UTC)
As I stated earlier, I think there should be at least one backup election clerk who is not a scrutineer with whom the encryption key is shared, so they can trigger a vote tally if necessary. isaacl (talk) 21:26, 20 May 2025 (UTC)
Sounds good to me. Sounds like through discussion this proposal has crystallized as me as lead election clerk and Robertsky as election clerk #2, and the idea is to share the encryption key between both of us. โ€“Novem Linguae (talk) 00:37, 21 May 2025 (UTC)
Notified: Wikipedia talk:Requests for adminship, Wikipedia:Administrators' noticeboard.
FWIW I'm happy to serve as a clerk or to test anything/be a test dummy. Giraffer (talk) 11:04, 21 May 2025 (UTC)
Also happy to be an election clerk in support of Novem & Robert as needed, or just as backup. โ€”Ganesha811 (talk) 15:52, 21 May 2025 (UTC)
I suspect we have enough volunteers, but... charlotte ๐Ÿ‘ธโ™ฅ 12:04, 22 May 2025 (UTC)
I suspect the same, but I'll be happy to help as well (especially on the techy side of things) Sohom (talk) 14:07, 22 May 2025 (UTC)
I marked myself as the main election clerk and Robertsky as the backup election clerk for now. Diff. Thank you to everyone who volunteered. If something happens and more election clerk volunteers are needed, we will be sure to reach out to the folks that volunteered here. โ€“Novem Linguae (talk) 22:29, 26 May 2025 (UTC)
It looks like our local page says that election clerks should only be added to administrators, however there appears to be one non-administrator in the list. โ€” xaosflux Talk 18:54, 10 June 2025 (UTC)
Turns out that was temporary and had to do with publishing the patch - I asked @SD0001 about it on their talk. โ€”Ganesha811 (talk) 20:37, 10 June 2025 (UTC)
I can attest to the fact that DreamRimmer was indeed involved in deploying the patch. While technically out of process, it is fine since to my understanding the right was only used to test if a admin was able to make a grant. (which was what the patch was for). Sohom (talk) 20:40, 10 June 2025 (UTC)

Admin election in June?

It looks as though the final technical changes to enable AELECT to run smoothly on English Wikipedia are moving forward and should be implemented soon. With that major task near-complete, it's time to think about scheduling our first non-trial elections. For simplicity's sake, we can wait out May to make sure everything is 100% ready, and aim for a June election. Proposed calendar:

  • June 3-10: Call for candidates, Tuesday to Tuesday to include a full weekend
  • June 11-15: Discussion phase, again including a full weekend
  • June 16-22: Voting phase, including a full weekend
  • June 23 to close - scrutineering and tallying, promote successful candidates.

With this schedule, we'd want to have a few election clerks volunteer in the first few days of June, though technically they wouldn't be needed until the voting phase begins on June 16th. Scrutineers could also be asked to volunteer ahead of time. Thoughts? โ€”Ganesha811 (talk) 16:25, 2 May 2025 (UTC)

My only thought is that this would put the voting period for the following elections at the same time as the voting period for the ArbCom elections (based on it being similar to the 2024 dates). I think it would be ideal to avoid that until admin elections are more established to reduce potential confusion, etc. Moving it circa 2 weeks forwards or backwards would resolve this I think. Thryduulf (talk) 17:04, 2 May 2025 (UTC)
Personally, I'd rather adjust the dates for any election in November/December if desired, than the one happening five months earlier. The rotating through the year approach means that eventually the problem will be encountered again, so I think it's sufficient to be flexible for the dates of the actual election in conflict. (The arbitration committee election dates could shift, for all we know at this time.) isaacl (talk) 17:17, 2 May 2025 (UTC)
If the technical changes are resolved fairly promptly, we could have a May/June election that runs from May 20th to June 9th, which would enable a October/November election ahead of Arbcom elections this fall. We could also use the June 3-23rd dates and then hold the fall election October 20th-November 9th anyway. I don't think we need to be super strict on the 5-month period between elections (after all, each election takes a few weeks) as long as we're close. โ€”Ganesha811 (talk) 17:21, 2 May 2025 (UTC)
For the technical reasons you discussed with Novem below, I recognize that a May 20th to June 9th admin election is definitely not happening, but I still want to oppose the first election after the renewal RfC running across two calendar months because it will spawn needless debate over whether the five-month timer is meant to go start-to-start or from the end of the prior election to the start of the next one. This upcoming election should be within a calendar month to set an expectation that the next one will occur in the fifth calendar month after. ViridianPenguin๐Ÿง (๐Ÿ’ฌ) 00:27, 16 May 2025 (UTC)
A thought: if we design this election cycle to not conflict with the same month as ACE, it'll end up conflicting some time in the future because of the odd # of months. โ€“Novem Linguae (talk) 19:13, 2 May 2025 (UTC)
Obviously, my thinking was just that it would be better to not conflict when AELECT is still a relatively new process. When it's established and routine, there should be fewer potential issues. If my maths is correct (and it might not be) if we delay this two weeks from the above suggested dates then the first clash will be the thirteenth election rather than the second and by that time any bugs in processes will likely have been ironed out, many unknown unknowns will have made themself known, we'll have experience of dealing with them and people will be familiar with both types of election. Thryduulf (talk) 19:25, 2 May 2025 (UTC)
Yes, that's what I said ("eventually the problem will be encountered again"). All I'm saying is we can defer worrying about this until the arbitration committee election RfC is over and the dates are known. There is enough flexibility in the administrator election process to allow for adjustments. isaacl (talk) 21:05, 2 May 2025 (UTC)
Election clerks will be needed before the start of the voting period in order to complete preparations and setup, particularly for the first time an election is run on the English Wikipedia server. Personally I think we'd want clerks and scrutineers in place before the call for candidates, and even the poll initially created (though not finalized for voting), so all resources are ready to run through the election process. isaacl (talk) 17:17, 2 May 2025 (UTC)
Whichever date we set, we could put out a request for election clerks and scrutineers say a week ahead of time. I agree it would be preferable to have volunteers and the poll in place ahead of the call for candidates, even if not strictly required. โ€”Ganesha811 (talk) 18:27, 2 May 2025 (UTC)
Fine by me. I take it the secure poll setup phase was for the trail only? fanfanboy (blocktalk) 18:22, 2 May 2025 (UTC)
Yes, it was more complicated then because it required the WMF to help set it up - in addition, because the suffrage requirements were complicated, a whitelist of eligible voters had to be manually generated and fed into SecurePoll. Neither should be true for future elections. โ€”Ganesha811 (talk) 18:26, 2 May 2025 (UTC)
I would be in favor of doing some localhost and enwiki test elections. During that testing I will write a work instruction, and that will shorten the SecurePoll setup phase, but probably won't eliminate it. โ€“Novem Linguae (talk) 19:14, 2 May 2025 (UTC)
I personally think this might be too early to schedule this. We do not have SecurePoll installed and working on en.wikipedia. Queuing up an election before we are 100% certain we can actually run it on that date is not a good idea, and puts undue pressure on us. We don't know if more software patches are required, and we haven't got a concrete decision on several key implementation details (eg. encryption) BugGhost ๐Ÿฆ—๐Ÿ‘ป 18:29, 2 May 2025 (UTC)
We certainly don't have to finalize any dates until those things have been taken care of, but it's good to start discussing it. From my understanding WMF has signed off and the technical changes will be implementable quite quickly. June is still a full month away. โ€”Ganesha811 (talk) 19:10, 2 May 2025 (UTC)
True, but it's worth remembering that the last RFC about AELECT ended up taking nearly 2 months to run its course. I agree with Novem that a June election isn't completely unrealistic and hopefully we'll be able to get it all working by that point, I'm just worried that we have several unknowns to deal with before we can be certain. BugGhost ๐Ÿฆ—๐Ÿ‘ป 01:46, 3 May 2025 (UTC)
It might be a bit early to pick dates. I have a sequential todo list that is something like 1) deploy config patch, 2) create the 3 MediaWiki pages and update the 3 documentation pages mentioned in Wikipedia:Administrator elections/SecurePoll permissions proposal, 3) ask WT:AELECT who the electionclerk(s) should be, 4) do a test election on localhost wiki, 5) do a test election on enwiki, 6) recruit 3 scrutineer volunteers from among the CheckUsers. Once that is complete, I think that'd be a good time to set the exact dates for the next election (because at that point it will have no blockers remaining). I do think June is realistic but I am not sure we should commit to exact dates yet. Hope that makes sense. โ€“Novem Linguae (talk) 19:11, 2 May 2025 (UTC)
Sounds reasonable. As mentioned above there's definitely no need to finalize anything until we're all set. โ€”Ganesha811 (talk) 19:24, 2 May 2025 (UTC)
phab:T378287 is probably blocked for another week on a security ticket. WMF is making good progress on the ticket and is on like step 4 of 5. The idea is they want to patch the security bugs before deploying SecurePoll more widely.
Revised estimate for next election is July or August. The gap in time is to allow some time for discussions of details, practicing with test polls, picking electionclerks and scrutineers, things like that. โ€“Novem Linguae (talk) 01:01, 16 May 2025 (UTC)
Update: the security ticket is on step 5 of 5. Should be unblocked in a week or so, and then will need another week to deploy enwiki config changes. Once that's done, we won't be reliant on anything outside our control, and we can pick dates for the election. The election dates will probably be around 1-2 months out from the unblocked/ready date, to give plenty of time to prepare. โ€“Novem Linguae (talk) 22:41, 26 May 2025 (UTC)
https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/1083870 is scheduled for backport. Once the backport is done, everything else will become unblocked, and we can move on to the next step, which is me doing test polls in localhost and on enwiki and writing work instructions for how to be an election clerk. โ€“Novem Linguae (talk) 22:36, 9 June 2025 (UTC)
And there it is! Special:ListGroupRights Special:ListUsers/electionclerk ๐ŸŽ‰๐Ÿฅณ๐ŸŽ‰๐Ÿฅณ๐ŸŽ‰๐Ÿฅณ Leijurv (talk) 18:02, 10 June 2025 (UTC)
Nice! I know we've got more to do but this feels like a big step - good job to those involved for us to get to this point. BugGhost ๐Ÿฆ—๐Ÿ‘ป 18:07, 10 June 2025 (UTC)
Agreed, great work from @Novem Linguae and others! โ€”Ganesha811 (talk) 18:12, 10 June 2025 (UTC)
Update: The next administrator election will very likely be in July. Let me do a test poll on my local computer, then a test poll on English Wikipedia using some volunteer test voters. I'll use that to write a work instruction for election clerks and gain confidence that we won't mess up the actual poll. Then once that's complete, let's set the dates. โ€“Novem Linguae (talk) 00:14, 11 June 2025 (UTC)

"blocked during the election"

I'm a bit confused by this criterion: "not be sitewide blocked during the election". This sounds like any block, even if removed before voting but after the poll starts, or applied after voting but before the poll ends, will make the vote ineligible. Is that really the intention? Should it be, "not be sitewide blocked at the time of voting"? Can blocked users actually vote? -- zzuuzz (talk) 23:40, 22 June 2025 (UTC)

From a technical control, it would be at the instance of voting. The larger question would be: If you are blocked after you vote (or even if you were blocked, then it expires), should your vote be striken? I think the technical control is sufficient alone. โ€” xaosflux Talk 23:44, 22 June 2025 (UTC)
Sockpuppets aside, I've never heard of anything being struck simply because someone got blocked a few days either side of a thing (technically, self-requested blocks and rapidly-undone mistakes would also be caught up in this). I propose then that the wording is changed to what I said above. -- zzuuzz (talk) 23:59, 22 June 2025 (UTC)
Arbcom elections use the wording "not currently sitewide blocked at the time of voting." Sockmasters who are not blocked can cast a vote, but if they cast a vote from more than one account then all of them are struck. No other blocks cause votes to be struck.
I don't see any reason for admin elections to differ in this regard. Thryduulf (talk) 00:08, 23 June 2025 (UTC)
I think it's implicit that all the voter eligibility criteria are "at the time of voting". I think just removing "during the election" is the simplest fix here. How's this look? โ€“Novem Linguae (talk) 05:17, 23 June 2025 (UTC)
That works for me, thanks. Out of curiosity I'd like to just return to my original question - can blocked users actually (technically) vote? -- zzuuzz (talk) 09:58, 23 June 2025 (UTC)
I don't think so. We'll test it in the next round of testing (enwiki test election) to be sure. โ€“Novem Linguae (talk) 10:11, 23 June 2025 (UTC)
No, it can be alwasy retested of course. The software looks up active blocks and will stop you if you are. โ€” xaosflux Talk 10:38, 23 June 2025 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Administrator_elections/Archive_5&oldid=1299859147"