Liquid Democracy Software

This document is part of a proposal to create a digital platform for voting with a so-called 'liquid' representation system. The proposal is divided into three parts. Each part will serve as a platform for facilitating and focusing discussion of the part following it. The decisions and ideas of those discussions will then be incorporated into that part when it's written.

The first describes the scope of the project, which users and organisations might find use for it, and why it's important.

The second part is a specification for the user experience and the basic functionality of the project.

The third part is a specification for the implementation details. The back end – the technology stack and the APIs. (TBD)

Part 2 - User Experience Specification

Duncan Robertson, 2022-02-02

Terminology

'LDS' this abbreviation (Liquid Democracy System) will be used to refer to the system being specified. This is not a recommendation for the actual name of the system, merely a shorthand for the purpose of this document.

'Instance' refers to a specific server hosting LDS for a specific organisation. Different instances may be configured differently from others and not everything here will apply universally to all of them.

'User' refers to a voter in the organisation who is authorised to participate in the LDS instance. All users are also representatives automatically.

'Decision' refers to any question of policy or action that is to be voted on.

'Organisation' refers to the group of people, community, organisation or business for whom the LDS instance is created.

Authentication

LDS will likely have to support multiple authentication and authorisation systems. Ideally it will be able to be added to an existing website, CMS or application with as little effort as possible, meaning it should support the authentication and authorisation systems already in use. For the moment this means things like OICD, Active Directory, and likely several more. A full list of desired authentication frameworks will be worked on in part 3.

What this looks like for the user is that they log into an existing account, and the credentials are automatically used on an integrated LDS module without the need for additional authentication. Alternatively, the LDS is hosted separately from the main content, and the user can log in with an existing account from an external service such as a Google, Apple, Microsoft or social media account that supports external authentication protocols. In some cases administrators will want the LDS to have its authentication system separate from any external system, so this will also need to be supported. In such cases a user would have to sign up for a new account to start using the LDS.

Decision Interface

The decision interface shows a searchable, filterable and orderable list of all the decisions the user is required/eligible to vote on. In large organisations the number of decisions will be large. The representation system is designed to reduce the number of individual decisions that the user has to make but the interface must still be usable with very large lists. Some users may wish not to delegate their decisions to representatives, and when a user is first added to the system they will not have any representatives assigned.

Selecting a decision in the list will display an overview of the information relevant to the selected decision, ideally including links to more detailed information and group discussions. This information will be provided by the individual proposing the decision and may be edited by administrators. All edits to the decision text will be avilable through a button on the interface in the same manner as the Wikipedia View history link. The category (see below) of the decision will also be displayed. As well as any deadlines or expiry dates.

Voting/Ballot

Each decision details panel will contain a ballot panel. All major forms of voting need to be supported. The user may cast their vote in the most common cases, by selecting one or more options. Remember, this is about policy decisions not representation. The options being selected will commonly be simply 'yes' and 'no'.

All voting is reversible. If the user has selected any options in this ballot panel, they can come back at any time in the future and simply unselect them, or switch their vote to other options. Some decisions such as those that are not reversible once implemented or require significant resource allocation, will require a deadline after which votes can no longer be changed.

Representation Interface

The representation interface allows for fine-grained and revocable selection of representatives based on areas of expertise.

Category Tree

The category tree breaks the decisions up into categories that the user can elect representatives to. These categories are specified by the organisation and will be different for each use-case

A tree will be used to enable categorisation of decisions for the purpose of allowing the user to have a fine degree of control over how they delegate their vote to various other users (representatives). The root node of the tree will represent all the decisions, with each child node representing all the decisions of the sub-tree below it. The number of nodes in the tree and the manner in which decisions are categorised must be left completely open.

As an example, a medium sized company operating out of an office building might wish to have a tree structure with departments immediately below the root, like human resources, research and development, engineering, production. Each of these could then be divided up further or not, depending on the size of the department and the number of decisions to be made. Here is an example tree in diagram form:

Representative Selection

Each category is selectable. Selecting a category opens a searchable list of representatives. Selecting a representative in this list will select that representative for the current user and allocate all the user's decisions under that category to the chosen representative.

