I love the idea of giving groups the option of setting up their own decision-making protocol, both by making the decision-button labels customizable, and by providing a specific space on the Groups page for groups to describe their agreed decision-making processes.

We've already seen a need for this in cases where Councils use Loomio as a public consultation tool - the group members in a case like that are not so much a defined decision-making body as participants in a collaborative discussion where people use Loomio to generate shared understanding and build on each others' ideas rather than making concrete decisions.

I'd be extremely reluctant to go down the track of automating 'blocks' (i.e. disabling voting etc), or anything else that would lock us in to one mode of decision-making.

In my mind, Loomio should strive to be as neutral a space as possible, so diverse groups are free to implement whatever decision-making protocol they want. This is all about lowering the cost of more participatory decision-making so that it becomes an easier option, not pushing people into consensus processes that may or may not be appropriate for them.

PS thanks heaps for sharing that @tomlord!

For anyone that hasn't checked it out already, Tom's amazingly awesome group Aptivate have been working on a really interesting open-source tool called e-Consensus.

Heaps of great process ideas for inspiration!

Stoked to have your expertise in here Tom :)

Thanks @benjaminknightloom :-) I haven't yet looked at Loomio's cool-looking markup text, and I left the links to my world stuff on my post on the introduction page, so thanks for giving me a context :-) And thanks @richarddbartlett for your context - I'm sure there must be loads of previous discussions like this that have gone on that I'm missing, so if I'm saying stuff you already heard then prod me :-) In general is this the place to raise feature suggestions or bugs, or do you use mainly github, or a combo, or something else?

@benjaminknightloom - totally agree about the flexibility and for groups to use things how they want, it's something we've been keen on over here. We have no idea how people will really use our stuff :-) And yes, pieces of a tool like this such as the discussion board in itself can be useful. I'm just about to start an instance of Econsensus for my housing coop of 85 people, where we don't want a discussion board (too many flame wars!) and we DO want to record policy changes that we've made over the years, so we'll be focusing on the decisions, not the discussions. We're agonising a bit over the difficulty of modularising all this stuff so that we can hive off useful pieces like this for re-use, and don't try to create "the one black box system that can do everything", even though we've probably drifted along that route a bit.

On a provocative note, seeing as it's Friday :-) Given that idea of flexibility, I'm curious about the behaviour of Loomio's deadline functionality. It seems that you have to enter a deadline for every proposal, and once it has passed, there is no way to bring a decision back to life. How does that work for your groups? The obvious edge cases I can see are... Do you ever get people who want to have an open ended discussion about something with no fixed deadline? Do conversations finish halfway through sometimes? How do people review decisions they've made - I guess you could create a new one that has precedence, although it might become unclear which decisions are "made" and which are "old" or "we didn't consent to anything here"... Or am I missing some technical tricks? Keen to understand how people use this model.

We are probably flexible to a fault here, in that anyone at any time can say "hang on, that decision is now un-made and it back in the proposal stage again!" This means that it's easy for us to review things in a month and record any changes to previous decisions, if we want to try something out that we're a bit nervous about. And we're far less savvy about deadlines, we display them as a table that can be sorted on, but we don't even send email reminders for them yet. One day...

Have a good weekend!

Does using a block force people to enter a position explaining why they are blocking?

If not, I think it should.

As @strypey has alluded to, the usual understanding in consensus groups is that a block should only be used if "core values are at risk".

Or, as described in the Seed for Change guide to Consensus: "A major objection isn't an 'I don’t really like it' or 'I liked the other idea better'. It is an 'I cannot live with this proposal if it passes, and here is why...!'

Similarly the Open Organization Guide to Consensus Decision making states that "It is acceptable to block a proposal only if you think that it violates the fundamental principles or purposes of being in the group, or if you think it endangers the very existence of the group. "

Sociocracy and Holacracy also take interesting/ potentially useful approaches when it comes to objections/ blocks.

In sociocracy they have to be "argued and paramount objections" which is essentially someone saying "some aspect of me is in danger of going out of safe limits or will be unable to perform as required is this proposal is implemented".

In Holacracy they have specific narrow rules about what counts as a valid objection e.g. will this harm us or move us backwards (not just fail to move us forward), would this objection still exist even if this proposal didn't go ahead? is the proposal safe enough to try?

