Have a run-off option for polls

[matgb]

Title:
Have a run-off option for polls

Area:
polls

Summary:
It should be possible to have polls where users ranks options in order of preference (instant runoff or preferential voting).

Description:
Currently we allow for simple plurality voting (radio buttons) and approval voting (checkboxes), but not for preferential voting. As a polling theory geek (involved in the UK campaign for reform) this makes me sad.

We should be able to have polls where a list of options is given, and voters can rank them in order of preference. When the poll is closed, a counting algorithm can be run to reveal which option wins after losing preferences are reassigned.

The code, I think, partially exists for this on LJ as they used it for the advisorty board elections. I don't think it was a good implementation, but it was workable and could probably be improved.

Drawbacks are mostly coding and processing time, as calculating a result will require backened work, especially true if the current result is showing. The LJ implementation is poor and would need improving.

Advantages are that polling geeks like me are very happy, and users can use polls in a more expressive manner. Prefential voting is a good way to organise outings and similar, so good for a journalling site; eg ten people plan a meal together, do they want pizza, burger or that new veggie place, etc...

Poll #4091 Have a run-off option for polls

Open to: Registered Users, detailed results viewable to: All, participants: 46

View Respondents

This suggestion:

View Answers

Should be implemented as-is.
33 (71.7%)

Should be implemented with changes. (please comment)
6 (13.0%)

Shouldn't be implemented.
0 (0.0%)

(I have no opinion)
6 (13.0%)

(Other: please comment)
1 (2.2%)

Comments

[thorfinn]

We have preferential voting down here in .au too, and it is good. :-)

[ratcreature]

I would only be in favor if this really also could show things before the poll is closed or if you never close it, because that is what all current kinds of polls do. And the scales poll we already have also calculates things. I think it would be strange if one kind of poll behaved differently.

[matgb]

Fair enough; if it's doable then great, although not sure how you'd display it. Then, not sure how you'd display it anyway, might have to do a mockup.

I'm guessing, although the code is beyond my ability to read, that the calculation for a scales poll is easy, runoff polls aren't.

And there's no way I'm going to suggest a multiple winners runoff poll option, as while I'd love it, I suspect the calculation'd be a PITA (I have dedicated software to do it for elections)

[zvi]

+1

[aedifica]

+1

[kerravonsen]

+1

[pauamma]

I'd rather have a "feed raw poll data to a user-configurable S2 thingy" option. That way, you're not stuck with one voting system (or 2, counting the current majority-vote).

[matgb]

Heh, if you reckon you can code it, I'd be happy, I'm still taking baby steps in S2.

But wouldn't feeding it to S2 make it harder to do post specific polls? Although you could code them with variables I guess.

[pauamma]

Depends on the design, but not necessarily. (The "feed poll data to S2 code" part would require a perl-level code change, and that part could be designed with a way to specify a voting system in the form of a style, a view, or something.)

[kareila]

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.

I'm pretty sure we ripped that code out of DW already, so we'd be starting from scratch.

[matgb]

Fair enough, and understandable given they palpably never finished it, the reason I mentioned it was that a way of doing it, however flawed, exists, and could be built on or at least learnt from.

Backend code is so far beyond my current competence there's no way I could even look at it and judge, but I do know it's there, etc.

[kerravonsen]

Oh, I have been wanting this for years!

[daweaver]

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.

[matgb]

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.

Agreed. I like the idea of caching the results if the process takes calculation as well.

Need to work on a 'how this would display' mockup at some point, but can leave that until it's agreed for implementation and put ideas into Bugzilla.