Representation will cascade down the tree so if, in the diagram example above, a user were to select a representative called Jack on the root node, Jack would obtain an additional vote for all decisions in the entire organisation and the user's decision list would be emptied. If the user also selected another representative called Sarah for the tree node labelled production, then Sarah would be able to vote on the user's behalf for all decisions relating to production, including materials and equipment, but Jack would retain the votes for HR, R&D and all the child nodes of those departments.

As with the ballot panel, representative selection can be changed by the user at any time. The user will be asked each time they change a representative whether they wish to change all the votes already cast on their behalf by that representative to match the votes of the new representative. If they choose not to do this only decisions not already voted on by the old representative at the time of the change will be allocated to the new representative.

Interactive Mockup

Here is an interactive example application to demonstrate some of the core features outlined above. This should not be treated as a design or interface example, it is merely a quick and dirty mock-up to demonstrate the basic concepts in this document for people who prefer an interactive way of understanding things to reading a vast wall of text. Refresh the page to reset all votes and representatives.

Optional Feature: Ratification

There might arise a situation in an organisation where representatives are not as trustworthy as one would hope, and users wish to have the opportunity to reverse their decisions if they act contrary to their mandate. Alternatively, in some organisations there might be issues where user participation is lacking and there is a need to force more eyes onto decisions. The temptation to simply delegate a root representative and not think about it ever again could be a problem in organisations where user interest in the decision making process is low. In both cases the optional ratification feature will be useful. If this feature is enabled, any decision that is voted for by a sufficient majority and constitutes an actual change in policy, will be returned to every user who voted for the current outcome. These users must then confirm that they agree with the decision outcome. Only after a majority of those voters actively ratify, i.e. confirm their yes vote, the decision will it go into effect. The required majority for ratification may need to be lower than that for passing policy, depending on participation rates. This ratification can't be delegated. In most organisations the number of policy changes that successfully pass the voting stage should be low enough that ratification is not too much of a burden on the user's time.

Majorities and Thresholds

Because voting is instantaneous and revocable, it will not be possible to use the standard majority threshold used in most voting systems of 50% of cast votes. Traditional voting systems only count percentages as a proportion of votes cast, whereas in this system they must by necessity be counted as a percentage of eligible voters. A user could otherwise propose a decision and then, rather than telling everyone about it, simply vote yes on it and since 100% of votes are yes, the decision is instantly passed. This would be absurd. Calculating a majority based on eligible voters is fairer as it automatically gives users a voice, and encourages participation. But it also causes the issue that user participation getting too low would cripple the system. This is not a very important problem however – it is incumbent on users proposing to change the policies of the organisation to convince other users that these changes are worth making. If no one is interested and those in charge can't convince anyone to vote then probably no change is needed. On the other hand if human beings are simply too lazy to make decisions and would rather let everything fall down around their ears, then no democratic system will ever work and we might as well give up.

Enaction and Revocation Thresholds

A much more serious issue is the potential for a controversial decision to fluctuate around the 50% mark, resulting in the decision becoming policy, then not policy, then policy again. In some cases this could happen over and over. To combat this there are two different majority thresholds, one for enacting a decision and one for revoking it. The exact value of each threshold will be decided by the organisation but for the purpose of this discussion we will use 60% for enaction and 40% for revocation. This means that in order for a decision to be enacted and made into policy, 60% of the eligible voters will be required to vote 'yes' on it. For a decision that has reached that threshold and been enacted, if voting drops back down below 60% it will remain policy. Only if support for the decision drops below 40% will it be revoked and no longer count as policy. In some cases values as close as 51%/49% might be sufficient, and in some cases where consensus is desired 90%/80% might be chosen. Decisions about the values that work for a specific organisation should be decided internally by that organisation, ideally by voting on the question.

Open Questions

The technical specification for this project will need to be written in collaboration with a large number of technical experts and potential users.

The questions that especially need to be answered are:

What frameworks, platforms, CMS services and social networks will this system need to interact with?

What framework or protocol would be best to satisfy all these different use-cases?

What types of authentication will be required to satisfy all these different use-cases?

What language or framework will be best suited for implementing these requirements?

If you want to have input into this, send a message to @Duncan@mendeddrum.org on Mastodon.