Using a 'Block'

@richarddbartlett I think @alannakrause explains the problem to be solved quite nicely. In a nutshell; the software makes no distinction between a ‘no’ and a ‘block’.

I don’t think I’ve ever blocked consensus in person. I can only think of one occasion where I blocked, on an Indymedia email list. Consensus -1 was used, and life went on, but I felt deeply alienated, and eventually I did leave the group. So, I was profoundly disturbed when I found myself blocking in Loomio (slightly less so when others joined me, which is interesting).

In the past, I have made arguments against allowing blocks as part of consensus process at all. After all, if it’s not a situation where I can just avoid helping implement that decision, and my ‘no’ is not enough for the group to want to improve or defer the proposal, I’m probably better off not being part of the group.

However, as I discovered with Indymedia (and later with Oblong), this is one thing in an ephemeral protest group, quite another thing in an organisation I’ve invested a lot of time in, and that I depend on for key resources. IE if that organisation is a business co-operative on which I rely to make a living, leaving on principle has a high cost, and a drift towards dictatorship of the majority is a high risk. In such situations, the opportunity to block is essential, even if it’s rarely or never used, because the risk of a block derailing a project motivates the group to really hear and respect each other (David Graeber writes about this in his ethnography of Direct Action, which I strongly suggest you all read).

For the same reason, I think a block should not be treated simply as a “position”, which makes it tempting to use it as a strong ‘no’. A block should at least pause a proposal, as @aaronthornton suggest, if not close it.

How about this. A 'block' turns the whole pie red (warning: a group member believes core values are at risk of being compromised). It also resets everyone's position (although leaving their position comments intact), and allows the proposal text to be edited.

The discussion thread can then be used to understand the reason for the block, and the proposal text modified. Users can then take a position on the modified proposal.

I guess I haven't perceived the distinction between the no and block to be problematic. It would help me if we could dig into the problem a bit further before suggesting solutions.

p.s. +1 for reading Direct Action - it is incredible.

Problem: 1. People don't understand the difference between 'no' and 'block' 2. There doesn't appear to be a meaningful difference between the two.

Simplest solution that at least addresses the problem somewhat: If one person blocks a proposal the whole pie gets a tinge of red. Groups can make of this what they will.

If, at a later stage, loomio starts to have a list of approved proposals in this group etc, then obviously a proposal with a majority in favor but one 'block' will have been deemed not to have passed.

We address this in Econsensus and in our internal consensus process by using "Danger" rather than "Block". To me, it feels less final and violent than "BLOCK!" so maybe it feels less risky to use, and people occasionally use it in our decision making. This feels different from the UK activist consensus processes I've been involved in which still talked about "blocks" although that felt clumsy and it was rarely used, as people seem to be talking about here.

Some of the terms we are using at the moment ("Concerns", "Danger") come from the Likert scale used in Dotmocracy. We're talking about making it easy for users to redefine the scale we are using so that the terms match their understanding of their decision making process - maybe at first just renaming the terms that we have, and then we've also talked about making it open-ended with as many or few terms as people want, although that is definitely a far-away pipe dream at the moment :-)

We've been discussing the idea that groups will probably always need to define how they will use an online decision making tool, unless it's made totally rigid to one system, and what their own norms are. E.g. how does someone decide a decision is made, what are the norms for deadlines etc. We're currently looking into providing individual org pages where groups can record ad-hoc info like this.

Thanks for the insight @tomlord - we've talked about giving groups the option to configure as many decision buttons as they like, with names, colours and symbols that suit them.

Personally I am quite attached to the idea of having under-specified protocols, as it forces people to engage with each other instead of with a rule book.

Obviously this won't suit some groups. The challenge for us is how do we support groups with stricter protocols, without constraining those that prefer to be more fluid?

plugins

@richarddbartlett

The challenge for us is how do we support groups with stricter protocols, without constraining those that prefer to be more fluid?

With more options in group settings and each group enables what they want and what they don't!

Having options early on the development of Loomio is important. It will significantly increase the number of groups/organisations that can use it out of the box.

:-) where is that edit button? Apologies for the missing 'in'. It should read 'in the development'.