Hide vote results until set threshold/date

I have found the same thing @timhartnett - that some open discussion first makes for much better proposals. That for me is a key difference between Loomio and some other decision making tools that pre-suppose a set of options, or jump straight to finding solutions too early. On the other hand, sometimes throwing a proposal up is the fastest way to get people to engage, highlight the main issues, and find out the real nature of the problem. That's why a proposal failing can often be a really productive step in the process, since the next proposal is always an evolution in a better direction.

As for the problem of early voting- I think Loomio could change the voting options to be more tentative, and thereby reduce the polarization of early voting. The options could be Strongly Support, Inclined Toward, Abstain, Disinclined, and Not Supportive. These options would move the mood away from adversarial debate (which is the real enemy of collaboration).

To further improve things, Loomio could offer the above voting options during the discussion period, and then there could be a "final decision" round wherein the votes were simply Yes, abstain, or No. Then, each group could apply their chosen decision rule to determine if a proposal is now a decision. This final decision round helps differentiate the value of "straw polls" during a discussion that show the group whether support is building or decreasing. And "final votes" wherein participants commit themselves to a definite choice so that a clear tally can be taken.

At any rate, the red hand "block" vote should be removed. It is very damaging to a consensus process to have people casting such a vote, especially early in the game. Additionally, the word pre-supposes that all groups offer the option for individual to "block" a group decision. Many groups committed to a collaborative, consensus-building process do not offer this option. So Loomio's current options are likely to confuse people in such groups.

@timhartnett the straw poll / temp check kind of thing is definitely already under consideration. We've been calling it the "ideas feature" and it's a part of the plan for Loomio 1.0. This will allow groups to test suggestions before coming to a final decision.

I personally disagree with your idea that the block feature should be removed. Personally I think it's the most important feature of the entire app, even though I hope most people never have cause to use it! That said, what I'm interested in doing is allowing the button labels, descriptions, and colors to be customizable by the group, so they can decide for themselves what the options mean.

Allowing groups to customize their own voting option labels is a great idea! I am much relieved. To explain my objection to a "block" vote: Discussions can die quickly when someone threatens to "block" a decision, especially early on. Other participants lose motivation to participate when a group member wields power in this way. Why keep talking about it when someone has already indicated that they will block it from ever happening? In groups that do allow someone to block a proposal, that option must be used with a very responsible and informed understanding of the ethics involved. When a consensus process ends in a block, the group will likely experience widespread disagreement and discontentment with the result. The many toxic by-products of this are descried in my book. If the objections of the blocker are addressed by the group, the collaborative process can continue. So the only healthy block is a block that influences a discussion (rather than stops it) and results in a decision for which there is widespread support. "Block" is not a very good word for such a contribution. Though I am aware that it is the word consensus facilitators have been using since the 1970s.

@timhartnett I think you're raising really good points. I'm going to post what you said in this thread about blocks and continue over there :)

Just stumbled across this issue as well, both anonymized voting and hiding the votes until the proposal is closed would be very helpful. Any chance to get this on the roadmap @alanna? :)

We're currently working on a reimplementation of proposals which will take these ideas into account. Some things we've been thinking about:

• Don't show the results until you've voted, a la twitter polls
• Decoupling proposals from groups, which will allow users to vote without having a Loomio account, by providing only an alias (and maybe an email which won't be visible to other participants)

This will allow us to cater to 'high trust' groups with a dedicated Loomio group, while allowing 'low trust' groups to participate using only a shareable link

You can follow along at home if you'd like with the polling-w-discussions branch on the repo.

@gdpelican that sounds very exciting, thanks for the link!

Voting on a proposal sounds like the end of a process, the full stop. In my experience, it rarely is, especially for complex issues. There will always be unanticipated consequences, learning and new ways of understanding things. All of which creates an imperative to revisit past decisions. Sometimes hardly any time passes before a decision is revisited, sometimes it could be years.

For me, decision making is the time for individual and collective learning. That's why I strongly support practices such as discussions and the structured exploration of perspectives before making proposals, and I strongly support reason-giving when voting as this can lead to further individual and group reflection, causing people to change their votes and/or the creation of improved proposals. I'd be very concerned if changes resulted in the group not being able to see the reasons behind votes as they are being cast. I also wonder how many people are aware that they can change their votes, i.e. that decision-making is a dynamic learning process, and whether there are ways to make this clearer.

I agree with groups being able to decide their own strategies and processes as Loomio is used in a wide range of contexts. For example, for groups made of people who know each other or share an affiliation with an organisation, power and status dynamics can adversely affect not only voting/decision-making but all communication/discussion. In this situation, an organiser might consider requiring all participants to use a pseudonym. But in other situations, e.g. some time-limited public engagement processes, participants may not have prior relations so power and status dynamics resulting in 'group think' might not be such a concern.