Introduction

Consensus decision-making is a process that allows group of people coming from very different positions, to develop a proposal they can all agree is beneficial. For me there’s no doubt that such a process is more productive than any voting-based approach. Voting-based approaches have two shortcomings:

1. They silence minority opinions when the voting is concluded. They might differ on where they set the threshold (“first-past-the-post” vs “90% approval required” for example), but fundamentally the majority is awarded legitimacy to do whatever they wish.

2. They discourage cooperation and innovation. Discrete options are put on vote and people are called to choose one (or order them from most to least liked, under some systems), instead of being used as the starting points of formulating a proposal everyone agrees on.

Voting-based approaches thus fail badly: people who systematically find themselves in the minority side grow alienated. People systematically in the majority are incentivised not to pay attention to dissenting opinions. The result is dysfunctional organisation and, almost always, hostile splits.

This observation, I believe holds true for any kind of organised community, be it “in the real world”, or “online”. Hostile software project forks are one such phenomenon. Recently, one software project, Libreboot, committed themselves to one consensus-inspired approach in a bid to secure the good functioning of the project and its surrounding community.

Before I elaborate on my thoughts, I need to also note that communities based around consensus might also want to interact with other communities. When they do that, they federate and might have one or more delegates tasked with interacting with other communities. This is not the same as sending a representative. A delegate is only a mouthpiece for the community they come from, and they are not empowered to make decisions in the name of the community. They are tasked with presenting to the outside world what their community agreed upon, and presenting outside suggestions to their community. This is a much stricter commitment than, eg being a member of parliament who holds townhall meetings to gauge public opinion in their constituency, but ultimately reserving the right to act according to their conscience.

With that out of the way, there’s some issues when it comes to implementing consensus-based approaches in an online discussion setting (ie some fort of discussion forum or chat system). Existing software is either making consensus-seeking harder because it is designed in ways that make meaningful discussion harder, or in some cases it is even consciously designed to promote majoritarian voting systems (see poll creation options in forums). The following points are some specific problems that come to mind, and a discussion of possible solutions for each one.

A Block/Veto Function

Ultimately, what motivates consensus-seeking is the agreement inside the community, that anyone might veto or block an unacceptable proposal. Blocking is not the end-goal though, everyone in the community must want to avoid inaction because of an unresolved disagreement. To avoid that, consensus is sought.

How can you implement a block option in a discussion forum in a way that makes it easily documented?

Do nothing

And allow the users of the forum write their thoughts as text. It’s up to everyone to understand if that text constitutes a veto, or if there’s still room for discussion. No special documentation is kept.

CLOSED:WONTFIX (or the Bug-tracker approach)

This is a familiar option in software development. Bug or enhancement reports might be closed with the WONTFIX justification if whoever is responsible for the component the bug report is about does not agree with the proposals suggested.

A Closed bug report might still be commented upon, and potentially by reopened. This is generally compatible with how a veto works in consensus decision-making. It provides a clear and documented event (eg “one person did not agree with this proposal”). It also allows for metrics to be collected (eg “is this member prone to blocking proposals early?”).

But like CLOSED:WONTFIX creates a lot of bad feelings in a software project, so will such an unqualified veto. Where exactly was a strong disagreement? It can again only be clarified with direct text input, which is not encouraging good documentation.

In-line Flagging

A proposal is presented as a structured piece of text. The community can flag any part of the text they disagree with. If the text contains any flagged passages, it’s essentially blocked.

With this, we have good documentation of who vetoed the proposal, and what accepts led them to do it. What needs to be revised is clearly seen. Feelings of frustration and misunderstandings are avoided.

This is the approach Loomio uses to some extend.

This option leads us to the next requirement for a consensus-oriented discussion system:

Collaborative Editing

A proposal presented as text must be rewritten until consensus is reached. But that’s not straight forward. There are a few ways to go about doing this.

Again, do nothing

Act like a typical forum or a mailing list, with posts in a given thread ordered in chronological order. The most recent formulation of the proposal will be found at the bottom and each time a new formulation is posted, expect that the discussion refocuses on the new version.

