Thoughts on additional polling types.

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

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

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

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

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/

@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)?

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

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

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.

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.

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.

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

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.

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.

Quite relevant to describing "decisions" or (a term I use more often) "agreements":
https://handbook.enspiral.com/decisions_agreement.html

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.

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!

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.

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.

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.