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]
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]
Interesting. Maybe we should abandon the patch and close the ticket then? Also, maybe it's worth having 4 second load times if we get to keep the extra user links, so maybe we should put that back? –Novem Linguae (talk) 21:36, 7 July 2025 (UTC)[reply]
, which renders as $1(talk, contribs). I assume this would be quicker to render than the User-SecurePoll template, but I'm not a template expert (and I'm editing on a phone so difficult to test thoroughly) - apologies if I'm barking up the wrong tree here. BugGhost🦗👻07:44, 8 July 2025 (UTC)[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]
At this point I don't think there's a need to post the MMS schedule announcement lol, or at most maybe it could be bundled into the call for candidates. Aaron Liu (talk) 23:13, 8 July 2025 (UTC)[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.
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]
I was incorrect. There was a hidden <inputbox> that was commented out, and the candidates use that to create their subpages. Thank you for checking. –Novem Linguae (talk) 04:50, 9 July 2025 (UTC)[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]
Probably neither. I think this talk page post will probably recruit the two monitors without having to bother bigger noticeboards. If it doesn't recruit anyone in a few days, I'll ping the old monitors. –Novem Linguae (talk) 21:52, 5 July 2025 (UTC)[reply]
You're hired! You'll do just fine. Just keep an eye on the candidate pages during the discussion phase, and call out anyone that gets rude, and maybe refactor a bit if things get really disorganized. And there's still one more spot. Tell your friends :) –Novem Linguae (talk) 03:11, 6 July 2025 (UTC)[reply]
I've not done any monitoring either (well, not since primary school...), but if no one better qualified steps up to the plate, I can give it a bash. Feel free to consider me the last resort option, though. -- DoubleGrazing (talk) 19:12, 7 July 2025 (UTC)[reply]
sorry, I don't think I can commit to being available for all of those days specifically, but I'll be poking in if there's things I can do! theleekycauldron (talk • she/her) 23:17, 7 July 2025 (UTC)[reply]
It's been a while, but I have been a monitor for both Enwiki and global SecurePolls. Willing to help out if needed. Note, I'm also a CU so could help on that end if needed. Risker (talk) 00:00, 8 July 2025 (UTC)[reply]
Clarification question: In a normal RFA, the monitors cannot participate by voting. Does this hold true also for the election-style RFAs? I won't be withdrawing from the role either way (I rarely participate at RFA, although I frequently read them), but it should be noted that a regular RFA disenfranchises the monitor with respect to a single candidate, while an election RFA can disenfranchise the monitor from up to 30+ RFAs, and that seems a little unbalanced. I'm okay either way, but this lack of balance should be noted. Risker (talk) 00:38, 9 July 2025 (UTC)[reply]
Yes. The suffrage requirements for administrator elections are the same as those for the open viewpoint request for adminship process. isaacl (talk) 00:55, 9 July 2025 (UTC)[reply]
I think it'd be OK for the monitors, election clerks, scrutineers, and other election officials to vote. Unless a bunch of folks on this talk page object. Last election we had no restrictions on who could vote other than suffrage. –Novem Linguae (talk) 01:41, 9 July 2025 (UTC)[reply]
Sorry, I've reverted your bold change to the election page. In addition to the existing RfA suffrage rules for monitors, I think there's a conflict of interest with scrutineers voting. isaacl (talk) 03:21, 9 July 2025 (UTC)[reply]
I think there is a risk of perceived bias in how the scrutineers decide which votes to strike. That being said, upon further reflection, in practice I think there won't be many situations where the scrutineers would be able to deduce the selections made by the voters in question. isaacl (talk) 04:16, 9 July 2025 (UTC)[reply]
I'd suggest keeping my change since it was just describing the status quo. We didn't forbid any election officials from voting in the last AELECT. I think we would need a consensus to change the status quo and introduce a prohibition. (Although feel free to work towards that consensus in this section.) –Novem Linguae (talk) 03:45, 9 July 2025 (UTC)[reply]
Two relevant things have changed from the previous election: stewards from outside the English Wikipedia community were used to scrutinize the last election, and the community decided to adopt the RfA suffrage requirements. Thus there is a consensus in place to prohibit monitors from voting. By virtue of the previous election's scrutineers not being contributors to English Wikipedia, the status quo there is that scrutineers didn't vote. isaacl (talk) 04:03, 9 July 2025 (UTC)[reply]
I would say instead that there's no consensus on whether scrutineers should be allowed to vote in the situation you're thinking of. That said, you seem to be confusing scrutineers with monitors. Scrutineers are the CheckUsers who tally the results and monitors are the admins who check the discussion pages. We used local admins for monitoring the last election too. I don't see how using stewards to scrutineer reflects any precedent to prohibit monitors from voting. Aaron Liu (talk) 16:11, 9 July 2025 (UTC)[reply]
Please be assured that, having followed the development of the process from the start, that I am aware of the difference between scrutineers and monitors. Nor did I say that the use of stewards as scrutineers was a precedent with respect to monitors. isaacl (talk) 16:43, 9 July 2025 (UTC)[reply]
Sorry, I was confused by your concluding Thus there is a consensus in place to prohibit monitors from voting. I'm guessing you meant to type "scrutineers" instead of "monitors"? In that case I still wouldn't call it a consensus. Using stewards was just a circumstance that says nothing about what consensus there is within the community, especially when last time's scrutineers' disinterest doesn't necessarily translate into a prohibition on voting. I don't think we used stewards because they would be uninterested in voting. Aaron Liu (talk) 21:52, 9 July 2025 (UTC)[reply]
Please be assured that I meant what I wrote. In my view, the consensus to use the RfA suffrage rules includes the rule for monitors. (I understand the counterarguments being made, so there's no need to repeat any of them in response.) My comments on the status quo with respect to scrutineers was a separate comment about scrutineers, not about monitors. (Again, there's no need to repeat any of the counterarguments.) isaacl (talk) 22:01, 9 July 2025 (UTC)[reply]
I think its fine for monitors/anyone else involved to vote. We currently don't even have any rules implying candidates can't vote, let alone monitors. BugGhost🦗👻02:34, 9 July 2025 (UTC)[reply]
To be honest, I probably wouldn't have really considered voting. However, there are some definite, fundamental differences between the election of admins and the RFA process, and the expectations on users and admins participating in these processes should be able to reflect some of those differences. I don't think this is a question that needs to be determined on this particular election, but is definitely worth discussing afterward. For the record, scrutineers for global elections have not been formally proscribed from voting, although generally speaking they do not vote. Having acted in all three roles (election setup/commission/whatever, scrutineering, and monitoring), I can say that the roles are quite different; of the three, I think there is a good argument that scrutineering (i.e., the group that determines whose votes actually count) may logically be restricted, but the logic involved in restrictions on the other groups is pretty tentative. Risker (talk) 03:36, 9 July 2025 (UTC)[reply]
The AELECT sufferage RFC didn't mention monitors and so I don't think this is a fair conclusion to draw. From looking at the RFA review page you linked, the main argument for disallowing monitor !votes at RFA is to stop the appearance of bias - and at AELECT votes are private, and so this is not an issue here. BugGhost🦗👻05:05, 9 July 2025 (UTC)[reply]
Monitors can't weigh in with comments on candidate subpages but can vote in the SecurePoll. I think that's fair. Their !vote isn't going to change anything either. If anything forbidding their vote might incentivize a bit electioneer-screwing with the comments. Aaron Liu (talk) 16:08, 9 July 2025 (UTC)[reply]
WP:ELECTCOM is allowed to vote, and that's by far most analogous to the monitor position (dealing with discussion pages surrounding a SecurePoll vote). The "RfA suffrage requirements" wording was pretty clearly not intended to apply to this situation, I think. Extraordinary Writ (talk) 04:26, 9 July 2025 (UTC)[reply]
I, too, would like to restore NL's edit. Although the community decided to adopt the RfA suffrage rules for these elections, I'm pretty sure that most if not all editors were thinking in terms of the minimum requirements for being able to participate, and not in terms of the "fine print" about those officiating. I'm not seeing any potential for abuse or the appearance of conflict of interest that would be significant enough to worry me. --Tryptofish (talk) 21:24, 9 July 2025 (UTC)[reply]
I don't think that the scrutineers should be voting. They have privileged access to the election, and are able to remove other people's votes. That's one reason for arbcom elections we always pick scrutineers that are not involved in the community. I don't really have an opinion on the "monitors". On the fence for election administrators, leaning towards allow. — xaosfluxTalk02:02, 10 July 2025 (UTC)[reply]
Election administrators, as in election clerks (for this election, Novem Linguae) who set up the pages and poll, or monitors (Thadeus and Risker) who patrol the candidate discussion subpages for naughty comments? The former should definitely be allowed to vote as I see little methods they can realistically influence the election's outcome. Aaron Liu (talk) 17:53, 10 July 2025 (UTC)[reply]
Honestly I don't get why scrutineers shouldn't vote. What's the downside, what's the fear? I could understand that a candidate can't be a scrutineer. I'd also understand if a candidate can't vote. Those are conflicts of interest. But what are we worried about if a scrutineer could vote? I don't see the downside. Leijurv (talk) 09:56, 10 July 2025 (UTC)[reply]
@Leijurv this will likely always be a multi-party, non-competitive election. Why would you think that running for admin should prohibit them from having an opinion on the other candidates? We could presume that candidates will vote for themselves, and change the passing calculation to ( (S-1) / (S+O) ) if the concern is about voting for themselves. — xaosfluxTalk14:45, 10 July 2025 (UTC)[reply]
Voters have declared an interest in the outcome. Scutineers are empowered to remove votes of others, which will also impact the outcome. — xaosfluxTalk14:49, 10 July 2025 (UTC)[reply]
To clarify, I think candidates should be allowed to vote, I was just saying I'd understand the line of argument against that. I do actually think candidates should never be scrutineers but that's a totally implausible scenario of course. Upon rereading, my message was confusing, sorry.
I think people are scared of scrutineers removing too many votes or distorting the vote counts to favor their preferred candidates. (Though besides what I said above, I think it's unlikely that the three scrutineers all have the same opinions on candidates and are willing to do such things.) Aaron Liu (talk) 17:55, 10 July 2025 (UTC)[reply]
Okay, fine. Scrutineers have to act impartial while scrutineering. If you allow them to vote, then they would probably form opinions on which candidates they prefer, perhaps they would even notice which other users prefer the same candidates. Perhaps they now have at the back of their mind which voters they agreed with more or agreed with less. Perhaps now they'll be more likely to accept / reject said votes. I feel as though this is a bit convoluted and unclear though, because allowing them to vote doesn't directly allow any misbehavior. The misbehavior of favoring a particular set of voters is possible regardless. I feel a bit torn because of how far removed this is from actual impropriety. Hm. But at the end of the day, xaosflux you are right that the work they do is in secret, and it helps decide who becomes a sysop, therefore the degree of trust is extreme. Therefore, even the slightest hint that they aren't impartial must be avoided. Even if the hint is just that they have read the candidate pages and formed an opinion on them. Tentatively I agree that scrutineers ideally shouldn't vote. Leijurv (talk) 18:16, 10 July 2025 (UTC)[reply]
Perhaps we can get to a consensus that scrutineers cannot vote (I'm personally not worried about that, but I'm looking for a consensus), but that monitors and all the other election officials may vote. Does that work? --Tryptofish (talk) 22:48, 10 July 2025 (UTC)[reply]
I think the others are at least OK, the work they do is in the open and if they were to do something outrageous (e.g. electionadmin starts tampering with the electoral roll, refuses to resolve roll errors, etc; monitors are inappropriately disrupting discussions, etc. ) - the community could swiftly deal with it. — xaosfluxTalk13:22, 11 July 2025 (UTC)[reply]
For purposes of keeping track of what we are discussion, here is the revert that is being discussed: [1]. What I'm suggesting is putting that back onto the election page, but without "scrutineers". Thus: Monitors and election clerks are permitted to vote. Is that OK? I recognize that there is new discussion in the comments immediately below, that includes the issue of the optics of voter guides and other public statements, but I'd prefer to treat that separately. --Tryptofish (talk) 19:56, 11 July 2025 (UTC)[reply]
Having thought about this a bit more, I think the fact that the voting is secret eliminates all issues with voting in the election for election officials. This is probably why election officials in real life are also allowed to vote. So I think all election officials should be allowed to vote. I do think the monitors specifically should avoid any public statements about what they think of the candidates though, including not doing voter guides. The monitors are the folks that might have to use subjective judgment and block someone on the discussion pages, and it would be bad for folks to think "oh, X monitor supports Y candidate, which is why they blocked Z opposition". So I would support a rule that monitors may not state any public opinions about the candidates and candidacies, and probably not even ask the candidates official questions on the discussion pages. I think this is less of an issue for scrutineers, who will be doing their vote striking and blocking based on more objective criteria (i.e. is there technical data here that they are a sock?), and zero issue for election clerks. –Novem Linguae (talk) 05:18, 11 July 2025 (UTC)[reply]
I agree, except that for optics, it might be better if none of the officials created voter guides or expressed their voting preferences. In case of some of them this may not matter, but although you know that, not every voter necessarily does. -- DoubleGrazing (talk) 05:45, 11 July 2025 (UTC)[reply]
I have the same view as NL, that secret voting makes this different from traditional RfA, and reduces the concern about abuse, but I also don't think we are going to get consensus to allow scrutineers to vote (but you can prove me wrong). I think it's easy to agree that none of the election officials should be making public statements about supporting or opposing candidates, especially including voter guides, but I also think that's such a no-brainer that we don't necessarily need to make it policy. --Tryptofish (talk) 20:01, 11 July 2025 (UTC)[reply]
I am a backup scrutineer in this election and want to figure out if I should invest time into learning about the candidates or not. I do agree that we're not going to get consensus to allow scrutineers to vote but it's also not clear to me that it will be possible to get consensus scrutineers can't vote nor is it clear to me what the position is if there's no consensus - which is how I read this discussion. I think the closest parallels are ACE and the various elections Stewards can vote in and scrutineer. Personally I think ACE Electcom people have more power to swing an election than scrutineers - they can, for instance, declare someone completely ineligible to run or last dramatically permit a borderline question that harms a candidate. I won't plan to vote in this election - time I can spend doing other things - but I do think trying to figure this out matters. BEst, Barkeep49 (talk) 21:35, 11 July 2025 (UTC)[reply]
I admit I'm confused by the idea that scrutineers can't vote because they might screw with things. The three of them together would have to mutually agree on anything shady, wouldn't they? Isn't that surety enough? -- asilvering (talk) 21:52, 11 July 2025 (UTC)[reply]
I don't think it's explicit manipulation, but more at the margin that they would make a decision to remove someone who didn't vote the way they wanted. The recent u4c election showed even single votes can matter (where if 1 oppose had been a support someone else would have been elected). In a large field like this it does become harder for me to understand how manipulation would truly work because the scrutineers would all have to be inclined to so support or so oppose some person (whose vote they also know) that they'd be willing to throw out all the other accompanying votes. Best, Barkeep49 (talk) 22:28, 11 July 2025 (UTC)[reply]
I agree with Barkeep49 that the perceived risk is more of unconscious bias. However since the scrutineers don't know how people voted, they would only be able to make suppositions from any public statements made by voters. I imagine that the intersection of voters whose votes could be surmised and voters who are at risk of appearing to be a sock puppet will be small. I think monitors have an opportunity to influence voters through their choices in moderating discussions, but I appreciate the viewpoint that this risk can be managed. isaacl (talk) 04:58, 12 July 2025 (UTC)[reply]
The only opportunity to sway the direction of votes would be when someone declares they have voted in a certain manner and then the scrutineers strike the entry out on that basis. But coming from what people see as an authoritarian country with an actually free election, I would say that people do say one thing and do another in secret, ie support the incumbent in the public but vote for the opposition behind the secret booths and vice versa. So personally I wouldnt take much stock in the declarations when scrutinizing. While exploring the backend tool, unless I am mistaken, there's no way to know which way people vote, and I suppose strikes would be mostly based on technicalities more than anything else. – robertsky (talk) 05:22, 12 July 2025 (UTC)[reply]
The administrator elections process has officially started! Interested editors are encouraged to self-nominate or arrange to be nominated by reviewing the instructions at Wikipedia:Administrator elections/July 2025/Candidates.
Here is the schedule:
July 9–15 - Call for candidates
July 18–22 - Discussion phase
July 23–29 - SecurePoll voting phase
Please note the following:
The requirements to run are identical to RFA—a prospective candidate must be extended confirmed.
The process will have a seven day call for candidates phase, a two day pause, a five day discussion phase, and a seven day private vote using SecurePoll. Discussion and questions are only allowed on the candidate pages during the discussion phase.
The outcome of this process is identical to making a request for adminship. There is no official difference between an administrator appointed through RFA versus administrator elections.
Ask any questions about the process at the talk page. A separate user talk message will be sent to official candidates with additional information about the process.
If you are interested in the process, please make sure to watchlist the appropriate pages. A watchlist notice will be added when the discussion phase opens, and again when the voting phase opens.
You're receiving this message because you signed up for the mailing list. To opt-out of future mailings, please remove yourself from the list.
Correct. No discussion until the discussion phase. Thanks for spotting. I went ahead and reverted, with a polite message and ping to the folks involved.
Someone already tried creating their nomination page at Wikipedia:Administrator elections/July 2025/Candidates/YOUR USERNAME HERE. I moved it to the correct location and salted the page, but we should probably add salting that title to the pre-election checklist. I also modified the inputbox to use |prefix= and |placeholder= instead of |default=, which makes it so that potential candidates actually have to type in their username. --Ahecht (TALK PAGE)12:19, 9 July 2025 (UTC)[reply]
Now that you took out the default, I don't think this will happen anymore. Should be OK to leave salting off the checklist. Thanks for improving this. –Novem Linguae (talk) 20:42, 9 July 2025 (UTC)[reply]
The current watchlist notice says Editors are invited to submit a candidacy for adminship in the second English Wikipedia administrator elections. The sign up period ends at 23:59 UTC on 15 July 2025, and will be followed by a discussion phase and a voting phase. To me, this implies that any editor is encouraged to do so, and that this is telling editors in the 500–5000 edit range that they're going to get a warm welcome, setting them up for disappointment. Thebiguglyalien (talk) 🛸17:47, 10 July 2025 (UTC)[reply]
All right, but I'm going to say "I told you so" when people who are obviously (to us) below community expectations nominate themselves and then get embarrassed when they're told no. Thebiguglyalien (talk) 🛸18:51, 10 July 2025 (UTC)[reply]
We currently have had 9 people put themselves forward. Of those, 1 is already blocked, 1 has 18 edits, 1 has 600 edits and the last (though having made a promising start) has 3k edits. The first three are blatantly not going to succeed and the last one is a very clear WP:NOTNOW. The major criticism of the first trial run was that we had too many candidates. Making it sound like anyone can run is setting many people up for failure and ourselves up for an even more bloated candidate list than first time round. That should be addressed. Valenciano (talk) 19:09, 10 July 2025 (UTC)[reply]
I'm surprised there isn't a relevant edit filter for either RfA or ADE. It's so surprising there's probably a reason for it. Aaron Liu (talk) 00:45, 11 July 2025 (UTC)[reply]
Edit filters are "expensive" - they have to check at least a couple of conditions for every single edit made on the project; so we don't use them for very niche things like a backstage page. Besides what would we stop here? We are already preventing non ECP editors from entering the election - that they could create a candidate page they can't use isn't very disruptive to the project as a whole. — xaosfluxTalk01:17, 11 July 2025 (UTC)[reply]
No - the candidates who are WP:XC should be allowed to stand if they sign up. Whether they should have signed up is a different question, but deleting valid candidate pages based on predictions of the outcome should not happen. BugGhost🦗👻02:24, 11 July 2025 (UTC)[reply]
Personally I think we should pull this watchlist message entirely. The largest criticism from the trial election was that there were too many candidates - broadcasting sign ups to editors who haven't seriously considered candidacy is not helpful. We will get more than enough decent candidates without advertising. BugGhost🦗👻02:19, 11 July 2025 (UTC)[reply]
At the time the first elections happened I was completely unaware of them until a month afterwards. Admittedly I was on a downswing in activity, but I checked my watchlist often enough I would've noticed. I had been (not very seriously) considering RfAing at the time and may have ran had I noticed. I suspect there were enough people in my position to make a watchlist entry worthwhile, though I strongly support adding "experienced" to the notice and any other measures to discourage clearly unqualified candidates from running. Rusalkii (talk) 04:13, 11 July 2025 (UTC)[reply]
The RFCs we ran had a consensus against any cap on the number of candidates, so I think we should be careful extrapolating "too many candidates ran last time, so we should take measures to reduce the number of candidates" from that. –Novem Linguae (talk) 05:12, 11 July 2025 (UTC)[reply]
(Sorry if this is covered somewhere, lazy as I am it's easier to ask than to research.) Not entirely hypothetically, if a candidate signs up who is technically eligible to run but has practically no chance of getting through, what, if anything, should we do? In an RfA that could be closed per SNOW, but a) this isn't RfA, and b) in any case SNOW close happens (always? usually?) once the discussion is underway, which this isn't yet. I'm not suggesting we should be removing anyone from the contest against their will, but is it appropriate to try to persuade them to withdraw? Unlikely as it may be, we probably want to avoid a situation where a large number of SNOW candidates sign up, possibly affecting the process adversely. -- DoubleGrazing (talk) 13:10, 11 July 2025 (UTC)[reply]
SNOW happens when votes pile up against something quickly - in the election you can't tell the votes until it is over, so it doesn't really apply. WP:NOTNOW could be, and perhaps if you think a candidate is too soon you could ask them specifically about that during the question period - they may agree and withdraw. — xaosfluxTalk13:16, 11 July 2025 (UTC)[reply]
Yeah, you're right, NOTNOW is what I should have said (this heat is melting my brain, or some other pathetic excuse like that!). Okay, so no need to do anything at this stage, then. -- DoubleGrazing (talk) 13:20, 11 July 2025 (UTC)[reply]
I think it's best to contact people as soon as you notice, so ideally in this phase. It fairer to the candidate to get clarity immediately and not spend time polishing a nomination. It's also better for the process to be less overwhelmed. One thing I always do is suggest a more appropriate alternative for the potential candidate (such as CVUA, writing a GA, getting a specific perm etc). —Femke 🐦 (talk) 16:12, 11 July 2025 (UTC)[reply]
I think given that this is an election, any candidate who meets the requirements may stand for election and we don’t force them out of the process.
That being said, I do also think though that if a candidate realizes during the discussion phase that their election candidacy doesn’t appear to have support due to users concerns, they are encouraged to withdraw their nomination and potential seek candidacy in the future if the concerns raised were addressed.
So I don’t think we should force closure necessarily, but candidates should use their good judgement in the interest of the communities time that if it appears obvious from the discussion that their candidacy likely has no success at that moment in time, that they should withdraw to help the community either not having to read through as many candidacy pages as are necessary. Raladic (talk) 18:54, 11 July 2025 (UTC)[reply]
What do see as the advantage of waiting until the discussion phase before raising this with the candidates? Either for the candidate or for the community? —Femke 🐦 (talk) 19:01, 11 July 2025 (UTC)[reply]
I'm not saying it has to happen during the discussion phase, if you see a candidate and feel like there's a reason that you want to bring up with them beforehand, you could do so at their user talk page and they can withdraw from the election at any point.
But at the same time, this is a semi-democratic process, so I don't think we should prematurely force a candidate out until they've had a chance to address whatever concern users have brought up. Whether that's in a direct message on their talk page, or during the discussion phase, either would be fine.
I will maybe partially walk back half a meter and say that if after the discussion phase it truly does look like there's a SNOW chance and the candidate hasn't already withdrawn on their own accord, that maybe we want to codify a process to urge them to so, so that less candidate pages have to be reviewed by voters.
But I would hope that people that put their hat in the ring for adminship and thusly should have reasonable good judgement. I could definitely see the fact of not withdrawing in the face of certain failure by itself could be telling and would likely not only cost community time for the current election, it likely also would hamper future candidacy chances as it would show poor judgement on a candidate's part. Just to be clear though, I don't think candidates should withdraw in throves if it could go either way, just that some cases may be pretty clear from the discussion/candidacy and in such cases, I'm hoping candidates have this insight in that moment of time.
I'd say the only time the community may reasonably "force" close of a candidacy is if it's blatant time waste, but hopefully that just doesn't happen (don't think such a case happened last election as far as I could recall and that was the first one with lots of uncertainty at that..).
that maybe we want to codify a process to urge them to so, so that less candidate pages have to be reviewed by voters. We have a process for that. It's called "Only editors with EC may become admins". If you want a higher threshold than that, let's have a higher threshold. I just disagree with the notion that the community can force candidates to step down unwillingly without formal voting.
And it's not like it's a massive timewaste anyway, all it forces is a few extra seconds of everyone's time, and lengthier voting guides. Not ideal, but not the end of the world. Far less important than "Are competent editors interested in standing for adminship now", in my opinion Soni (talk) 05:42, 12 July 2025 (UTC)[reply]
Is there a way to catch these before new editors waste their time putting together a statement when they cannot run? That seems like it would be a frustrating experience. Rjjiii (talk) 14:31, 11 July 2025 (UTC)[reply]
So the workflow is: Go to the election page, see the guidance, scroll down and use the form maker to start a page, get a warning banner about exactly this, ignore all this and continue anyway. At that point I'm not sure what else to say? Perhaps they just want to play around. — xaosfluxTalk14:49, 11 July 2025 (UTC)[reply]
Eh, it is kinda tiny overall compared to the editing window and to other warning banners. Maybe increasing the size of either the image or the text would make it more discouraging. --Super Goku V (talk) 15:08, 11 July 2025 (UTC)[reply]
I can't see the example as I am edit confirmed, but I was able to just copy the code of the template and view it with previews in my userspace after a modification. Thank you for also considering to increase the non-bolded text as well as that is a good idea. --Super Goku V (talk) 15:26, 11 July 2025 (UTC)[reply]
No easy way actually. @Novem Linguae is gonna knock me silly for suggesting this :P, but an edit filter may prevent direct page creation. However, nothing will prevent them from moving from a userpage to a candidancy subpage. – robertsky (talk) 14:46, 11 July 2025 (UTC)[reply]
Wrapping the form in <spanclass="extendedconfirmed-show sysop-show">...</span> may help, but do we actually have a rule against a non-XC editor nominating someone else? --Ahecht (TALK PAGE)05:49, 12 July 2025 (UTC)[reply]
Much of that has been incorporated into this main page, and we could bring anything more that may require a mention. (Maybe a "History" section"?) I simply find it non-standard to give such prominence to one particular edition of the election. —CX Zoom[he/him](let's talk • {C•X})22:32, 11 July 2025 (UTC)[reply]
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)
Resolved
