Latest comment: 2 months ago63 comments14 people in discussion
I'm glad to see Novem's comment above that a July election would be feasible and that Wikipedia:Administrator elections/2025 has been created. July, though, is in two weeks. Ideally we figure out the dates and announce them before then, so that potential candidates can look for nominators and prepare. Adapting Ganesha's proposed June timeline from above for July, we'd get something like:
July 9–16: Call for candidates, Wednesday to Wednesday to include a full weekend. (This can also be longer; afaict the length of the nomination window was not decided by the commmunity.)
July 17–21: Discussion phase (5 days), again including a full weekend
July 22–28: Voting phase (7 days), including a full weekend
July 29 to close - scrutineering and tallying, promote successful candidates.
I don't mean to pressure the folks running the election, so if anything is not ready and this would be too soon, that's okay and we can postpone slightly. I deliberately moved Ganesha's schedule to the second week of July, rather than the first, because July is fast approaching and ideally we have the dates set at least a week in advance. I've also shifting the entire schedule back a weekday, since I think the aim of including a "full weekend" for discussion is better served by doing Thu–Mon rather than Wed–Sun (which is the workweek of many in the restaurant business and would also end before the weekend is over in time zones behind UTC). Toadspike[Talk]14:37, 16 June 2025 (UTC)
:facepalm: I missed the part of Novem's message that says "once that's complete, let's set the dates". Apologies for seriously jumping the gun here. I'll leave this up for others to comment, though, in the hope that Novem's tests have gone okay and we do start workshopping a July schedule. Toadspike[Talk]14:39, 16 June 2025 (UTC)
I wonder if late July or start of August would be better, would let the community (read candidates, nominators) have some time to get ready and think things through (Also for the election commission to test and re-test until they are sure of the process). (On a different note, I'm open to volunteering to be a dummy to be tested around if Novem's polls need test voters:) Sohom (talk) 16:07, 16 June 2025 (UTC)
That's fair. I'm hoping candidates will be more prepared this time around and more of them have nominators. Pushing this back two weeks (or more) might help with that. To maximize preparedness we should try to have the dates set and widely announced a few weeks before the call for candidates opens. Toadspike[Talk]16:12, 16 June 2025 (UTC)
I'm all for making sure the technology works as planned and not be hasty, but I don't think people would be more prepared if we push the date further back really, as they have had months to find nominators and think about the elections since the last RfC. (my email is always open to talk for people seeking advice or a nominator). —Femke 🐦 (talk) 16:19, 16 June 2025 (UTC)
For better or worse, there seems to be a number of Wikipedia editors who wait to engage when deadlines are at hand. Taking the arbitration committee elections as an example, even though the approximate dates are known well in advance so potential candidates have a year to prepare and decide, the community of editors participating in the annual RfC still felt that the nomination period shouldn't be shortened from 10 to 7 days, to give editors more time to decide within the actual nomination period. isaacl (talk) 16:30, 16 June 2025 (UTC)
While I agree that folks will probably be better prepared, I think giving folks a week or two of notice is good to have a back and forth on the availability of noms and find noms if their existing noms are going to busy. (also note that noms don't really when the elections are going to happen, you or I will pre-emptively clear our calendar cause we are involved in this discussion, others might not be able to do that on a shorter notice) Sohom (talk) 16:34, 16 June 2025 (UTC)
That's fair. We also no longer have a gap between nominations and discussion, so there's less leeway there now compared to the trial. —Femke 🐦 (talk) 16:44, 16 June 2025 (UTC)
I personally quite liked the week gap between candidacy signups and discussion phase during the trial, as it gave some time to research the candidates. With the huge number of candidates last election, without that gap we wouldn't have had any decent voting guides, and voter research would have been even more sparse. BugGhost🦗👻22:08, 16 June 2025 (UTC)
I have mixed feelings; scrutiny is good, but the point of having a shorter discussion period is so AELECT is less intense than RfA. Without the technical reason, the only remaining reason for a delay would be vetting/preparation, which might contradict the AELECT philosophy. Maybe we can make the signup period longer (two weeks?) as a compromise? Though, given 20 people signed up in the last two days last time, I'm not sure how much that would help. Toadspike[Talk]10:41, 17 June 2025 (UTC)
@Sohom Datta Start of August for the actual elections will be generally a bad time, I think. Editors will go to Wikimania IRL. Having admin elections concurrently may be a hassle if any of them also are involved in AELECT in any way. Soni (talk) 04:23, 17 June 2025 (UTC)
@Soni, yeah forgot about that cause I personally can't make it, good point that we should try to finish before Wikimania then. Sohom (talk) 14:51, 17 June 2025 (UTC)
I haven't been able to do my tests yet. Been a bit busy. Will probably get to it this week though.
I agree that having it all done in July would be best. Early August is Wikimania and I'll be a bit busy with that.
I am not sold on deleting the SecurePoll setup phase yet, although I think we can probably shorten it. Maybe we can re-draft the above schedule to add a 2 day SecurePoll setup phase?
I think page watchers know AELECT is coming since we've mentioned July in a couple places now. For candidates that don't want to wait for the mass message and other announcements and want extra prep time, the time to start preparing is now. I'm like 90% confident the next election will be in July. –Novem Linguae (talk) 11:22, 17 June 2025 (UTC)
I've added some dates as a placeholder / rough draft. I mostly copied the above, but shortened the call for candidates from 8 days to 7, added a 2 day SecurePoll setup phase, and penciled in scrutineering as taking 5 days since that's how long it took last time. –Novem Linguae (talk) 11:29, 17 June 2025 (UTC)
Localhost testing is complete. I've got my head wrapped around everything and I think the chosen settings are good.
The work instruction is now written. It's located at Wikipedia:Administrator elections/July 2025/SecurePoll setup. I think it's detailed enough that an electionclerk that isn't me (such as in the future, or if I get hit by a bus) could follow the steps and figure things out.
One tiny issue I saw is that the de facto voter eligibility criteria will be slightly different than the RFC'd voter eligibility criteria. For example I don't think there's a way to program in "only allow extendedconfirmed and sysop user groups", so I had to program in "only allow users with 500 or more edits". Also SecurePoll has a hard-coded, unchangeable thing where your account needs to have been made the day before the poll started, UTC time. My thought is that these are small enough differences that we can move forward, then post-election we can RFC these voter eligibility changes to make it official.
I think I tried blank/0 already and it didn't work. It'd be hacky, but I'll bet setting it to 10,000,000 would probably work. Will try both and report back. –Novem Linguae (talk) 08:05, 21 June 2025 (UTC)
@Sohom Datta. 1) Blanking the minimum number of edits gives a form validation error. 2) Setting the minimum number of edits to 0 lets everyone vote. 3) Setting the minimum number of edits to 10,000,000 and trying to add sysop and extendedconfirmed as "always allowed" groups didn't work, because implicit groups such as extendedconfirmed cannot be added, only explicit groups. I filed phab:T397587. After the patch for that task is merged, this workaround will work, but will show confusing error messages to non-extendedconfirmed folks on the vote screen, such as "Sorry, you cannot vote. You need to have made at least 10,000,000 edits to vote in this election, you have made 0."
I guess we keep the minimum at 500 for now if folks are OK with it. I'll start a section below to discuss this in more detail. –Novem Linguae (talk) 22:24, 22 June 2025 (UTC)
That's not really desirable to do manually. To do this check at voting time, it would probably be better to go back to generating an electoral roll, but of course part of the intent behind the new criteria was to avoid this and let the SecurePoll software check the criteria automatically. isaacl (talk) 02:10, 21 June 2025 (UTC)
I forgot about the 30 days aspect of XCON. That makes this issue a bit more out of alignment with the voter eligibility criteria than I thought. –Novem Linguae (talk) 08:05, 21 June 2025 (UTC)
Is it possible to change the de facto eligibility criteria via config change for future polls? Or this is something best handle as a feature request? – robertsky (talk) 11:42, 21 June 2025 (UTC)
Probably feature request. I think SecurePoll on-the-fly voter eligibility calculations are unrelated to config ($wg variables). –Novem Linguae (talk) 16:52, 21 June 2025 (UTC)
Other wikis that have more complicated voting criteria generate a voter list before each election - they essentially run a database query/script that enumerates all people who meet the criteria.
Though this leaves out people who become eligible during voting - they could complain and electionadmins can add them to the voter list manually. dbeef [talk]12:14, 21 June 2025 (UTC)
Yes, this was done for the first election, with the criteria for the arbitration committee elections used (as per consensus at the time). (I don't remember if any voters were added manually after the electoral roll was generated, but I believe it has been done for arbitration committee elections in the past when eligible voters have been missed.) The intent discussed during the followup discussions was to try to avoid this extra overhead cost, as well as provide a better user experience, by using criteria that could be enforced by the SecurePoll extension. If administrator elections become a more frequent occurrence, minimizing the cost of managing them will be helpful. isaacl (talk) 16:06, 21 June 2025 (UTC)
This should definitely be a feature request, but if Novem is able to hack their way to the same result by using a absurdly high edit count (as I mentioned above), I don't think it should be a blocker for the election. Sohom (talk) 16:09, 21 June 2025 (UTC)
Dropping the account age 30 days requirement
As a recap, our voter eligibility criteria is that the voter has to be extendedconfirmed, not blocked, and not a bot. Extendedconfirmed means the account age is >=30 and the account edit count is >=500. Due to some limitations in SecurePoll, it looks difficult to enforce the 30 day thing. A) I would like to drop the 30 day requirement for the July 2025 election, then we can look into patching SecurePoll for future elections. Is this OK? Alternatives are B) to generate the voter eligibility list manually (more work but could be done, I could do a quarry query), or C) to postpone the election to give time for a patch to be written. I prefer A but want to double check consensus. Thoughts? –Novem Linguae (talk) 22:29, 22 June 2025 (UTC)
Yes, I think having a cutoff at 500 edits is fine for this round, no need to let the perfect be the enemy of the good enough. --Tryptofish (talk) 22:55, 22 June 2025 (UTC)
Isn't this supposed to be using the RFA suffrage requirements? That RFA suffrage requirements are that voters are extendedconfirmed, not that they have any specific number of edits or tenure days. That seems to have been erroneously made a requirement for elections. (Perhaps in attempting to explain what extendedconfirmed typically means). — xaosfluxTalk23:42, 22 June 2025 (UTC)
Important note: if you are going to use a whitelist of the members of extendedconfirmed, also append the members of sysop. — xaosfluxTalk23:49, 22 June 2025 (UTC)
May want to test using the 'Include users in these groups, regardless of edits or other groups' votereligibitily parameter, coupled with some very high edit count as the setting (like 10000). — xaosfluxTalk23:52, 22 June 2025 (UTC)
Important note, you have a bunch of former admins who are within 500/30 but not in extendedconfirmed or sysop, because of how EC is granted, among other things. Soni (talk) 05:57, 23 June 2025 (UTC)
Is extendedconfirmed added back automatically when they make an edit? I forget. Maybe not since it was "removed" when they became an admin? Some of this group could be quarried with something like ...
... and added to the eligibility list, if there's consensus to do so. However the above query would get confused by renames, and isn't all-inclusive. Maybe this is kind of complex and should just be handled on a case-by-case basis. Folks that aren't eligible and should be can post on this talk page and, if needed, be added to the "override list" mid-election by an election clerk. –Novem Linguae (talk) 07:01, 23 June 2025 (UTC)
Checking user_former_groups is a lot easier than trying to parse logging. Users desysopped before that table was added in mid-2011 won't be in it, but if those users still haven't gotten extendedconfirmed back, I'd not worry about disenfranchising them. —Cryptic07:31, 23 June 2025 (UTC)
(I'd thought it was only *, user, and autoconfirmed that were implicit.) How much effort is it to import an eligibility list? The query for just sysop/extendedconfirmed isn't just easy, it's a trivial oneliner; nothing like supporting the agglomerated mess that's the arbcom eligibility reqs. —Cryptic23:56, 22 June 2025 (UTC)
It isn't very hard to upload a list. It will not be dynamic of course, so those who gain or lose EX status during the election will be in the wrong eligibility, which may be solvable with the group whitelist option I mentioned above. — xaosfluxTalk00:44, 23 June 2025 (UTC)
Thank you for the callout. I appear to be conflating "implicit user groups" with "autopromoted user groups". I tried to do my localhost testing with autoconfirmed rather than extendedconfirmed, thus the confusion. Perhaps setting the max edits really high + adding extendedconfirmed to the whitelist would actually work after all, but as mentioned above, has the downside of giving a confusing error message to folks that aren't extendedconfirmed: "Sorry, you cannot vote. You need to have made at least 10,000,000 edits to vote in this election, you have made 0." Because of this, I think voter rolls (option B) are the way to go for this particular election. –Novem Linguae (talk) 04:47, 23 June 2025 (UTC)
That, I think we can hack our way to the end result wrt to modifying on-wiki messages if needed. But it's your call :) Sohom (talk) 15:41, 23 June 2025 (UTC)
Actually, scratch that. It looks like blocked users and bots can vote as well by being in one of the user groups listed in "Include users in these groups". – SD0001 (talk) 16:22, 23 June 2025 (UTC)
Yes. I've fixed these issues in gerrit:1162995. The eligibility requirements can be implemented without any hacks or externally generated lists, if merged before the election. – SD0001 (talk) 18:16, 23 June 2025 (UTC)
Perhaps it would be better to go back to generating an electoral roll for the July election. This would allow for either new features to be added to the SecurePoll extension to meet our needs, or for the community to be consulted on changes to the voter eligibility criteria. Personally, I don't like diverting from community consensus about the criteria without a broad village pump discussion, and that would delay the timetable. isaacl (talk) 02:53, 23 June 2025 (UTC)
I agree with isaacl. I empathize with no need to let the perfect be the enemy of the good enough, however, the mechanics of administrator selection is one of, if not the, most high-profile and high-sensitivity subjects on-wiki. Adjusting voter eligibility criteria without broader consensus is likely to go over poorly. —Sirdog(talk) 03:25, 23 June 2025 (UTC)
Thanks everyone for your feedback. Option B (uploading a voter roll) should allow us to have the election on time and stay faithful to the voter eligibility criteria, so let's just go with that for now. That is hard to test in localhost (localhost lacks tens of thousands of users to test the voter eligibility upload system at scale), but I can give this a proper test in the enwiki test election I plan on having soon. –Novem Linguae (talk) 04:44, 23 June 2025 (UTC)
Here's the voter eligibility quarry query if anyone wants to double check it: quarry:query/94828. I don't think we need to do any block checking in this query since it looks like SecurePoll handles that. –Novem Linguae (talk) 05:11, 23 June 2025 (UTC)
User:Dennis Brown and User:Zero0000 are in both groups, so they each show up twice in that query. Does that matter for anything? And does this work with the other SecurePoll options - I mean, are you sure that if it's set to forbid bots and blocked users, that takes precedence over the user whitelist? That "regardless of edits or other groups" in the screenshots on phab is concerning. —Cryptic05:22, 23 June 2025 (UTC)
Thanks. I changed the SQL query to SELECT DISTINCT and now there are 2 less in the results, probably solving the two duplicates you mentioned. Since we are using the SecurePoll eligibility list, I plan to leave the "regardless of edits in other groups" thing blank, so I think the "no sitewide blocks" thing will work. We can double check this during the English Wikipedia test election. –Novem Linguae (talk) 06:37, 23 June 2025 (UTC)
Polishing and double checking the eligible voter Quarry query
Is everyone OK with adding around 377 former admins who are not technically extended confirmed? quarry:query/94838
Can folks also help me double check that the following Quarry query is accurate and fetches the 3 user groups we want? The 3 user groups this query should be listing are extendedconfirmed, sysop, and former sysops since 2011: quarry:query/94837. –Novem Linguae (talk) 08:17, 23 June 2025 (UTC)
Suffrage says is extendedconfirmed. That is included with current admins, but is not with former admins. I suspect this is an edge case of former admins that are also very long term inactive, who can cure this themselves by making an edit or requesting at PERM in the worst case. That report also has accounts such as 'EyeEightDestroyerBot' that shouldn't be manually added. — xaosfluxTalk10:37, 23 June 2025 (UTC)
Yeah I agree with xaosflux - from spot checking some of the users on that list, they look to be admins who haven't edited since being desyssopped. I don't know how auto-granting EC works, but I agree that it's something those users can likely resolve themselves by simply editing. I don't oppose them being added, but I think we don't really need to worry about the former admins in this case. BugGhost🦗👻17:18, 23 June 2025 (UTC)
If it isn't auto-re-granted, then the core problem is probably that bureaucrats forget to add it back when they remove sysop from folks. The fix is probably to get bureaucrats in the habit of adding extendedconfirmed whenever they remove sysop. Perhaps a reminder message to WP:BN could help with this. There appears to be at least 377 of these folks: quarry:query/94838. –Novem Linguae (talk) 19:22, 23 June 2025 (UTC)
Something seems a bit off here. Example from your list: User:Amalthea. This user never appears to have EC revoked, so it never needed to be "added back". Should this user ever make an edit, they should become EC for the first time. — xaosfluxTalk20:29, 23 June 2025 (UTC)
Copying subpages
Latest comment: 2 months ago5 comments3 people in discussion
Thank you very much. You or anyone else should feel free to start updating these newly created subpages. The wikilinks may need to be changed from /October 2024/ to /July 2025/, schedules/dates may need updating, etc. –Novem Linguae (talk) 11:52, 25 June 2025 (UTC)
I have already updated everything, though a few adjustments might still be needed to align fully with the current guidelines. – DreamRimmer■11:59, 25 June 2025 (UTC)
If the subpages are going to be the same or similar election to election, it might be worthwhile creating preload templates to auto populate pages and make adjustments from there. – robertsky (talk) 22:08, 25 June 2025 (UTC)
Outcome: There was support for implementing this type of SecurePoll logging. I withdrew the original proposal in favor of a similar one that did not involve writing to an entire private namespace, but instead subpages of MediaWiki:SecurePoll, which is narrower so creates less clutter. Creating a config setting so that SecurePoll writes its logs to MediaWiki:SecurePoll subpages was tracked in phab:T378444. Deployment of this feature to enwiki is tracked in phab:T398080. I do not consider this to be a blocker for the upcoming admin elections so I am not in a rush. I expect this to deploy within the next week or so, but if it is delayed, it won't be a problem. –Novem Linguae (talk) 06:37, 28 June 2025 (UTC)
Adding backup scrutineers to the poll
Latest comment: 2 months ago4 comments4 people in discussion
When we asked for checkusers to volunteer to scrutineer, 5 folks volunteered their services. I chose 3 to be main and 2 to be "backup" scrutineers, based on the order that they posted in. The backup scrutineers are Dreamy Jazz and Barkeep49. Is everyone OK with me adding the backup scrutineers to the July AELECT poll? I probably should have done this for the test election we just had, but it didn't cross my mind. This needs to be decided in advance since election administrators cannot be added once the poll ends. Thanks. –Novem Linguae (talk) 06:28, 29 June 2025 (UTC)
Sounds good to me - if we can't add scrutineers after the poll closes then it sounds like this is the only way backup scroots would be able to do anything. BugGhost🦗👻07:36, 29 June 2025 (UTC)
Latest comment: 2 months ago4 comments3 people in discussion
We currently say: "To vote, an editor must ... have an extended confirmed account (500 edits and 30 days of tenure)". Which is it; having the bit set, or having the right number of edits and tenure? Technically, those are not interchangeable, as EC can be manually granted and revoked. It doesn't happen often, but it would be good if we knew ahead of time which was the real requirement. RoySmith(talk)20:10, 29 June 2025 (UTC)
Yep - the RFC closed saying AELECT should use the same suffrage criteria as for RfA, continuing: at the time an editor attempts to cast a vote, that they be extendedconfirmed on English Wikipedia, not be sitewide blocked on English Wikipedia, and not be a bot. I think the text about 500 edits is just an explanation of what EC normally means in most cases. BugGhost🦗👻20:23, 29 June 2025 (UTC)
Latest comment: 2 months ago18 comments8 people in discussion
Alright, the local SecurePoll test election is complete. I'd like to take a day or two to discuss scrutineering and to let scrutineers explore their buttons in SecurePoll. The scrutineers for the test election and for the upcoming July election are Dbeef, RoySmith, and Zzuuzz.
Your scrutineering page can be found by visiting Special:SecurePoll, then next to the election "English Wikipedia test election, June 2025", clicking on the "List" link at the top right. This will bring you to a page that lists every single vote. Normal users can also access this page but do not have as many columns. You can also click "Details" to see details of a specific voter and vote. Normal users can also visit details pages, but again, don't have as many rows. Stuff like IP addresses are hidden from non-scrutineers.
For this test election, just explore the interface a bit and get comfortable with it. Maybe strike and unstrike some votes to see how striking works.
I've never scrutineered before so I would guess the process for the real, July election should be something like...
if sockpuppets are found, use your best judgment on whether to strike their vote, block them, or both
all 3 scrutineers make a pass through the list and investigate suspicious things and abnormalities
when all 3 have completed their pass, then the election clerk (me) should be informed so that I can decrypt and tally
I copy paste the tally results onwiki
the scrutineers visit the tally page and confirm that the copy pasted results onwiki match the tally in SecurePoll, then sign off on the results on the results wiki page
Pinging the steward scrutineers from the previous enwiki administrator election. Johannnes89, EPIC, and Yahya, am I missing any steps above? Got any other tips and tricks you can divulge? I'll make a work instruction somewhere and summarize your tips in there.
I'm able to click on that column's header to sort it in my localhost testing. I cannot test this directly on enwiki since I am not a checkuser/scrutineer. Do you get any WP:CONSOLEERRORs when you click the IP header and try to sort? Does anything happen at all? Did you try clicking it multiple times? Is the header hyperlinked? Are you on desktop or mobile? What skin? –Novem Linguae (talk) 06:31, 29 June 2025 (UTC)
Oh. The header is hyperlinked. I'm not sure why they have to design it that way. Anyways it's all sorted now. Thanks. dbeef [talk]06:34, 29 June 2025 (UTC)
When the voting list spans multiple pages, it will be necessary to make a new database query to produce the sorted list. Using a hyperlink to indicate that a new web page request is being made isn't unusual, even with the current front-end web environment. isaacl (talk) 16:16, 29 June 2025 (UTC)
You didn't miss any steps. Note that the CU investigation is optional. If SecurePoll shows accounts on the same IP, you can usually judge this without CU (e.g. people accidentally used their publicly disclosed alt-account to submit a second vote -> just strike the vote, no CU investigation needed). --Johannnes89 (talk) 07:29, 29 June 2025 (UTC)
We are just waiting for a round or two of input in the scrut-chat, it shouldn't take too long (it looks like the 3 scrutineers are probably in widely separated timezones). I have a couple of questions while we're waiting. Has anyone clicked on the 'Archive' link? It uses a token, so I'm guessing it might perform some action. Anyone? Struck votes: I assume we're going to follow the standard practice of striking votes of sockpuppets (of anyone), but not the sockmaster unless also a sock. Does that sound about right? Does anyone expect the scrutineers to publicly detail these strikes? -- zzuuzz(talk)11:10, 29 June 2025 (UTC)
Haha. No rush. Gotta find those test election sockpuppets ;-)
Don't click archive. That will instantly archive the election, and then you'd have to go to the list of archived elections and unarchive it. I've filed phab:T398135 to make the archive link a little bit safer to click in the future.
I'm open to feedback from other scrutineers and from talk page watchers, but my suggestion would be to strike the sockmaster vote if the sock is operating in bad faith, and keep it if the user is operating in good faith and just made a mistake. An example of bad faith would be 5 accounts with 5 edits, identical IPs, and identical user agents. That seems like a sockfarm trying to sway the election. An example of good faith would be RespectedUser and RespectedUserAlt both voting -- that's likely a mistake involving being logged into the wrong account when voting, since someone acting in bad faith would probably not use accounts so obviously related.
In previous elections there has been no public explanation of the strikes. I actually wouldn't mind a public explanation for transparency reasons if you choose to go that route, but I think the status quo is fine too. –Novem Linguae (talk) 11:32, 29 June 2025 (UTC)
In the arbitration committee election, all votes from a sockmaster (including the sockmaster account) are struck if the user voted multiple times (see Wikipedia:Arbitration Committee Election/Rules, under "Scrutineering"). The corresponding discussion did distinguish the case of unintentional multiple votes (such as someone voting from an alternate account). I think it's reasonable to follow the same practice for administrator elections. isaacl (talk) 16:11, 29 June 2025 (UTC)
@Novem Linguae: The scrutineers have each scruted and spoken. On behalf of them I declare: we've struck two obvious sockpuppets, plus my own vote. We're ready for the next stage. -- zzuuzz(talk)13:47, 30 June 2025 (UTC)
Nice job catching the sockpuppets Awkward42 and DGrazing tester. Their dastardly sockpuppetry had the potential to corrupt and de-legitimize this very important test election. Well done scrutineers! ;-)
I started doing it then realised I was being very inefficient: we should have a template:Admin election schedule so we only need to update once. This would use the syntax {{Admin election schedule|election|phase}} e.g. {{Admin election schedule|July 2025|discussion}} would output July 18–22. The value of "whole" for the second parameter would output the whole schuedule in the bulleted list format used Wikipedia:Administrator elections/July 2025#Schedule. Using the named parameter "from" instead of the second parameter would output the bulleted list format, but only including the specified portion and subsequent portions, e.g. {{Admin election schedule|July 2025|from=discussion}} would output a bulleted list containing the dates of only the discussion, voting, scruitineering and results phases.
When setting up subpages, if we're just copying from the previous then it's a simple find and replace. If they are generated automatically, then they just need to output the first parameter.
This is all beyond my ability with templates to code though.
Two pages seems good, but I don't see the need to make a big deal about self-nominations and third-party nominations other than the "please accept" not being needed on the former. Thryduulf (talk) 08:10, 2 July 2025 (UTC)
I wrote some quick proofs of concept; if they seem reasonable to use, then I'll write documentation. {{Administrator elections info}}{{Administrator election info}} is an analog to the arbitration committee template to which I linked, holding dates and any other info. {{Administrator election schedule}} can be used to show date/time ranges: Note: keywords have been modified from original post, based on updates to the template
{{Administrator election schedule|July 2025|candidates}}: Wednesday 00:00, 09 July 2025 – Tuesday 23:59, 15 July 2025
{{Administrator election schedule|July 2025|poll_setup}}: Wednesday 00:00, 16 July 2025 – Thursday 23:59, 17 July 2025
{{Administrator election schedule|July 2025|discussion}}: Friday 00:00, 18 July 2025 – Tuesday 23:59, 22 July 2025
{{Administrator election schedule|July 2025|voting}}: Wednesday 00:00, 23 July 2025 – Tuesday 23:59, 29 July 2025
{{Administrator election schedule|July 2025|scrutineering}}: Wednesday 00:00, 30 July 2025 – around Saturday 23:59, 02 August 2025
I've only implemented showing these date ranges. It's not hard to add something to show a bulleted list of all the phases, though. isaacl (talk) 23:11, 3 July 2025 (UTC)
That looks like the start of what I was thinking of, thank you. Perhaps add some aliases for the parameters (e.g. "voting_phase") and some errors in case of unknown parameters, months with no elections, etc if that's easy. Thryduulf (talk) 23:36, 3 July 2025 (UTC)
The names are just ones I chose arbitrarily, so it can be voting_start/voting_end for the info template and voting for the schedule template. (I was going for noun + descriptor, keeping the nouns the same across the two templates, but anything will do for the first part.) The first parameter is just an identifier used by the the info template as a selector; there's no concept of month or year. The info template can have a default error message. The schedule template just passes the first parameter through to the info template, though, so it's more work than I would like to do with basic template syntax to generate an error message. isaacl (talk) 01:21, 4 July 2025 (UTC)
Should we split the first parameter into two or have it stay one parameter? In my Status template I currently have it split for ease of turning July into JUL, though it should not be hard at all to get JUL from July 2025.
I think "Administrator election schedule" is preferable to "Administrator elections schedule", since the template is showing the schedule dates for a specific election. I deliberately used a generic election identifier, rather than assuming that it was composed of specific subfields, to allow for more flexibility. isaacl (talk) 16:01, 5 July 2025 (UTC)
The current header on WP:Administrator elections, MMS messages, admin newsletter entry, and October 2024 subpage all pluralize a specific edition (the upcoming July 2025 administrator elections, Administrator elections will take place this month.). This makes sense because every edition of elections contain one election for each candidate, and there is no fixed amount of spots. However there is "contrary evidence" such as the second sentence of the current ADE page's header, the hatnote, and the July 2025 page. I've made Status also single-parameter. Aaron Liu (talk) 16:54, 5 July 2025 (UTC)
In the context of an adjectival phrase, to me "Administrator election schedule for July 2025" reads more naturally than "Administrator elections schedule for July 2025". With July 2025 moved to the front and thus "election" serving as a noun, "elections" sounds fine as well. Since the template call places July 2025 after the template name, I feel "administrator election" is more natural. Of course, we can have both if desired. isaacl (talk) 17:07, 5 July 2025 (UTC)
Automatically-switching header, take two
Latest comment: 1 month ago8 comments4 people in discussion
I don't think I should push this onto the actual election subpage like last time but if this template doesn't fail again maybe we could adopt this for the December election.
You're correct that this template currently uses all dates as 12 AM while the schedule uses some dates at 11:59 PM. Should I change the former to align with the latter? Aaron Liu (talk) 15:19, 5 July 2025 (UTC)
For consistency with the arbitration committee election, personally I would prefer to continue to use UTC midnight-based dates in the data template, and adjust the display of dates to show 11:59 PM on the preceding day for the end of a given period. The proof-of-concept template I wrote to display the date ranges does this adjustment. isaacl (talk) 15:28, 5 July 2025 (UTC)
Another thing is that this template has capabilities for automatic generation of {{shortcuts}} (though, of course, it does not create the actual redirects). What should the format of the shortcuts be? Currently I have "WP:ADE"MY, e.g. WP:ADEJUL2025. Aaron Liu (talk) 15:44, 5 July 2025 (UTC)
I know many people like shortcuts, even if they never get used (or only used by the creator), but all the same I think we should consider whether or not shortcuts are really needed for this circumstance. On English Wikipedia, shortcuts inevitably create jargon. Although there are cases where sentences become easier to understand with a jargon term encompassing a specific concept, personally I don't feel that's the case for election pages. isaacl (talk) 16:24, 5 July 2025 (UTC)
The administrator elections process has officially started! Interested editors are encouraged to self-nominate or arrange to be nominated by reviewing the instructions at Wikipedia:Administrator elections/July 2025/Candidates.
Here is the schedule:
July 9–15 - Call for candidates
July 18–22 - Discussion phase
July 23–29 - SecurePoll voting phase
Please note the following:
The requirements to run are identical to RFA—a prospective candidate must be extended confirmed.
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. A separate 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've added instructions to add in alphabetical order under the "list of candidates" heading, though note that Bugghost had already updated the invisible comment to read "alphabetical" instead of "the current" order. Aaron Liu (talk) 14:13, 2 July 2025 (UTC)
Finished task 3 and set up the category displays as well. Had to use automatic generation of only the last and the next since the catnav template doesn't seem to support monthnames. I wonder what we're going to do with the redirect Category:Wikipedia administrator elections 2025 when nearing December's elections? Is there such thing as a category disambig? Aaron Liu (talk) 14:52, 2 July 2025 (UTC)
(Novem has made the admin newsletter message and) I've made the MMS announcement based on the 2024 one. I added some accessibility roles and made the image go towards the right (it's also now frameless. I made the heading invisible to screenreaders since they'd've already read out the actual heading (e.g. "Tasks to help with" here); in fact I wonder if we should remove the duplicate heading? I also removed the bullet point pointing to a talk page section on things to help out with since I expect the single remaining link to be created by the time the MMS is sent out. Aaron Liu (talk) 23:07, 3 July 2025 (UTC)
At this point I don't think there's a need to post the MMS schedule announcement lol, or at most maybe it could be bundled into the call for candidates. Aaron Liu (talk) 23:13, 8 July 2025 (UTC)
Hey @Tryptofish:, you reverted my edit adopting the linked consensus language a sentence similar to 'An unofficial list of voter guides may be found at Category:Wikipedia administrator elections 2024 voter guides' to implement the A link to a category containing unofficial voter guides will be provided on the main election subpage. part mentioned by the procedure parent page. Could you detail what you mean by "in a way that I think does not reflect consensus"? Aaron Liu (talk) 20:09, 2 July 2025 (UTC)
You deleted Voter guides may be mentioned in passing and directly linked from candidate pages and talk pages. There will be no official voter guide. To my knowledge, there was never a consensus to delete that. I'm fine with replacing the general mention of a link to the category, with an actual link to the category. --Tryptofish (talk) 20:18, 2 July 2025 (UTC)
Taking a cue from ACE I felt that having a separate heading on the voter guides gives them too much prominence against the spirit of the relevant Phase II discussion and the discussions before that. However I didn't mean to delete the contents of that section; I think I meant to merge it up but was interrupted after Ctrl+X'ing the contents and forgot about it when I returned. Sorry about that. What do you think about just merging the contents up into the "voting" subsection? Aaron Liu (talk) 18:16, 3 July 2025 (UTC)
That's OK, I think all is fixed now. As for moving it into "voting", I have mixed feelings. I'm not really opposed to moving it there, but I'm not seeing a compelling reason to do it, either. Having text that indicates how we are limiting the guides actually serves the spirit of the discussions by making it easy to find. --Tryptofish (talk) 00:29, 4 July 2025 (UTC)
Correct. No discussion until the discussion phase. Thanks for spotting. I went ahead and reverted, with a polite message and ping to the folks involved.
Does someone want to edit Wikipedia:Administrator elections/July 2025/Candidate subpage template to make it more obvious that the discussion section is closed? Maybe we can put a red atop/abot in the discussion section, and inside of it, put a message about the discussion phase not being open yet? We currently have an ombox/notice, but clearly it is blending in with the other stuff on the page. –Novem Linguae (talk) 09:16, 9 July 2025 (UTC)
Creating Wikipedia:Administrator elections/July 2025/Candidates/YOUR USERNAME HERE
Latest comment: 1 month ago2 comments2 people in discussion
Someone already tried creating their nomination page at Wikipedia:Administrator elections/July 2025/Candidates/YOUR USERNAME HERE. I moved it to the correct ___location and salted the page, but we should probably add salting that title to the pre-election checklist. I also modified the inputbox to use |prefix= and |placeholder= instead of |default=, which makes it so that potential candidates actually have to type in their username. --Ahecht (TALK PAGE)12:19, 9 July 2025 (UTC)
Now that you took out the default, I don't think this will happen anymore. Should be OK to leave salting off the checklist. Thanks for improving this. –Novem Linguae (talk) 20:42, 9 July 2025 (UTC)
Header is broken
Latest comment: 1 month ago4 comments2 people in discussion
Should be good now... I made a change and assumed the thing would work fine if the preview on that page looked fine. Aaron Liu (talk) 14:43, 11 July 2025 (UTC)
Latest comment: 1 month ago18 comments10 people in discussion
The current watchlist notice says Editors are invited to submit a candidacy for adminship in the second English Wikipedia administrator elections. The sign up period ends at 23:59 UTC on 15 July 2025, and will be followed by a discussion phase and a voting phase. To me, this implies that any editor is encouraged to do so, and that this is telling editors in the 500–5000 edit range that they're going to get a warm welcome, setting them up for disappointment. Thebiguglyalien (talk) 🛸17:47, 10 July 2025 (UTC)
The landing page for that goes to Wikipedia:Administrator elections/July 2025/Candidates, which talks about candidate expectations in the lead section. We could put "Qualified editors" on there if you think it is attracting those that are ineligible, but candidate qualifications certainly don't require 5001 contributions first. — xaosfluxTalk17:56, 10 July 2025 (UTC)
All right, but I'm going to say "I told you so" when people who are obviously (to us) below community expectations nominate themselves and then get embarrassed when they're told no. Thebiguglyalien (talk) 🛸18:51, 10 July 2025 (UTC)
We currently have had 9 people put themselves forward. Of those, 1 is already blocked, 1 has 18 edits, 1 has 600 edits and the last (though having made a promising start) has 3k edits. The first three are blatantly not going to succeed and the last one is a very clear WP:NOTNOW. The major criticism of the first trial run was that we had too many candidates. Making it sound like anyone can run is setting many people up for failure and ourselves up for an even more bloated candidate list than first time round. That should be addressed. Valenciano (talk) 19:09, 10 July 2025 (UTC)
I've added the word 'experienced' to the watchlist notice and left a kind note on the talk of the 3k editor. —Femke 🐦 (talk) 19:42, 10 July 2025 (UTC)
I'm surprised there isn't a relevant edit filter for either RfA or ADE. It's so surprising there's probably a reason for it. Aaron Liu (talk) 00:45, 11 July 2025 (UTC)
Edit filters are "expensive" - they have to check at least a couple of conditions for every single edit made on the project; so we don't use them for very niche things like a backstage page. Besides what would we stop here? We are already preventing non ECP editors from entering the election - that they could create a candidate page they can't use isn't very disruptive to the project as a whole. — xaosfluxTalk01:17, 11 July 2025 (UTC)
No - the candidates who are WP:XC should be allowed to stand if they sign up. Whether they should have signed up is a different question, but deleting valid candidate pages based on predictions of the outcome should not happen. BugGhost🦗👻02:24, 11 July 2025 (UTC)
Sorry, I was talking about just the one with 18 edits. I already nominated the blocked one since they withdrew. Aaron Liu (talk) 02:34, 11 July 2025 (UTC)
Personally I think we should pull this watchlist message entirely. The largest criticism from the trial election was that there were too many candidates - broadcasting sign ups to editors who haven't seriously considered candidacy is not helpful. We will get more than enough decent candidates without advertising. BugGhost🦗👻02:19, 11 July 2025 (UTC)
At the time the first elections happened I was completely unaware of them until a month afterwards. Admittedly I was on a downswing in activity, but I checked my watchlist often enough I would've noticed. I had been (not very seriously) considering RfAing at the time and may have ran had I noticed. I suspect there were enough people in my position to make a watchlist entry worthwhile, though I strongly support adding "experienced" to the notice and any other measures to discourage clearly unqualified candidates from running. Rusalkii (talk) 04:13, 11 July 2025 (UTC)
The RFCs we ran had a consensus against any cap on the number of candidates, so I think we should be careful extrapolating "too many candidates ran last time, so we should take measures to reduce the number of candidates" from that. –Novem Linguae (talk) 05:12, 11 July 2025 (UTC)
Latest comment: 1 month ago86 comments19 people in discussion
Hello friends. I've created an English Wikipedia test election. It will run for approximately 3 days, until 2025-06-28 23:59:59 UTC. Please go ahead and vote in it to help us test.
There are 5 candidates, and it tells you how to vote for each candidate. For example, the first candidate's name is "Candidate A - everyone vote support for this one". Please everyone follow the directions so that we can test that the encrypted tallier is working.
Please report back here with any feedback.
Note that your IP address, user agent, and XFF info will be visible to the 3 scrutineers (Dbeef, RoySmith, and Zzuuzz) for 60 days from the end of the test poll, after which this private info will be automatically deleted.
Ideas for things to test / call out:
per the RFC, we will be alphabetizing candidate names
make sure you're OK with the order of the columns (oppose, abstain, support. default is abstain filled in.)
try voting with an administrator account. should be able to vote
try voting with an extended confirmed account. should be able to vote
try voting with a non extended confirmed account (<500 edits). should not be able to vote.
try voting with a blocked account. should not be able to vote
try voting with a bot account. should not be able to vote
double check the instructions text and wikilinks at the top of the vote.
double check the text that you get when you're not eligible to vote
anything else?
@Robertsky, @Dbeef, @RoySmith, @Zzuuzz. You are set as election clerks / election administrators for this poll, so you get some extra buttons. Please feel free to visit Special:SecurePoll and click on the pages in the "links" column. I'd recommend viewing only for now and not editing, with the exception of striking and unstriking your own votes.
I'll re-ping the scrutineers at the end of the poll and give them a day or two to pretend to "scrutineer" the poll, where we can hash out if we need to write a work instruction for that, if there's anything confusing about it, etc. Once they're done, I'll decrypt and tally the poll and post the results. I know everyone is on the edge of their seats for the results of this very important election ;-) –Novem Linguae (talk) 08:33, 25 June 2025 (UTC)
Many thanks for pulling this together! After voting, I saw it said Thank you. Your vote has been recorded. If you wish, you may replace this vote with a new one by returning to the voting page any time before the close of voting. If you do so, you will have to start over from scratch. - is it possible to make that link go direct to Special:SecurePoll/vote/821 (or whatever the page for that election is)? I hadn't realised we'd be able to see Special:SecurePoll/list/821 to see who has voted, though can't see how they voted, which is the important thing. -Kj cheetham (talk) 08:56, 25 June 2025 (UTC)
I also created a brand new account, and tried with that, but couldn't vote (got "Sorry, you are not in the predetermined list of users authorized to vote in this election.").
We had to use a "voter roll", which means I ran a quarry query and uploaded a whitelist right before I opened the poll. Anyone extendedconfirmed after the whitelist is uploaded will need to post a special request on this talk page in order to get added. This is a good opportunity to test that workflow. I've added DGrazing tester to the "override list" if you'd like to try voting again. (Technically I could have added them to the "eligibility list", but that list has tens of thousands of entries and takes a minute to save, so safer and easier to add them to the "override list"). –Novem Linguae (talk) 09:39, 25 June 2025 (UTC)
I blocked DGrazing tester, and tried to vote. It correctly said I've already voted, but by the looks of things, it would have let me vote again. Is it meant to be like that? -- DoubleGrazing (talk) 10:41, 25 June 2025 (UTC)
Try logging out and back in. When I was testing the on-the-fly voter eligibility stuff, I had to do that to get it to recalculate. –Novem Linguae (talk) 10:59, 25 June 2025 (UTC)
No, it hadn't expired, it was still blocked after I posted the above. But sure, I can try again with indef.
I don't think this matters, but just in case it does: I didn't actually log out of that account, per se. I was working in a private browser session, and closed down the browser and restarted it, which meant that I had to log in again. I'm assuming that serves the same purpose as explicitly logging out/in. -- DoubleGrazing (talk) 12:24, 25 June 2025 (UTC)
I couldn't reproduce this on localhost. I blocked an account and tried to vote and it was not able to vote. Is anyone else able to vote with a blocked account? Or maybe if you've voted once already, you're always able to vote again to change your vote? Strikethrough incorrect hypothesis. –Novem Linguae (talk) 13:18, 25 June 2025 (UTC)
I tested it on localhost by voting with an unblocked account, blocking it, and seeing if I could still vote. I could not. –Novem Linguae (talk) 14:41, 25 June 2025 (UTC)
Okay, now my test account is indeffed, so I tried again from a private browser session, and same result = could vote. I then switched to a different browser (from which I've never logged into WP before), and tried from a regular (non-private) session, and same thing, it recognised me as a returning voter, and let me vote again. -- DoubleGrazing (talk) 13:41, 25 June 2025 (UTC)
Oh duh. Of course the one account I put on the override list is the one that is testing the on-the-fly block detection. The override list can always vote. Lol. –Novem Linguae (talk) 14:42, 25 June 2025 (UTC)
OK, I moved DGrazing tester from the override list to the eligibility list, and I added Awkward42 to the eligibility list. Those two accounts should be able to properly test voting while blocked now. I think both will be unable to do so. –Novem Linguae (talk) 14:48, 25 June 2025 (UTC)
Awkward42 is indeed unable to vote while blocked "Sorry, but editors who are currently blocked may not vote in this election." I also got the "Your account does not meet the requirements to vote..." message, despite being on the eligibility list. When I tried after unblocking I was able to vote successfully, so it seems that being blocked was the reason for not being eligible - seeing both messages was confusing as it implied that I would not be able to vote even after being unblocked. Thryduulf (talk) 15:00, 25 June 2025 (UTC)
This is the same issue I pointed below, here. The latter one should be unbulleted, ideally implying that one can't vote due to the list of bulleted reason(s) above, and what they can do (complain here) is in the last message set per election in the config. (I hope I am conveying the same rationale as Novem below). ~/Bunnypranav:<ping>15:07, 25 June 2025 (UTC)
Yes being unbulleted would help, it could also be made explicit by adding "for the reason(s) above" at the end of the first sentence. Thryduulf (talk) 15:10, 25 June 2025 (UTC)
I tried reblocking to see whether it would let me revote and the results were mixed: I'd left myself logged in and viewing the vote confirmation screen, from there I clicked the link to revote which too me to Special:SecurePoll. I clicked the link for the test election and, despite being blocked, was able to vote again. I then tried logging out and back in (in the same browser window), followed the direct link to the test election but was not able to vote (same messages as when I first tried). Thryduulf (talk) 15:07, 25 June 2025 (UTC)
That sounds like a bug that should be filed. Can an election admin/scrutineer get the exact timestamps of the vote, along with the block log, so we can open a bug. Sounds like SP is using a cache that it shouldn't. — xaosfluxTalk15:14, 25 June 2025 (UTC)
I wouldn't call that a showstopper, as this seems to be an existing condition - not something specific to the local implementation. — xaosfluxTalk15:15, 25 June 2025 (UTC)
If it helps, the ID of the revote was 6419, the ID of the initial vote is not in my browser cache and I didn't think to record it. Thryduulf (talk) 15:17, 25 June 2025 (UTC)
After the block expired I clicked the link to securepoll on the editors who are blocked can't vote screen, following the link to the test election it took me to the voting page as it should (although I didn't save that vote) so that at least is working correctly.
I blocked again while I had the voting page open, refreshed and then hard refreshed the page, and it still would allow me to vote (although I didn't attempt to submit one). I navigated away from the voting page (clicking the link on Candidate A), then followed links back to the voting page and again would have been able to vote. I then logged out and back in, followed the link from this page to the test election and got the error as I should. I then explicitly unblocked, refreshed on the error page and was taken to the voting page.
In conclusion it appears to be correctly detecting when accounts are not blocked but not always correctly detecting when they are. Thryduulf (talk) 15:36, 25 June 2025 (UTC)
OK, it looks like it is checking "are you blocked" when you enter the poll, not when you exit the poll. So not necessarily a bug, and a very unlikely race condition. Thanks for the details. — xaosfluxTalk18:16, 25 June 2025 (UTC)
Except it isn't always getting the correct result when I enter the poll while blocked unless I've logged out between being blocked and opening the poll. On my main account I very rarely log out (I don't know how common this is, but comments on phab:T372702 suggest it's not just me). Thryduulf (talk) 19:45, 25 June 2025 (UTC)
Yes, this time DGrazing tester couldn't vote, and got instead the "Sorry, editors who are blocked" reason. (Good catch, Beef!) -- DoubleGrazing (talk) 15:26, 25 June 2025 (UTC)
Just reporting that the scrutineer data is coming through as expected. I'll probably strike one of my own votes sooner rather than later. I am curious about the column marked 'Duplicate', which remains empty at this time. Let's hope it remains unused. -- zzuuzz(talk)10:53, 25 June 2025 (UTC)
I found that "duplicate" column to be pretty confusing. I filed phab:T397819 about it. It has something to do with duplicate cookies, and is perhaps only relevant in global elections. –Novem Linguae (talk) 10:58, 25 June 2025 (UTC)
Everything looked good from my perspective. It let me vote using this account, it didn't let me vote using my alt (Awkward42) which is not extended-confirmed. Thryduulf (talk) 11:49, 25 June 2025 (UTC)
3 different reasons for non-eligibility.One opening the page from my bot account, BunnysBot, I can see three different reasons (image added) for why the account is not eligible to vote; it's a bot, it's not in the eligibility list (the big list from quarry), it does not meet requirements (editcount/age). The first may not be there if it is not a bot, but is there any way to show only one of the latter two, with the link to post here in case of any issues? From ?uselang=qqx I think the last is set manually, so maybe the other can be modified (temporarily should work) for making the voters life easier in understanding why they can't vote. ~/Bunnypranav:<ping>12:13, 25 June 2025 (UTC)
The third bullet isn't a reason for lack of eligibility (it's not an "insufficient edit count / insufficient age" message), it is just the generic message that everyone sees if they are not eligible. Perhaps it'd be less confusing if the third bullet didn't have a bullet. I've filed phab:T397835 –Novem Linguae (talk) 12:48, 25 June 2025 (UTC)
As this is going to be new for contributors, we should probably add a section on Wikipedia:Administrator_elections about privacy, and link to it from election descriptions for a while. Most people are used to the central securepoll and may not realize the differences now. Some voters had expressed apprehension with the enhanced info collection, which should be able to be overcome as less information about voters is being collected now. — xaosfluxTalk13:00, 25 June 2025 (UTC)
I am able to access the translate page for the poll, here, which exposes changing the labels for English (eg changing "Oppose" to "Against" or whatever). The text boxes are editable but I can't hit "update" thankfully - so I assume there's some sort of missing permission blocking this - but I wanted to ask who this functionality is available to, in case we need to worry about unauthorised label changes. BugGhost🦗👻16:50, 25 June 2025 (UTC)
Should be OK to view translations. All of that is public. Only election administrators can press the "Update" button. Thank you for mentioning it. –Novem Linguae (talk) 21:01, 25 June 2025 (UTC)
Don't know if you still need data but I voted with my (extended confirmed) account and was not able to with my 0-edit testalt and everything behaved as expected. Perfect4th (talk) 17:03, 25 June 2025 (UTC)
If a user is extended-confirmed at the beginning of the election but has the right revoked, will they still be able to vote (and have their vote counted)? Jruderman (talk) 05:57, 27 June 2025 (UTC)
When I hover the ballot's rows, the blue highlight extends past the visible right side of the table. This happens in both Chrome and Firefox. Jruderman (talk) 05:59, 27 June 2025 (UTC)
Visual issue I've noticed that in dark mode in default skin (Vector 2022), there are some visual issues on the ballot table. Hovering over the options changes the background colour to white, which makes the white text impossible to read. There also appears to be half an extra column to the right of the main table(?), causing some extra lines to jut out the side. Screenshot is of the mobile site, but appears in dark mode in desktop site as well. BugGhost🦗👻16:53, 27 June 2025 (UTC)
On the list-of-votes page, I'd like to be able to filter to only active votes (hiding replaced votes and other votes that will not be counted). Jruderman (talk) 01:34, 28 June 2025 (UTC)
Few readers will understand "X-Forwarded-For". Consider folding it into "IP address (including X-Forwarded-For information)".
I was surprised to find out that my username and rough vote time were listed publicly. It might be good to state that in this section.
The section could include a link to information about the privacy of the ballot: who can see my specific support/abstain/oppose votes (or view the totals before the election is finished, which would amount to the same thing).
I'm not editing the section directly because I think it should be done by someone with direct knowledge, and because I don't know where to edit such that it will apply to future elections (is it a subst'd template?). Jruderman (talk) 02:08, 28 June 2025 (UTC)
The ballot page says "consider keeping a private record of your vote". Maybe change this to "consider copying the confirmation page as your private record of how you voted", since that's less time-consuming than transcribing the vote manually from the ballot page, and it's not clear that it will be possible in one's first election. Jruderman (talk) 08:02, 28 June 2025 (UTC)
The order mirrors that of the arbitration committee election. There was some discussion of this during the 2022 arbitration committee election; my view then was that it would be desirable to maintain that order for continuity. Now the administrator election ballot could go its own way and change the order. I think we should consider though the synergy benefits in keeping the order the same across the two types of elections. isaacl (talk) 16:03, 25 June 2025 (UTC)
I don't have a strong opinion about which order the options should be in but I do think the order should remain the same from one election to the next, and that elections happening concurrently (as arbcom and aelect will if the schedules stay the same) should use the same order. Thryduulf (talk) 16:30, 25 June 2025 (UTC)
FWIW, I feel (and I can't really explain why) that oppose should be on the left, and support on the right. Maybe this comes from the typical rating scale in a survey, where it might go from 0 to 10 or -3 to +3 or whatever, ie. the 'positive' is on the right. (And no, it's not a Tinder 'swipe left' thing, honest guv!)
But I definitely do think that abstain (= 'neutral') should be in the centre column.
I vaguely remember some voters last time saying that they got the columns confused, so we're right to discuss this to minimise that risk. Would it be possible to add colour to the columns as extra visual clue; say, oppose = red / support = green (although that won't help some colourblind users, of course)? -- DoubleGrazing (talk) 16:50, 25 June 2025 (UTC)
I was just about to say I feel support should be on the left and oppose on the right, also for no specific discernable reason. Perfect4th (talk) 17:03, 25 June 2025 (UTC)
In the discussion to which I linked, I commented on the potential influence of a rating scale. Since "abstain" isn't a "neutral" vote, there is an argument for moving it out of the scale. However, my impression is that the SecurePoll software controls the formatting of the options, and doesn't allow for one to be placed some distance away from the other. Thus I think having the support and oppose options at the two extremities makes it easier for voters to review their selections. isaacl (talk) 17:13, 25 June 2025 (UTC)
I have no strong feelings about which order Support and Oppose should go, but they should certainly be at the two ends with Abstain in the middle. And it should certainly be consistent; whatever way we pick here should be used for all future elections. RoySmith(talk)14:24, 27 June 2025 (UTC)
Well, the first election has already set a precedent and it aligns with the arbitration committee election ballot. isaacl (talk) 16:59, 27 June 2025 (UTC)
I really like this idea, but there appears to be a bug in SecurePoll that causes wikitext to render as raw HTML code instead of formatted. I've filed phab:T398102. When that ticket is solved, and if there aren't objections, I'd be happy to add these icons. –Novem Linguae (talk) 06:49, 28 June 2025 (UTC)
Column order in intro message
The text instructions say "Support", "Oppose", or "Abstain". I have no preference as to the order, but the text matching the order on the voting would make sense to me. -Kj cheetham (talk) 10:12, 25 June 2025 (UTC)
I think the natural speaking order for someone discussing the options is to put "Abstain" last, but I appreciate that the written order doesn't necessarily have to follow the usual speaking order (which of course the actual ballot didn't, in the first election). isaacl (talk) 16:03, 25 June 2025 (UTC)
Sort speed
Right now, there's 50 votes recorded. If I click on any of the column headings, it takes from 2-4 seconds to sort, which seems like an extraordinarily long time to sort 50 items. Is this normal? I'm not so worried about 4 seconds, but wondering if this is some sort of O(n^2) behavior which will become pathological when we've got 100s or 1000s of votes. RoySmith(talk)12:56, 27 June 2025 (UTC)
Sorting 50 elements certainly can't take that long, but, it could certainly be a missing mysql index, my suspicion would be that it's wasting time loading all votes ever cast in any poll, then filtering down to just this poll. Leijurv (talk) 22:52, 27 June 2025 (UTC)
I tried a couple other SecurePoll special pages, and I was getting around 2 seconds. Visiting the list page, whether sorting or not sorting, just now I was getting about 4 seconds. So good point that it's not super slow, but I do think it's a little bit slower. –Novem Linguae (talk) 06:10, 28 June 2025 (UTC)
The time is spent in fetching things from the db, rather than in sorting. The harmless-looking counts at the top of the page are using egregiously bad queries that I've fixed in gerrit:1164549. – SD0001 (talk) 09:24, 28 June 2025 (UTC)
Interesting. Maybe we should abandon the patch and close the ticket then? Also, maybe it's worth having 4 second load times if we get to keep the extra user links, so maybe we should put that back? –Novem Linguae (talk) 21:36, 7 July 2025 (UTC)
, which renders as $1(talk, contribs). I assume this would be quicker to render than the User-SecurePoll template, but I'm not a template expert (and I'm editing on a phone so difficult to test thoroughly) - apologies if I'm barking up the wrong tree here. BugGhost🦗👻07:44, 8 July 2025 (UTC)
Yes, 800 lines of lua to render a few links seems a bit much. I restored the links by checking the template's post-expand output using Special:ExpandTemplates. It results in load time under 1.5 seconds. It should also be fine to create a lightweight template to avoid putting the markup directly in MW space. – SD0001 (talk) 21:31, 12 July 2025 (UTC)
SNOW
Latest comment: 1 month ago13 comments8 people in discussion
(Sorry if this is covered somewhere, lazy as I am it's easier to ask than to research.) Not entirely hypothetically, if a candidate signs up who is technically eligible to run but has practically no chance of getting through, what, if anything, should we do? In an RfA that could be closed per SNOW, but a) this isn't RfA, and b) in any case SNOW close happens (always? usually?) once the discussion is underway, which this isn't yet. I'm not suggesting we should be removing anyone from the contest against their will, but is it appropriate to try to persuade them to withdraw? Unlikely as it may be, we probably want to avoid a situation where a large number of SNOW candidates sign up, possibly affecting the process adversely. -- DoubleGrazing (talk) 13:10, 11 July 2025 (UTC)
SNOW happens when votes pile up against something quickly - in the election you can't tell the votes until it is over, so it doesn't really apply. WP:NOTNOW could be, and perhaps if you think a candidate is too soon you could ask them specifically about that during the question period - they may agree and withdraw. — xaosfluxTalk13:16, 11 July 2025 (UTC)
Yeah, you're right, NOTNOW is what I should have said (this heat is melting my brain, or some other pathetic excuse like that!). Okay, so no need to do anything at this stage, then. -- DoubleGrazing (talk) 13:20, 11 July 2025 (UTC)
I think it's best to contact people as soon as you notice, so ideally in this phase. It fairer to the candidate to get clarity immediately and not spend time polishing a nomination. It's also better for the process to be less overwhelmed. One thing I always do is suggest a more appropriate alternative for the potential candidate (such as CVUA, writing a GA, getting a specific perm etc). —Femke 🐦 (talk) 16:12, 11 July 2025 (UTC)
I think given that this is an election, any candidate who meets the requirements may stand for election and we don’t force them out of the process.
That being said, I do also think though that if a candidate realizes during the discussion phase that their election candidacy doesn’t appear to have support due to users concerns, they are encouraged to withdraw their nomination and potential seek candidacy in the future if the concerns raised were addressed.
So I don’t think we should force closure necessarily, but candidates should use their good judgement in the interest of the communities time that if it appears obvious from the discussion that their candidacy likely has no success at that moment in time, that they should withdraw to help the community either not having to read through as many candidacy pages as are necessary. Raladic (talk) 18:54, 11 July 2025 (UTC)
What do see as the advantage of waiting until the discussion phase before raising this with the candidates? Either for the candidate or for the community? —Femke 🐦 (talk) 19:01, 11 July 2025 (UTC)
I'm not saying it has to happen during the discussion phase, if you see a candidate and feel like there's a reason that you want to bring up with them beforehand, you could do so at their user talk page and they can withdraw from the election at any point.
But at the same time, this is a semi-democratic process, so I don't think we should prematurely force a candidate out until they've had a chance to address whatever concern users have brought up. Whether that's in a direct message on their talk page, or during the discussion phase, either would be fine.
I will maybe partially walk back half a meter and say that if after the discussion phase it truly does look like there's a SNOW chance and the candidate hasn't already withdrawn on their own accord, that maybe we want to codify a process to urge them to so, so that less candidate pages have to be reviewed by voters.
But I would hope that people that put their hat in the ring for adminship and thusly should have reasonable good judgement. I could definitely see the fact of not withdrawing in the face of certain failure by itself could be telling and would likely not only cost community time for the current election, it likely also would hamper future candidacy chances as it would show poor judgement on a candidate's part. Just to be clear though, I don't think candidates should withdraw in throves if it could go either way, just that some cases may be pretty clear from the discussion/candidacy and in such cases, I'm hoping candidates have this insight in that moment of time.
I'd say the only time the community may reasonably "force" close of a candidacy is if it's blatant time waste, but hopefully that just doesn't happen (don't think such a case happened last election as far as I could recall and that was the first one with lots of uncertainty at that..).
that maybe we want to codify a process to urge them to so, so that less candidate pages have to be reviewed by voters. We have a process for that. It's called "Only editors with EC may become admins". If you want a higher threshold than that, let's have a higher threshold. I just disagree with the notion that the community can force candidates to step down unwillingly without formal voting.
And it's not like it's a massive timewaste anyway, all it forces is a few extra seconds of everyone's time, and lengthier voting guides. Not ideal, but not the end of the world. Far less important than "Are competent editors interested in standing for adminship now", in my opinion Soni (talk) 05:42, 12 July 2025 (UTC)
Some reasons to try to design the AELECT process to exclude editors that don't have a realistic chance of getting elected are 1) to avoid WP:BITE and 2) to avoid poor use of community time. The BITE reason in particular should be given serious consideration. Letting up-and-coming editors throw themselves in the deep end of this process is probably not very motivating. Personally I would support a minimum edit count of 5000 as a hard, red line rule. But I doubt a 5000 minimum edit count for AELECT could pass an RFC. –Novem Linguae (talk) 17:55, 12 July 2025 (UTC)
Personally, I agree that the mere requirement of ECP is an unrealistic level for someone to actually get elected as an administrator as it feels near-impossible to have built up enough experience to wield the mighty WP:MOP with that little experience, so I'm actually not sure if we did an RfC to raise that requirement whether it would fail - we may need to do a WP:RFCBEFORE to figure out the right level to poll, e.g.:
Maintain status quo - ECP (500 edits, 30 days)
ECP & 1000 edits
ECP & 2000 edits
ECP & 3000 edits
ECP & 4000 edits
ECP & 5000 edits
ECP & 10,000 edits
I'd make a guess than 10k is too high as arguably some people have gained enough experience with less edits that they may be good mop-wielders, but I think there may actually be support for a minimum level being somewhere between 2k-5k range - do you want to start a separate discussion on it? Raladic (talk) 23:24, 12 July 2025 (UTC)
Certainly there should be some discussion prior to an RFC. The greater the edit count the less well it correlates with cluefulness and as such we should avoid making it unrealisticly high. Someone who spends their wiki-time making well-researched, high-quality articles and single, thoughtful contributions to discussions may take years to reach 5000 edits yet be a much better admin than someone who prioritises quantity over quality in discussion contributions and whose voluminous NPP and AFC reviews have a high error rate who racks up 3k edits a year. Thryduulf (talk) 00:23, 13 July 2025 (UTC)
10k is too high. There's been at least 2 admins in the last 5 years who succeeded with edit counts below 10k (Dbeef in the 8000s, and Sohom Datta in the 7000s).
The format we used last election for RFCs, in my opinion, worked super well and I plan on copying it again. The format was election > debrief phase to collect feedback > RFC workshop phase > RFC phase. I am keeping track of issues on this talk page that don't have consensus, and we can use that and the debrief phase for the RFC workshop phase post-election. –Novem Linguae (talk) 00:24, 13 July 2025 (UTC)
How about a two-pronged approach? Something like ECP &#### edits with an administrator nomination and ECP &#### edits for self-nomination? (Edited: the ECP part would then by superfluous.) Schazjmd(talk)13:06, 13 July 2025 (UTC)
About hatnote
Latest comment: 1 month ago10 comments5 people in discussion
Much of that has been incorporated into this main page, and we could bring anything more that may require a mention. (Maybe a "History" section"?) I simply find it non-standard to give such prominence to one particular edition of the election. —CX Zoom[he/him](let's talk • {C•X})22:32, 11 July 2025 (UTC)
It's not that WP:AELECT is missing data, its just that it previously had a different purpose. Check out this old revision - it had the schedule for the trial election, the list of trial candidates and the trial results. The page was not about the process as a whole, it was about the trial election specifically, and it was linked to as such. Because the purpose of the page has since changed, we should signpost those who are looking for its previous purpose. BugGhost🦗👻12:06, 12 July 2025 (UTC)
Looks like I'm in the minority on this one. While I still think keeping it is worthwhile to help anyone who arrived here via a historic link, I'm happy to admit not everyone else agrees, so I won't stop anyone removing the hatnote. BugGhost🦗👻08:25, 13 July 2025 (UTC)
I would be in favor of removing the hatnote. There is a list of elections farther down the page. With each passing election, the importance of individual elections will continue to decline, making it hard to justify mentioning them at the top of the page. –Novem Linguae (talk) 18:01, 12 July 2025 (UTC)
I'm in favor of keeping it. WP:RfA has a list of people currently running at the top, and since WP:AELECT is the closest equivalent for elections, if we don't want the current list of candidates up at the top, keeping the hatnote is a good idea. Another alternative would be to convert the "List of elections" table into a sidebar that can go up near the top. --Ahecht (TALK PAGE)20:40, 12 July 2025 (UTC)
@Ahecht: I think there's a misunderstanding. The hatnote currently links to the first edition of elections in 2024, not the current one, as you suggest should be linked. —CX Zoom[he/him](let's talk • {C•X})20:58, 12 July 2025 (UTC)
Is there a way to catch these before new editors waste their time putting together a statement when they cannot run? That seems like it would be a frustrating experience. Rjjiii (talk) 14:31, 11 July 2025 (UTC)
So the workflow is: Go to the election page, see the guidance, scroll down and use the form maker to start a page, get a warning banner about exactly this, ignore all this and continue anyway. At that point I'm not sure what else to say? Perhaps they just want to play around. — xaosfluxTalk14:49, 11 July 2025 (UTC)
Eh, it is kinda tiny overall compared to the editing window and to other warning banners. Maybe increasing the size of either the image or the text would make it more discouraging. --Super Goku V (talk) 15:08, 11 July 2025 (UTC)
I can't see the example as I am edit confirmed, but I was able to just copy the code of the template and view it with previews in my userspace after a modification. Thank you for also considering to increase the non-bolded text as well as that is a good idea. --Super Goku V (talk) 15:26, 11 July 2025 (UTC)
but most of the edit notices are not visible on my mobile. Not sure if it because I'm extended confirmed, or due to my browser. Sometimes the the notice doesnt pop up, and when it does, most of the times it is empty like the screenshot. —usernamekiran (talk)17:24, 13 July 2025 (UTC)
No easy way actually. @Novem Linguae is gonna knock me silly for suggesting this :P, but an edit filter may prevent direct page creation. However, nothing will prevent them from moving from a userpage to a candidancy subpage. – robertsky (talk) 14:46, 11 July 2025 (UTC)
Wrapping the form in <spanclass="extendedconfirmed-show sysop-show">...</span> may help, but do we actually have a rule against a non-XC editor nominating someone else? --Ahecht (TALK PAGE)05:49, 12 July 2025 (UTC)
Latest comment: 1 month ago9 comments8 people in discussion
Sometimes, it feels odd to have nominators for rfa elections. Wouldn't it be better to give up this method? There is a chance that "passable candidates" never get asked by someone, and they possibly don't request for being nominated. If there are only self noms, I think more people might come forward. We can still encourage people to run for rfa/elections obviously. And then we have this foolish, but large-scale misconception that only admins can/should nominate a candidate. —usernamekiran (talk)18:46, 13 July 2025 (UTC)
And there's the cognitive dissonance of not allowing discussion before the official discussion period - unless it's verbose, glowing, and preapproved by the candidate. —Cryptic19:04, 13 July 2025 (UTC)
I think it's an interesting idea. I had hoped that we would go to a system with 1 nominator, but that does not seem to be the case. It is somewhat unfair that shy people, or people not in the orb of the small group of people actively seeking out possible candidates, have less of a chance.
I've added the list of people to ask for a nomination to the candidates page, and encourage any experienced editor who's willing to nominate to add their name to the list, to make the barrier for asking lower for now.
Nominators sometimes do play a large role behind the scenes to make the process less rocky, give feedback, and help editors grow. We would throw that out as well. —Femke 🐦 (talk) 19:56, 13 July 2025 (UTC)
Indeed. It's not for nothing that all the candidates with nominators were elected last time. And we can already see that people are happy to throw their names in the ring without nominators. -- asilvering (talk) 22:17, 13 July 2025 (UTC)
I guess you could rationalize this with why ADE exists in the first place: to get more administrators, who will have no need to fear the pressure of a typical RfA. Statements of support and opposition were banned too for this reason. After everything, the designers of this elections process has had us end up with a candidate presenting themselves with laudation before discussion starts. Putting nominator statements in there doesn't change anything. It's a candidate presenting themselves with laudation before discussion starts. If you wanted to remove nominator statements from this, you would see trending a "testimonials" section in every self-nomination that does the same thing, yet is worse than just having nominator statements because of potential misrepresentations and cherry-picking, of statements that are out-of-context like those designed to give WP:Rope. I don't think that's what we should go for. Aaron Liu (talk) 20:14, 13 July 2025 (UTC)
As with all processes, there are tradeoffs. Historically, there have been a lot of editors who mistakenly believe they meet community expectations to be an administrator. The community has shown that it has limited capacity to manage these types of candidates (see the previous section on managing candidates unlikely to be approved for concerns). Asking a potential candidate to consider finding one other person who thinks it's a good idea is reasonable advice. Until the community exhibits greater collective forbearance, I don't think it would be effective to drop this suggestion. isaacl (talk) 21:58, 13 July 2025 (UTC)
In my opinion, anecdotally, having 1-2 good admin nominators correlates very strongly with passing both RFA and alect. I don't think taking this tool away from candidates would be a good idea. The current system allows but doesn't require nominations, which seems like the best of both worlds to me. –Novem Linguae (talk) 22:54, 13 July 2025 (UTC)
I'm going to concur with those who prefer nominated candidate statements as opposed to self-noms. Nominators can be a very important ally/coach during the discussion period. On the merits there's little difference, but historically !voters have often tended to support those with a nominator more than those without. Depending on the nominator of course. I would have big issues with any attempt to remove nominators from this process. For my part I wouldn't nominate any candidate who I think would harm the pedia. As a voter, when I see a good nominator I'm more likely to think the candidate has been vetted by someone the community trusts. BusterD (talk) 11:51, 14 July 2025 (UTC)
Especially given that last time, there were so many complaints about how it was impossible to vet the candidates because there were too many. -- asilvering (talk) 15:55, 14 July 2025 (UTC)
Unable to create a candidacy page on the Android mobile app
Latest comment: 1 month ago11 comments8 people in discussion
Android app
As seen in the screenshot to the right the boxes referred to to create a candidacy do not exist. the "THEIR USERNAME HERE" text (from the nominate someone else box) is not clickable.
The page is identical whether I'm logged in as Thryduulf (admin) or Awkward42 (non-extended confirmed). I don't have a way of easily testing what it looks like as a non-admin but extended confirmed user but I imagine that it will be the same. I don't have any iOS devices so cannot test on that operating system. Thryduulf (talk) 15:47, 13 July 2025 (UTC)
Works fine on iOS app, you can scroll to the right there - iOS app
But I agree with @Sohom Datta that it seems like a rather fringe case. I’d say anyone who wants to submit a nomination would more likely than not do it in the web version. If it’s indeed a known issue with the android app, maybe we just add a small footnote into the page to tell users of the android app that if they wish to submit a nomination, to please go to the web version instead? Raladic (talk) 16:35, 13 July 2025 (UTC)
The official apps use a different API for rendering pages; what you see is taken from https://en.wikipedia.org/api/rest_v1/page/mobile-html/Wikipedia:Administrator_elections/July_2025/Candidates. (For some reason, when encountering projectspace pages, the iOS app decides to render the web version instead of this special version it renders for articles. You can see that by looking at the formatting surrounding the section-edit buttons.) I don't even know where the source code for this API is as it's "Not included with MediaWiki, Available for Wikimedia projects only". So the only thing we can do about this is report to the WMF, but I agree that I don't see why we'd want this. Aaron Liu (talk) 19:56, 13 July 2025 (UTC)
Code could be added to the candidates page to wrap the buttons, perhaps only on narrow viewports. That would fix this. The buttons were wrapped until recently when an edit was made to the candidates page. An option is to revert that edit or improve it. However I also agree that supporting the mobile app is not highest priority. –Novem Linguae (talk) 22:59, 13 July 2025 (UTC)
The buttons only work on the web version, which incidentally is what the iOS app uses but not the Android app. I've added captions to the screenshots; the main problem is with the first screenshot. Aaron Liu (talk) 23:10, 13 July 2025 (UTC)
We should just call it out. Realistically, if someone wants to be a sysop - they should know how to solve this problem for themselves.... — xaosfluxTalk23:28, 13 July 2025 (UTC)
Personally I don't understand the active opposition to editors who primarily use the app from becoming admins, but that's beside the point. If we can't (or won't) support it then we need to make it clear that you cannot nominate using the (Android) app rather than presenting a page that gives knowingly wrong information. I also don't know why we would expect an admin to magically know that the page is broken in the app and they need to use a different interface - admins are not required to be technically knowledgeable (especially now interface admin is a separate thing). Thryduulf (talk) 02:13, 14 July 2025 (UTC)
Thryduulf, part of the issue is with regards to this edit by Ahecht. For some reason, the Android App acts as if I am not extended-confirmed for the process of bringing up the "Nominate yourself" box, despite being logged in. So there is some bug here related to the "class="extendedconfirmed-show" text. However, that alone isn't the full problem as the button still can't be hit when that text is removed and I don't know fully what to recommend. (Per Bug reports and feature requests, this should be reported to Phabricator if the issue is with MediaWiki, but I am not sure if either issue is or isn't MediaWiki.) --Super Goku V (talk) 09:15, 14 July 2025 (UTC)
Hmm. It doesn't look great in browser either. Screenshot. Can someone please take a stab at re-designing it? Could wrap and center the buttons, could reduce the width of the input boxes, etc. –Novem Linguae (talk) 11:10, 14 July 2025 (UTC)
I made the input boxes a bit narrower and moved the statement about consent to the preload template and the instructions above to make the button narrower. --Ahecht (TALK PAGE)16:11, 14 July 2025 (UTC)
scrutineers nominating people
Latest comment: 1 month ago14 comments10 people in discussion
Is there a second nominator? In the first election round, we saw all 1-nominator candidadates pass, so there might be less of a need for two nominators. This time around, with the low number of sign-ups, we seem to edging more towards the old 2-nom system. I sort of agree that it looks a bit odd to nominate and scrutineer.. —Femke 🐦 (talk) 14:57, 13 July 2025 (UTC)
We have 2 backup scrutineers if it comes to that. But would be nice to not put election officials under restrictions that encourage them to not participate. The chilling effect on election officials is already beginning. –Novem Linguae (talk) 15:13, 13 July 2025 (UTC)
This seems like a very reasonable restriction, though. We don't want the appearance that the people removing votes might have a bias. Obviously it's incredibly unlikely that that actually happens, but the possibility is enough to give people a target for outrage and create drama. ThadeusOfNazereth(he/him)Talk to Me!15:35, 13 July 2025 (UTC)
I don't think it is as reasonable as it initially appears. because (1) scrutineering is strictly based on whether the same person voted multiple times using multiple accounts, (2) votes are only struck when all scrutineers agree or come to a consensus. if there is a situation where three scrutineers collude and corruption happens, allowing scrutineers to vote/comment/nom or not can't change that. (3) everyone can verify that their vote was counted in the final tally by saving their vote receipt and comparing that to the dump.
further more, I really don't think "appearing unbiased" is a virtue. It is quite analogous to laziness. The real work happens when people admit to their biases and reducing the harm they cause. So I don't think it is really beneficial for us to appease unreasonable people by doing (IMO) pointless optics, but I also can't stand in the way.
Alright, I will not be doing scrutineering then. Consider me officially stepped down from scrutineering when I add the nom statement, I'll notify here when that happens.
I'd want to vote on the candidates, vouch editors whom I trust, and voice potential concerns too, it seems that I cannot do so when being a scrutineer. dbeef [talk]15:26, 13 July 2025 (UTC)
Thank you for volunteering to scrutineer and for also doing the valuable task of nominating a candidate. Hopefully we can figure out something so this situation is easier in the future. BugGhost🦗👻18:48, 13 July 2025 (UTC)
Alright, just added my co-nom statement. Someone else will have to scrute because we haven't got any consensus for election officials getting involved with elections yet. Sorry for the noise. dbeef [talk]06:15, 14 July 2025 (UTC)
OK, well thanks for the decision and letting us know (and for taking part in the testing!). We should probably now implement the alternate scrutineer protocol. Hopefully we can just ping Dreamy Jazz and Barkeep49, and that will sort itself out. -- zzuuzz(talk)09:59, 14 July 2025 (UTC)
There was some sort of consensus above that even if scrutineers could vote they shouldn't make public statements of support a la monitors in RfAs, though. Aaron Liu (talk) 19:41, 13 July 2025 (UTC)
Test election results
Latest comment: 1 month ago11 comments4 people in discussion
Hello friends. I'm pleased to announce the results of our recent test election.
Per DRY, don't cite two different sets of instructions. On the slight chance they don't agree about some detail, it won't be clear which set has priority. Also, on the results listing, it would be nice if the "Strike" column were sortable just like the others. Then you could sort all the struck votes to the top, making it easier to see which they are. RoySmith(talk)00:31, 1 July 2025 (UTC)
My concern, as noted above, is that by over-specifying the requirement, you introduce ambiguity into which definition is the controlling one. If you want to leave that in, then I'd qualify it with "which typically means" or some other language which makes it clear that its the actual status of the bit which matters. We recently had an example at DYK of how adding too much information leads to problems with the definition changes in some places but not others. RoySmith(talk)17:12, 15 July 2025 (UTC)
Awesome. All ratified. Now I can go post on WP:BN and ask the bureaucrats to promote our one hypothetical test candidate :) I'm very glad we did the test election. It was good practice for the new scrutineers, and it was good practice for me. We were able to test some things that we didn't catch in the smaller localhost test, such as formatting the tally being more complicated than I thought. Should be all set for the real election now. Great job everyone. –Novem Linguae (talk) 10:19, 1 July 2025 (UTC)
RFA subpage redirects - help wanted
Latest comment: 1 month ago4 comments3 people in discussion
Would someone be willing to double check that each candidate has a WP:RFA subpage that redirects to their AELECT candidate page? So for example, Wikipedia:Requests for adminship/Jlwoodwa should be created and it should have the content #REDIRECT[[Wikipedia:Administrator_elections/July_2025/Candidates/Jlwoodwa]]. If it is not their first RFA or AELECT, the RFA page should have a 2, 3, etc. appended to it. For example, Wikipedia:Requests for adminship/Jlwoodwa 2. Careful, some candidate redirects were already created for this election, so careful not to double create. Thanks. –Novem Linguae (talk) 03:49, 16 July 2025 (UTC)
It turned out that the only one needing to be done was Jlwoodwa. And for them I just created an unnumbered page and undeleted the previous rejected RfA for behind the redirect. * Pppery *it has begun...03:59, 16 July 2025 (UTC)
Thanks – I did the rest as they came in (except I think I got beat for Smason?) but forgot about jlw since she came in right at the end. charlotte👸♥04:28, 16 July 2025 (UTC)
call for candidates phase - 1 hour, 30 minutes left
Latest comment: 1 month ago5 comments3 people in discussion
Hello friends. We've got about 1 hour 30 minutes left until the call for candidates phase closes at 0:00 UTC. I will probably be away from the computer, so anyone should feel free to close the call for candidates page at the appropriate time. Simply add an HTML comment to make the form disappear, and maybe a one sentence message that the call for candidates phase has ended. Oh, and also WP:PURGE the page so the automatic banner refreshes. The banner and the watchlist notice should turn themselves off automatically. Thanks. –Novem Linguae (talk) 22:32, 15 July 2025 (UTC)
I removed the banner (out of date after 23:59) (1, 2). Hope I didn't make your life harder. Glad we got more to vote over in the last few hours. BusterD (talk) 00:18, 16 July 2025 (UTC)
There was actually some magic in that banner that you removed that would have caused it to automatically update the wording after 0:00 UTC, so removing it wasn't necessary. (You may have needed to purge the cache to see it take effect.) In any case, I decided to make a rudimentary navigational bar {{Administrator elections navbar}} to replace the previous minimal {{ombox}} banner, and I've gone ahead and boldly installed it. I'm thinking we can add links to the candidate and discussion pages as well (similar to {{ACE2024}}), so that the election pages are easier to navigate. Mz7 (talk) 02:23, 16 July 2025 (UTC)
Thank you both. Just now I made a couple edits to the banner and pages transcluding the banner, and I think the new and improved one is looking pretty good :) –Novem Linguae (talk) 03:37, 16 July 2025 (UTC)
In a regular RFA, there's no deadline so I don't think there's any urgency to delete abandoned pages. For EFA, there's no point to the pages once the election deadlines are up. Should the pages then be deleted/moved/something else?
It's probably best to move them to a subcategory - Category:Wikipedia administrator elections July 2025 withdrawn candidates perhaps (treating anyone who did not transclude as withdrawing before the election started). As for the pages themselves, I suggest wrapping them in a closed template or similar that prominently notes the candidate "withdrew on <date>" or "withdrew before the election". As for A.FLOCK discuss it with them. Thryduulf (talk) 11:06, 16 July 2025 (UTC)
If the candidate never added their name to the ballot list they haven't "withdrawn". These are invalid or incomplete. — xaosfluxTalk12:59, 16 July 2025 (UTC)
I agree with Xaosflux: they were never candidates, and shouldn't be in a subcategory of the candidates. I suggest removing the category, and perhaps moving them to a subpage of the user's page. isaacl (talk) 16:59, 16 July 2025 (UTC)
I agree with Pppery that the candidate's software username (with the capitalized first letter) should be used in as many places as possible, for consistency. –Novem Linguae (talk) 01:48, 17 July 2025 (UTC)
To facilitate tooling, I think there should at least be a redirect from a page using the capitalization from the actual registered user name (which always has the initial letter uppercased at registration time). But to avoid confusion and clashes with other user names, I think I would only support cases where the first letter was lowercased. For example, I didn't realize that "charlotte" is Queen of Hearts, until by chance I looked at the wikitext source right now. isaacl (talk)
Administrator Elections | Discussion phase
Latest comment: 1 month ago1 comment1 person in discussion
On July 23, we will start the voting phase. The candidate subpages will close again to public questions and discussion, and everyone 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 totals during the election. You must be extended confirmed to vote.
Once voting concludes, we will begin the scrutineering phase, which will last approximately four days, or perhaps a little longer. Once everything is certified, the results will be posted on the results page (you may want to watchlist this page) 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 must also have received 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.
You are invited to join the discussion at Wikipedia:Village pump (technical) § Adding a SecurePoll namespace. –Novem Linguae (talk) 08:05, 19 June 2025 (UTC)
Resolved
make AELECT cats more specific: Category:Wikipedia administrator elections 2024 -> Category:Wikipedia administrator elections October 2024, Category:Wikipedia administrator elections 2025 -> Category:Wikipedia administrator elections July 2025. then fix all existing uses
