It looks as though the final technical changes to enable AELECT to run smoothly on English Wikipedia are moving forward and should be implemented soon. With that major task near-complete, it's time to think about scheduling our first non-trial elections. For simplicity's sake, we can wait out May to make sure everything is 100% ready, and aim for a June election. Proposed calendar:
June 3-10: Call for candidates, Tuesday to Tuesday to include a full weekend
June 11-15: Discussion phase, again including a full weekend
June 16-22: Voting phase, including a full weekend
June 23 to close - scrutineering and tallying, promote successful candidates.
With this schedule, we'd want to have a few election clerks volunteer in the first few days of June, though technically they wouldn't be needed until the voting phase begins on June 16th. Scrutineers could also be asked to volunteer ahead of time. Thoughts? —Ganesha811 (talk) 16:25, 2 May 2025 (UTC)[reply]
My only thought is that this would put the voting period for the following elections at the same time as the voting period for the ArbCom elections (based on it being similar to the 2024 dates). I think it would be ideal to avoid that until admin elections are more established to reduce potential confusion, etc. Moving it circa 2 weeks forwards or backwards would resolve this I think. Thryduulf (talk) 17:04, 2 May 2025 (UTC)[reply]
Personally, I'd rather adjust the dates for any election in November/December if desired, than the one happening five months earlier. The rotating through the year approach means that eventually the problem will be encountered again, so I think it's sufficient to be flexible for the dates of the actual election in conflict. (The arbitration committee election dates could shift, for all we know at this time.) isaacl (talk) 17:17, 2 May 2025 (UTC)[reply]
If the technical changes are resolved fairly promptly, we could have a May/June election that runs from May 20th to June 9th, which would enable a October/November election ahead of Arbcom elections this fall. We could also use the June 3-23rd dates and then hold the fall election October 20th-November 9th anyway. I don't think we need to be super strict on the 5-month period between elections (after all, each election takes a few weeks) as long as we're close. —Ganesha811 (talk) 17:21, 2 May 2025 (UTC)[reply]
For the technical reasons you discussed with Novem below, I recognize that a May 20th to June 9th admin election is definitely not happening, but I still want to oppose the first election after the renewal RfC running across two calendar months because it will spawn needless debate over whether the five-month timer is meant to go start-to-start or from the end of the prior election to the start of the next one. This upcoming election should be within a calendar month to set an expectation that the next one will occur in the fifth calendar month after. ViridianPenguin🐧 (💬) 00:27, 16 May 2025 (UTC)[reply]
A thought: if we design this election cycle to not conflict with the same month as ACE, it'll end up conflicting some time in the future because of the odd # of months. –Novem Linguae (talk) 19:13, 2 May 2025 (UTC)[reply]
Obviously, my thinking was just that it would be better to not conflict when AELECT is still a relatively new process. When it's established and routine, there should be fewer potential issues. If my maths is correct (and it might not be) if we delay this two weeks from the above suggested dates then the first clash will be the thirteenth election rather than the second and by that time any bugs in processes will likely have been ironed out, many unknown unknowns will have made themself known, we'll have experience of dealing with them and people will be familiar with both types of election. Thryduulf (talk) 19:25, 2 May 2025 (UTC)[reply]
Yes, that's what I said ("eventually the problem will be encountered again"). All I'm saying is we can defer worrying about this until the arbitration committee election RfC is over and the dates are known. There is enough flexibility in the administrator election process to allow for adjustments. isaacl (talk) 21:05, 2 May 2025 (UTC)[reply]
Election clerks will be needed before the start of the voting period in order to complete preparations and setup, particularly for the first time an election is run on the English Wikipedia server. Personally I think we'd want clerks and scrutineers in place before the call for candidates, and even the poll initially created (though not finalized for voting), so all resources are ready to run through the election process. isaacl (talk) 17:17, 2 May 2025 (UTC)[reply]
Whichever date we set, we could put out a request for election clerks and scrutineers say a week ahead of time. I agree it would be preferable to have volunteers and the poll in place ahead of the call for candidates, even if not strictly required. —Ganesha811 (talk) 18:27, 2 May 2025 (UTC)[reply]
Yes, it was more complicated then because it required the WMF to help set it up - in addition, because the suffrage requirements were complicated, a whitelist of eligible voters had to be manually generated and fed into SecurePoll. Neither should be true for future elections. —Ganesha811 (talk) 18:26, 2 May 2025 (UTC)[reply]
I would be in favor of doing some localhost and enwiki test elections. During that testing I will write a work instruction, and that will shorten the SecurePoll setup phase, but probably won't eliminate it. –Novem Linguae (talk) 19:14, 2 May 2025 (UTC)[reply]
I personally think this might be too early to schedule this. We do not have SecurePoll installed and working on en.wikipedia. Queuing up an election before we are 100% certain we can actually run it on that date is not a good idea, and puts undue pressure on us. We don't know if more software patches are required, and we haven't got a concrete decision on several key implementation details (eg. encryption) BugGhost🦗👻18:29, 2 May 2025 (UTC)[reply]
We certainly don't have to finalize any dates until those things have been taken care of, but it's good to start discussing it. From my understanding WMF has signed off and the technical changes will be implementable quite quickly. June is still a full month away. —Ganesha811 (talk) 19:10, 2 May 2025 (UTC)[reply]
True, but it's worth remembering that the last RFC about AELECT ended up taking nearly 2 months to run its course. I agree with Novem that a June election isn't completely unrealistic and hopefully we'll be able to get it all working by that point, I'm just worried that we have several unknowns to deal with before we can be certain. BugGhost🦗👻01:46, 3 May 2025 (UTC)[reply]
It might be a bit early to pick dates. I have a sequential todo list that is something like 1) deploy config patch, 2) create the 3 MediaWiki pages and update the 3 documentation pages mentioned in Wikipedia:Administrator elections/SecurePoll permissions proposal, 3) ask WT:AELECT who the electionclerk(s) should be, 4) do a test election on localhost wiki, 5) do a test election on enwiki, 6) recruit 3 scrutineer volunteers from among the CheckUsers. Once that is complete, I think that'd be a good time to set the exact dates for the next election (because at that point it will have no blockers remaining). I do think June is realistic but I am not sure we should commit to exact dates yet. Hope that makes sense. –Novem Linguae (talk) 19:11, 2 May 2025 (UTC)[reply]
phab:T378287 is probably blocked for another week on a security ticket. WMF is making good progress on the ticket and is on like step 4 of 5. The idea is they want to patch the security bugs before deploying SecurePoll more widely.
Revised estimate for next election is July or August. The gap in time is to allow some time for discussions of details, practicing with test polls, picking electionclerks and scrutineers, things like that. –Novem Linguae (talk) 01:01, 16 May 2025 (UTC)[reply]
Update: the security ticket is on step 5 of 5. Should be unblocked in a week or so, and then will need another week to deploy enwiki config changes. Once that's done, we won't be reliant on anything outside our control, and we can pick dates for the election. The election dates will probably be around 1-2 months out from the unblocked/ready date, to give plenty of time to prepare. –Novem Linguae (talk) 22:41, 26 May 2025 (UTC)[reply]
Nice! I know we've got more to do but this feels like a big step - good job to those involved for us to get to this point. BugGhost🦗👻18:07, 10 June 2025 (UTC)[reply]
Update: The next administrator election will very likely be in July. Let me do a test poll on my local computer, then a test poll on English Wikipedia using some volunteer test voters. I'll use that to write a work instruction for election clerks and gain confidence that we won't mess up the actual poll. Then once that's complete, let's set the dates. –Novem Linguae (talk) 00:14, 11 June 2025 (UTC)[reply]
What are our current thoughts on who the election clerk(s) for the next election should be?
As a reminder, these are the technical folks who set up the poll, hold the encryption key, configure the eligible voter criteria, things like that. This role is not able to see any confidential data like IP addresses (unless they are also a checkuser). The 3 scrutineers that we pick will also be de facto election clerks (they'll have access to everything an election clerk does) but I do not envision election clerking being the scrutineer's main role.
I'd like to propose myself as the next poll's election clerk. Happy to follow the community's lead though. If selected for this role, I plan to load up SecurePoll on my localhost wiki and set up a test election there, then write a thorough work instruction on how to do it. Then create an enwiki test election and have a couple volunteers vote, and refine the work instruction. Then do it for real the third time. Writing a good work instruction will help someone else be able to take over this role in the future, and practicing a couple times will make sure that the election clerk is experienced enough to avoid something like messing up an encryption key or a voter eligibility configuration during the real poll. –Novem Linguae (talk) 01:10, 16 May 2025 (UTC)[reply]
I believe the best way to handle this is by a simple notified discussion on this page. I believe it's best you are election clerk for this election, but will prefer a neutral discussion, just in case. Something as simple as "Who will election clerk for next election" and allow anyone to discuss options. And then crosspost the same/notify the same on WP:RFA and two three other pertinent venues.
Basically I'd like to dot all Ts and crossed all Is, even when I believe you're the best option for facilitating this election. Soni (talk) 05:25, 16 May 2025 (UTC)[reply]
While I am a bit hesitant to bother noticeboards about AELECT stuff yet again (I feel like I'm asking for their input on the small details of AELECT perhaps a little more than I should), there's been very little participation in this section, so we might have to. –Novem Linguae (talk) 17:43, 17 May 2025 (UTC)[reply]
The noticeboards see "There is a pertinent discussion at X place about Y" all the time. It doesn't have to be fancy or all over the place, as long as we inform the main places it would be fine Soni (talk) 19:01, 17 May 2025 (UTC)[reply]
Novem is a very good choice for being an election clerk for this election. I think we would need at least one more just for redundancy and to increase our bus factor a bit. BugGhost🦗👻07:05, 18 May 2025 (UTC)[reply]
Robertsky is an admin. By the way, what do we envision the second clerk doing exactly? Technically the second clerk is actually the 5th clerk because the scrutineers are also election clerks. –Novem Linguae (talk) 14:58, 20 May 2025 (UTC)[reply]
Mainly just for redundancy, for example having a copy of the encryption key in case the "primary" election clerk goes missing, and to double check config etc before the election goes live. I agree it's not the most essential role but at the moment having one person responsible for the setup is a single-point-of-failure. I'm happy with any of the scrutineers volunteering to act as an election clerk - I know they technically will have the user right either way, but I assumed scrutineers would be added to the poll after it was configured, and only carry out their roles after the ballot closed. (If people think having extra election clerks is unhelpful I'm happy to back down on this.) BugGhost🦗👻16:26, 20 May 2025 (UTC)[reply]
As I stated earlier, I think there should be at least one backup election clerk who is not a scrutineer with whom the encryption key is shared, so they can trigger a vote tally if necessary. isaacl (talk) 21:26, 20 May 2025 (UTC)[reply]
Sounds good to me. Sounds like through discussion this proposal has crystallized as me as lead election clerk and Robertsky as election clerk #2, and the idea is to share the encryption key between both of us. –Novem Linguae (talk) 00:37, 21 May 2025 (UTC)[reply]
I marked myself as the main election clerk and Robertsky as the backup election clerk for now. Diff. Thank you to everyone who volunteered. If something happens and more election clerk volunteers are needed, we will be sure to reach out to the folks that volunteered here. –Novem Linguae (talk) 22:29, 26 May 2025 (UTC)[reply]
It looks like our local page says that election clerks should only be added to administrators, however there appears to be one non-administrator in the list. — xaosfluxTalk18:54, 10 June 2025 (UTC)[reply]
I can attest to the fact that DreamRimmer was indeed involved in deploying the patch. While technically out of process, it is fine since to my understanding the right was only used to test if a admin was able to make a grant. (which was what the patch was for). Sohom (talk) 20:40, 10 June 2025 (UTC)[reply]
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)[reply]
: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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
@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)[reply]
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)[reply]
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)[reply]
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)[reply]
@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."
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
(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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
I'm a bit confused by this criterion: "not be sitewide blocked during the election". This sounds like any block, even if removed before voting but after the poll starts, or applied after voting but before the poll ends, will make the vote ineligible. Is that really the intention? Should it be, "not be sitewide blocked at the time of voting"? Can blocked users actually vote? -- zzuuzz(talk)23:40, 22 June 2025 (UTC)[reply]
From a technical control, it would be at the instance of voting. The larger question would be: If you are blocked after you vote (or even if you were blocked, then it expires), should your vote be striken? I think the technical control is sufficient alone. — xaosfluxTalk23:44, 22 June 2025 (UTC)[reply]
Sockpuppets aside, I've never heard of anything being struck simply because someone got blocked a few days either side of a thing (technically, self-requested blocks and rapidly-undone mistakes would also be caught up in this). I propose then that the wording is changed to what I said above. -- zzuuzz(talk)23:59, 22 June 2025 (UTC)[reply]
Arbcom elections use the wording "not currently sitewide blocked at the time of voting." Sockmasters who are not blocked can cast a vote, but if they cast a vote from more than one account then all of them are struck. No other blocks cause votes to be struck.
That works for me, thanks. Out of curiosity I'd like to just return to my original question - can blocked users actually (technically) vote? -- zzuuzz(talk)09:58, 23 June 2025 (UTC)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
@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)[reply]
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! ;-)
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
(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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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.
Nominations for the July 2025 administrator elections will open 00:00, 9 July 2025 (UTC).
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)[reply]
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)[reply]
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)[reply]
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)[reply]
OK, we've got about 3 and a half days to go. We're almost out of time. Are we ready for the call for candidates? Can someone please test signing up as a fake test candidate and make sure that the directions make sense, the templates are working, etc? Wikipedia:Administrator elections/July 2025/Candidates.
This is actually simpler than I remember it. I thought it'd be like RFA where candidates were creating subpages and subst-ing things. Now that I research this a bit more, I think that our team will create all the candidate subpages during the subsequent Housekeeping Phase. So this phase is super easy. Candidates just add themselves to the candidates page.
According to an HTML comment I just read, folks that withdraw during the candidates phase don't even need to be recorded. The "withdrawn" section is for folks that withdraw during the discussion or voting phase. So yeah, just remove yourself when you're ready. Thanks for testing. –Novem Linguae (talk) 13:56, 5 July 2025 (UTC)[reply]
Can we please get 2 admins to volunteer to be monitors? This role is basically the same as RFA monitors. Most of the monitoring will occur during the discussion phase (July 18–22), but there's a spot on the candidates page where we fill in your name, so I'm asking a bit early. Thanks. –Novem Linguae (talk) 13:24, 5 July 2025 (UTC)[reply]
French
Deutsch
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) 
Done. Thanks for the idea. –Novem Linguae (talk) 21:06, 25 June 2025 (UTC)
