Thoughts on additional polling types.
Something clicked in my head yesterday while I was thinking about how great it would be to have additional polling types for Loomio. Here's a brain dump.
How our system works now:
A motion
- Has a name and a description
- Allows each person to participate (create a vote of some kind)
- Is temporary (i.e. has a closing time, and a concept of being open or closed)
- Has an outcome
- Has ‘votes’ and ‘did not votes’ (i.e., participants and non-participants)
- Following from this, it has a participation level, i.e. ’25% of eligible people voted')
A vote
- Belongs to a user and a proposal
- Can only be created while the proposal is active
- Has a ‘previous vote’, i.e., you can vote more than once, but your new vote takes the place of your old one.
- Has a position of ‘yes’, ‘no’, ‘abstain’, or ‘block’
That's pretty much everything I can name about those models.
On a slightly different note, here’s a list of some other voting systems we might be interested in implementing in the future:
- Temperature check (yes / no to this idea)
- Spectrogram (each person rates from -100 to +100 their feelings on the idea)
- Loomio proposal (what we have now)
- Multiple choice polling
- Election polling (pick one of an arbitrary # of options)
- Dot voting (people get X dots to distribute amongst Y ideas)
In order for these things to work nicely, here's what we need to change:
A motion
- Has a concept of what kind of votes it can create (similar to an event’s ‘kind')
A vote
- Has a position of ‘yes’, ‘no’, ‘abstain’, or ‘block’
- Has an arbitrary value
For dot voting, would be { “option_a”: 1, “option_b”: 3” }
For temperature check, boolean true/false
For spectrogram, integer 1-100 for/against (or maybe -50 to 50)
For traditional Loomios, could be an Enum (yes no abstain block)
That's... not a lot at all! The primary work is making vote value polymorphic (probably changing the 'position' field type from 'string' to 'json', or possibly separating vote position out into it's own table(s))
Once we do that, we simply need to create/update our templates (one for the proposal, one for the vote form, one for email. We'd also add a 'proposal_kind' dropdown to the existing create proposal form.), which will take into account the possible vote values (a pie graph for loomios, bar graph for dot voting, etc.).
This bit will be a little tedious, but not overly time consuming (the hardest part will be writing emails for each one imho).
I think this is the perfect premium feature, as I believe this will offer a tremendous amount of surplus value, while allowing us to keep our core, free offering robust and useful.
I’m going to present this as a thing I could spike on next sprint, while we are getting our thoughts around product strategy.
I'd love to hear your thoughts on this, technical or otherwise.
James Kiesel Sun 6 Nov 2016 1:59AM
I think the difference between 'dot voting' and 'multiple choice polling' is that you can express your stronger feelings for a certain option by giving it more dots. Multiple choice polling might be useful for a doodle-like functionality, like 'I can go to meetings on Tuesday and Fridays, but not Saturdays.'
I'd also love to hear what other kinds of processes folks have in mind, keeping in mind that this particular chunk of work is more like 'Let's enable the architecture to allow for more diverse decision-making', rather than 'Let's implement a ton of new features in this direction right away.'
Alanna Irving Sun 6 Nov 2016 9:48PM
I went into a lot of my thoughts on this in the thread about convergence options, including a design for a single voting interface that combines Borda Count, Condorcet Count, Approval Voting, Ranked Choice, and Majority Voting.
I think combining various voting methods with Loomio's design emphasis on both deliberation (hearing from others can change your mind) and interpretation (setting qualitative outcomes explicitly indicating that no voting outcome is an unbiased representation) could be extremely powerful.
My vision for how this would work in our app is that you could pick other "decision" formats in the current "proposal" area (tabs or a drop down or something showing the various options and what kind of decisions they are good for).
James Kiesel Mon 7 Nov 2016 3:04PM
That list of options makes me pine even more for building this kind of arch, because I think it's a great delineation between what 'Basic Loomio' is (get some folks together and talking, save some time, make your group processes better, make some decision, wee!) and 'Premium Loomio' is (Have an existing process or paradigm? Are you discerning about the kinds of decisions you want to make within your group? Are you knowledgeable about enough about your own group's decisionmaking that you want to tweak the dials some? Do you know what the word 'Condorcet' means without googling it? You might want to check out our next tier.)
William Asiata Mon 17 Apr 2017 9:12AM
Just found out about Loomio's new polling features today, really cool to see.
An aside about election polling:
I'm personally interested in seeing some kind of combination between Condorcet ranking/preference and approval voting methods for 'office-ial' elections.
Something that I feel is important to take into account is to think about how an election voting system can be designed to always achieve the "least worst" or conversely the "most widely agreeable" outcomes so that the result is as inclusive of the diverse voting base as possible, in such wise that the "winners" represent a unity/consensus of the voters from a maximised spread of voters that were able to be included in calculating the outcome.
Some random inter-related academia:
https://www.math.auckland.ac.nz/~slinko/
https://www.cs.auckland.ac.nz/~jliu036/publication.html
http://www.cmss.auckland.ac.nz/
https://www2.warwick.ac.uk/fac/cross_fac/cim/people/student-researchers/nathalie-mezza-garcia/
Matthew Bartlett Mon 7 Nov 2016 7:30AM
@gdpelican do you have an idea of how much work it would be to make that architectural change (before actually adding any new voting modalities)?
DOSSE SOSSOUGA Mon 7 Nov 2016 11:51AM
Thanks for this voting processes which I do not know well.
James Kiesel Mon 7 Nov 2016 12:23PM
I had a play with it yesterday, and it's up here, which passes the test suite (well, almost).
Sooo... not much. A little more arch work and a regression testing round. Also would need a thorough code review by @robertguthrie
EDIT: I'm going to retract this a little bit. I'll want to pull the existing vote functionality out into a plugin, which will take some time to untangle on the frontend. Then I want to make an explicit command in the plugin arch for adding a new vote type, and making sure that works (I'd probably start with yes/no polling because that's simplest. I'd estimate 3-4 days work.)
James Kiesel Mon 7 Nov 2016 3:08PM
Oh, in reference to a conversation that I had with @gregorycassel the other day, I want to emphasize that just because we're thinking about 'Premium' features, that does not mean that our code is / will ever be closed source, or that you need to pay us to use them. I won't got into tech details here, but essentially the code will live in public, where any third party installs could install them at their leisure.
Greg Cassel Mon 7 Nov 2016 3:18PM
Instant runoff voting (or ranked voting), which @coopchange mentioned, is IMO just right for situations in which a group generally beliefs that it must choose one option from a limited set. Dot voting can be used for that too, but it only works well if users actively adjust to others' inputs.
Dot voting can be quite powerful, but it comes close to some potential use-cases for CoBudget. So, assuming that CoBudget develops well and the two apps are effectively integrated, I'd tend to look more towards CoBudget on that front.
By contrast, I think that simple yes/no 'temperature checks' often do more harm than good, and don't justify the attention they ask of communities.
Five point scales from Strongly Agree to Strongly Disagree are one of my preferred metrics. I believe they're way underused outside of psychological assessments. In addition to five point ordinal scales of that sort, which we're all familiar with, it's possible to use "continuous"/ quasi-analog ((possibly -100 to +100 digital clicks) sliders with scales which have five prominent default positions.
agree/disagree/abstain/block is IMO currently indispensable for consent-based deliberation and decision. In theory, it could be improved by a system which accepts different intensities of "agree" and "disagree" to be registered, as long as "block" is present. Practically speaking, however, I think that the simplicity of the four-position system is quite helpful for people trying to make the profound leap to consensus-based deliberation and decision.
john gieryn · Sat 5 Nov 2016 8:42PM
Glad to see voting types come up- on first glance it seems a great idea.
Is Multiple Choice Polling really the same as Dot Voting but you have as many dots as there are options? Or is there a difference?
I'd love to see what other voting types the network has kept in mind (i remember there being a thread on it once); one that I would love to see is Instant-runoff Voting