The similarity between all of the is that you can't just block without good reason, so I think people should be forced to give a reason when blocking, ideally with some explanatory text, e.g. please explain how this propsal will harm/ damage/ is dangerous/ goes against core value/ violates fundamental purpose and principles etc.

Yes I have heard a couple of ideas that would be great treatments for the 'block' card. One is it requires a proposal on how to resolve the block, so you can't block unless you are prepared to put energy into resolution. This stops people taking a blocking role but not involving themselves in constructive resolution. The second is this idea the @josefdaviescoates has raised about having. To enter an explanation. Right now you have the option of explaining and as little as Block in used in Loomio, I have never seen it used without an explanation. I have also seen other people inquire further into the reason for the Block, and in some situations people challenging it didn't feel like a good enough reason to Block. This has given me a really high trust in the overall group and how it responds to Blocks. I think we could make a explanation linked to Blocking, but I am also totally comfortable that discussion are not being damaged and in some instances are being improved by the whole group taking responsibility, seeking clarification or issue ing challenge. Ya for group wisdom. I love it.

The problem as I see it is in the interaction of two aspects of the current UI, each of which was set that way good reasons:

• one proposal per discussion at a time
• uneditable proposal texts

Let's say someone has blocked a proposal, and offered a counter-proposal (as a comment) which is not just an amendment, but incompatible with the current text. In the current UI, the proposal text cannot be edited to make this amendment, even if there is support for it in the comments. If the proposer digs their heels in and refuses to close their proposal early (or even extends it), the group has to talk them around before someone can advance another proposal (or start another discussion or some other work around).

Now this problem may already be solved by the plans the coding group have for the next major roll-out. If would be good for those of us not working from Loomio HQ to have a place we can keep in the loop on feature decisions which have been made by the code team (on Loomio.org somewhere?).

It seems to me that, as it stands, the software allows someone to block progress by refusing to let their failed proposal close, as I did recently on the 'Editing Comments' thread (to my shame). In hindsight, I would rather that @neilmorris pushing the block button had closed my proposal, because I think knowing that would discourage him from saying 'block' if he really just mean 'no'. Then, if he did 'block', I would have found it easier to accept that he was serious about it, and we could have immediately shifted the discussion onto what the conflicting issues were/ are, and what amendments might pass consensus in a future proposal.

It's funny revisiting this thread after talking to @richarddbartlett and @benjaminknightloom about a Pause button, and seeing that this was the behaviour @aaronthornton suggested for the Block. I think if it's worth having a 'block' button (and it may not be), it's worth giving it a distinct effect. I'll admit though, that the problem I'm addressing ('state proposals'?) could also be fixed by other suggestions being discussed in other threads:

• allowing editing of proposals on-the-fly
• allowing multiple proposals on the same discussion
• a draft proposal feature

i saw today a person in my group use veto instead of no, and worry little because i don't know exact what effect can have to proposals.

Is it just simple strong no, or it has any effect like the proposal can't close?

At the moment, what effect a 'block' has on the decision depends on what rules you set as a group. As noted in previous comments, in consensus-based groups, a 'block' is usually a pretty clear sign that either:
* something is very wrong with the proposal
* someone is in the wrong group
* someone in the group is feeling disempowered and is using the 'block' as a defensive tool

some people use it for no reason. instead of no they are using block, and i don't know how the groups are going to work if someone uses block all time.

Will be an option in the future if some groups can disable it???

Why block could be considered as a big NO, choosing no may also be a "danger"" in some situation.

Blocking a poll, imho, is not necessarily saying no...

I see no reason why one proposal at a time per discussion shouldn’t remain, along with having uneditable proposal texts... provided the group has protocols in place and a proposer can remove their proposal before the time is up. To test my views and the group I’ll put a proposal.
As an example, the group could have rules like:
1. If a proposal is blocked it cannot pass.
2. The blocker must offer reasons for the block and a resolution.

Under these circumstances, the blocked proposer has the choice of continuing discussion in the hope of resolution, or ending it so another proposal can come forward. The proposer wants to keep the process alive, not stall it.... so why refuse to close early or extend it, which would be counter-productive? In my view it’s the proposer who should have the right to either continue discussion in hope of resolving the block, or choose to close the proposal, but NOT the blocker. Once closed another proposal can then come forward.

@milesthompsonkapit I agree. Implementing protocols should be part of the development of this software. I'm proposing a starting point for discussion and to identify the real issues for development. In my view introducing “Ideas” will improve the collaboration/consensus toolbox dramatically from this starting point.

