Wikipedia talk:Administrator elections/Archive 6

Archive 1

←

Archive 4

Archive 5

Archive 6

Dates

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)

Yep – I believe that gap only existed for technical reasons and is no longer necessary. Toadspike [Talk] 17:06, 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)

Awesome, thank you Novem! Toadspike [Talk] 11:45, 17 June 2025 (UTC)

Localhost testing and creating the work instruction

Work on the election clerk work instruction and localhost test polls has begun. Folks can follow along at Wikipedia:Administrator elections/July 2025/SecurePoll setup. –Novem Linguae (talk) 19:44, 19 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.

Next step will be to hold an enwiki test election. Will give that some more thought then post details soon. –Novem Linguae (talk) 22:57, 20 June 2025 (UTC)

Could scrutineers enforce the remaining parts of XCON (30 days, XCON not revoked)? Toadspike [Talk] 23:15, 20 June 2025 (UTC)

@Novem Linguae Could you try setting the edits to a 0/null value (or a impossibly high number) and then using the include users in X group field ? Sohom (talk) 23:21, 20 June 2025 (UTC)

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). — xaosflux ^Talk 23: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. — xaosflux ^Talk 23: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). — xaosflux ^Talk 23: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 ...

SELECT DISTINCT REPLACE(log_title, '_', ' ') AS promoted_to_admin
::::FROM logging
::::WHERE log_type = 'rights'
::::    AND log_action = 'rights'
::::    AND log_params LIKE '%sysop%'
::::ORDER BY log_title ASC;

... 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. —Cryptic 07:31, 23 June 2025 (UTC)

Side note: EC can be revoked (which should remove suffrage). — xaosflux ^Talk 23:52, 22 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. —Cryptic 23: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. — xaosflux ^Talk 00:44, 23 June 2025 (UTC)

Election admins can manually add someone missing during the election if needed. — xaosflux ^Talk 00:49, 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)

We can temporarily customise MediaWiki:Securepoll-too-few-edits to get rid of that message and instead link to the eligibility criteria. And yes, extendedconfirmed is not an implicit group. – SD0001 (talk) 15:38, 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)

@SD0001 Even when must not be sitewide blocked = true is set ? Oh god. Sohom (talk) 16:26, 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)

Thanks for the quick work – it's appreciated! isaacl (talk) 21:29, 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. —Cryptic 05: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)

Note, for the upload, format the names as USERNAME@enwiki — xaosflux ^Talk 10:31, 23 June 2025 (UTC)

(since this is a local election) — xaosflux ^Talk 10:32, 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. — xaosflux ^Talk 10: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)

Sounds good. Will go back to the simple query without former admins then: quarry:query/94828. –Novem Linguae (talk) 18:02, 23 June 2025 (UTC)

If they never had EC, it will be autogranted on their next edit. — xaosflux ^Talk 18:54, 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. — xaosflux ^Talk 20:29, 23 June 2025 (UTC)

Copying subpages

Can someone help me? Would love for someone to go through the subpages of the last election (Wikipedia:Administrator_elections/October_2024/Subpages) and copy them all over to the July election. For example, copy paste Wikipedia:Administrator elections/October 2024/MMS/Call for candidates to Wikipedia:Administrator elections/July 2025/MMS/Call for candidates, with the appropriate WP:CWW edit summary ("copied content from X, please see that page's history for attribution"). –Novem Linguae (talk) 09:28, 25 June 2025 (UTC)

All done! Wikipedia:Administrator elections/July 2025/Subpages – DreamRimmer ■ 11:45, 25 June 2025 (UTC)

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)

Discussion at Wikipedia:Village pump (technical) § Adding a SecurePoll namespace

 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)

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

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)

I assumed that's how we would handle backup scrutineering in the first place. I agree Soni (talk) 08:19, 29 June 2025 (UTC)

LFG then. CNC (talk) 16:19, 29 June 2025 (UTC)

Voter eligibility: extended confirmed?

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)

I believe the requirement is being extended confirmed. Thryduulf (talk) 20:11, 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)

I've removed the extraneous extra text. RoySmith (talk) 20:29, 29 June 2025 (UTC)

Scrutineering the test election

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...

• sort by IP address column
• investigate any duplicate IP addresses using checkuser tools such as Special:CheckUser or Special:Investigate
• 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.

Thanks a lot. Looking forward to your feedback. –Novem Linguae (talk) 01:08, 29 June 2025 (UTC)

Is the intent that who voted is public information? If I go to https://en.wikipedia.org/w/index.php?title=Special:SecurePoll/list/821 in an incognito window, I can see for example:

27 June 2025   RoySmith (talk · contribs · block log · email)
27 June 2025   RoySmith (talk · contribs · block log · email)

RoySmith (talk) 01:21, 29 June 2025 (UTC)

That is intentional. HouseBlaster (talk • he/they) 01:27, 29 June 2025 (UTC)

There's an option to turn off displaying the voter list, but it defaults to on, and it was on in the last election. https://vote.wikimedia.org/wiki/Special:SecurePoll/list/1691. Would be happy to discuss a proposal to hide voters/usernames in a different section if people are interested. –Novem Linguae (talk) 01:40, 29 June 2025 (UTC)

It doesn't seem like I can sort by the IP address column for some reason? dbeef [talk] 02:46, 29 June 2025 (UTC)

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)

Great feedback. Thank you. I've created Wikipedia:Administrator elections/July 2025/SecurePoll setup#Instructions for scrutineers and will continue incorporating tips posted here. –Novem Linguae (talk) 08:56, 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)

I've added:

a[href*="Special:SecurePoll/archive"] { display: none; }

to my common.css which makes the link invisible so I can't click it by accident. RoySmith (talk) 12:02, 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)

Getting scruted sounds painful. (Sorry, now I'll scrute off.) --Tryptofish (talk) 21:38, 30 June 2025 (UTC)

It sounds like something that would happen in Joe's Garage. RoySmith (talk) 22:06, 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! ;-)

Anyway, on to tallying. Back in a bit. –Novem Linguae (talk) 22:06, 30 June 2025 (UTC)

Updating the subpages

Hello friends. I've finalized the schedule. We will begin the call for candidates in 10 days. The schedule is up at Wikipedia:Administrator elections/July 2025#Schedule. If somebody can go through all the subpages at Wikipedia:Administrator elections/July 2025/Subpages and insert the schedule where needed and double check anything else that needs updating, that'd be great. –Novem Linguae (talk) 10:22, 1 July 2025 (UTC)

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.

Separately, please check I got the Wikipedia:Administrator elections/July 2025/Candidate subpage template changes correct.

I also made some minor changes to the Wikipedia:Administrator elections/July 2025/MMS/Candidate instructions, please review. Thryduulf (talk) 11:23, 1 July 2025 (UTC)

@Thryduulf On the Candidate subpage template, do we want to differentiate between a self nomination and a third-party nomination? I modified the template so that there is a self-nomination parameter that also hides the "Candidate, please indicate acceptance of the nomination here:" line. Easiest way would be two have two different preload pages, one for "Nominate yourself" that would use Wikipedia:Administrator elections/July 2025/Candidate subpage preload self and one for "Nominate someone else" that would use Wikipedia:Administrator elections/July 2025/Candidate subpage preload other. --Ahecht (TALK
PAGE) 02:28, 2 July 2025 (UTC)

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)

{{Arbitration Committee candidate/data}} is where the dates (and other info related to SecurePoll) are stored centrally for the arbitration committee elections. A similar template can be used for the administrator elections. isaacl (talk) 04:00, 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)

Well, I see now that {{Administrator elections status/data}} already exists. I've changed {{Administrator election schedule}} to use it. The keywords supported by the schedule template are mapped to the ones supported by {{Administrator elections status/data}}. isaacl (talk) 01:46, 4 July 2025 (UTC)

I've added support for a list value. For example, {{Administrator election schedule|July 2025|list}} produces the following:

• Call for candidates: Wednesday 00:00, 09 July 2025 – Tuesday 23:59, 15 July 2025
• Housekeeping phase: Wednesday 00:00, 16 July 2025 – Thursday 23:59, 17 July 2025
• Discussion phase: Friday 00:00, 18 July 2025 – Tuesday 23:59, 22 July 2025
• Voting phase: Wednesday 00:00, 23 July 2025 – Tuesday 23:59, 29 July 2025
• Scrutineering: Wednesday 00:00, 30 July 2025 – around Saturday 23:59, 02 August 2025
• Results

isaacl (talk) 15:34, 5 July 2025 (UTC)

That's a wonderful template! Two minor things:

1. 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.
2. elections or election? I personally prefer elections for consistency with Wikipedia:Administrator elections/July 2025.

Aaron Liu (talk) 15:49, 5 July 2025 (UTC)

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)