November 5th, 2016 18:44

Thoughts on additional polling types.

James Kiesel Public Seen by 556

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.

John Gieryn

John Gieryn November 5th, 2016 20:42

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


James Kiesel November 6th, 2016 01:59

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

Alanna Irving November 6th, 2016 21:48

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).

Matthew Bartlett

Matthew Bartlett November 7th, 2016 07:30

@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 November 7th, 2016 11:51

Thanks for this voting processes which I do not know well.


James Kiesel November 7th, 2016 12:23

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 November 7th, 2016 15:04

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.)


James Kiesel November 7th, 2016 15:08

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

Greg Cassel November 7th, 2016 15:18

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.

Greg Cassel

Greg Cassel November 7th, 2016 15:31

Thanks @gdpelican for emphasizing an open source code base here. In addition to that, I think that it's highly desirable for free/unpaid groups to have access to Loomio's general toolkit on loomio.org. (And I'd personally consider additional polling types to be part of the general toolkit.) Low budget/ no budget groups are often unable to self-host Loomio.

Obviously I don't know all of the financial issues which Loomio Cooperative faces. However, I favor revenue models based on pre-funded R&D, paid customer service plans and (potentially) customized features for specific organizations. I think that releasing all general tools at loomio.org could ultimately help Loomio's fundraising by strengthening its goal of fostering true digital democracy.

Richard D. Bartlett

Richard D. Bartlett November 10th, 2016 03:42

@gdpelican, I am basically 100% behind everything you've said, and totally swooning with love and enthusiasm for your work.

@gregorycassel's latest comment did raise something for me though, which you might need consider for the generalised model: notification volume.

Right now, proposals are the "big guns" of Loomio engagement. If you start a thread and it is not getting much traction, you hit that green button and boom: people engage. Partly because of the shared mental model that proposals are important, partly because the request for input is really explicit, and partly because the architecture is optimised for notifying people about proposals starting, closing soon, closing, and reaching an outcome.

I suspect that we may want to keep some tools like temperature checks and polls at a low volume, and preserve the loudness of the proposal for HEY THIS IS IMPORTANT I NEED YOUR CONSENT PLEASE.


James Kiesel November 10th, 2016 04:08

Cool, thanks for that, it's an excellent point.

I see proposal volume as a bit tied up in the Quiet Threads conversation, and want to leave it for a later iteration, if only because this is a big paradigm shift in the aorta of our app; the less ventricles we staple on right now, the better.

Greg Cassel

Greg Cassel February 28th, 2017 14:05

I made a new comment here a few minutes ago before I noticed the new thread Experiment with some new polling types!. That's the right place for my commentary, so I'll comment there!

Bob Haugen

Bob Haugen February 28th, 2017 14:12

Greg, I got an email notification about your comment I think criticizing my silly poll, and now I can't find it. Was that the one you moved? I don't see it over there, either.

Regardless, I probably should not have created a silly poll, and apologize for doing so. I did not mean it as a comment that polls are silly as a feature. I was just testing the feature without putting a lot of time into designing a good poll. Please create a better one.

Greg Cassel

Greg Cassel February 28th, 2017 14:35

I just made a comment in the new thread, @bobhaugen , after fully realizing your poll's direct (but unclear) relationship to it. Sorry for the 'noise'! It's hard for me to balance my desire for reducing discussion thread noise with my reluctance to delete my own commentary anywhere.

Danyl Strype

Danyl Strype April 8th, 2017 03:46

I agree with Richard about making Proposals super-poll. Along those lines, I'd like to propose a change to the wording in the description under Proposal in the interface. It currently says "find consensus", but that's a bit vague, because all the new poll types are ways of finding consensus. Can I suggest something like "make a decision" or even "formalize a decision"? For groups where having a clear record of what decision have been reached and should be actioned is important, this wording would imply that the other poll types are ways of iterating towards consensus by guiding and supplementing the discussion, but a Proposal is the final decision itself.

Danyl Strype

Danyl Strype April 8th, 2017 03:48

I would also suggest, if you agree with my logic above, that you consider taking Proposal out of Facilitation Tools and putting it above them, in its own box, so it stands out from the other poll types in the interface.


James Kiesel April 8th, 2017 04:27

My current thinking is parallel, but not quite in agreement with, the above.

I'm imagining having a few decision 'pipelines', which will allow you to transform completed polls into a 'next step' poll automatically. Examples might be

Brainstorm (gather ideas) -> Dot Vote (which ones are good?) -> Proposal (let's do this one)
Meeting (when can we meet?) -> Check (who's taking notes?)
Poll (where should we go?) -> Check (who's going to organize?)

I'm thinking that as the decision types get used we'll notice common usage patterns which will inform some more of these as well.

Greg Cassel

Greg Cassel April 10th, 2017 20:34

Quite relevant to describing "decisions" or (a term I use more often) "agreements":


[deactivated account] April 17th, 2017 09:12

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: