The SecurePoll extension is already installed on enwiki.

Change #1083870 had a related patch set uploaded (by Dreamrimmer; author: Dreamrimmer):

[operations/mediawiki-config@master] Enable electionadmin user group on enwiki

https://gerrit.wikimedia.org/r/1083870

I suggest stalling this until T377531 is resolved.

At the moment, it sounds like enwiki wants to put all the SecurePoll perms in the electionadmin user group. Having all the perms in the same group that they were basically in before means that the unbundling in T377531 will have no effect on this ticket, right? May not need to stall this.

As for the social/consensus side of things, we can create the electionadmin group as a first step, then not give it to anyone until we hammer out the details of how it will be given out. The exact process for giving it out is still being discussed on enwiki, but there is a consensus to have SecurePoll on enwiki and to have electionadmins.

WP:SNOW: unanimous support to have the ability to hold local SecurePoll elections, including enabling the electionadmin right on enwiki. An RFC to determine how the new right should be distributed can be launched at any time; it may be advisable to advertise that RFC on WP:CENT. --Levivich

Would the line $wgGroupPermissions['electionadmin']['securepoll-administrate-poll'] = true; cause any problems if securepoll-administrate-poll isn't created yet?

In T378287#10271579, @Novem_Linguae wrote:

Would the line $wgGroupPermissions['electionadmin']['securepoll-administrate-poll'] = true; cause any problems if securepoll-administrate-poll isn't created yet?

This wouldn't cause any problems, but it would be redundant in the codebase, so leaving it for now is the best approach. For now, we can create the electionadmin user group with existing rights, and later, if there are any updates, we can add more rights as needed. I think creating this user group is harmless since no one can add or remove it at the moment (except stewards). When the community decides who can grant access to this user group and to whom, we can then add the configurations for wgAddGroups and wgRemoveGroups.

In T378287#10271575, @Novem_Linguae wrote:

At the moment, it sounds like enwiki wants to put all the SecurePoll perms in the electionadmin user group.

In https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(idea_lab)#Determining_who_should_be_an_electionadmin, there is just one user who appears to suggest putting all perms in one group.

There are more people who suggest bundling poll creation and editing into sysop, and view-voter-pii into CheckUser. If that is the eventual consensus, we don't need the electionadmin group at all.

Also, it's just an idea lab discussion, likely a prelude to a more organized VPR discussion or RfC which the closer of https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals)#Enabling_SecurePoll_elections_with_the_electionadmin_right suggested should happen before enwiki deployment:

An RFC to determine how the new right should be distributed can be launched at any time; it may be advisable to advertise that RFC on WP:CENT.

It would help if T377531 is resolved before such a discussion happens.

I'd be in favor of getting this deployed so the electionadmin group exists. This would get the technical part out of the way. Then, onwiki and at the community's convenience, we can workshop a policy/guideline for which users it can be granted to.

I think this will be ready for deployment once the two code review comments are resolved.

I would like to avoid decision paralysis here.

I will tweak the patch shortly.

Hi @Novem_Linguae , is such investigate still in progress? And may I know what kind of database challenge is facing, is it related to T381197 or not?

I'll reach out to @SDeckelmann-WMF via email and see if I can get an update. The discussion is currently off phabricator I think. Would be great to get it moved onto phabricator to make progress a bit easier to track.

@Novem_Linguae I can look into it. Let me get back to you with more information shortly.

Thanks!

In terms of SecurePoll database scalability (which I believe is the concern), my understanding is that there's only issues for global elections, because a maintenance script is used to generate a table of authorized voters for every single wiki. Naturally that does not scale. I first learned about this after reading T355594: For global elections, SecurePoll creates an eligible voters table for each election on every wiki and keeps it forever.

But my understanding is that a local election that only involves one wiki doesn't generate any extra tables, and just uses the existing 12 SecurePoll tables already installed on that wiki. Please let me know if I'm misunderstanding something.

In T378287#10475973, @Novem_Linguae wrote:

Thanks!

In terms of SecurePoll database scalability (which I believe is the concern), my understanding is that there's only issues for global elections, because a maintenance script is used to generate a table of authorized voters for every single wiki. Naturally that does not scale. I first learned about this after reading T355594: For global elections, SecurePoll creates an eligible voters table for each election on every wiki and keeps it forever.

But my understanding is that a local election that only involves one wiki doesn't generate any extra tables, and just uses the existing 12 SecurePoll tables already installed on that wiki. Please let me know if I'm misunderstanding something.

This is correct. SecurePoll supports local elections through its base tables and if you're curious about the process around global elections, you can read this documentation. I don't think the global databases will block local elections but SecurePoll making assumptions about the access to global elections may. T384302: SecurePoll: Restrict creation of foreign and global elections tracks the work needed to gate some of those features. IIRC, SecurePoll was intended to run on votewiki and therefore although it supports local elections, in practice it assumes any election it runs will be global and therefore whoever is has permission to administrate it it has permissions to do global things, will be running the support cli scripts, etc.

This needs some engineering specification to see what we can decouple from global elections permissions, so moving it to the "Needs engineering specification" column.