Will be an option in the future if some groups can disable it

I hope so. Having a 'block' option (whatever it does) is useful for a tight group who are agreeing on a course of action to take together. Removing the 'block' button would be the simplest way to make a decision-making group into a consultation group (which the Loomio Community is meant to be, for example).

The proposer wants to keep the process alive, not stall it

In practice, this is not what happens. Despite the best of intentions, it's all too easy for the proposer to become attached to keeping their proposal alive, regardless of its effect on the process. I've done this, and I've seen other users do it on numerous occasions.

Also, as @christaklis points out, a 'block' which has no immediate effect is used too lightly. I've also seen this happen a lot, particularly by people who are new to consensus process, and don't really understand the tradition of what a 'block' means.

The proposer wants to keep the process alive, not stall it

In practice, this is not what happens. Despite the best of intentions, it's all too easy for the proposer to become attached to keeping their proposal alive, regardless of its effect on the process. I've done this, and I've seen other users do it on numerous occasions.

Also, as @christaklis points out, a 'block' which has no immediate effect is used too lightly. I've also seen this happen a lot, particularly by people who are new to consensus process, and don't really understand the tradition of what a 'block' means.

If the 'block' has no immediate effect - even as mild as turning the whole pie red - it might as well be removed from the app.

The point I am trying to make is that maybe users of loomio just need to learn to become "loomio savvy". I'm first in with a proposal so I'm "in charge". My expectation is that others in the group will say why they disagree and we all work towards consensus. We discuss the proposal's strengths and weaknesses. In my view we can't blame the tool for our own best intentions on how to collaborate in this space. Bring it on... block me! Provided we debate why. The group is all "listening". I'll either address the reason given, or I see your point and remove the proposal. Blocking me, or even disagreeing without a reason is not collaboration...

If the proposer becomes attached to keeping the process alive and stubbornly sticks to their unchanged proposal they deservedly get blocked. Someone else puts a proposal. The group needs rules about dealing with difficult participants, and what a block means, not the tool. How the tool is used is up to the group, and I'm afraid even this group of consensus-devotees needs boundaries. Of course Loomio can always provide advice around group collaboration...

Now, if in the course of this discussion someone comes up with something better.... then great! Currently, I'm thinking I'll have to extend the proposal because I am yet to be convinced with a sound argument or good solid debate that there is something better. @barrybaker , could you elaborate on polling?

Hello @deansatchell . At the moment the way my test group want to use Loomio is to use a poll to narrow down a bunch of alternatives to then lead a proposal about. Or a series of polls to get to a proposal.

So choose a favorite of four game systems, then a time period, then a style of game, then a proposal about more details about the game world's .

Just a proposal means hard to gauge preference on a path if there are concrete choices as you neerd to one a proposal for each choice...one by one..

Thanks for your comments @joshuavial , as the proposer I appreciate an explanation for disagreeing. This proposal is a test case to explore issues around whether the proposer should have control. There was considerable discussion before I put the proposal and opportunity for anybody to propose (and take control). In practice the only control I have is to extend the proposal, which I would not hesitate to do if discussion were continuing towards consensus... or if I chose to be disruptive. I ask the group: Should another participant, leader or facilitator be able to take control of my proposal? Should I have the right to decide when my proposal ends, for the “floor to be opened” for others? If not, why not? In my view the proposer should have control over the time the proposal stands because the proposer is the one putting the most energy into reaching consensus.
My concern is that once a group has admins or any individual (leader) in charge the opportunity for this software to be truly collaborative is lost. Maybe somebody does need to be in charge, but my suggestion is that facilitators would not be required, provided that the group has predetermined rules (that for example deal with disruptive participants and blocks). My proposal provides simple, effective decision making protocols: What block means is predetermined by the group; one proposal at a time for linear discussion while keeping the focus on the proposal at hand. Providing alternatives is nicely addressed by @matthewbartlett in the “Ideas” discussion. No need to edit the proposal (good reasons are given in other discussions why this is problematic). The proposer can always remove it and introduce another or let others propose. I’m looking for good reasons for disagreement.
@strypey , could you provide details please on where my proposal has flaws in theory?
@rossomullane and @christaklis , if the proposer could deactivate block, might this give the proposer too much control?
@barrybaker , what you describe is linear but you want to vote on multiple choices. Is not offering the option of polling in my proposal the basis for you disagreeing? I’m not against implementing further protocols.
@raphaeljadot please explain your reasons for disagreeing, I am seeking consensus.

