Evaluation:

Will probably require refactoring of tally logic. In general feasible. We need to know what to do with previous tally results (discard or preserve). Low risk, but quite some work (couple of days).

Disagree that retallying is an acceptable solution. Normal processes would be to run the election, with advance processes for filling seats due to resignation. The appropriate solutions would be either (a) next past the post candidate (who may also need to meet any other additional requirements) or (b) run a new election.

It was a bad idea when it was done for the MCDC candidate elections, and created more problems than it solved.

In T309416#8761398, @Risker wrote:

Normal processes would be to run the election, with advance processes for filling seats due to resignation. The appropriate solutions would be either (a) next past the post candidate (who may also need to meet any other additional requirements) or (b) run a new election.

That's fine to have additional processes or procedures to fill those seats if this happens, but technically, there is no "next past the post candidate" with Meek STV. Your only options are to re-tally or run the election a second time, and the latter option is extremely expensive in terms of staff time.

It was a bad idea when it was done for the MCDC candidate elections, and created more problems than it solved.

Could you elaborate on this? All this required was a Python script in the end. Not ideal, but this task would directly improve that.

In T309416#8761559, @jrbs wrote:

In T309416#8761398, @Risker wrote:

Normal processes would be to run the election, with advance processes for filling seats due to resignation. The appropriate solutions would be either (a) next past the post candidate (who may also need to meet any other additional requirements) or (b) run a new election.

That's fine to have additional processes or procedures to fill those seats if this happens, but technically, there is no "next past the post candidate" with Meek STV. Your only options are to re-tally or run the election a second time, and the latter option is extremely expensive in terms of staff time.

The STV tally ranks all candidates. If there are 7 seats, the candidate who is #8 is next in line, followed by #9, and so on. Seems that would be pretty straightforward. This should be the standard process; completed elections shouldn't be reopened (for both security and initial vote validation purposes) for the purpose of re-tallying. I'd be very interested to see examples of other organizations that use an STV system to elect people who reopen completed elections to select a replacement; while I haven't researched this too intently, everything I've seen is either "take the next in line" or "full by-election". I recognize that this doesn't formally follow the STV system in current use, but it (a) maintains election security and (b) has zero impact on staff or community time; you don't even have to run a script. Another option would be to run the election using the principle that there will be the number of open seats plus an additional X number of "runner up" seats calculated using the system the first time through, so that there are X number of replacements that have already been fully community approved waiting in the wings.

It was a bad idea when it was done for the MCDC candidate elections, and created more problems than it solved.

Could you elaborate on this? All this required was a Python script in the end. Not ideal, but this task would directly improve that.

The problems were mainly social, aside from the vote security issue above. Specifically, the group that was intended to select candidates based on diversity and qualification decided they wanted to re-run the election and choose the person who came out on top. Partly this was also related to the overall rules of that election, which on the whole were not directly related to the voting system.

In T309416#8770018, @Risker wrote:

The STV tally ranks all candidates. If there are 7 seats, the candidate who is #8 is next in line, followed by #9, and so on. Seems that would be pretty straightforward.

It sure seems that way -- but it's technically not. If a candidate is removed from a Meek STV election, all uncounted lower-list preferences from their votes are also removed. So if you just take 8 and 9 as the next two, you are technically improperly tallying the votes, and if we re-tallied with the full vote list the outcome may change.

As an example, you can see here the results of the MCDC election as originally tallied. Using the logic of just taking the last candidate to be eliminated, that would be Tito Dutta. But instead we had to re-tally with all the votes from those who selected Alice in play as well, removing her from the ballots and sliding the other choices up a rank to accommodate. This re-tallying led to Daria's election, even though she was eliminated about halfway through the original tally. (Partly this is because others were not ultimately eligible due to the limited number allowed from each community though.)

This should be the standard process; completed elections shouldn't be reopened (for both security and initial vote validation purposes) for the purpose of re-tallying. I'd be very interested to see examples of other organizations that use an STV system to elect people who reopen completed elections to select a replacement; while I haven't researched this too intently, everything I've seen is either "take the next in line" or "full by-election". I recognize that this doesn't formally follow the STV system in current use, but it (a) maintains election security and (b) has zero impact on staff or community time; you don't even have to run a script. Another option would be to run the election using the principle that there will be the number of open seats plus an additional X number of "runner up" seats calculated using the system the first time through, so that there are X number of replacements that have already been fully community approved waiting in the wings.

