You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
one_of_m is a special case with number_elected = 1.
approval where votes_allowed = number of options.
I think in these three cases votes_allowed == number_elected.
Im looking at the other VoteVariationType's, and Im guessing some of those (majority, plurality, proportional, super_majority) can be done by the current system because they are just special versions of n_of_m. Some (borda, cumulative, range, rcv) I guess cannot currently be done.
For clarity, we should remove the VoteVariationTypes not supported in the 1.0 library, and for the supported ones, make clear if election guard needs to do any special handling.
Possible Implementation
For 1.0, remove all VoteVariationType's except n_of_m, one_of_m, and approval. Remove number_elected and only use votes_allowed, which is required.
Is there an existing issue for this?
Suggestion
AFAICT, the 1.0 reference library supports
I think in these three cases votes_allowed == number_elected.
Im looking at the other VoteVariationType's, and Im guessing some of those (majority, plurality, proportional, super_majority) can be done by the current system because they are just special versions of n_of_m. Some (borda, cumulative, range, rcv) I guess cannot currently be done.
For clarity, we should remove the VoteVariationTypes not supported in the 1.0 library, and for the supported ones, make clear if election guard needs to do any special handling.
Possible Implementation
For 1.0, remove all VoteVariationType's except n_of_m, one_of_m, and approval. Remove number_elected and only use votes_allowed, which is required.
Anything else?
Also see Issue #224 and Discussion #247
The text was updated successfully, but these errors were encountered: