Personally I have never used the "autogenerate" functionality provided there. I looked into the settings from the 2017 Board Elections, which was the last major election we ran that did not use a hard-coded eligibility list, and it also does not appear to have made use of this functionality. Instead we just used the "basic" settings here, which seems to have worked just fine and done more or less the same thing that auto-populating the list would.

I think I'd be fine with just binning the broken part of this process given it isn't really used and is kind of superseded by one of the other processes (either adding the voter list manually, or using the basic settings). There's a chance that in the future we want to allow for more complex criteria to be set up in votewiki - the English Wikipedia ArbCom election already has some pretty specific requirements which necessitate a Python script to generate the list independently.

(Sidenote: Pretty much everything on votewiki hasn't been used in a long time since the last Board election was almost four years ago. :)

Thanks @jrbs. I'll update the task to remove the auto-generation facility based on your input.

Meeting notes:

• Removing the will also the feature also remove the ability to filter by certain groups (note that the functionality is broken at the moment). This will prevent us from doing T271884: Investigate ways to allow WMF staff to be added to the voter list for board elections [8H] by adding a user-right for all staff.
• Hold off on this task until we have clarity on whether on not the user-right can be created and employed for this use case

@STran I have a clarifying question. Sorry if you explained this elsewhere and I missed it. Is the "Basic options" that Joe referred to and the "Eligibility List" feature intertwined in any way? I notice they both have the same "minimum edits" option.

@Niharika They are not! The two operate on entirely independent mechanisms. This actually came up during engineering meeting and shoutout to @DLynch for suggesting it but we think we can remove "Eligibility List" and implement usergroup access in "Basic Options." tl;dr:

• "Basic Options" are all checked at the time the user session attempts to vote. There's caching on the session which caches the user's info (ie. edits, blocks, etc) but the check for these parameters happens on demand.
• "Eligibility List" generates a fixed list based on the requirements set at the time it's enabled/edited. That list appears to only get updated if the requirements ever change. The list can be manually modified but otherwise, the list that "Eligibility List" outputs is used during the vote eligibility check and compared against the username of the voter at the same time as the "Basic Options."
• We only need "Eligibility List" because we want the user groups settings
• Not only does "Eligibility List" not work, we're not sure why some of these essentially "advanced" options were split off from "basic" options. Performance? Need for a basic list to work off of? Unclear without additional research.

Since we only need the user group feature (theoretically) and since we know that we can do these checks on demand (we check for electionadmin eligibility at the time of adding the admin to a poll), we can theoretically make "allow usergroups" a "basic" option and then remove "Eligibility List."

@STran Thanks for the explanation! That helps.

Since we only need the user group feature (theoretically) and since we know that we can do these checks on demand (we check for electionadmin eligibility at the time of adding the admin to a poll), we can theoretically make "allow usergroups" a "basic" option and then remove "Eligibility List."

This makes sense to me. I don't have clarity from IT about whether a 'staff' group can be added anytime soon. But we could add the feature and it would be ready to use whenever the group gets created.

@STran @Tchanders I updated the task description to reflect what we talked about.

@Niharika Do you think we could separate removing the eligibility list feature into a separate task? I think it could be a bit of work finding everything that's related to it, and might also not be as high priority as this work and the tallying work?

Change 670976 had a related patch set uploaded (by STran; owner: STran):
[mediawiki/extensions/SecurePoll@master] [WIP] Add usergroup-based voter eligibility

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

Change 670976 merged by jenkins-bot:
[mediawiki/extensions/SecurePoll@master] Add usergroup-based voter eligibility

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

The Special:SecurePoll/votereligibility "basic options" form has has a tag multiselect widget which allows you to add user groups.

It does not autocomplete user groups, so you have to know the exact name of the group you want.

I checked that, on submit, the chosen user groups get saved to the database (and to any connected database if it is a remote election).

This bypasses other eligibility criteria. I tested "Minimum edits". So, even if my user does not have the correct minimum edits I can still vote if I am in the right group. If I am not in the right group, I can only vote if I have enough edits.

Test Environment: https://vote.wikimedia.beta.wmflabs.org SecurePoll 2.0.0 (e911b1f) 10:03, 6 April 2021.