-
Notifications
You must be signed in to change notification settings - Fork 2
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
Review/implement distributed voting UI in WGs and test that it works well with latest version #1427
Comments
Distributed Voting process and API statusCurrently, the Voting API has support for tallying votes of a ballot of types plurality, range, and distributed (named cumulative in the API). See code below to know which module implements each type. ...
when "PLURALITY", "APPROVAL"
RangeVoting.sort_candidates_by_score(@ballot.votes) results = PluralityVoting.sort_candidates_by_score(@ballot.votes)
when "RANGE"
results = PluralityVoting.sort_candidates_by_score(@ballot.votes)
when "DISTRIBUTED", "CUMULATIVE"
results = CumulativeVoting.sort_candidates_by_score(@ballot.votes)
end None of these voting systems are fully complete. Basically, we only have the methods for tallying the votes for each system. For example, in distributed, the tallying process simply sums up votes received for each candidate and returns the sorted array of candidates along with their scores, but the validation mechanism is not implemented for any voting system (i.e., we do not check if the voter submitted only N votes in distributed for example). When voting is distributed, each voter has N votes to distribute among the candidates. The winning proposal is the one with most votes. Or using the Validation is needed in all the systems when saving or updating votes (see https://github.com/socialappslab/appcivist-voting-api/blob/d83e844979531a9aa5baffd36325912ec93490ae/app/models/ballot_paper.rb), the voting API does not check if the votes distributed by the voter equal the total number of votes that are allowed to distribute (in the ballot configurations) in the case of distributed. It does not check if votes are within the minimum and maximum allowed scores in RANGE, and it does not check plurality rules related to abstain or blocking options. So this is a TODO in the voting API, that could be simply implemented in the UI for the moment. In fact, the UI might already have some of these checks in place for the campaign page, but certainly not for the WG page. So, we should now focus only in the WG voting story, and fix later the current issues with campaign voting. WG Voting Story:The basic idea for voting in the WG page is that a coordinator can, at any given time, create a ballot that would include a list of candidates representing proposals in the group. By default, all published proposals could be included, but ideally, the coordinator should be able to select which proposals to include in the ballot (so as to create mini decision making competitions sort of). The current model only allows for one ballot at a time, but ideally, a WG might contain several ballots at the same time (for example, to make decisions on multiple groups of dissensus proposals), and members could select which ballot they want to vote on, therefore filtering contributions bellow including only those in the selected ballot. The idea of having multiple ballots (i.e., multiple voting processes with different list of candidates) running in parallel might also be useful for the campaign page. Perhaps also there the voting can be configured by coordinators rather than automatically (as it is now). ToDo List.Based on comments above, below is the preliminary ToDo of priorities (on top of all the problems identified in the previous comments).
|
This is still an issue |
No description provided.
The text was updated successfully, but these errors were encountered: