We should be able to have polls where a list of options is given, and voters can rank them in order of preference.
So the voter would see something along the lines of...
What is your favourite vowel? [] A [] E [] I [] O [] U [] W [] Y
with [] replaced by a drop-down containing numbers 1 to 7 and a blank.
Back-end checking at vote time would ensure that the voter had specified a strict sequence, with no number repeated. Is it necessary to check that voting runs 1, 2, 3? Not strictly according to the mathematics, but it would make the coding so much easier.
The count is initially of first-preference votes, then re-assigning the least popular first-prefs to their second and so on until one option achieves a majority of initially valid votes. (Or a majority of effective votes.)
The code, I think, partially exists for this on LJ as they used it for the advisory board elections. I don't think it was a good implementation, but it was workable and could probably be improved.
The biggest problem in Livejournal's code was that they restricted people to a finite number of picks from a list of candidates, rather than numbering their votes. The handling of tied eliminations was also sloppy, eliminating all candidates involved in a tie; preference tends to be a countback method and/or conditional eliminations.
If this aspect is going to be done properly, it may be possible to provide a single transferrable vote to return multiple winners. Where would this have a practical application? "Two of these seven vowels are going forward to our Favourite Letter poll." One-winner transferrable vote is just a degenerate case of multi-winner.
Drawbacks are mostly coding and processing time, as calculating a result will require backened work, especially true if the current result is showing.
Coding is a one-time hit, processing is an ongoing matter. I would not be averse to cacheing the result, and only recalculating it after increasing intervals - for the sake of argument after 15 minutes, 30 minutes, 1 hour, 2 hours, 4, 8, 12 hours, and so on. Closing the poll forces a count, natch.
The LJ implementation is poor and would need improving.
The wheel has already been invented. Implementers may wish to consider the algorithm embedded in the source code for http://www.openstv.org/download as a starting point.
no subject
So the voter would see something along the lines of...
with [] replaced by a drop-down containing numbers 1 to 7 and a blank.
Back-end checking at vote time would ensure that the voter had specified a strict sequence, with no number repeated. Is it necessary to check that voting runs 1, 2, 3? Not strictly according to the mathematics, but it would make the coding so much easier.
The count is initially of first-preference votes, then re-assigning the least popular first-prefs to their second and so on until one option achieves a majority of initially valid votes. (Or a majority of effective votes.)
The code, I think, partially exists for this on LJ as they used it for the advisory board elections. I don't think it was a good implementation, but it was workable and could probably be improved.
The biggest problem in Livejournal's code was that they restricted people to a finite number of picks from a list of candidates, rather than numbering their votes. The handling of tied eliminations was also sloppy, eliminating all candidates involved in a tie; preference tends to be a countback method and/or conditional eliminations.
If this aspect is going to be done properly, it may be possible to provide a single transferrable vote to return multiple winners. Where would this have a practical application? "Two of these seven vowels are going forward to our Favourite Letter poll." One-winner transferrable vote is just a degenerate case of multi-winner.
Drawbacks are mostly coding and processing time, as calculating a result will require backened work, especially true if the current result is showing.
Coding is a one-time hit, processing is an ongoing matter. I would not be averse to cacheing the result, and only recalculating it after increasing intervals - for the sake of argument after 15 minutes, 30 minutes, 1 hour, 2 hours, 4, 8, 12 hours, and so on. Closing the poll forces a count, natch.
The LJ implementation is poor and would need improving.
The wheel has already been invented. Implementers may wish to consider the algorithm embedded in the source code for http://www.openstv.org/download as a starting point.