Wikipedia talk:Administrator elections/SecurePoll permissions proposal

Second draft

Moved from Wikipedia talk:Administrator elections § Second draft

 – –Novem Linguae (talk) 17:54, 23 April 2025 (UTC)

Alright. I've made a bunch of changes based on the comments above. How's Wikipedia:Administrator elections/SecurePoll permissions proposal look? –Novem Linguae (talk) 17:53, 22 April 2025 (UTC)

I made a slight tweak to the first bullet in the technical changes section to try and make it easier to understand. The bullet re checkusers could do with simplified wording too I think but I haven't yet come up with something better. On the substance of the proposal though that looks good. Thryduulf (talk) 18:14, 22 April 2025 (UTC)

I expanded the Background slightly, but overall it looks solid. When sharing it, I would recommend linking people to a discussion on the talk page for it asking for any tweaks or modifications. Consensus will come naturally as any concerns are addressed. This is, in the end, a proposal required to technically implement the result of 3 major, successful RfCs, and does not need separate authorization from the community, just buy-in from those who will be involved. —Ganesha811 (talk) 18:51, 22 April 2025 (UTC)

Looks good! One thing I would like to ask is are we working under the assumption that electionadmin is a subset of admin? There's some comparison to edit filter managers above, which don't require member to be an admin. If electionadmins aren't required to be regular admins, then the name "electionadmin" may cause confusion. I assume it's a subset, but just wanted to check we're all on the same page here. BugGhost 🦗👻 20:11, 22 April 2025 (UTC)

"Election administrator" is what it's called on other WMF wikis such as votewiki, so I think we should keep the terminology consistent.

That's a good point though. Should there be a procedural requirement that election administrators be administrators? We should probably specify this. For now, I went ahead and edited the proposal to specify that non-administrators can be election administrators. However I am happy to flip it if folks want. I also added some wording to emphasize that this perm is for folks working on AELECT or ACE, and isn't intended to be handed out like candy. –Novem Linguae (talk) 21:07, 22 April 2025 (UTC)

There's nothing "adminy" about what election administrators are going to be doing, but somewhat echoing the comments made back in the two int-admin RFCs, AELECT and ACE are pretty important processes that should be operated by trusted editors, and admins are already vetted by the community in this regard which makes things more convenient (admittedly ELECTCOM doesn't have adminship as a criteria, but they go through an additional vetting process; are we going to do the same? The draft is a bit ambiguous on this).

Also, to what extent can securepoll be edited after the election has begun? Because if it can be significantly altered during an election then we absolutely want trusted folks as election administrators and have them enable 2FA. A mischievous editor or compromised account messing things up during setup would be annoying, but breaking the election while it's running would be disastrous. Liu1126 (talk) 23:22, 22 April 2025 (UTC)

I agree that the ability to unlock and report election results should be held by a trusted editor. I don't think that the arbitration committee electoral commissioner role is a good parallel, though. The commissioners aren't election admins for the SecurePoll vote (and by design they aren't required to be involved in the process at all, outside of their formal scope of making certain decisions as necessary), and the selection process is very lightweight (for example, only supporting statements are collected). isaacl (talk) 04:43, 23 April 2025 (UTC)

Also, to what extent can securepoll be edited after the election has begun? Important question, yes. Could you rename the candidates near the end of the election so that votes for one candidate appear to be votes for another? Leijurv (talk) 06:23, 23 April 2025 (UTC)

Also, to what extent can securepoll be edited after the election has begun? I tested it just now, and on the edit poll screen (which has things like poll questions and answers, start time, end time, poll name, poll type, and encryption), once the election start date occurs and the election is running, almost the entire edit poll screen becomes disabled, except for the "Return-to URL" and "Admins" fields. So I think the SecurePoll software engineers took these security concerns into account when designing it.

Could you rename the candidates near the end of the election so that votes for one candidate appear to be votes for another? Looks like this cannot be done. –Novem Linguae (talk) 06:48, 23 April 2025 (UTC)

Good to know. I guess there's still a chance that an electadmin might mess up the configs immediately before the election begins (out of error or malice), but if other electadmins check the settings just after the election begins then the current poll can just be quickly scrapped and no major damage will be done (as opposed to breaking changes late in the election that would require the whole election to be rerun, which thankfully isn't possible as Novem explained above).

I've thought a bit more on the level of trust needed for electadmin. Since AELECT and ACE are meant to be primarily run by community volunteers (plus ELECTCOM for ACE), electadmins are just going to be an arm of the community that mechanically implements community decisions. The level of trust and experience needed is going to be lower than admins (who may carry out unilateral actions like blocking or granting permissions) or int-admins and EFMs (who could break vast swathes of the site with their actions). They won't see any private information since securepoll-view-voter-pii is only given to checkusers. Maybe a lower requirement like extended confirmed? Further vetting can be done by the crats and, if necessary, a brief comment process like the one used for int-admin.

The worst thing a "rogue" electadmin could probably do is publish the results too early, like during scrutineering or even halfway through the election (assuming that tallying can be done while the poll is running). The latter case could unduly influence the votes of later voters. Though if XCON editors are trusted to keep cool in the most heated contentious topics (i.e. under ECR), then they should be trustworthy enough to follow a simple directive of "don't publish results until scrutineering is done". Liu1126 (talk) 12:43, 23 April 2025 (UTC)

or even halfway through the election (assuming that tallying can be done while the poll is running). The latter case could unduly influence the votes of later voters. I tested it just now and the tally page doesn't work until after the poll concludes. –Novem Linguae (talk) 17:51, 23 April 2025 (UTC)

Personally, I'm not sure "lower" is the right comparison for the level of trust. I think the scope of where trust is required is narrower. As I recall, when the extended-confirmed privilege was created, there was some concern that it would become a criterion used more out of convenience than because it was tailored for the specific needs of a situation. I think the proposed lightweight process (which is similar to the one for interface admins) seems sufficient. I have a theoretical concern about expanding the bureaucrat role in this way, as it crosses the boundary between deciding the outcome of a request for administrative privileges and managing the process. In practice, I guess it's just a small step over the line. isaacl (talk) 18:05, 23 April 2025 (UTC)

Yea, I suppose using XCON as a criterion isn't necessarily more suitable for this situation than adminship; best to leave it to the crats' discretion then (I highly doubt a new editor would be in a position to request electionadmin anyway, so even if implemented it would be no more than a pro forma requirement). Liu1126 (talk) 18:44, 23 April 2025 (UTC)

I think this is good, but the wording The Election Administrator right can be requested by anyone (administrator or non-administrator) by making a post at the bureaucrat's noticeboard. seems waaay to soft to me. Yes, it seems like electionadmins can't screw up an ongoing election, but we still shouldn't be handing this out like candy and I think we ideally give this right to the minimum number of people needed. Same concern, to a lesser extent, with It does not need to be revoked upon completion of the election. Toadspike [Talk] 18:35, 23 April 2025 (UTC)

Ready for a wider audience?

Alright, I see a couple of ideas and concerns raised in the above section, and some changes were made as a result, and some changes were not made for now. Do we think this proposal is fleshed out enough to be ready to ask for feedback from the bureaucrats and the checkusers? Are there any items above that have consensus to change that I'm missing? Thanks. –Novem Linguae (talk) 17:59, 23 April 2025 (UTC)

I think it's ready enough for more feedback from a broader audience. —Ganesha811 (talk) 18:02, 23 April 2025 (UTC)

 Done. CheckUsers and Bureaucrats have been notified on their respective wiki pages. –Novem Linguae (talk) 18:33, 23 April 2025 (UTC)

"Election admin"

Seeing as these aren't really doing the things we would expect are related to administrators, consider a name like "election editor" (in line with "template editor" as former art). Izno (talk) 19:06, 23 April 2025 (UTC)

I see my first point is a point of contention above. I don't really honestly care about what other wikis call it. The user right can be named whatever but I would suggest at a minimum that all the user-facing information be named in the direction of election editor. Izno (talk) 19:08, 23 April 2025 (UTC)

Seems reasonable. Thoughts from others? –Novem Linguae (talk) 19:56, 23 April 2025 (UTC)

"Election editor" or "Election manager" (word copied from WP:EFM) are totally fine. I don't personally agree it's notably better than "election admin", but I could see it's a bit better in terms of the intuitions it tugs on. More of a procedural/ministerial position rather than an administrative decision maker. Leijurv (talk) 20:14, 23 April 2025 (UTC)

Also fine with election manager. Izno (talk) 20:20, 23 April 2025 (UTC)

Two British terms we could appropriate for this are Polling Clerk or Returning Officer, the only option I don't like is Election Admin as this might be taken to imply you need to be an admin before taking on this role. ϢereSpielChequers 21:07, 23 April 2025 (UTC)

"Election clerk" also has good connotations and good precedent with SPI clerks and arbcom clerks. Leijurv (talk) 21:48, 23 April 2025 (UTC)

I like "Election clerk", both an accurate description and has wiki-precedent. —Ganesha811 (talk) 23:44, 23 April 2025 (UTC)

Yes, Election clerk would work. ϢereSpielChequers 06:03, 24 April 2025 (UTC)

 Done –Novem Linguae (talk) 06:09, 24 April 2025 (UTC)

Perhaps "electoral officer" (used in Canada) or "election official". If the "editor" noun is desired, then perhaps "poll editor" should be considered, since that's what they're setting up and editing. isaacl (talk) 00:38, 24 April 2025 (UTC)

Clerking the process implies holding the election fairly and calculating the true result. Editing an election implies altering the election result in a particular direction. ϢereSpielChequers 06:03, 24 April 2025 (UTC)

Yes; that's why I suggested electoral officer or election official first, and suggested poll editor instead of election editor, if people wanted to have "editor" in the name. isaacl (talk) 10:01, 24 April 2025 (UTC)

Make assignable by any sysop?

I'd also suggest making it assignable by admins. Creation and editing of polls is low stakes, if even we might prefer not to hand it out to too many people (and can say as much at PERM or wherever it's decided to grant this, since BN wouldn't make sense if admins could assign). This would allow most theoretical CUs (and all current CUs) to self-assign if/when they need to do so as part of the election process. Izno (talk) 19:06, 23 April 2025 (UTC)

Involving the bureaucrats was an attempt to copy the interface administrator process. Having sysops just self-assign (or assign to non-sysop editors with SecurePoll experience on other wikis or with technical skills) would simplify things. I think this is a good idea. We could keep this out of WP:PERM to discourage hat collecting. Thoughts from others? –Novem Linguae (talk) 19:55, 23 April 2025 (UTC)

I think Only editors who are involved in managing elections processes such as administrator elections, arbitration committee elections, etc. should request the right. It does not need to be given out widely. is really ambiguous and thus not actually useful criteria. I don't know how you balance "give it to anyone who asks because they're putting their hand up to help with the election" with "it does not need to be given out widely". Making it assignable by any sysop - which loses the virtue of at least having the requests go to a single visible place where there can be coordination about it - feels like it make that worse. This feels like one of those things where it won't be a problem - because it's a thankless task only competent people are likely to volunteer - until it is a problem - someone incompetent volunteers and messes things up for everyone. I would suggest that if we want to be bank on "wont' be a problem" instead securepoll-create-poll & securepoll-edit-poll just get bundled into sysop, rather than make it grantable by any sysop. This would exclude non-sysop election admins (or whatever we end up calling it), but I don't know how much we're losing by that. If keeping it open for non-admins is useful, then I suggest not making it assignable by any sysop and make the criteria somewhat useful for someone (admin or crat) to decide if they should grant it or not. Best, Barkeep49 (talk) 23:07, 23 April 2025 (UTC)

Prior discussion: Wikipedia_talk:Administrator_elections#Have_CheckUsers_be_in_charge_of_creating/editing_SecurePoll_polls?. My opinion: the permission should be for sysops only, they shouldn't have it by default but can self-grant with volunteering to clerk for a particular election. Second choice is still sysop-only but they can't self-grant, they have to request a bureaucrat to grant it. Leijurv (talk) 00:11, 24 April 2025 (UTC)

I think I agree with Barkeep49 that if there is a desire for the number of users empowered to create polls to be low, there should be a centralized process, just like for interface admins. The simplest way to keep the number low is to only assign the user privilege for a specific period of time, after which it is removed and the user can request it again if desired. isaacl (talk) 00:54, 24 April 2025 (UTC)

I'm thinking the same thing. I don't know how many people we'd expect to have as "Election Admins" at any given time, but a centralized process acts as a barrier to entry, of sorts. Even if requests were granted at a 100% rate, I would expect fewer Election Admins than self-granting would result in, simply because of that extra step. Either way, though, I would expect a large influx at the beginning, which would then settle down over time. Useight (talk) 03:33, 24 April 2025 (UTC)

only assign the user privilege for a specific period of time. I'm not sure this is a good idea. It would probably result in the same people applying over and over again. It would also be the only perm on enwiki that is always handed out on a temporary basis. I don't think this level of security is needed. Don't forget that each poll is compartmentalized, so having SecurePoll permissions doesn't mean you can go editing every poll -- you can only edit polls that you are added to.

