Feature summary
While for some elections (such as the Board elections) it makes sense to use a "central" wiki like votewiki (vote.wikimedia.org), for elections that only pertain to individual wikis, we should allow the wiki functionaries of those wikis to set up the election locally.
Use cases
Currently, the only way a WMF wiki can set up an election is to request it to be created on votewiki and this involves a busy process in which Trust-and-Safety team also has to be involved. This has limited the adoption of SecurePoll. At least in the case of fawiki (which has been the leading community using SecurePoll for local elections), this process has been perceived as cumbersome.
Although I cannot find a task on Phabricator about this, I recall a conversation about this in the past where two arguments were raised against this:
- Some elections require CLI level actions (such as setting up encryption) and having control on the creation of elections (and effectively, rate-limiting the elections using the T&S process) can help ensure these needs are met and we don't end up with a backlog of CLI level actions
- Installing SecurePoll databases on individual wikis would complicate replication of local DBs into Cloud-Services and can pose potential security risks
It appears that the second argument is not valid anymore, as we have robust data replication scripts that accurately control which tables can or cannot be replicated (such as check_private_data.py and maintain-views.yaml). The first argument still holds, except most elections are not encrypted (I believe the only ones encrypted are those for the Board).
Benefits
Allowing locally-defined elections has the added advantage that other wikis won't see them in the list of elections and the list would be less cluttered. Also, the current process in which votewiki's interface language must be change to that of specific communities during their election period would be unnecessary. This also allows local wikis to create more elections, use SecurePoll to convert some of the current voting processes (adminship, etc.) into ones with close ballots, conduct aggregated surveys about key project ideas, and so forth.
Other considerations
The expansion for SecurePoll to local wikis can be done in a calculated way, e.g. at first only wikis with local CUs could be allowed to use it, because those CUs can also work as scrutineers of the votes and are already NDA'ed to see the private details of votes.