@deansatchell the best way to not give the control to the proposer is to let the admins decide with an option for the group and/or subgroups to disable it or no. It is so easy.

For example my group doesn't want for now the block, but maybe a subgroup wants it. Why not have the option as an admin to disable it for the group?

I disagree mainly on "one proposal at at time... no issues are identified which justify a change to this."

From our experience, it would be really useful if we could ask several decisions at the same time in the same discussion.

Imagine we create a topic called "OpenSource convention", It would be great to be able to ask in the same discussion
"Do you agree if we invite Microsoft at the convention"
and
"My friend make the proposal of building some cakes for the afternoon, is it a problem ?"
and any other decision related to the organization of the convention without having to wait for the first decision to be taken.

@deansatchell I have no issues with a proposer having control of their own proposal. That's as it should be. I do have a problem with one proposal at a time as I think the ability to explore multiple options in parallel and see which ones have the most support makes the tool much more useful.

One of the reasons in person consensus is so hard is that only one person can speak at a time. We definitely need to have a focal point for our online discussions but I think helping groups process information in parallel instead of in series substantially increases the appeal of collaborative decision making.

For example, if I had the ability to fork your proposal and make an amendment or two to a new one we would start to get a lot faster progress towards an outcome the group agrees upon.

I agree that groups should have flexibility to set their own protocols around how blocks are used, but I don't agree that the way Loomio currently works is ideal. I think it's a given that we'll be developing it further, and intensively user-testing along the way to come up with the most effective, dynamic, flexible system we can design :)

For some context, one of the most consistent pieces of user feedback we've been getting is that it would be really helpful for people to be able to discuss more than one proposal at a time. I think the 'ideas' feature will go a long way to address this, so we'll see how that goes as a first step.

In fact, this decision is a good example of the interest of having multiple proposal at the same time. At least @joshuavial disagreed because of point 2, while we could have another position on point 1 and 3 :)

The current decision is a confusion on its ow as it covers three separate proposals. I feel that a good proposal should be the prime one, allowing subsequent decisions to be made on subsequent proposals. If it turns out that the original proposal is out of sync, IE not the the prime one, then the discussion should suggest that the proposal should be withdrawn and a new one put up.

    If the proposer becomes attached to keeping the process alive and stubbornly sticks to their unchanged proposal they deservedly get blocked. Someone else puts a proposal.

Nobody else can put a new proposal if the proposer gets attached, and keeps extending. This is exactly the problem I described.

    Currently, I’m thinking I’ll have to extend the proposal because I am yet to be convinced with a sound argument or good solid debate that there is something better.

See what I mean? ;)

I have described the problems caused by the statuo quo you propose sticking with, numerous times in some details. Particularly in my comments 13 days ago in this thread. However, the comment below pretty much sums up the problem.

I understand that a 'block' doesn't mean anything in the Loomio Community, as it is a consultation group, rather than a decision-making group.

What I'm doing here is a bit of role play, to test Dean's theory that a proposer will be more committed to the process than to their proposal. If Dean is right, he will look at all the 'no' positions, and this 'block', realise his proposal is a long way from the consensus, and let it close so another proposal can be made.

BTW I think the "ideas' feature will help a lot, as would a straw poll feature, as they will allow groups to map out the options before proceeding to a formal proposal.

Thanks @strypey , yes this scenario is a role-play to explore whether appropriate conduct is more important than features. And to gain insight. So is the software lacking essential features, or do people just need to learn how to use it?
I’ll also assume that these group rules apply:
1. If a proposal is blocked it cannot pass.
2. The blocker must offer reasons for the block and a resolution.

Extending a proposal indefinitely is disruptive behaviour and this also could be dealt with in group rules. In my case I did extend only a brief period for discussion to continue. I know eventually I would be seen by the whole group as disruptive if I dig my heels in, which would not serve my purpose. So looking at the discussion now, I have a choice on whether I continue with the current proposal or let it fall. Winning the group over with the current proposal is gonna be pretty hard now that I’m blocked. Its failing anyway.... However I can see that consensus might be achievable by dividing my proposal up, as there are 3 components:
1. Group rules are predetermined
2. One proposal at a time
3. Only the proposer should be able to close their proposal.
I continue to believe that the components 2 & 3 would need to remain intact for the “Ideas" feature to work. So, based on the comments and positions, here we go.... Proposal: Only the proposer should be able to close their proposal before it times-out. Proposal: One proposal at a time. I’ll also close the current proposal and replace with “The group should make their own rules around block.”