There's been several ideas mentioned in this section. Which approach are people leaning towards? So far I kind of like Barkeep's idea of bundling securepoll-create-poll & securepoll-edit-poll with sysop, since that is a simple solution that skips needing to have a process to request it. I like simple workflows. My original proposal was to bundle it with CheckUser but that didn't catch on, so maybe bundling it with sysop is a good compromise. Thoughts? –Novem Linguae (talk) 03:59, 24 April 2025 (UTC)

That seems reasonable to me, or allowing admins to self-grant the right when volunteering to clerk an election. —Ganesha811 (talk) 04:02, 24 April 2025 (UTC)

There are permissions that have to be used in order to be kept. Specifically because I think it's beneficial for a larger pool of editors to gain experience with creating polls, rather than the same editors doing it repeatedly, I didn't suggest that approach for the electionadmin privilege.

My suggestion was contingent on their being a desire to limit the number of people with the privilege. As I recall, I previously said that I didn't see a big risk in all admins having the privilege assigned (though someone else disagreed). However I'm not sure what community consensus is on this issue. isaacl (talk) 04:23, 24 April 2025 (UTC)

Having Election Clerk be assignable/self-assignable by Administrators

I've edited the draft to have Election Clerks be assigned by Administrators instead of Bureaucrats. I don't think we have a consensus for anything yet, but I do think it'd be helpful to have this in writing to see what it looks like. Then folks can think about it more and discuss it more in this section. Thoughts? Is this change palatable? Or is Election Clerk too sensitive to hand out this easily? –Novem Linguae (talk) 06:16, 24 April 2025 (UTC)

There is a certain overhead to the community in holding an election, at the least it distracts from other things and clutters internal advertising. So I assume we will only want elections to take place after some sort of consensus process to start one, as opposed to an RFC which anyone can call. That implies us only needing a limited number of election clerks as opposed to any admin being able to make themselves a clerk and start a secure poll election. If you want us crats to flip the bit on new election clerks, you need a criteria for us to measure those clerk applications against or better a process for the community to pick those clerks with us crats flipping the bit for the winners. Hopefully this can be as informal as a subpage of any election that has consensus to proceed with the clerks volunteering on that subpage. ϢereSpielChequers 07:01, 24 April 2025 (UTC)

Or is Election Clerk too sensitive to hand out this easily? Just going off your comment above, it seems like the opposite? It sounds foolproof the way you describe it. When an election is running, it cannot really be interfered with. Therefore, you only need to trust the clerks to simply not vandalize. You don't need to trust them not to interfere with the results, because, they can't. (unlike scrutineers, who can). Assuming this understanding is correct, per WP:NOTBURO, I still believe sysops should just get this right by default (no new user group). Failing that, sure, your updated proposal is best, where sysops can self-grant the right without much fanfare. Leijurv (talk) 07:18, 24 April 2025 (UTC)

The person managing the poll has to be trusted to manage the poll's encryption (including not losing the key to decrypt the results) and to report the results accurately. I don't think there's any risk of undetected vandalism. isaacl (talk) 10:08, 24 April 2025 (UTC)

I don't know how to come to a consensus on this question without the information of how trusted of a role Election Clerk should be. Novem's comment above seemed to indicate that once a poll has been started, the clerks cannot really mess with it. But your message indicates that the clerks must be trusted to report the results accurately. Is that true? I thought only the scrutineers could edit the results? What exactly are we trusting a clerk to do, or not do?Leijurv (talk) 19:06, 24 April 2025 (UTC)

From my understanding of the arbitration committee elections, the WMF staffer uses the key to trigger the SecurePoll software to decrypt the votes and tally them, and then the staffer reports the results. I believe after tallying the results are visible to the users who have access to administer the specific poll (they have been assigned by the poll creator or someone else with the ability to assign election admins for a given poll). So there should be multiple election admins assigned both for redundancy and to double check the tallied results. (I don't know if the results can be made visible publicly, directly from the SecurePoll extension.) As I understand it, scrutineers cannot "edit the results" per se. They can discard cast votes, but they don't know the actual contents of the vote, as it is encrypted. isaacl (talk) 22:02, 24 April 2025 (UTC)

Maybe this is naive but do we need encryption? I could see why they set up this process, because the original use was for WMF board of directors. But, I don't think we should have any problem trusting the WMF's servers / databases to be untampered? Would this encryption key problem go away if the encryption option was disabled for our elections? Leijurv (talk) 23:24, 24 April 2025 (UTC)

The primary issue, in my opinion, is not tampering but keeping the submitted ballots secret. Encrypting the votes ensures that no one with access to the backend can see the votes, and it's also easy to state that the election admins have no access to the votes, without someone hacking the software to expose the data. There was some discussion of this last year. I think enough people expressed a desire to keep the votes secret that leaving the votes unencrypted wasn't pursued, but I haven't re-checked the conversations. isaacl (talk) 23:41, 24 April 2025 (UTC)

I think some level of trust needs to be established and thus some request process is needed (or, as previously discussed, all admins can be assigned the electionadmin privilege). isaacl (talk) 10:16, 24 April 2025 (UTC)

As I indicated above I do not find this change palatable. isaac's point about the key is an important one and would lead me to support some kind of centralized process as a first choice, which also carries the advantage that it could be granted to anyone. To the comments @WereSpielChequers and I have left around criteria, I would suggest something along the lines of Election Clerk may be granted to a small number of users (optional: for each election) who are trusted to manage elections processes such as administrator elections and arbitration committee elections. As a 2nd choice, I think admins self-granting (with explicit prohibition against granting to others) works well (just so we ahve some log of who is raising hands to do the work) but have no real issue with it also just being bundled. Best, Barkeep49 (talk) 16:39, 24 April 2025 (UTC)

You (or anyone) should feel free to edit the page to your preferred version. Maybe we can land on a good compromise if multiple people edit it. I am not seeing a clear consensus so far. –Novem Linguae (talk) 17:05, 24 April 2025 (UTC)

Although the sample size is really small, I think most people have expressed a willingness to live with the electionadmin right being bundled with the privileges given to administrators. We can see what other interested persons have to say.

On a bigger picture note: I think there needs to be some discussion on how the community wants the SecurePoll feature to be used before the electionadmin right starts to be handed out (alternatively, it could be given out with a caveat that it's only for admin elections for now). Does it want polls to be like mass messages, where anyone can request a message meeting certain criteria to be sent and a mass message sender can choose to approve the request and send it? Or does it want polls to be used only for specific community-approved events (one-time or recurring)? I think most editors involved in these discussions have been assuming the latter, but an argument can be made for allowing more broad use (not all polls have to be on topics requiring widespread participation; they can just be another tool for team collaboration). isaacl (talk) 18:54, 24 April 2025 (UTC)

My impression of the extension was that you can still have only one poll running at any given time, which has likely been a significant reason for feeling it was to be used for limited purposes. If that limitation has been lifted, then I think there is indeed an actual viable question of how the tool can be used. Izno (talk) 19:21, 24 April 2025 (UTC)

I tested it just now, and I was able to open and vote in two elections running simultaneously, locally.

I think the community would approve of SecurePolls for tests, AELECT, and ACE at the moment. I would probably support putting wording somewhere saying that using SecurePoll for other things would need some discussion first. For example, if WikiProject ABC wanted to have a lead coordinator election with 2 candidates, there might be some reasons to at least discuss it before doing it (SecurePoll has a lot of overhead for such a small election, and maybe the community doesn't want to normalize "voting" too much). –Novem Linguae (talk) 19:30, 24 April 2025 (UTC)

My instinct is that the community wouldn't want to make secret ballot voting a common mode for collaboration, but I could be wrong. If they do, then there's a greater incentive to empower more users with the ability to create polls, so the workload can be spread. isaacl (talk) 22:16, 24 April 2025 (UTC)

My understanding is that there's no limitation—right now there are eleven polls running for Chinese Wikipedia (see votewiki:Special:SecurePoll). The (virtual) server itself can only be configured for a specific language, but polls themselves can be multilingual, as that is one of the design requirements. (I believe there is some trickle down effect regarding left-to-right vs right-to-left languages due to the server configuration, but that doesn't impede the actual poll.) There is a limitation on the number of WMF staffers available to manage polls, but if English Wikipedia decides it wants to be able to run polls more freely, it can alleviate this bottleneck by assigning the electionadmin right to a broader pool of editors, such as all admins. isaacl (talk) 21:33, 24 April 2025 (UTC)

Redundancy in poll administration

One other aspect I think needs to be discussed about using SecurePoll is redundancy in poll administration. Should the decryption key be held by at least two election admins, so in case one is unavailable, the other can tally the results? isaacl (talk) 22:36, 24 April 2025 (UTC)

This might be a good post for WT:AELECT. –Novem Linguae (talk) 23:45, 24 April 2025 (UTC)