I would say, so long as you are comfortable with the fact that Meek STV doesn't actually have "runner up" seats in this way, you could explain that ahead of the election and just deal with it that way. That's probably the easiest solution if not necessarily the "fairest", since those who voted for the withdrawn candidate will have less say in the outcome than other voters.

The problems were mainly social, aside from the vote security issue above. Specifically, the group that was intended to select candidates based on diversity and qualification decided they wanted to re-run the election and choose the person who came out on top. Partly this was also related to the overall rules of that election, which on the whole were not directly related to the voting system.

That's fair. I personally think the approach taken was fair, if expensive. But if you wanted to run it as mentioned above (with "runners up"), so long as you are clear about that and what it actually means with Meek STV, that would probably be acceptable to the community.

I keep coming back to how and why we decided to use one of the more complicated STV processes. I know it makes the election geeks happy, but the purpose of these elections isn't to make them happy, it's to give us an unimpeachable decision that isn't going to wind up being revisited the second someone quits. There should be a system that ranks every single candidate right down to the last one, so that elections do not need to be rerun or restarted. There were so many things wrong with rerunning this election (including the fact that half of the MCDC members weren't elected, they were appointed from the candidate pool, so the results were already going to be messed up no matter what), and I note that nobody actually informed the individuals whose name was being put forward in the rerun election that this was going to happen.

As I say, the mathematical system is one problem. The much bigger one is the social problem, and it's one that can't be solved with technology unless we're looking at a very different STV system.

In T309416#8780970, @Risker wrote:

I keep coming back to how and why we decided to use one of the more complicated STV processes. I know it makes the election geeks happy, but the purpose of these elections isn't to make them happy, it's to give us an unimpeachable decision that isn't going to wind up being revisited the second someone quits. There should be a system that ranks every single candidate right down to the last one, so that elections do not need to be rerun or restarted. There were so many things wrong with rerunning this election (including the fact that half of the MCDC members weren't elected, they were appointed from the candidate pool, so the results were already going to be messed up no matter what), and I note that nobody actually informed the individuals whose name was being put forward in the rerun election that this was going to happen.

I was not involved in the decision-making process for this election process but Meek STV is one of the most fair methods for selecting a group of candidates, which is the usual use case for Wikimedia elections (Board, MCDC). The issue is if someone immediately withdraws. For this, the only solutions are:

1. We use a different methodology for elections where someone might quit, so that we have a fair ordered list of candidates with which we can replace them (something like histogram range, which we already moved away from because it's gameable)
2. We make clear before the election that the candidates eliminated last will be the backup candidates - that's not especially "fair" but it's reasonably intuitive
3. We re-run the election if a candidate immediately withdraws after being elected. That's the "fairest" option but obviously running a whole new election is very expensive in terms of time and staff support.
4. We do what we did here (remove the candidate and re-run the tally so that the votes may be correctly distributed as though the withdrawn candidate never ran).

IMHO, we did the right thing in this election cycle by removing the withdrawn candidate and re-tallying the election. The MCDC election had the unusual stipulation that only x candidates from each wiki would be allowed onto the committee which obviously complicated things quite a lot. I don't think this would have been an issue in e.g. a Board election since that stipulation doesn't exist.

The goal of a multi-winner election should be proportional representation. That means that if a candidate who is favored highly enough by some segment of the voters to get elected is found to not be eligible to serve, you don't just pick the next in line. You simply need to re-run the algorithm, after eliminating votes for all the ineligible candidates.

We picked STV in order to achieve PR.

This should be carefully documented, and the community should be educated about these aspects ahead of time, to minimize any confusion.

The example by @jrbs seems very helpful - I should dig in to it more. Thanks!

As far as implementing tally modifiers in the UI goes, would it make more sense to create a new page for editing these separate from CreatePage? At least in the case of eliminated candidates it wouldn't make sense to include this during creation, though it would make sense if being edited.

Change #1142001 had a related patch set uploaded (by Amdrel; author: Amdrel):

[mediawiki/extensions/SecurePoll@master] WIP: Add tally modifiers page and canididate pre-election for STV

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

Change #1166805 had a related patch set uploaded (by STran; author: STran):

[mediawiki/extensions/SecurePoll@master] Declare tally modifications on a per-tally basis

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

Change #1142001 abandoned by STran:

[mediawiki/extensions/SecurePoll@master] Add tally modifiers page and canididate pre-election for STV

Reason:

prefer Ifec7e2a189c342d03cd6d1b3fe4152c1780c7014

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

Change #1166805 merged by jenkins-bot:

[mediawiki/extensions/SecurePoll@master] Declare tally modifications on a per-tally basis

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