OK, we've got about 3 and a half days to go. We're almost out of time. Are we ready for the call for candidates? Can someone please test signing up as a fake test candidate and make sure that the directions make sense, the templates are working, etc? Wikipedia:Administrator elections/July 2025/Candidates.
Is withdrawing done simply by editing the page manually to delete myself from the candidate list and add to the withdrawn one? -- DoubleGrazing (talk) 13:47, 5 July 2025 (UTC)
This is actually simpler than I remember it. I thought it'd be like RFA where candidates were creating subpages and subst-ing things. Now that I research this a bit more, I think that our team will create all the candidate subpages during the subsequent Housekeeping Phase. So this phase is super easy. Candidates just add themselves to the candidates page.
According to an HTML comment I just read, folks that withdraw during the candidates phase don't even need to be recorded. The "withdrawn" section is for folks that withdraw during the discussion or voting phase. So yeah, just remove yourself when you're ready. Thanks for testing. –Novem Linguae (talk) 13:56, 5 July 2025 (UTC)
I was incorrect. There was a hidden <inputbox> that was commented out, and the candidates use that to create their subpages. Thank you for checking. –Novem Linguae (talk) 04:50, 9 July 2025 (UTC)
Can we please get 2 admins to volunteer to be monitors? This role is basically the same as RFA monitors. Most of the monitoring will occur during the discussion phase (July 18–22), but there's a spot on the candidates page where we fill in your name, so I'm asking a bit early. Thanks. –Novem Linguae (talk) 13:24, 5 July 2025 (UTC)
Probably neither. I think this talk page post will probably recruit the two monitors without having to bother bigger noticeboards. If it doesn't recruit anyone in a few days, I'll ping the old monitors. –Novem Linguae (talk) 21:52, 5 July 2025 (UTC)
I have not acted as a monitor before but am happy to volunteer to help moderate, although I'm sure you'd prefer a more experienced admin to do so if possible. ThadeusOfNazereth(he/him)Talk to Me!01:47, 6 July 2025 (UTC)
You're hired! You'll do just fine. Just keep an eye on the candidate pages during the discussion phase, and call out anyone that gets rude, and maybe refactor a bit if things get really disorganized. And there's still one more spot. Tell your friends :) –Novem Linguae (talk) 03:11, 6 July 2025 (UTC)
I've not done any monitoring either (well, not since primary school...), but if no one better qualified steps up to the plate, I can give it a bash. Feel free to consider me the last resort option, though. -- DoubleGrazing (talk) 19:12, 7 July 2025 (UTC)
Having two admins from the previous election monitor the next one does have a pleasing sort of symmetry, though. -- asilvering (talk) 21:38, 7 July 2025 (UTC)
sorry, I don't think I can commit to being available for all of those days specifically, but I'll be poking in if there's things I can do! theleekycauldron (talk • she/her) 23:17, 7 July 2025 (UTC)
It's been a while, but I have been a monitor for both Enwiki and global SecurePolls. Willing to help out if needed. Note, I'm also a CU so could help on that end if needed. Risker (talk) 00:00, 8 July 2025 (UTC)
@ThadeusOfNazereth and Risker: Alright monitors. It's your time to shine. The discussion phase is now open for exactly 5 days. Duties: 1) respond to pings, user talk messages, etc. asking for you to investigate things on the candidate pages. 2) keep an eye on the candidate pages proactively. Please call people out for any incivility so that AELECT remains a pleasant process for everyone involved, similar to what RFA monitors do at RFA. This link may come in handy for watching all the candidate pages. Thanks for volunteering :) –Novem Linguae (talk) 00:33, 18 July 2025 (UTC)
Thanks for the link, Novem Linguae, I'll definitely use it. One question: are editors who are not eligible to vote permitted to ask questions? 03:35, 18 July 2025 (UTC)
I think non-XC are allowed to comment. I don't think AELECT has made a rule against it, and in other parts of the 'pedia editors who can't participate in a process are usually allowed to use the talk page. Thanks for checking. –Novem Linguae (talk) 03:54, 18 July 2025 (UTC)
Are election officials allowed to vote?
Clarification question: In a normal RFA, the monitors cannot participate by voting. Does this hold true also for the election-style RFAs? I won't be withdrawing from the role either way (I rarely participate at RFA, although I frequently read them), but it should be noted that a regular RFA disenfranchises the monitor with respect to a single candidate, while an election RFA can disenfranchise the monitor from up to 30+ RFAs, and that seems a little unbalanced. I'm okay either way, but this lack of balance should be noted. Risker (talk) 00:38, 9 July 2025 (UTC)
Yes. The suffrage requirements for administrator elections are the same as those for the open viewpoint request for adminship process. isaacl (talk) 00:55, 9 July 2025 (UTC)
I think it'd be OK for the monitors, election clerks, scrutineers, and other election officials to vote. Unless a bunch of folks on this talk page object. Last election we had no restrictions on who could vote other than suffrage. –Novem Linguae (talk) 01:41, 9 July 2025 (UTC)
Sorry, I've reverted your bold change to the election page. In addition to the existing RfA suffrage rules for monitors, I think there's a conflict of interest with scrutineers voting. isaacl (talk) 03:21, 9 July 2025 (UTC)
I think there is a risk of perceived bias in how the scrutineers decide which votes to strike. That being said, upon further reflection, in practice I think there won't be many situations where the scrutineers would be able to deduce the selections made by the voters in question. isaacl (talk) 04:16, 9 July 2025 (UTC)
I'd suggest keeping my change since it was just describing the status quo. We didn't forbid any election officials from voting in the last AELECT. I think we would need a consensus to change the status quo and introduce a prohibition. (Although feel free to work towards that consensus in this section.) –Novem Linguae (talk) 03:45, 9 July 2025 (UTC)
Two relevant things have changed from the previous election: stewards from outside the English Wikipedia community were used to scrutinize the last election, and the community decided to adopt the RfA suffrage requirements. Thus there is a consensus in place to prohibit monitors from voting. By virtue of the previous election's scrutineers not being contributors to English Wikipedia, the status quo there is that scrutineers didn't vote. isaacl (talk) 04:03, 9 July 2025 (UTC)
I would say instead that there's no consensus on whether scrutineers should be allowed to vote in the situation you're thinking of. That said, you seem to be confusing scrutineers with monitors. Scrutineers are the CheckUsers who tally the results and monitors are the admins who check the discussion pages. We used local admins for monitoring the last election too. I don't see how using stewards to scrutineer reflects any precedent to prohibit monitors from voting. Aaron Liu (talk) 16:11, 9 July 2025 (UTC)
Please be assured that, having followed the development of the process from the start, that I am aware of the difference between scrutineers and monitors. Nor did I say that the use of stewards as scrutineers was a precedent with respect to monitors. isaacl (talk) 16:43, 9 July 2025 (UTC)
Sorry, I was confused by your concluding Thus there is a consensus in place to prohibit monitors from voting. I'm guessing you meant to type "scrutineers" instead of "monitors"? In that case I still wouldn't call it a consensus. Using stewards was just a circumstance that says nothing about what consensus there is within the community, especially when last time's scrutineers' disinterest doesn't necessarily translate into a prohibition on voting. I don't think we used stewards because they would be uninterested in voting. Aaron Liu (talk) 21:52, 9 July 2025 (UTC)
Please be assured that I meant what I wrote. In my view, the consensus to use the RfA suffrage rules includes the rule for monitors. (I understand the counterarguments being made, so there's no need to repeat any of them in response.) My comments on the status quo with respect to scrutineers was a separate comment about scrutineers, not about monitors. (Again, there's no need to repeat any of the counterarguments.) isaacl (talk) 22:01, 9 July 2025 (UTC)
I think its fine for monitors/anyone else involved to vote. We currently don't even have any rules implying candidates can't vote, let alone monitors. BugGhost🦗👻02:34, 9 July 2025 (UTC)
As I stated, the consensus is that admin elections use the same suffrage rules as the open viewpoint RfA process. Monitors can't weigh in for RfAs, and so the same rule applies for admin elections. isaacl (talk) 03:09, 9 July 2025 (UTC)
To be honest, I probably wouldn't have really considered voting. However, there are some definite, fundamental differences between the election of admins and the RFA process, and the expectations on users and admins participating in these processes should be able to reflect some of those differences. I don't think this is a question that needs to be determined on this particular election, but is definitely worth discussing afterward. For the record, scrutineers for global elections have not been formally proscribed from voting, although generally speaking they do not vote. Having acted in all three roles (election setup/commission/whatever, scrutineering, and monitoring), I can say that the roles are quite different; of the three, I think there is a good argument that scrutineering (i.e., the group that determines whose votes actually count) may logically be restricted, but the logic involved in restrictions on the other groups is pretty tentative. Risker (talk) 03:36, 9 July 2025 (UTC)
The AELECT sufferage RFC didn't mention monitors and so I don't think this is a fair conclusion to draw. From looking at the RFA review page you linked, the main argument for disallowing monitor !votes at RFA is to stop the appearance of bias - and at AELECT votes are private, and so this is not an issue here. BugGhost🦗👻05:05, 9 July 2025 (UTC)
Monitors can't weigh in with comments on candidate subpages but can vote in the SecurePoll. I think that's fair. Their !vote isn't going to change anything either. If anything forbidding their vote might incentivize a bit electioneer-screwing with the comments. Aaron Liu (talk) 16:08, 9 July 2025 (UTC)
WP:ELECTCOM is allowed to vote, and that's by far most analogous to the monitor position (dealing with discussion pages surrounding a SecurePoll vote). The "RfA suffrage requirements" wording was pretty clearly not intended to apply to this situation, I think. Extraordinary Writ (talk) 04:26, 9 July 2025 (UTC)
I, too, would like to restore NL's edit. Although the community decided to adopt the RfA suffrage rules for these elections, I'm pretty sure that most if not all editors were thinking in terms of the minimum requirements for being able to participate, and not in terms of the "fine print" about those officiating. I'm not seeing any potential for abuse or the appearance of conflict of interest that would be significant enough to worry me. --Tryptofish (talk) 21:24, 9 July 2025 (UTC)
I don't think that the scrutineers should be voting. They have privileged access to the election, and are able to remove other people's votes. That's one reason for arbcom elections we always pick scrutineers that are not involved in the community. I don't really have an opinion on the "monitors". On the fence for election administrators, leaning towards allow. — xaosfluxTalk02:02, 10 July 2025 (UTC)
Election administrators, as in election clerks (for this election, Novem Linguae) who set up the pages and poll, or monitors (Thadeus and Risker) who patrol the candidate discussion subpages for naughty comments? The former should definitely be allowed to vote as I see little methods they can realistically influence the election's outcome. Aaron Liu (talk) 17:53, 10 July 2025 (UTC)
Honestly I don't get why scrutineers shouldn't vote. What's the downside, what's the fear? I could understand that a candidate can't be a scrutineer. I'd also understand if a candidate can't vote. Those are conflicts of interest. But what are we worried about if a scrutineer could vote? I don't see the downside. Leijurv (talk) 09:56, 10 July 2025 (UTC)
@Leijurv this will likely always be a multi-party, non-competitive election. Why would you think that running for admin should prohibit them from having an opinion on the other candidates? We could presume that candidates will vote for themselves, and change the passing calculation to ( (S-1) / (S+O) ) if the concern is about voting for themselves. — xaosfluxTalk14:45, 10 July 2025 (UTC)
Voters have declared an interest in the outcome. Scutineers are empowered to remove votes of others, which will also impact the outcome. — xaosfluxTalk14:49, 10 July 2025 (UTC)
To clarify, I think candidates should be allowed to vote, I was just saying I'd understand the line of argument against that. I do actually think candidates should never be scrutineers but that's a totally implausible scenario of course. Upon rereading, my message was confusing, sorry.
My question stands: what misbehavior could arise if scrutineers could vote? I don't see what we are scared of. Leijurv (talk) 15:04, 10 July 2025 (UTC)
I think people are scared of scrutineers removing too many votes or distorting the vote counts to favor their preferred candidates. (Though besides what I said above, I think it's unlikely that the three scrutineers all have the same opinions on candidates and are willing to do such things.) Aaron Liu (talk) 17:55, 10 July 2025 (UTC)
Okay, fine. Scrutineers have to act impartial while scrutineering. If you allow them to vote, then they would probably form opinions on which candidates they prefer, perhaps they would even notice which other users prefer the same candidates. Perhaps they now have at the back of their mind which voters they agreed with more or agreed with less. Perhaps now they'll be more likely to accept / reject said votes. I feel as though this is a bit convoluted and unclear though, because allowing them to vote doesn't directly allow any misbehavior. The misbehavior of favoring a particular set of voters is possible regardless. I feel a bit torn because of how far removed this is from actual impropriety. Hm. But at the end of the day, xaosflux you are right that the work they do is in secret, and it helps decide who becomes a sysop, therefore the degree of trust is extreme. Therefore, even the slightest hint that they aren't impartial must be avoided. Even if the hint is just that they have read the candidate pages and formed an opinion on them. Tentatively I agree that scrutineers ideally shouldn't vote. Leijurv (talk) 18:16, 10 July 2025 (UTC)
Perhaps we can get to a consensus that scrutineers cannot vote (I'm personally not worried about that, but I'm looking for a consensus), but that monitors and all the other election officials may vote. Does that work? --Tryptofish (talk) 22:48, 10 July 2025 (UTC)
I think the others are at least OK, the work they do is in the open and if they were to do something outrageous (e.g. electionadmin starts tampering with the electoral roll, refuses to resolve roll errors, etc; monitors are inappropriately disrupting discussions, etc. ) - the community could swiftly deal with it. — xaosfluxTalk13:22, 11 July 2025 (UTC)
For purposes of keeping track of what we are discussion, here is the revert that is being discussed: [1]. What I'm suggesting is putting that back onto the election page, but without "scrutineers". Thus: Monitors and election clerks are permitted to vote. Is that OK? I recognize that there is new discussion in the comments immediately below, that includes the issue of the optics of voter guides and other public statements, but I'd prefer to treat that separately. --Tryptofish (talk) 19:56, 11 July 2025 (UTC)
Scrutineers check that votes are not made from accounts that are ineligible to vote (e.g. alt accounts), and look for evidence of sockpuppetry. Why would this require seeing how people voted? jlwoodwa (talk) 19:43, 13 July 2025 (UTC)
Well then, I have no idea why participating would create any appearances of bias. That said there is already a consensus here and the election is not far away so I feel like I should hold off on discussing this until the election's over. Aaron Liu (talk) 19:50, 13 July 2025 (UTC)
Having thought about this a bit more, I think the fact that the voting is secret eliminates all issues with voting in the election for election officials. This is probably why election officials in real life are also allowed to vote. So I think all election officials should be allowed to vote. I do think the monitors specifically should avoid any public statements about what they think of the candidates though, including not doing voter guides. The monitors are the folks that might have to use subjective judgment and block someone on the discussion pages, and it would be bad for folks to think "oh, X monitor supports Y candidate, which is why they blocked Z opposition". So I would support a rule that monitors may not state any public opinions about the candidates and candidacies, and probably not even ask the candidates official questions on the discussion pages. I think this is less of an issue for scrutineers, who will be doing their vote striking and blocking based on more objective criteria (i.e. is there technical data here that they are a sock?), and zero issue for election clerks. –Novem Linguae (talk) 05:18, 11 July 2025 (UTC)
I agree, except that for optics, it might be better if none of the officials created voter guides or expressed their voting preferences. In case of some of them this may not matter, but although you know that, not every voter necessarily does. -- DoubleGrazing (talk) 05:45, 11 July 2025 (UTC)
I have the same view as NL, that secret voting makes this different from traditional RfA, and reduces the concern about abuse, but I also don't think we are going to get consensus to allow scrutineers to vote (but you can prove me wrong). I think it's easy to agree that none of the election officials should be making public statements about supporting or opposing candidates, especially including voter guides, but I also think that's such a no-brainer that we don't necessarily need to make it policy. --Tryptofish (talk) 20:01, 11 July 2025 (UTC)
I am a backup scrutineer in this election and want to figure out if I should invest time into learning about the candidates or not. I do agree that we're not going to get consensus to allow scrutineers to vote but it's also not clear to me that it will be possible to get consensus scrutineers can't vote nor is it clear to me what the position is if there's no consensus - which is how I read this discussion. I think the closest parallels are ACE and the various elections Stewards can vote in and scrutineer. Personally I think ACE Electcom people have more power to swing an election than scrutineers - they can, for instance, declare someone completely ineligible to run or last dramatically permit a borderline question that harms a candidate. I won't plan to vote in this election - time I can spend doing other things - but I do think trying to figure this out matters. BEst, Barkeep49 (talk) 21:35, 11 July 2025 (UTC)
I admit I'm confused by the idea that scrutineers can't vote because they might screw with things. The three of them together would have to mutually agree on anything shady, wouldn't they? Isn't that surety enough? -- asilvering (talk) 21:52, 11 July 2025 (UTC)
I don't think it's explicit manipulation, but more at the margin that they would make a decision to remove someone who didn't vote the way they wanted. The recent u4c election showed even single votes can matter (where if 1 oppose had been a support someone else would have been elected). In a large field like this it does become harder for me to understand how manipulation would truly work because the scrutineers would all have to be inclined to so support or so oppose some person (whose vote they also know) that they'd be willing to throw out all the other accompanying votes. Best, Barkeep49 (talk) 22:28, 11 July 2025 (UTC)
I agree with Barkeep49 that the perceived risk is more of unconscious bias. However since the scrutineers don't know how people voted, they would only be able to make suppositions from any public statements made by voters. I imagine that the intersection of voters whose votes could be surmised and voters who are at risk of appearing to be a sock puppet will be small. I think monitors have an opportunity to influence voters through their choices in moderating discussions, but I appreciate the viewpoint that this risk can be managed. isaacl (talk) 04:58, 12 July 2025 (UTC)
The only opportunity to sway the direction of votes would be when someone declares they have voted in a certain manner and then the scrutineers strike the entry out on that basis. But coming from what people see as an authoritarian country with an actually free election, I would say that people do say one thing and do another in secret, ie support the incumbent in the public but vote for the opposition behind the secret booths and vice versa. So personally I wouldnt take much stock in the declarations when scrutinizing. While exploring the backend tool, unless I am mistaken, there's no way to know which way people vote, and I suppose strikes would be mostly based on technicalities more than anything else. – robertsky (talk) 05:22, 12 July 2025 (UTC)
While exploring the backend tool... there's no way to know which way people vote is correct. And you can't can't re-scrutinize after dumping the file for results. Best, Barkeep49 (talk) 21:33, 13 July 2025 (UTC)
I think you can still strike and unstrike votes after tallying. Tallying multiple times is allowed. I think the idea is to have the option to re-tally if a sockfarm is found really late. However this is very hypothetical and I doubt this would happen. Also, tallying only reveals the count of votes. It does not ever reveal individual votes –Novem Linguae (talk) 22:40, 13 July 2025 (UTC)
To be explicit about the problem I believe Novem is referencing: this does lead to the hypothetical ability to tally, strike a vote, tally again, then compare tallies to see who the struck vote was for (and then optionally unstrike to reinstate the vote). More info over here: User:Bugghost/Securepoll notes#Strike/unstrike vulnerability and previously discussed here. I agree with Novem that this is very unlikely to occur in practice and our scroots/election clerks are highly trusted users, but just wanted to be clear that there currently are ways for scrutineers to unseal individual votes. BugGhost🦗👻06:15, 14 July 2025 (UTC)
Different question - are scrutineers allowed to nominate people? I'm planning on adding a co-nom statement for a candidate. If a conflict arises I'd rather do the nom instead of scrutineering, so other people will have to step in. dbeef [talk]10:28, 13 July 2025 (UTC)
I think in general it's best to avoid scrutineers nominating people or stating their voting intentions. It's not that I don't trust any individual scrutineers, it's just that I think it's just a business-as-usual example of being wp:involved while in an administrative position. BugGhost🦗👻13:05, 13 July 2025 (UTC)
(To clarify: I don't think this has been discussed previously and we should figure this out at RFC after the election - I'm personally not going to kick up a fuss if you nominate and scroot this election, just indicating what my position will be when the RFC inevitably occurs) BugGhost🦗👻13:17, 13 July 2025 (UTC)
I agree with BugGhost. For the sake of both being and appearing to be unbiased, I think those who have an official role with regards to the election should avoid stating their votes/voting intentions publicly. Thryduulf (talk) 14:52, 13 July 2025 (UTC)
I agree it provides a bad look. But as I am noting above in a multi-candidate election like this (especially when we get above 2 or 3 candidates) scrutineers can't really bias the election in a particular way even if they wanted to. This is in contrast to "monitors" who could, though there a monitor could recuse from a particular candidate (as candidates are not in competition with each other unlike in an arbcom election). Best, Barkeep49 (talk) 21:35, 13 July 2025 (UTC)
I don't see a problem with anybody voting here, just like you don't use your vote in real life when you are an election official. The remote chances of manipulation are largely independent of whether someone votes or not. For such a thing have even the tiniest chance of happening, I imagine a scrut would need to be already deeply involved in an editor's success, and just voting won't give you that level of caring. —Femke 🐦 (talk) 07:06, 14 July 2025 (UTC)
I've been a scrutineer for a federal election and not only was I allowed and expected to vote in that election, I was expected to be partisan in my scrutineering. (That's why they have scrutineers from each party.) What I wasn't allowed to do was wear party colours anywhere near the polling location. -- asilvering (talk) 16:03, 14 July 2025 (UTC)
I don't think we should model our elections on any particular country's practices. I also don't think trying to get a fair system trying to balance equal-and-opposite bias is the right design. I do however agree that everyone involved should be allowed to vote. Also, Femke did you mean to say "you don't lose your vote" when you said you don't use your vote in real life when you are an election official? BugGhost🦗👻16:35, 14 July 2025 (UTC)
EC gaming
This probably isn't related to the election, and even if it is, I'm sure our Central Scrutinizers are all across it anyway, but just to flag up that there seems to be some sort of ongoing campaign to game large numbers of sock accounts to extended confirmed status. Many of them are going about in a blatantly vandalistic way (see this AN thread) and therefore getting blocked pretty swiftly. But I've also blocked at least two accounts recently which were much more 'flying under the radar'. In all cases (that I've seen) this involved making repeated trivial edits in user space. --DoubleGrazing (talk) 08:57, 18 July 2025 (UTC)
I've been seeing many more EC vandals lately and have been seeing some AI use in gaming permissions. The sysop vote is one clear way gamed accounts might have an outsized influence on the pedia. Based on anecdotal experience I believe (but have yet been unable to verify) some new accounts are being Pgamed to EC via AI and then sold via crypto. BusterD (talk) 15:51, 18 July 2025 (UTC)
In ArbCom elections, one important way we deter this behavior is freezing the eligibility list on a date prior to the election. That way, there is no risk of this mass campaign while election operations are already underway. This prevents a user from being able to take an old sleeper account, game the eligibility criteria, and then use it to vote midway through the election. Maybe this is something to consider implementing for the next admin election. Something like, "Your account must be extended-confirmed by 14 days prior to the start of voting in order to vote in this election." Mz7 (talk) 19:05, 18 July 2025 (UTC)
I already ran the voter roll for this election and uploaded it. Yesterday I think. If anyone tries to GAME an old account, and they do their gaming between now and the end of the voting phase, they'll not be able to vote and will have to post on this talk page to ask to be added to the override list. At that point we can catch their gaming and deny their request.
Next election, we plan to switch to on-the-fly voter eligibility calculations (that software wasn't ready for this election, but SD0001 and I merged a patch that will allow it for future elections). So this hypothetical could become an issue. I guess the plan then would be to catch the sockmaster via scrutineering.
On-the-fly voter eligibility calculations are overall superior to voter rolls. It is less complexity / less work for the election clerk. –Novem Linguae (talk) 19:50, 18 July 2025 (UTC)
Ah ok, nice. For next election, could we still have it both ways? Could we have on-the-fly voter eligibility calculations to reduce the clerk workload, but also still make “have EC before XYZ date” be part of those calculations to deter gaming during the election itself? Mz7 (talk) 20:32, 18 July 2025 (UTC)
I don't think MediaWiki neatly stores the date that a user received a user group. Just that they're in the user group. (MediaWiki does store this in a not-neat way, via Special:Log. But that would not be efficient to query, and the code that reads the logs would be pretty fragile.) This might be something that we shouldn't proactively fix since the solution is messy. We're not even sure this would be a common attack vector. cc SD0001 for a second opinion. –Novem Linguae (talk) 20:38, 18 July 2025 (UTC)
Yes, the software can't directly check for "EC before <date>", but once phab:T397565 is resolved, we can check for EC + 500 edits before <date>, which is essentially the same thing. – SD0001 (talk) 15:46, 19 July 2025 (UTC)
If someone is willing to just make vandalism edits to reach a deadline for voting, then I don't think moving the deadline up is going to matter much. From a scrutineering standpoint, if this type of editing pattern is considered to be sufficient to reject a vote, then it's going to have to be checked anyway, no matter when the deadline is. isaacl (talk) 21:04, 18 July 2025 (UTC)
Why does {{Rfa-question}} suggested in the html comment create bold formatting, but the instructions say "Make sure to use level 3 section headers, not bold face. (3 equal signs)"? Rjjiii (talk) 05:09, 18 July 2025 (UTC)
Looks like RFA uses bold face rather than headers. I think I also lean towards bold face instead of headers. The size of the table of contents on the page Wikipedia:Administrator elections/July 2025/Discussion phase is increasing quite a bit with each question added because folks are currently using headers. Might not be worth fixing for this election, but maybe we can edit the preloads so that this problem is solved for the next election:
I'm not sure I understand the answer here. Are we to use the {{Rfa-question}} template AND then manually use the level 3 section header? Which is true? Looks like a two-stage process. When I attempted to insert a question, I ended up with two different appropriately styled headers so I've deigned not to add my questions yet. BusterD (talk) 13:22, 18 July 2025 (UTC)
You can hide level-3 headings with {{TOC limit}}. I don't think the number of "optional question from..." subheadings is a problem in any way, but if consensus is that it's problem hiding all level-3 headings wouldn't be too bad either since you would either want to scroll from the top of a candidate page or get to the discussion section, which is easily navigable as it is the end of a candidate page, if you get what I mean. Aaron Liu (talk) 13:44, 18 July 2025 (UTC)
I ended up just inserting the questions using the template, then going back manually to style the headers. The headers choice requires anybody adding questions (or fixing headers) to click the edit link at the top of each candidate subpage. BusterD (talk) 14:24, 18 July 2025 (UTC)
I have edited Template:Rfa-question to show a level 4 or level 5 header instead of pseudo-headings for all future RfA and ADE questions going forward. Each optional question belongs under "Questions for the candidate" and thus should have the next heading level (either 4 for ADE or 5 for RfA). GTrang (talk) 16:45, 18 July 2025 (UTC)
Instead of also introducing the same bug to RFA, I would prefer to instead revert this edit, which was added after the last election, undiscussed, and untested. –Novem Linguae (talk) 19:42, 18 July 2025 (UTC)
That is a change that would've benefited lots from discussion, but I'd say the bug is the mass creation of pseudoheadings, which is prohibited by MOS for accessibility reasons. Aaron Liu (talk) 20:03, 18 July 2025 (UTC)
I just came here to ask a similar question -- why do we even have an instruction to Make sure to use level 4 section headers, not bold face. (4 equal signs) instead of instructing users to just only use the template in the first place? Like, boldface, l3, l4, whatever the consensus is, enforce it through mandatory template use and there's no need for an explanatory instruction. ⇒SWATJesterShoot Blues, Tell VileRat!17:46, 19 July 2025 (UTC)
I don't think the community's sentiments support that much visibility. At the PhaseII RfC on voter guides, the opponents' argument that ArbElect's differences in needs made voter guides needed went unopposed. Aaron Liu (talk) 19:36, 19 July 2025 (UTC)
Weak oppose. Things like the voter guide category seem to me to be a level below in weight/importance of the items already in the navbar. Also voter guides are a touchy issue overall and had to be RFC'd after the last AELECT. –Novem Linguae (talk) 20:39, 19 July 2025 (UTC)
I agree with Novem Linguae regarding the past disagreements on voter guides. As quoted by BugGhost, there was a very specific type of sentence approved by consensus for one page, and no others. isaacl (talk) 21:20, 19 July 2025 (UTC)
Strong, foaming-at-the-mouth, jumping-up-and-down, oppose. The premise of these elections is to minimize the amount of stress on the candidates, and we have had numerous RfC discussions where the consensus has been against giving any voter guides any kind of official status – and a consensus that these elections are different than ArbCom elections in this regard. --Tryptofish (talk) 23:55, 19 July 2025 (UTC)
In the voting phase, the candidate subpages will close to public questions and discussion, and everyone who qualifies to vote will have a week to use the SecurePoll software to vote, which uses a secret ballot. You can see who voted, but not who they voted for. Please note that the vote totals cannot be made public until after voting has ended and as such, it will not be possible for you to see an individual candidate's vote total during the election. The suffrage requirements are similar to those at RFA.
Once voting concludes, we will begin the scrutineering phase, which will last for approximately four days, perhaps longer. Once everything is certified, the results will be posted on the results page (this is a good page to watchlist), and transcluded to the main election page. In order to be granted adminship, a candidate must have received at least 70.0% support, calculated as Support / (Support + Oppose), and a minimum of 20 support votes. Because this is a vote and not a consensus, there are no bureaucrat discussions ("crat chats").
Any questions or issues can be asked on the election talk page. Thank you for your participation. Happy electing.
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.
What is your perspective on Artificial Intelligence (AI) as it relates to Wikipedia?
I wanted to discuss the implications of this question in the discussion phase of the July 2025 admin elections.
On the surface, this is a timely and relevant question. However, I am concerned that it may have an unintended consequences such as facilitating the creation of groupthink among new admins.
When we ask candidates about their stance on paid editing or how they would treat a good-faith editor who made a mistake, we are testing their understanding of well-established community consensus.
The issue with the AI question is that it is fundamentally different. AI is a rapidly evolving technology. It is also a divisive topic. There is currently no community-wide consensus on the best way to integrate, regulate, or restrict AI-generated content. We have active, good-faith disagreements among experienced editors. Since there is no consensus, voters evaluate a candidate's response, they are likely to judge it based on their own personal, and often strong, feelings about AI. There might be deeper concerns about candidates tailoring their answers to what they think the community will elect. Though I am not sure that is a real concern.
An admin corps that has a pre-formed groupthink on AI may be less able to neutrally and effectively handle the complex AI-related disputes that will inevitably arise as the technology and our community's understanding of it evolves. I'm not outright suggesting that we forbid questions about AI, but I am curious to what extent others share my concern and have idea for what can be done with it.
Are others concerned that this specific question is becoming a litmus test on an issue where we have no community consensus?
Is there a better way to probe a candidate's understanding of AI? For example, would a more abstract question be more useful, "How would you approach an administrative issue involving a new technology where policy is unclear and the community is divided?"
I am not sure how asking a question of admin candidates on a topic that does not have established community consensus facilitates groupthink? Cheers, SunloungerFrog (talk) 06:41, 23 July 2025 (UTC)
And isn't it better to be asking questions about things that don't have established community consensus? Why would we want to be asking admin candidates about their position on things that are completely settled? -- asilvering (talk) 10:40, 23 July 2025 (UTC)
There are different reasons for asking questions, so I think it can be reasonable to asking about topics where there is community consensus. isaacl (talk) 17:26, 23 July 2025 (UTC)
We have some established and community-wide consensuses on different integrations and restrictions on AI, as well as on AI-generated content. I don't see why admins would be in particular unable to navigate AI disputes in a way they cannot navigate say questions on notability, paid editing, and similar perennially debated issues. CMD (talk) 08:34, 23 July 2025 (UTC)
Since this OP was posted an hour after all AELECT questions and discussions were closed, this seems a misplaced query, more appropriate at village pump. IMHO, this discussion does not belong here (it's off-topic). BusterD (talk) 08:41, 23 July 2025 (UTC)
Even tricky questions can be an opportunity to show good temperament, good communication, WP:CLUE, knowledge about hot topics, and other good admin qualities. If I were answering this one in an RFA, I'd probably spend most of the answer summarizing the discussions and sentiments about LLM that I've observed on English Wikipedia over the last year, then end it with a sentence or two about my own opinions on LLM. –Novem Linguae (talk) 11:51, 23 July 2025 (UTC)
A typical use for questions is to see how the respondent reasons about the topic. For this purpose, a question where editors have many different points of view can be enlightening. Any question on a topic where some editors have ardent opinions has the potential to sway voters to or away from a candidate. I don't think the degree of concreteness makes a significant difference in this respect. isaacl (talk) 17:22, 23 July 2025 (UTC)
I agree with Novem and Isaac - not all questions need to be a litmus test for good admin/bad admin. Reading an answer to an open-ended qualitative question is a good way of gauging the way an editor approaches a problem. BugGhost🦗👻20:50, 23 July 2025 (UTC)
Oops. My bad. Is it worth fixing though? I think it would trigger a user talk message notification for hundreds of people. –Novem Linguae (talk) 03:48, 24 July 2025 (UTC)
I have an approved bot task to fix typos in mass messages. I can run it, but I am away from home at the moment, so it might take a few hours. – DreamRimmer■04:11, 24 July 2025 (UTC)
Is the number of votes cast shown somewhere (in broadly real time), or is it kept secret until the poll closes? Just curious how the numbers are looking compared to the pilot. -- DoubleGrazing (talk) 14:02, 24 July 2025 (UTC)
It looks like Purplebackpack89 voted in the ongoing elections, but later that same day were banned by the community [2]. I'm pretty sure that votes by blocked users stand as long as the vote was not made when the user was blocked, but I had in my head that votes by banned users are struck retroactively. However, I couldn't find this covered in the voter eligibility rules of AELECT or RfA. Toadspike[Talk]09:10, 25 July 2025 (UTC)
Similarly, what about users banned after the voting phase, ie during the scrutineering phrase, should they also be struck? What about voting with a temporarily blocked account, that is then unblocked by the time of the scrutineering phase? As this wouldn't show up so obviously (as banned) unless checking logs individually I assume. There should be clarity based on when blocked accounts will be discounted, ie "if blocked during the voting phase July 23–29", or "if blocked during the election process July 9–??", for example. Recommending scrutineers make it up as they go along if no concrete guidance this time around, and then resolve this for December. CNC (talk) 09:30, 25 July 2025 (UTC)
Trying to disenfranchise voters that were only blocked for some of AELECT sounds complicated. For this reason, it may make sense to let their votes stand. –Novem Linguae (talk) 09:33, 25 July 2025 (UTC)
I'd be in favor of not striking it. It appears to have been valid at the time of voting. Trying to retroactively delete these kind of votes introduces complexity to the process. Also we didn't do anything like this last election, and we haven't previously discussed this kind of thing before, so there's no precedent. –Novem Linguae (talk) 09:32, 25 July 2025 (UTC)
Agree, as unless stipulated that votes would be deleted retroactively, then this shouldn't occur without community consensus, if it hasn't been discussed and no precedent has been set. That said, I still think scrutineers should decide, as those appointed to be responsible for such actions, and if deemed necessary to strike votes per current ambiguous wording. CNC (talk) 10:28, 25 July 2025 (UTC)
My interpretation is that the vote stands. I don't know if that's written anywhere, but is based on longstanding policy. For example, WP:BAN and WP:G5 are always very explicit about mentioning "in violation of their ban". Sockpuppetry may complicate the issue, but that doesn't seem to apply in this case so I won't go into that. However this discussion about socking seems to agree with my interpretation. -- zzuuzz(talk)09:40, 25 July 2025 (UTC)
I believe that the rules are clear: if the vote was valid at the time it was cast it stands. The only exception is if the scrutineers find that an editor has engaged in sockpuppetry and cast multiple votes in the election, in that circumstance all the votes they cast are struck. Thryduulf (talk) 10:22, 25 July 2025 (UTC)
To make the rules clearer, I think WP:RFA#Expressing_opinions should adopt the AELECT wording of "not be sitewide blocked", or something similar.
Your interpretation of sockpuppetry is a little limited. If the editor socked to evade a block, all votes are struck. If the editor socked to vote-stack, but not in evasion of a block, I believe we strike all votes but one (presumably the most recent one from the master's account). But again, I'm not sure. Toadspike[Talk]10:29, 25 July 2025 (UTC)
If someone socks in bad faith (not an accident involving voting with both their main account and their alt account due to inattentiveness, obfuscation is involved), I think it's reasonable to strike all the votes. –Novem Linguae (talk) 10:47, 25 July 2025 (UTC)
(ec) I believe we're going with the following interpretation, based on the link I've provided above (more in this page's recent archives): If someone tries vote-stacking with sockpuppets, all their votes are struck. This is not a common approach outside of Arb and Admin elections, but I'm comfortable with applying it here. -- zzuuzz(talk)10:52, 25 July 2025 (UTC)
Hm. I am also in favor of that, but it conflicts with the "if a vote was valid, it stands regardless of what happens afterward" principle expressed in response to my initial question. Toadspike[Talk]10:58, 25 July 2025 (UTC)
You're welcome to bring that up in a future discussion, though I would point to the discussion I've already linked. We're only concerned with attempts to fraudulently sway the election. I can see a clear difference in practice (though I will admit I'm not necessarily a huge fan). -- zzuuzz(talk)11:06, 25 July 2025 (UTC)
If the editor socked to evade a block, all votes are struck. If the editor was blocked before the election and casts a single vote with a sock, then that single vote was not valid at the time it was cast and is struck for that reason. If the same editor casts multiple votes with a single sock then all-but the latest vote would be struck (if it wasn't done automatically) in the same way for as any other casting multiple votes from the same account, the latest vote would be struck for the same reasons a single vote would be struck. If they cast votes with multiple socks then all the votes would be struck both for being invalid when cast and for being an attempt at vote stacking. Thryduulf (talk) 13:46, 25 July 2025 (UTC)
to be short: in general, the votes/participation of banned/blocked users stand/is accounted for in discussions (that is, obviously, if they made it before getting blocked). In case they were socks, votes of socks are discounted (this often happens in AFDs). To be very bureaucratic, in case the ban was imposed in relation of that particular discussion, even then discounting the vote is borderline. If that participant was blocked for gaming that discussion, then it would be appropriate to discount their participation. Other than that, if the editor was not blocked/banned when they participated, then their participation is considered valid. —usernamekiran (talk)10:32, 25 July 2025 (UTC)
As I discussed previously regarding sockpuppets, I think following the arbitration committee election rules is reasonable. For the arbitration elections, voters must not be sitewide blocked at the time of voting. Being blocked afterwards does not disqualify the vote. isaacl (talk) 14:14, 25 July 2025 (UTC)
Except, they say: "Scrutineers will strike all the votes cast by any sockmaster who voted multiple times, independent of whether the editor was blocked before or after casting the votes". I could interpret your comment to narrowly refer to this specific case described above, but then you mentioned sockpuppets. -- zzuuzz(talk)16:22, 25 July 2025 (UTC)
I was referring to my previous comment on handling sockpuppets, where I said I think it's reasonable to follow the same practice [used by arbitration committee elections] for administrator elections. This means allowing editors to vote if they aren't blocked sitewide at the time of voting if they are otherwise eligible. Users who vote multiple times using sockpuppets (added to clarify) become ineligible to vote. isaacl (talk) 17:05, 25 July 2025 (UTC)
I'm a bit unclear why we're preferring Arbcom election rules to RfA election rules, and then only some of them. Another example would be vanished users. Anyway I've spoken enough, and I'd want to hear from the other scrutes. -- zzuuzz(talk)17:24, 25 July 2025 (UTC)
These specific scenarios weren't discussed during any of the various large-scale community discussions, so there are no specific rules for administrator elections. In this absence, I feel it is reasonable to look at the community's views on arbitration committee elections and generalize them as applicable. English Wikipedia is not a bureaucracy, so we can leverage previous experience to craft a procedure based on common practice, gain more experience, and adjust later as needed. isaacl (talk) 20:54, 25 July 2025 (UTC)
I think we're in broad agreement about how to implement rules for this election (though it's possible the scrutineers may have to work some things out on the fly). Thanks to some excellent documentation for the most part. But for future elections, I think we should be aiming more for alignment with RfA procedures. Some specific discrepancies that I've noticed are the striking of sockmasters thing, of vanished users, and the prohibition of bot accounts (though I'd accept that last one is pretty edge-case). I'd prefer more alignment with RfA, but at least some type of mini-RfC would be a positive. Or a statement about defaulting to RfA rules, or something. For the next one. -- zzuuzz(talk)23:24, 25 July 2025 (UTC)
I don't see these as discrepancies, as the underlying principle of giving each person equal weight a priori remains. As anonymous voting has inherent differences with an open discussion, there has to be adapatations. Anonymous voting follows the one vote per person approach, which is why you can't vote multiple times, no matter how you try to do it. With a open viewpoint request for adminship, the identify of everyone weighing in is known, and when the bureaucrats count noses to get a rough idea of the level of support, they can combine comments all belonging to the same person as needed. isaacl (talk) 01:21, 26 July 2025 (UTC)
After an off-wiki scrute chat, we're of the opinion that Purplebackpack89's vote will not be struck. This is a decision which applies narrowly to this one user and is not intended to establish any kind of precedent. RoySmith(talk)19:12, 25 July 2025 (UTC)
Unable to vote despite being an Extended Confirmed user
I have been in the Extended Confirmed user group since July 19th, which means I should meet the requirements of being a voter (it goes without saying that I am not a bot nor have been blocked sitewide), and yet when I try to vote in the current election, I am told by the SecurePoll that Sorry, you are not in the predetermined list of users authorized to vote in this election. It directs me to this talk page to request assistance, which I am doing so now. I spent a couple hours (especially today) reading the full discussions of each candidate to make an informed vote for the election, so it would be unfortunate if that time spent reading on candidates (when I could have used to make improvements to articles instead) went to waste from being unable to vote despite meeting the listed requirements, and learning about this too late when I already put in the investment in learning about each candidate. Now if this is due to the fact that I received this user group too soon to the voting phase then I can understand that, but I would appreciate any help I can get on being to still vote in this election if I were allowed to based on these circumstances. Gramix13 (talk) 02:52, 26 July 2025 (UTC)
I wonder if adding a note to that error message saying that it might also appear if you very recently became extended confirmed and to just leave a note of this page if that is the case might be useful? Thryduulf (talk) 09:55, 26 July 2025 (UTC)
We could markup that part of the message with extendedconfirmed-show class, to avoid confusing folks to whom it doesn't apply. – SD0001 (talk) 17:16, 26 July 2025 (UTC)
I'm tempted to be lazy and not fix it, since it only affected one person so far, and we will be changing away from voter rolls next election (so the root problem will fix itself). –Novem Linguae (talk) 01:49, 27 July 2025 (UTC)
Voting phase closes in 5 hours 18 minutes
Hello friends. Friendly reminder that the voting phase will close in approximately 5 hours and 18 minutes, at 23:59 UTC.
If I'm not around when this happens, I think most of the relevant things will auto-close/auto-switch (SecurePoll, watchlist message, banner at the top of AELECT pages). You may need to WP:PURGE the page to get some of these to update. Feel free to clean up anything if I'm not around. Just make sure not to close early :) –Novem Linguae (talk) 18:42, 29 July 2025 (UTC)
Howdy. Can someone good with templates take a stab at adding a parameter to Wikipedia:Administrator elections/July 2025/Header such as |custom_message=, where I can add a custom message? Now that results are posted, I'd like to be able to update that. And I might want to update it again during the debrief phase, RFC workshop, and RFC phase. Thanks. –Novem Linguae (talk) 16:35, 31 July 2025 (UTC)
Support/Oppose/Abstain is also the general order that most votes are tallied/presented in government chambers (e.g. US Congress - which shows them as Yay / Nay / Present / Not Voting. Or WP:ARBCOM which also shows them as Support / Oppose / Abstain (e.g. latest Arbcom case.
So basically we use "Support/Oppose/Abstain" everywhere on wiki except here - so I'm gonna invoke Wikipedia:Consistency and would ask to reconsider so we can bring the results page here in line with other use on Wiki to avoid confusion :) Raladic (talk) 04:47, 1 August 2025 (UTC)
The status quo ante was neither of the options presented here. The status quo ante was oppose/abstain/support, to match the order of the columns in SecurePoll. The order of those columns in SecurePoll was the result of previous discussion. I'd recommend reverting to that order on the results page while this discussion takes place. I'm also not a big fan of folks messing with these results too much. What if a typo or miscalculation is made during refactoring? Then it looks like the scrutineers certified something that they did not. –Novem Linguae (talk) 05:02, 1 August 2025 (UTC)
I already reverted the column order (using the template).
I did also (as I noted in my edit summary) triplecheck the results to ensure that no typo or miscalculation was made (the % were helpful to crosscheck the support/abstains as I was replacing them one by one and had matching % in the preview to know it was right).
I just didn't realize the results page wasn't already using a row template since pretty much everything else around adminship stuff has some and I had created Template:AdErow last year for the October election already for the Wikipedia:Successful adminship candidacies/2024 page (which as I mentioned above, necessitates the columns being in sync with the status quo since 2003.
So, I get that the securepoll has some other order (and that was part of some discussion I missed), but it seems rather counter-intuitive, given that it is the opposite of pretty much every ballot sheet I've ever seen.
Support is always first, followed by Oppose and either you leave them blank, or there's a 3rd box thereafter for abstaining.
I already reverted the column order (using the template). The column order is currently support-abstain-oppose. When I originally posted these results, the column order was oppose-abstain-support. My attempt to put it back in this order was reverted by you, I believe.
No, that order of Oppose-Abstain-Support was changed to Support-Abstain-Oppose by @Extraordinary Writ - here.
I made my template conform to that. I didn't realize you want to go and introduce a different 3rd different order for the results page.
I do understand the psychology for during the voting due to limitations of the voting software, but we do not need to limit our resulting outcome pages to that. No one cares about how the voting software was structured once we look at the results tally and I think we should show the results tally in the usual order of modern election tallies, aka Support/Oppose/Abstain. Raladic (talk) 05:29, 1 August 2025 (UTC)
Personally, I don't think the column order on the results page has to match the order on the ballot. Some of the considerations for the ballot (matching the arbitration committee election ballot, layout limitations) don't apply to the results page. Thus I think matching how the results are displayed on the RfA page and arbitration committee election pages is reasonable. isaacl (talk) 05:29, 1 August 2025 (UTC)
I think it's fine that the secure poll is set up to have Oppose and Support be visually separated by the neutral abstention in the middle. But I don't think we should stick to that for the results page.
(Personally I do feel that on the voting page support should be first and Oppose at the end, but that's a separate discussion that doesn't need to happen here, though I take your comment I saw from that other discussion that that order for the voting software is consistent with how it's presented for Arbcom member vote, so maybe we'll just keep that one as it is). Raladic (talk) 05:31, 1 August 2025 (UTC)
I don't really mind whether we use Support/Abstain/Oppose (like ArbCom election results) or Support/Oppose/Abstain (like everything else). But yeah, I found it very confusing to do Oppose/Abstain/Support: it's one thing to do it like that on the ballot, but the results don't need to be the same way (as in ArbCom elections, where the ballot is O/A/S but the results are S/A/O). I don't think there's anywhere else on Wikipedia where we report results starting with Oppose. Extraordinary Writ (talk) 05:37, 1 August 2025 (UTC)
My point is that "Neutral" in an RFA is still someone actively taking point in the discussion. "Abstain" in the election is someone specifically not taking part in the decision for a candidate. — xaosfluxTalk09:57, 1 August 2025 (UTC)
I don't care about the way the results are ordered. But I am wondering if, for future ballots, it might be worth changing the order from "oppose, abstain, support" to "support, abstain, oppose". Something that seems clear (at least to me) from the results is that voters trended towards opposing much more than what typically happens in traditional RfA. Perhaps, having "oppose" as the left-hand column has a psychological effect, and it might be worthwhile to reverse that. --Tryptofish (talk) 14:17, 1 August 2025 (UTC)
I suspect it is more that those voting oppose in the election don't need to worry about having to defend their position later. In traditional RFA's while supporters are mostly ignored, a significant number of opposers spawn discussions about their individual stances. — xaosfluxTalk14:43, 1 August 2025 (UTC)
Yeah, who would have thunk it? The way to make RfA less toxic is to allow badgering of opposes. But, seriously, I find it hard to believe that the number of editors who hold back from opposing in traditional RfA would be large enough to account for the voting numbers in the election. --Tryptofish (talk) 22:22, 1 August 2025 (UTC)
There is a good argument that the election is by far "less toxic" for opposers, which far outnumber candidates. — xaosfluxTalk17:51, 2 August 2025 (UTC)
I did almost vote oppose for all of the candidates I was intending to support until I did a double check of my ballot. signed, Rosguilltalk18:10, 2 August 2025 (UTC)
We could also just leave them there. They're not hurting anything. They're not listed on the main candidate page, so the only way someone could find them is through a subpage search. –Novem Linguae (talk) 18:22, 2 August 2025 (UTC)
I agree with Novem that the best solution is to do nothing (aside from removing those categories, which you have correctly done already). I think the current wording at Wikipedia:Administrator_elections/July_2025#Withdrawing is fine: we can still ask people to request WP:G7 (author-requested deletion) for their unlisted candidate subpages, but if they don't do that, then there's no harm in just leaving it there. Mz7 (talk) 23:54, 2 August 2025 (UTC)
Would we maybe want to move them to a subpage structure though to make it clear they were not actually running in the election?
Personally, I think people checking manually will generally look at the candidates page to see who ran. I think only categorizing actual candidate pages should suffice to support tools looking for a list of candidates. isaacl (talk) 03:26, 3 August 2025 (UTC)
election guides
The candidate discussion page said Please do not cast votes or issue any declarations of support/opposition here. Yet there were "guides" declaring support/oppose like this, and this. I am not opposed to actual guides that are neutral like by FemkeAsilvering, Novem, and others. But the two pages above are clear declarations of votes. Why is this this permitted? This is against the spirit of EFA. —usernamekiran (talk)05:36, 3 August 2025 (UTC)
The sentence you're quoting is just guidance about the purpose of that specific part of the page (hence the "here"). It's mainly just to make sure people don't treat the discussion phase like RFA, and post stuff like "Support - I already thought they were an admin!" or whatever. People are still allowed to disclose who they are planning to vote for elsewhere. BugGhost🦗👻07:47, 3 August 2025 (UTC)
Secret ballot doesn't mean individuals are bound to secrecy as to their votes, it means that votes are by default secret. Every one of the linked examples you've provided is a valid voter guide. ThadeusOfNazereth(he/him)Talk to Me!10:38, 3 August 2025 (UTC)
you are missing the big picture - I don't think I am, I have been involved in AELECT since before the trial and this has been discussed multiple times, and I am not aware of any community consensus to require people to conceal their voting intentions. Based on previous discussions, I don't think a proposal to create that requirement would get much traction. BugGhost🦗👻14:12, 3 August 2025 (UTC)
I know I keep saying this like a broken record, but the voter guides are a net negative. I realize that, with numerous candidates, many editors are eager to have ways to simplify the process of choosing, but I think the existing consensus should be reexamined before the next election. --Tryptofish (talk) 16:05, 3 August 2025 (UTC)
It's going to happen, on-wiki or off-wiki. I appreciate the on-wiki guides even if they didn't recommend me because I got a feel for why someone might not choose to support me, and I'm able to look into that now if I choose to stand again later. The election process gives startlingly little feedback. ~Darth StabroTalk • Contribs16:41, 3 August 2025 (UTC)
@Bugghost: I did not mean to offend you. On side note, I have been active in RfA reform (generalised discussions to improve RfA) in 2017-18. I have been observing the AE related discussions as well, I haven't commented much there though. If the participants aren't allowed to display their vote on discussion page, then displaying it somewhere else (with or without rationale) before voting period is over, is swaying the election. It is similar to voting in RfA with only difference being commenting it on userpage instead of actual page. Then whats the point of going through all that trouble of AE (for candidates, scrutineers, participants, tech-team, and everybody). That's what I'm saying. —usernamekiran (talk)16:41, 4 August 2025 (UTC)
Don't worry, no offense taken, was just clarifying. As far as I am aware, participants are allowed to make their voting intentions obvious on discussion pages, and are also allowed to "sway" the election (what else is the purpose of nominators?), and it's pretty common thing to do (eg. comments like this are perfectly fine). The benefit of AELECT over RFA is that support/oppose comments aren't necessary, and so the discussion isn't a boolean two-tribes decision. These aspects lower the temperature a lot - but it doesn't bind anyone to secrecy. BugGhost🦗👻17:16, 4 August 2025 (UTC)
I'm just writing this FYI for the future scrutes (see also phab:T397819). The 'CSRF' and 'Duplicate' columns were empty while scrutineering the test election, and there was some speculation they may be something related to global elections. We had examples appearing in both columns for the July 2025 admin election. There were five CSRF failures labelled 'Failed'. The scrutineers did not strike these votes. A successful CSRF basically means you're logged in, and you return the edit token provided to you by the voting page. A failed CSRF could be caused by a few things, most of them bug-related. Timeout (taking too long to vote) could be one option, but I see that the token is valid for 30 days. The worst case scenario is probably some hacker tricking a user into voting from another site. This seems relatively unlikely, both generally and in these cases. The Duplicate column contained 'Dup cookies' for one user who had their account renamed during the election (and did not vote twice). You can see which account name has the other cookie by looking at the vote details. -- zzuuzz(talk)21:45, 3 August 2025 (UTC)
CSRF tokens are not valid for 30 days. The expiry is based on how long the php session remains active, which is mostly random. It is quite possible for it to become invalid if a user takes too long to vote (though not for all users who take too long to vote). "Dup cookies" is shown in the duplicate column when two users visit the voting page from the same device (hence share the same cookie), which makes it quite likely they're socks. Renames can indeed cause false positives because names are used instead of ids to tell differentiate users (this is because in global elections, the same user can have multiple ids as they could vote from multiple wikis). – SD0001 (talk) 17:49, 18 August 2025 (UTC)
My overall impression of the field of candidates was very positive, and I'm somewhat surprised that so many of them fell short of the support cutoff. Despite it not being a competition, I imagine that many voters may have felt pressure to avoid supporting more than half of the candidates. I think that even those who were unsuccessful should still feel proud to have been a part of such a strong field of candidates. signed, Rosguilltalk16:02, 31 July 2025 (UTC)
Agree. That said, 9 out of 16 = 56% got elected, whereas in the previous (Oct-24) one 11 out of 32 = only 34% did. Of course, any number of factors could account for that difference. -- DoubleGrazing (talk) 16:10, 31 July 2025 (UTC)
This is the second election in a row where the 65%-69.9% range of candidates was strong. We should look into RFCing a lowering of the pass threshold to 65% during the upcoming RFC phase. –Novem Linguae (talk) 16:37, 31 July 2025 (UTC)
I don't know, if you're looking for breakpoints in the data there's +2.2%/-3.4% around 70% but only +0.8%/-0.4% around 65%. Unless you're willing to go all the way down to 60%, 70% seems like a natural break in the distribution. --Ahecht (TALK PAGE)17:02, 31 July 2025 (UTC)
If you include the last election, there's +1.66%/-1.09% around 70% and +0.79%/-0.25% around 65%. The largest breaks between 60% and 80% are 4.7% around 62%, 3.7% around 80%, and 2.7% around 70%. --Ahecht (TALK PAGE)17:12, 25 August 2025 (UTC)
I'm glad that this time (unlike last time) there were enough questions/conversations that everyone who didn't pass has at least some understanding of why people opposed and where they can improve. I actually think these results are evidence that the 70% threshold is working exactly as it should, and I'll continue to oppose lowering it if another RfC on the topic is started. Extraordinary Writ (talk) 19:32, 31 July 2025 (UTC)
Honestly speaking, I'm not sure why I got so many opposes. With RfA it would have been clear. —usernamekiran (talk)21:42, 31 July 2025 (UTC)
I feel similar. I wasn't really expecting to pass based on how things went in the discussion phase and what I observed off-Wiki, but I wasn't expecting it to be so low. A real downside to this method. If I stand again, it'll definitely be as an RfA. ~Darth StabroTalk • Contribs22:40, 31 July 2025 (UTC)
Yeah, several people I gave my wholehearted support to fell short for reasons I really can’t identify. EF522:46, 31 July 2025 (UTC)
I share the perception that there were some well-qualified candidates who did not make it, and I want to encourage anyone who wants to, to run again, in either format. I feel that there were also some things that went very well this time, and that are worth noting. First, the results were compiled and made public very rapidly, and I want to thank everyone who worked on that. Also, I think that the process was reasonably successful in preventing obvious not-yet candidates from staying in before the start of voting. --Tryptofish (talk) 22:56, 31 July 2025 (UTC)
this is like a solution to non-existent problem. With RfAs there is no need for scrutiny/compilation. The result are instantaneous. Same goes for not-yet candidates. RfAs can handle that pretty well. —usernamekiran (talk)23:33, 31 July 2025 (UTC)
Maybe there could be an optional short "Feedback from voters" phase where all candidates (whether successful or unsuccessful) can choose to receive feedback from voters after results are revealed. fanfanboy(blocktalk)23:08, 31 July 2025 (UTC)
The debrief for the October 2024 election was not intended to be place for candidates to receive feedback from voters, rather, it was a place for both candidates and voters to express what they thought went well/didn't go well with the process. The reason for the debrief was because the first AELECT was a trail election to see how it would work out, and we needed a place to discuss areas of the process that potentially needed changes so they could be included in the Phase II RFC. What I'm suggesting is an entirely different idea from the debrief. fanfanboy(blocktalk)01:30, 1 August 2025 (UTC)
I think there's a very strong case to be made by lowering the bar 7.5 points to a 62.5% pass rate. Looking at the top end of admin candidates, it's very common for a strong RFA candidate to sail through with 99/100% of the vote. At Aelect, there is a soft ceiling at 80% with only 3/48 candidates exceeding it, and a hard ceiling at 85% which nobody has yet exceeded. At the high end, AELECT is 15-20% harsher than RFA. Looking at the lower end, we have EggRoll97, who received 39.89% in the October 2024 election, kept his head up, and ran a RFA that ended with a no-consensus crat chat in April 2025 at 65.8% support. He certainly improved as a candidate in the interim, but it's likely that RFA was the kinder venue there as well by a substantial amount. There is a natural break in the data just below 65%, with 10 out of our 48 candidates scoring between 69.9% and 64.5%. Given that AELECT is harsher than RFA, those candidates probably should pass in the future. On the other hand, there was only 1 candidate between 65% and 56%, so that's a good natural gap to put the bar between "easily passes at RFA scrutiny: and "close call" Given that Aelect is a newer process, I'd be conservative, and put the bar near the top of that natural break at 62.5, which is a round fraction (5/8ths). Tazerdadog (talk) 00:08, 1 August 2025 (UTC)
Officially we're currently still waiting for one of the scrutineers to sign, or otherwise. I'm sure they'll be along soon. -- zzuuzz(talk)17:16, 31 July 2025 (UTC)
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.
AELECT3 is supposed to be in December (+5 months after AELECT2, per RFC). I propose the following dates to pencil in:
Tue Nov 25 - Call for Candidates
Tue Dec 2 - SecurePoll setup
Thu Dec 4 - Discussion phase
Tue Dec 9 - Voting phase
Tue Dec 16 - Scrutineering phase
This bleeds into November a bit, and the Call for Candidates is over the USA Thanksgiving holiday. But the alternative is to have the Scrutineering Phase overlap with Christmas a bit, which isn't great for our candidates or our scrutineers.
Although subject to change based on the arbitration committee election request for comments discussion, for reference the current projected timeline for the arbitration committee election is as follows:
(edit conflict) The provisional dates for WP:ACE2025 have the voting period from 18 November to 1 December. I don't think that this overlapping with the AELECT call for candidates is a problem. It's worth noting that there is likely going to be a proposal in the RFC to shorten the voting period, if that passes then there may be no overlap at all (it's currently undiscussed whether it will be proposed to move the start or end of the elections) Thryduulf (talk) 00:56, 25 August 2025 (UTC)
I think asking the community to participate in two high research high impact votes in such a short period of time is not ideal. Best, Barkeep49 (talk) 03:02, 25 August 2025 (UTC)
Yes, I think pushing AELECT3 to Jan might be better in this case. That way, there's no risk of overlapping with ArbCom election and it also avoids the whole end of November and month of November time issue, given that there's the holidays around that time that a good chunk of people of the English-speaking world, which makes up a good chunk of the en-wiki editor base, might observe those and may have family obligations.
And that way, we could hold theoretically AELECT4 six months later in July 2026 thereafter (if we assume that the twice-a-year thing is going to stick) - so they'd be evenly spaced out by 6 months, which in theory we could then actually rinse-and-repeat assuming that the post-AELECT review and refinement of procedures will get less and less as it gets more routine with each instance. Thoughts? Raladic (talk) 07:48, 25 August 2025 (UTC)
The rationale for 5 months was so that they wouldn't always happen on the same months. I think that logic still holds water. -- DoubleGrazing (talk) 07:58, 25 August 2025 (UTC)
I don't think the overlap with American Thanksgiving is a problem. The whole point of the 5-month cycle is that some dates may be inconvenient for some editors, but the following year will avoid those inconveniences. --Ahecht (TALK PAGE)13:39, 25 August 2025 (UTC)
I am good with the Nov-Dec dates as suggested initially.
No issues with having the elections over holidays of some. (heck, my RfA was over the Christmas/New Year week). Sooner or later, the elections will hit the major holidays of my country as well. – robertsky (talk) 07:53, 26 August 2025 (UTC)
I think that is too late per the RFC. Call for Candidates was started on July 9th, so a January 6th start would be 181 days afterwards. (Dumb question, but the only specific period is that discussion must lasts seven days (Apparently, I can't count the days from January 15th to January 20th...) and must be followed by voting, right?) --Super Goku V (talk) 08:56, 25 August 2025 (UTC)
the only specific period is that discussion must lasts seven days and must be followed by voting, right? The call for candidates is a week, SecurePoll setup is 2 days, discussion phase is 5 days, voting phase is 7 days, scrutineering phase was around 2 days for AELECT2. All in all, need around 3.5 weeks to do everything. –Novem Linguae (talk) 09:08, 25 August 2025 (UTC)
Figured, but I was hoping that it wasn't set in stone to see if adding a few days here and there would still make it work. (Also, I don't know why I said seven instead of five.) --Super Goku V (talk) 09:18, 25 August 2025 (UTC)
As I mentioned above, I think we should stick to the 5 month cycle. Yes, you avoid American Thanksgiving, but you're now hitting Epiphany and Eastern-Orthodox Christmas. --Ahecht (TALK PAGE)13:41, 25 August 2025 (UTC)
We are giving people several months notice re these elections, if the call for candidates overlaps with a US holiday, surely candidates can just get their drafts prepared a day or more earlier. The discussion phase is different as candidates may want to respond, so that should avoid a clash with anything that would mean a significant proportion of candidates had days offline for a big real life event. To some extent the same is true of the voting phase, or rather it needs to include dates when everyone is available, even if there are a couple of days when members of various faith, sport or cultural groups will be offline. As for the scrutineers, would we have a problem if one year they said the scrutiny phase needs an extra weekend because we were all watching Wimbledon/off at Glastonbury/Involved in last weekend's alien invasion? We may actually find that some of them have some slack time around Christmas, especially if the team has more people than the minimum needed for one scrutiny. So I'd be inclined to go with the post Arbcom December dates suggested earlier. ϢereSpielChequers16:24, 25 August 2025 (UTC)
It's not so much the overlap with holidays, inasmuch as it is the overlap with the ArbCom election that will be right in the middle of the original schedule.
As per the top of the thread, an Arbcom Voting period of November 18–December 1 wouldn't overlap with the discussion phase of the RFA election. I don't see a problem if there is an overlap involving different people or software. For example the scrutiny of one and the nominations of another. I'm not disputing that the voting and discussion parts can't overlap. ϢereSpielChequers07:39, 26 August 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.
Advertising the upcoming RFC
Howdy folks. The workshop has slowed down and can probably be closed soon. When the workshop is closed, we will launch the RFC phase. How widely do you think we should advertise the RFC phase?
Minimum:
AELECT MMS list - note that this has some of the below pages on it
add an {{RFC}} tag to the page, which will put it in RFC lists and advertise via the Feedback Request Service bot
Possible other places to advertise: (defaulting to no unless asked for in this talk page section):
watchlist notice
talk pages or noticeboards not mentioned above
I think this RFC is important to AELECT folks such as the watchers of this talk page, but may be less important to the wider wiki. So I'm actually leaning against advertising at all the above places, but am happy to be convinced. Thoughts? –Novem Linguae (talk) 22:27, 26 August 2025 (UTC)
I'm puzzled by you listing WT:RFC, since the RfC tag is what is important. I think a watchlist notice or any kind of banner would be overkill. But listing it on CENT might be a good idea. --Tryptofish (talk) 22:31, 26 August 2025 (UTC)
I would agree, for almost all of the RFC questions, except for one, which is so weighty that I think T:CENT or similar would be a good idea. Purely because one of the RFC questions is the pass percentage I think slightly wider advertisement is warranted. Leijurv (talk) 22:33, 26 August 2025 (UTC)
If there is a question about the pass percentage for reconfirmation elections (see new discussion about Q1) then WT:RECALL should be added to the notification list. Thryduulf (talk) 22:34, 28 August 2025 (UTC)
Hi @Novem Linguae:. I hope you're doing well. I noticed that there's a clear consensus for 3rd admin election to be held from 25 November to 16 December. Can we start to create a pages regarding it? Cheers! Fade258 (talk) 15:49, 2 October 2025 (UTC)
I was going to wait until all the RFCs close. But starting early should be fine. Anyone should feel free to copy paste the pages at Wikipedia:Administrator elections/July 2025/Subpages to their new home at Wikipedia:Administrator elections/December 2025/*. Then we can tweak the AELECT3 page a bit based on the RFC outcomes. Please use December 2025 and not November 2025, even though the start date is in November. Don't forget to give attribution in the edit summary, i.e. "copied content from abc, please see that page's history for attribution". –Novem Linguae (talk) 15:56, 2 October 2025 (UTC)
Because the actual election phase would be in December (so the admins elected will be admins as of December). Raladic (talk) 17:40, 2 October 2025 (UTC)
1) Because December is 5 months after July, which follows the RFC guidance of every 5 months, and 2) most of AELECT3 is in December. Hope that's OK and makes sense. –Novem Linguae (talk) 21:05, 2 October 2025 (UTC)
and when results are announced after (assumed two days after election ends like last one did) are correctly inferred? Thanks. Raladic (talk) 18:03, 2 October 2025 (UTC)
The results bullet is currently un-dated, which looks good to me. It's hard to put a date on it because scrutineering takes a variable amount of time. Everything else looks good. Thanks to all that are helping copy paste pages. –Novem Linguae (talk) 21:07, 2 October 2025 (UTC)
Thanks sounds good. I amended above to say ~Dec 17 (estimated) (based on the last one having taken 2 days) in case someone revisits this talk page for reference, but as you said, left the bullet point in the header undated (which is also what the July25 and Oct24 headers have.) Raladic (talk) 01:28, 3 October 2025 (UTC)
This exercise gave me some ideas to expand the template magics I've made so far for the past two elections to make the process easier for the future, I'll do some background stuff behind the scenes. Raladic (talk) 19:13, 2 October 2025 (UTC)
Yup, I'll come up with some preloads we can subst for the next election next year since a lot of it was boilerplate with repeating find-replaces for the name and exact dates to control the right phase texts to show up. I'll have them ready before the next election. CC: @Novem Linguae fyi. Raladic (talk) 19:55, 2 October 2025 (UTC)
The RFC phase of the July 2025 administrator elections has started. There are 10 RFCs for consideration. You can participate in the RFC phase at Wikipedia:Administrator elections/July 2025/RFCs.
Any questions or issues can be asked on the election talk page. Thank you for your participation. Happy electing.
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.
@Ganesha811: Thanks for implementing the recent RFCs, but I wanted to ask about this edit. Since the relevant RFC occurred post-election, I think adding that language retroactively is not correct. If I'm off here (as I probably am), please let me know. Always glad to see your name pop up on my watchlist and I hope life is treating you well. Best, ~ Pbritti (talk) 21:13, 15 September 2025 (UTC)
I think you're right, but we don't currently have a generalized AELECT procedure page - the main page just links to the most recent election's procedure, so that's where I added it. I'm not sure what the best way to resolve this discrepancy is. —Ganesha811 (talk) 21:16, 15 September 2025 (UTC)
Oh, well, without the general page, I think this is a more than fine landing point for the time being so that we can use it as a copy-and-paste in future elections. Thanks for the quick reply–let me know if you need any help around this area! ~ Pbritti (talk) 21:38, 15 September 2025 (UTC)
I agree that I don't think the procedure for past elections should be changed. Either a general procedure description can be reinstated, or the updated procedure can be placed on a placeholder page for the next election. isaacl (talk) 00:51, 16 September 2025 (UTC)
I went and made some edits before I saw this talk page section. Basically I reverted the edit to the AELECT2 rules (which I feel should be a snapshot of AELECT2 and not AELECT3), then added an RFC section to the bottom of AELECT1 and AELECT2 with bullets of the closes of all the major RFCs from the RFC phases of those elections. Then I removed that info from the main AELECT page. I feel like everything is organized pretty well now, but feel free to double check my work. When we make the AELECT3 page, we can look at the AELECT2 RFC section for a list of things we need to update on the AELECT3 page. –Novem Linguae (talk) 09:50, 16 September 2025 (UTC)
I think that works fine, though I also think it's worth having the most recent version of the procedure / eligibility rules transcluded on the main AELECT page as well, and not just linked. —Ganesha811 (talk) 10:17, 16 September 2025 (UTC)
I'm not a fan of a structure that seems to presume there'll be a request for comment discussion after every admin election. I think I prefer having the current procedure documented directly on the main admin election page, or on a general procedure subpage, similar to the arbitration committee election rules page. isaacl (talk) 15:38, 16 September 2025 (UTC)
Interesting. It had not occurred to me that an RFC phase after every election would be controversial. I think WP:ACE does something similar, except their RFC phase is before each election instead of after? –Novem Linguae (talk) 19:39, 16 September 2025 (UTC)
At this point, there are still enough disagreements over the still-newish process that it can be reasonable to have frequent reexaminations. But I expect that, as we gain more experience, there will be less need for frequent RfCs. --Tryptofish (talk) 22:14, 16 September 2025 (UTC)
Now that the RfCs have concluded, I have transcluded the December 2025 eligibility and procedure subsections onto the main page, and this can be updated as needed every 5 months. —Ganesha811 (talk) 14:59, 3 October 2025 (UTC)
If we're going to be asking this question in future RfCs, I think we need to revise to specifically include higher pass percentages. The question we just closed was worded:
Option A – 70.00% (current)
Option B – 66.67%
Option C – 65.00%
Option D – 60.00%
Option E – Other (specify)
This introduces a bias, the name of which I am blanking on, but the theory is that providing specific choices only in a single direction biases respondents in that direction.
If we're going to ask this question again, we need to frame it as an open set of options rather than as a closed set. I know not many people would vote to increase the pass percentage requirement, but we shouldn't word the question as if that's the only valid direction for change. We're implying that we do need to lower these percentages and the only question is by how much. Valereee (talk) 15:25, 3 October 2025 (UTC)
What xaosflux said and also I don't think we should include this question anymore as it had the same result twice. It would fine to include this question every few elections if it ever comes up again though. fanfanboy(blocktalk)16:17, 3 October 2025 (UTC)
I agree with fanfanboy. It's starting to give the impression of wanting to keep asking the question until the community gets the "right" answer (i.e. the one that corresponds with the preference of the asker). Thryduulf (talk) 17:04, 3 October 2025 (UTC)
The accusations I had to endure during the last RFC because this question was included were pretty outrageous and made me lose a lot of respect for someone I previously respected. I am certainly soured on asking this question of the community at least in the short term. It will certainly not be me that adds this question in the next round of RFCs. –Novem Linguae (talk) 02:28, 4 October 2025 (UTC)
@Novem Linguae Yeah those accusations you received didn't sit right with me. I was also disappointed with the jumping to conclusions other editors were doing with people who had minor disagreement. fanfanboy(blocktalk)03:10, 4 October 2025 (UTC)
Apolgies, I did not mean to ping. I was using my phone instead of my computer and it chooses to ping editors by default in the Wikipedia app. fanfanboy(blocktalk)03:12, 4 October 2025 (UTC)
This is a sincere question, so I hope it doesn't sound like I just want to shut down discussion: what does "if it ever comes up again" mean? What I'm getting at is does it mean someone brings it up? Does it mean someone brings it up and it gets some discussion? Does it need multiple people expressing concern? I kind of just feel like we've discussed it multiple times. Obviously there are community members who think 70% is too high, and they probably aren't going to change their minds about that, but when do we decide we no longer can assume we can rely on past consensus? Valereee (talk) 19:11, 3 October 2025 (UTC)
I guess if more people than before are complaining that it's too low after at least 4-5 more elections. I don't know exactly what I meant by that either.
Thanks, NL, I've done that! I also am on the notifications list, but I was out of the country when the RfC started and missed the notification. Valereee (talk) 14:37, 4 October 2025 (UTC)
I appreciate that during these initial elections, there's a desire to re-evaluate and adjust the process. I hope, though, that at some point the community will allow a few cycles to run before discussing changes. This will allow for more data to be collected and thus help avoid overreacting to the most recent election, as well as provide stability for the vast majority of editors who aren't following every discussion on admin elections. isaacl (talk) 22:43, 3 October 2025 (UTC)
Agree with this. Questions such as election timing should also be raised with caution. The existing five-month cycle allows editors to plan, if the question is open for every election (there is already a planned December workshop?) then it undermines the purpose of a fixed schedule. CMD (talk) 02:41, 4 October 2025 (UTC)
I'm not sure what questions will be raised at this next workshop, but I'm sure it'll be less than before. I also assume if no questions are raised then there is no RfC phase? fanfanboy(blocktalk)15:47, 6 October 2025 (UTC)
Correct. Also, some folks on this talk page opined that we're having RFCs too often, so I will probably ask on this page and get consensus before starting an AELECT3 RFC workshop. –Novem Linguae (talk) 02:35, 7 October 2025 (UTC)
Following up here with two things to take into account if this comes up again.
Outcomes In the July 2025 election, all but one of those with a nominator succeeded. Of the nine who didn't have a nominator, only two passed, and one of those barely. In the October 2024 election, 100% of those with a nominator passed. 80% of those who self-nom'd failed.
According to this post, an analysis of the date shows 70% is being used as the de facto cutoff point by crats in their closures of cases that fall between 65% and 75% support.
For those looking to nominate someone, or encourage someone to run, this query might be of interest. The query looks at recent activity over a whole lot of admin-related areas (AfD, AfC, RfPP, AIV, DYK etc), as well as content areas. If you see someone on the list who demonstrates good judgment and a solid understanding of policies and guidelines, please do reach out to them! —Femke 🐦 (talk) 15:37, 18 October 2025 (UTC)
Hello friends. If anyone would like to help out, there's around 10 pages at Wikipedia:Administrator elections/December 2025/Subpages that are redlinked. Would be great if these could be filled in with the contents of those subpages from AELECT2. You can use an edit summary such as Copied content from XYZ page, please see that page's history for attribution. Thanks in advance for any help :) –Novem Linguae (talk) 18:18, 30 October 2025 (UTC)
I would like to note that there is something about a cookie on the watchlist message pages (inlcuding the call for candidates one) which I don't know about, so someone else would have to take a look at that.
Hi all. I might me little bit too early for this. How and when do we select election officials? Is there any rules or procedures for it? Cheers! Fade258 (talk) 16:04, 7 October 2025 (UTC)
I usually just post on this talk page asking for volunteers. I guess we can start now. If you're interested in volunteering to be an election official, please post in one of the subheadings below. I may give priority to folks from the last election since they are now experienced. If we have too many qualified volunteers, alternates are welcome. cc @ThadeusOfNazereth, Risker, Robertsky, RoySmith, Zzuuzz, Dreamy Jazz, and Barkeep49:. –Novem Linguae (talk) 16:09, 7 October 2025 (UTC)
I am interested to become an Election official but yet I didn't meet those requirements for any of subheadings below. So, If I got any of those rights in future I will be there If Election happens. For now, I will just monitor the pages only. Thank You! Fade258 (talk) 16:28, 7 October 2025 (UTC)
Hi @Novem Linguae. I hope you’re doing good. Well, I’m not trying to pressure you, but since we have about a month before the admin election. Still we haven’t been able to fill the vacant spot of scrutineer and monitor positions for AELECT3. Fade258 (talk) 14:27, 27 October 2025 (UTC)
Thanks for the reminder. Sounds like we still need one scrutineer and one monitor. Any other takers want to add their name to the lists below? Let's give these comments a couple days, and if that doesn't work, then I'll do a talk page post to WT:CHECKUSER and WT:ADMIN. –Novem Linguae (talk) 18:27, 27 October 2025 (UTC)
Post in this section to volunteer to be an election clerk for AELECT3 in December (need 2)
I plan to be an election clerk for this election and handle everything but the encryption keys. The other election clerk will handle those. –Novem Linguae (talk) 16:11, 7 October 2025 (UTC)
I'm happy to scrute again, and/or help out with my experience in any other way. I would like to see other CUs get some experience, so add my name beyond the end of the list. -- zzuuzz(talk)18:01, 7 October 2025 (UTC)
Hi. I might be little bit early for this. If everything is fine then, Can we add the message about call for candidates in watchlist and notify users through mass message? Fade258 (talk) 13:18, 13 November 2025 (UTC)
As far as I can tell, it will automatically be added when the call for candidates starts. @Novem Linguae can you confirm this? I don't know exactly how the watchlist works and there is still the cookie parameter being left unfilled in the watchlist messages.
Each watchlist notice has to be added to MediaWiki:Watchlist-messages by an administrator or interface admin for it to display. (The arbitration committee election has a template-based notice that is kept on the page for the entire period, with the text changing based on the current stage of the process.) Non-admin/interface admin editors can post a request at MediaWiki talk:Watchlist-messages. Conventionally, though, watchlist notices are only made visible immediately before the corresponding event, so it's still early to make a request. isaacl (talk) 19:43, 13 November 2025 (UTC)
We do a watchlist notice only when the call for candidates starts.
For previous elections, we did an MMS 1–2 weeks before with the schedule, then an MMS at the beginning of the call for candidates. However I am thinking about skipping the 1–2 weeks MMS this time (less work, less spam, folks still get a week of notification before the deadline).
I agree with just one mass message calling for candidates. There can be postings on the miscellaneous pump page and perhaps the administrators noticeboard ahead of time, to remind anyone interested. isaacl (talk) 06:31, 16 November 2025 (UTC)
Concur with isaacl about just one message + AN. I suspect those signed up for the MMS are aware enough of the process by now to not need two messages, and anyone not yet so informed can click the links in the watchlist notice if they wish to read further. Perfect4th (talk) 06:38, 16 November 2025 (UTC)
Personally I think it would be desirable to also post a notice at the miscellaneous village pump, to cast a broader net than just those who follow the administrators' noticeboard. isaacl (talk) 19:39, 16 November 2025 (UTC)
If we do one mass message, I think it's better to do the one 1-2 weeks before the call goes out. That way, we're giving people more time to decide on running. The watchlist notice is already quite visible, so a mass message at the same time might not do that much. —Femke 🐦 (talk) 20:09, 16 November 2025 (UTC)
Hmm. Confusing. I personally feel that the call for candidates MMS is the more important one since it's more actionable. Getting a "no consensus" vibe from this discussion now. Will revert back to doing a 1) pre-MMS and 2) a call for candidates MMS, and will add WP:VPM to the MMS delivery list. –Novem Linguae (talk) 08:01, 17 November 2025 (UTC)
Hello friends. FYI I do not plan to do a test SecurePoll election like last time, because that'd be a decent amount of work, and I'm confident that if we follow the work instruction exactly, the test will be unnecessary. I will likely create the actual SecurePoll during the housekeeping phase. Thanks. –Novem Linguae (talk) 05:43, 23 November 2025 (UTC)
I didn't exactly set you up for success, since I forgot to un-hide the inputbox and instructions on the /Candidates page. Whoops. Lol. Anyway, I tried it myself and most of the process worked fine, but I made several tweaks to wording and templates. Should be slightly improved now and ready for candidates. Done –Novem Linguae (talk) 10:52, 23 November 2025 (UTC)
The process will have a seven day call for candidates phase, a two day pause, a five day discussion phase, and a seven day private vote using SecurePoll. Discussion and questions are only allowed on the candidate pages during the discussion phase.
The outcome of this process is identical to making a request for adminship. There is no official difference between an administrator appointed through RFA versus administrator elections.
Ask any questions about the process at the talk page. Later, a user talk message will be sent to official candidates with additional information about the process.
If you are interested in the process, please make sure to watchlist the appropriate pages. A watchlist notice will be added when the discussion phase opens, and again when the voting phase opens.
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.
I posted a question for one of the candidates, and then realized that that's not part of this phase and should be saved for the discussion period, per the main WP:AELECT page. However, that's not obvious on the candidate subpages, so perhaps we should modify the invisible comment there to make it clearer to hold off on questions until the discussion period begins. —Ganesha811 (talk) 16:23, 25 November 2025 (UTC)
I think there used to be a {{Notice}} in that section notifying not to ask questions yet, similar to the one in the discussion section, but I forgot to add it back. I'll probably just add that back. Sorry for any confusion. –Novem Linguae (talk) 21:31, 25 November 2025 (UTC)
Hi @Novem Linguae:. I hope you're doing well and all ready for the election. I noticed that Unknown FG had withdrawn their nomination from AELECT3. Can you confirm it please? Best Regards! Fade258 (talk) 15:04, 28 November 2025 (UTC)