Group rules can and will modify the way a group uses Loomio. For example, if there was no 'block button, a user could say that they 'block' the decision in the comments, or in a 'no' position statement. If there was no Proposals system at all, users could put proposals in comments, and use 'likes' and reply comments to see how popular they are.

However, a Loomio discussion like that would be no more useful than a vanilla Forum topic, or a FB discussion. Hard-coding the Proposals engine, and the ability to take the traditional range of consensus positions ('yes', 'no', 'abstain', 'block'), gently leads users towards a consensus form of decision-making, where just coding a yes/no option would lead them towards polarization, and a straw poll would lead them towards majority-rules. The medium is the message.

In face-to-face groups I've practiced consensus in, the purpose of a 'block' is to prevent a majority bullying or shouting down a minority, even a minority of one. This power to 'block', and the frustration it creates towards the person blocking, creates a natural consequence with discourages people from using a 'block' unless it is really justified. For this reason, I think a 'block' on Loomio should have the same effect it would in a face-to-face meeting; killing the proposal in its current form until discussion illuminates and resolves the issues raised by the 'block'. Otherwise, there's really no point having a 'block' button at all.

@strypey something different than "no" can also be a strong effect. Blocking imho is blocking, but from a logical POV, a no is not the only danger.

Imagine I make the proposal (all is of course exagerated)
"We should make loomio a proprietary software"
Well someone could use block as a big NO, because it's a danger related to the philosophy of the project.

Now I make a decision
"we should keep Loomio open source, even though we could sell it at a very expensive price if it's closed source"
And the suddenly people become greedy and say "no, let's make it closed source, and earn a lot of money, yum!"
What can we do with a big NO?

I meant a "yes" is not the only danger.

I definitely support custom workflows and processes for different groups but I think we need to make it really easy for people to have visual queues about how things work (who facilitators are, who can comment, who can vote etc.)

I'm all for adding features that provide cues and facilitate group rules and conduct. Meantime processes and protocols are evolving and groups can currently manually customise these to suit the group. Software implementations will follow. Some things may need to be consistent between groups, but different groups will have different requirements.
If rules are set by a group, in order to participate one must abide by these. If the group doesn't like core functionality, they will override it. @joshuavial do you have ideas about what core functions should be the same in all groups? I agree there could be visual cues about who facilitators are (if the group wants them) who can't comment (if the group accepts that such restrictions are to take place) or who can't vote (again if the group accepts such a protocol), but my proposal is more specific. I am proposing that the group needs predetermined rules around what is "block". Because you have disagreed, as proposer what I'd like from you is a suggestion.... a core function that could do better, that will end up the proposal.

Hi @strypey, In the face to face group you describe, the group had a simple rule around block. The rule had a purpose and this must have been predetermined and understood by the group. That is all I’m asking here, that the purpose of the block is predetermined. Different groups may want to set their own rules to discourage people from using block unless it is really justified and may not want the proposal killed immediately. Personally I feel that would cause grievances, and is not as good as these simple group rules:
1. If a proposal is blocked it cannot pass.
2. The blocker must offer reasons for the block and a resolution.
These keep the process alive and the proposer might offer something that the blocker accepts and remove the block themselves. Different groups will seek and achieve consensus in different ways. Defining what is frivilous use or what is a threat to the group is highly subjective, so surely it is the group who should decide on how block should be used?

aside: @joshuavial your comment rise an interesting concern, you say that you support the custom workflow and process, but disagree with the decision entitled "the group should their own rule"
In fact, you disagree with "rules would have to be made by the person starting the discussion", if I'm correct, and it finally goes to a disagree.

Technically it's not a problem, of course :) Just it gives a distorted perception.

Oups, i posted too quickly, I don't mean that your position here in this case gives a distorted perception, but talking in a general way (hard to differentiate when someone partly agree or totally disagree)

@raphaeljadot I agree that each group should be able to set it's own decision making protocols and that a general principle of loomio should be to build core functionality that is the same for everyone but groups can assemble that functionality into their own beautiful processes like lego blocks.

