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.
Richard D. Bartlett Thu 10 Nov 2016 3:42AM
@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.
Danyl Strype Sat 8 Apr 2017 3:46AM
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 Sat 8 Apr 2017 3:48AM
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.
Greg Cassel Mon 10 Apr 2017 8:34PM
Quite relevant to describing "decisions" or (a term I use more often) "agreements":
https://handbook.enspiral.com/decisions_agreement.html
James Kiesel Thu 10 Nov 2016 4:08AM
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 Tue 28 Feb 2017 2:05PM
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 Tue 28 Feb 2017 2:12PM
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 Tue 28 Feb 2017 2:35PM
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.
James Kiesel Sat 8 Apr 2017 4:27AM
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 · Mon 7 Nov 2016 3:31PM
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.