Experience tells me that this is a great recipe to create a mess, and get little done. Forums and mailing lists suffer from several problems, such as people overlooking new messages and keep replying on previous versions of the proposal, “IM-like” behaviour of short context-less replies, and extensive discussion derailments (going off-topic).

So there needs to be more structure in editing a proposal, even if that system is complemented by a chat system on the side.

Real-time collab

There’s several real-time collaborative editing solutions, such as Etherpad. In an application like that, several people can be typing and deleting stuff at the same time, with changes propagating near-instantly.

But what happens when two or more people disagree on the formulation of one specific passage? They usually type and retype over each other, often not even doing so maliciously (the system is near-instantaneous, so it might give the illusion that the other person is done typing even when they are still pressing keys on their end - and of course, people do pause to think too).

In such a real-time system you can’t have any meaningful revision control. Usually what you get is “commits” to the document history every N number of seconds or every specific amount of characters typed or deleted. The stored revisions do not tell a story of how the proposal evolved, they are more like a linear Undo/Redo history.

Asynchronous editing

Real-time editing is probably not suitable when it comes to decision making. It might be useful in steps prior to it though. So what’s the opposite of real-time? Asynchronicity.

Under this system, people edit a copy of the latest revision of the proposal, making changes in their own time, and nothing is visible until they choose to submit.

This incentivises clarity and transparency, but it creates a new problems:

1. Should a new revision immediately replace the previous one?
2. What do we do when people are trying to edit the same revision?
3. What happens when a new revision is submitted while a person is still editing a now-obsolete revision?

Wikipedia for the most part allows everyone to replace the current revision, and so do most wikis. There’s two aspects to consider when evaluating Wikipedia’s approach. On the political side of things, that means that any single person has the right to change every single word in a proposal in a single swoop. That could be a breakthrough in finding a consensus (a welcome change of perspective on an issue), or it could be a hostile action. The technical question here is how do you handle more than one person editing the same revision. Wikipedia usually solves it by either placing a lock while a person is editing, or by asking the person to rebase their edits to the new revision before they can submit (with the option of disregarding the new revision).

This gets messy. Like in a forum or a mailing list, people will very often keep bringing old versions back to life, disregarding intermediate revisions. So being asynchronous is not a solution on its own.

Branches

There’s something that can improve the Wikipedia approach, and that’s again something the software development community knows well. Branching under a revision control means working on a copy but without submitting your changes directly to the official version of the code (or here, text) – in git terms, not committing directly to master.

This way, multiple branches can be worked upon at the same time. Combined with the in-line flagging approach of the previous section (which now act as new branch initiators), that means that each specific idea of a proposal can be reformulated by someone, and then it becomes a matter of merging that self-contained idea back to the master revision. Repeat until there’s no more veto flags left.

This also allows radical changes to the proposal. Someone can create a branch in which they rewrite the entire proposal, and everyone jumps into that to make further changes, discontinuing the old master branch in favour of the new.

There’s no problem with parallel editing by multiple people as long as they are modifying different parts of the text. If approved by the community, the changes can all be merged back to master. Conflicting edits (ie on the same passages) are resolved by further edits, without continuous overwrites, and without committing immediately to the master. (How a solid, unfixable veto is resolved is outside of the scope of the collaborative editor – it’s up to the community to decide if they split up, choose inactivity, or expel a member).

The revision history is meaningful as it has to do with specific disagreements, and not arbitrary time periods like in real-time editing.

So I’m basically describing git at every single step. But the crux here is wrapping git with a UI that suits collaborative writing, and not code.

Handling Inactivity

In a system that incorporates in-line flagging, the subconscious assumption is that people who haven’t disagreed, must agree. If no-one flagged anything on the proposal, then the software understands this as unanimous agreement.

Is that really true in communities? Not always. It’s true that most of the time we spend the least effort – if we don’t disagree, we do nothing. But a lot of misunderstandings are caused because of this assumption.

If there’s a flood of proposals in the system, people might not be able to keep up. Circumstances might keep them away from their computers. Maybe they cannot locate a specific point they disagree so they don’t raise a flag.