Examples of things which should be configurable would be things like (from the top of my head)

• % of people participating required to pass a proposal
• which sets of people can view/comment/vote on a discussion
• minimum length of time for a proposal
• clarity on what a block means (text description or perhaps select from options)
• rules around reopening decisions that have been made (our rule in craftworks is at least half the number of people who participated in the proposal need to be in favour of reopening it)
• I think the option of removing block is a reasonable one

These configurations form what should be a formal document outlining the decision making protocols of a group or sub group.

Whether rules are specified as text or configured in the software makes no difference to the current decision. I thought it was clear that I am only proposing text protocols as the starting point. These would then provide experience to develop configurable protocols. @joshuavial you have specified some protocols, however I can't see how what you have said is different from the proposal you have disagreed with.
What I am saying is that loomio currently does not have an appropriate place where the group can have text protocols. The discussion context can be changed by anyone so is not appropriate. The only place where protocols can reside currently is in the comments area and because they must be predetermined the only option is for the person starting the discussion to put decision making protocols in the first comment. This is not ideal, nor adequate.
Before setting up configurable group protocols there just needs to be somewhere that the group can have their formal text outlining the decision making protocols of the group.

@deansatchell agree completely about groups needing a place where their protocols are defined and text is a great place to start.

The main objection I have to the proposal is about groups redefining what block does. I think a block should be a block, we may not know what that is completely and if groups don't want to use it then that should be fair enough but when they do then I think it should do the same thing in each group.

I honestly don't think consensus will be reachable on a definition for block. I don't even think consensus is achievable on whether block should do the same thing for each group. I won't change the close date for this proposal and there certainly isn't a clear course of action.

@joshuavial your post on what could be set by the group was incredibly useful to me, thank you!

Dean:
I honestly don’t think consensus will be reachable on a definition for block.

This whole discussion seems to revolve around this misperception - that a 'block' doesn't have a defined meaning. In fact it has a very definite meaning, one refined through decades of consensus practice, and which @raphaeljadot summed up nicely in his example of a proposal to make Loomio proprietary.

All I'm asking is that either:

the behaviour of the software reflects the well accepted meaning of a 'block'

OR
the 'block' button is recognised as useless and confusing, and removed

Just re-reading this entire thread. Some rambling:

I'm wondering if one issue here is that people want the "block" to "do something", because Loomio doesn't have a clear distinction otherwise between "a proposal that resulted in consensus around a way forward" and "a proposal that did not result in consensus around a way forward".

If it did, then it could be still up to the group whether or not to take a proposal forward to the "we have reached a consensus here" state, when it obviously had at least one "block" in the mix.

For the group of us that is Aptivate, when someone raises a "danger" (not a "block") in our process, it has to be addressed satisfactorily (e.g. "we will do X and Y and monitor Z") before we can go forward. It doesn't mean we don't record the "danger" as part of the decision we made, if we manage to make one, and the steps we took to address the perceived danger. I think we wouldn't be as comfortable using a system that forced us to "block" each other. It feels like more-violent language.

If the end intention is for users to be able to redefine the terms used here, then does it make sense to hard-code behaviour?

We're also discussing a "can of worms!" flag, which means that we want to discuss something in person or by voice call, not just online text. Where people are raising blocks / danger flags / whatever they're called, we would very likely want to have personal discussions to make sure stuff was getting heard, and we would almost certainly discuss this in person. If people tried to go on discussing it online, we might raise this flag! Maybe that addresses the fear that "even if I raise a block, people could just try to carry on anyway".

I guess for some large / distributed groups, discussion in non-text-forms might be difficult, however it does feel like "only online" can lead to "consensus discussion by flame war", even with the best of intentions and participants :-)

Time Hartnet (sorry can't seem to tag him for some reason!) brough this up in another thread and I'd like to continue the conversation here...

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.

I my experience, blocks are very serious and they mean "I feel so strongly against this that if it goes ahead I will leave the group". That interpretation means it's actually a risk for the person making the block, and therefore people don't throw them around.

I think the fact that anyone in the group has the power to block is actually to root of the power of a consensus process, even if it's never actually used. It means a single voice has power, and therefore everyone else must consider every single person in the proposals they make.

If someone is making unconstructive blocks that aren't "healthy" by the definition Tim explained above, and the efforts of the group to address their concerns aren't helping or it's not possible to address them. then honestly they probably shouldn't continue in the group anyway.