Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP Configuring Number of Winners > Number of Declared Candidates results in confusing error message #797

Open
yezr opened this issue Feb 15, 2024 · 2 comments · May be fixed by #823
Open

Comments

@yezr
Copy link
Collaborator

yezr commented Feb 15, 2024

RCTab Version: 1.4.0 and 1.3.1

What Happened

If you configure Number of Winners > the number of candidates you have configured in the Candidates tab you get the following error

2024-02-15 08:55:30 EST SEVERE: numberOfWinners must be an integer from 0 to [numberOfConfiguredCandidates]!
from line 700 in ContestConfig.java in 1.4.0

So for example I configured one candidate and set the Number of Winners to 3 and got
image

I imagine this check failed validation because when you have less configured candidates than the configured number of winners you don't need to run any tabulation rounds: each configured candidate is automatically elected. If I only have two candidates running for 3 City Council seats then I don't need to count any votes to know that those two will be elected.

What I Expect To Happen

A more detailed message like

"The number of declared Candidates (numDeclaredCandidates) must be greater than or equal to the Number Of Winners (numberOfWinners) for Multi-Winner contests.

OR

Another option we are discussing is to let this pass config validation. When it gets to the tabulation I expect it will get to the logic that says "Do we have less continuing candidates than the configured number of winners? If so, elect them"

I lean towards RCTab producing output with winners in this example, because that can be certified as an election result whereas this halting exception cannot.

@yezr yezr changed the title Configuring Number of Winners > Number of Declared Candidates results in confusing error message WIP Configuring Number of Winners > Number of Declared Candidates results in confusing error message Feb 15, 2024
@yezr yezr added this to the v1.3.2 milestone Feb 19, 2024
@yezr yezr removed this from the v1.3.2 milestone Feb 21, 2024
@yezr yezr added needs-rcvrc-clarification where RCVRC input could help clarify development tasks and removed needs-rcvrc-clarification where RCVRC input could help clarify development tasks labels Feb 21, 2024
@yezr
Copy link
Collaborator Author

yezr commented Feb 21, 2024

Since winners can be confirmed by the naked eye, without RCTab ever getting involved, I'm going to prioritize this is a P2.

@artoonie
Copy link
Collaborator

artoonie commented Apr 1, 2024

I'm implementing allowing this to proceed, but I realize that we may need some customized behavior here depending on statute.

I can see two types of statutes being out there:

while (number of remaining candidates > number of candidates to be elected):
  If anybody is over the threshold, elect and surplus transfer
  else, if nobody is over threshold, eliminate until somebody is over the threshold or until you need to elect all remaining candidates

Versus:

if any candidate is over the threshold, elect the one with the highest # of votes and then do a surplus transfer
if no candidate is over the threshold, eliminate until somebody is, or until everybody needs to be elected

The difference is this:
The former has a single round and everybody is elected
The latter will have a few rounds of surplus transfers, only electing people as they meet the threshold

I have assumed that we only care about the former, since that's what all statutes I've read do, but I do want to flag this assumption

@artoonie artoonie linked a pull request Apr 1, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: In Review
Development

Successfully merging a pull request may close this issue.

2 participants