Is the opposite assumption the solution? If you introduce a “Ratify” button and require every member of the community to ratify the proposal, what are the new problems you will have to deal with? How can you make sure the discussion forum design doesn’t fall into the trap of the silent consent and the silent disagreement? How do you tell non-blocking disagreement (“I can live with it”) apart from inactivity?

Do nothing

Inactivity is not an “online”-only problem, it’s a problem all consensus-based communities face regardless of modality. The ways they use to resolve or workaround this problem do not have to be codified and implemented in software.

The discussion platform will not facilitate but neither hinder decision-making in this specific aspect.

Seen.

Maybe you don’t treat lack of feedback as consent, because you understand that people might be away, or somehow missed the proposal, but once they’ve read it, their lack of reaction must mean they agree.

But Seen doesn’t mean Read, and finished thinking about it.

Ratify

Everyone must signal approval of the current revision of the proposal. Lack of flags is not automatically treated as unanimous agreement. Merely having seen it doesn’t mean unanimous agreement.

But what if it’s Friday and we are asking if we are going to release this article on the Saturday issue of a publication, and some people aren’t online. You don’t have all the Ratify clicks required.

What happens if people maliciously withhold their Ratify clicks without entering a productive discussion by creating a new revision?

Time-sensitivity

Perhaps some proposal can be marked as time-sensitive, and the software does everything it can to let people know about it in time.

Stick it to the top of the website, email registered users, send an HTML5 notification to the user’s browser, and hope that they are take it seriously.

This is approaching real-life decision-making at least. When there’s an urgent decision to be made, the community tries to notify and get the opinion of everyone.

Quorum

Another real-life approach is setting a minimum number of people who can be empowered to make decisions, be it a straight-up number, or a percentage of the community’s population.

In real life that means that a community might start the decision-making process if at least X number of people are present. In software terms, you can skip the “counting ourselves” part and just program the software to treat any un-flagged proposal as accepted if it has X number of Ratify clicks.

An override switch might also be useful. Sometimes you have a quorum, but you think the matter is too serious to leave just to a subset of the community. A “Require Wider Participation” button might allow one person to pause the process and make the forum start notifying members to join the discussion, like the time-sensitivity feature discussed right above. A dedicated button isn’t required (they could just flag the text using the in-line flagging system), but it is a more transparent way to do it.

Who moderates the moderators?

Finally, when it comes to designing “digital democracy”, we have to consider that she who controls the infrastructure, controls the world. Even if we find a way to implement consensus decision-making in a forum/wiki/git-like software, the person who has access to the settings panel and the database can override everyone else, in ways that wouldn’t be so easy in “real-life” communities.

Giving everyone root access to the server is certainly solution that allows you to say “everyone has equal power”, but is it meaningful? Even in a technical community, not everyone has the skills needed to maintain the whole stack, from server OS upgrades to the forum’s control panel. Maybe not even everyone in the software community which develops the software I describe is empowered even in a meaningful way by just being handed root access to the server.

A more coherent stand is saying that some members of the community are delegated the sysadmin role, and they have to follow the wishes of the community, or be recalled. But software development has shown us that “recalling” your sysadmin doesn’t mean a lot when they have control of the infrastructure. Many hostile software forks included taking pieces of the infrastructure, such as the server and the domain name, with you (eg GNU Nano, recently, before returning back to GNU). This could happen in real-life of course, there’s a meaningful difference in how hard it is to do it.

So, are we again faced with the moral inescapability of the need for federalised network services? Should this system work as some kind of GNU Social instance where everyone keeps a copy of the data on their own server (or client, for added decentralisation but also to lower the bar of technical knowledge required), and every node of this federated network might at any time decide to break ties with another node, without anyone losing access to the data they shared so far, and with the possibility to federate again in the future? Are there ways to meaningful diffuse authority in non-decentralised networks?

It’s just a collection of thoughts at the moment, written down because I’d like to revisit them with a fresh pair of eyes at some point in the future. Do drop me a line for any feedback or existing software solutions on any or all concerns raised in the text though.

Let me know what you think about this via email or in the public chatroom.

Tags: consensus, forum, organisation, CMS