LiquidFeedback's Issue Limiter

LiquidFeedback is a software that doesn't just implement transitive proxy voting (Liquid Democracy) but also provides a process for proposition development and decision making that is collectively moderated by all participants. [PLF, section 4.3] The electorate isn't just voting on proposals but also fully in power to develop these proposals and to select which of them are available in the final voting procedure. While each individual participant may put up proposals for consideration, only those proposals that gain enough supporter votes are admitted to pass to a longer discussion phase or be eligible for final voting. [PLF, section 4.6] LiquidFeedback version 1.0 through 3.2 used a configurable supporter quorum (of, for example, 10%) relative to the number of participants who enlisted in a particular subject area (optional “membership” in a subject area) to determine the required count of supporter votes. [PLF, section 4.9]

There are two major drawbacks with this approach:

• The effects of enlisting in a subject area are difficult to explain to a user of the software. Often participants won't actively update the subject areas they are interested in or engaged in. Furthermore, the requirement to select subject areas is an obstacle when integrating LiquidFeedback with other software components.
• A minority exceeding the configured quorum in its size will be capable to flood the system with proposals. While LiquidFeedback provides a system that restricts participants to not post more than a configurable count of proposals within a given time, this approach doesn't scale as the number of participants grows. [Evolution] [Finite]

A previous idea to solve the second drawback has been published in [Finite] but was never implemented. In the remainder of this article, we'll present a new approach that is simpler but addresses both of the drawbacks listed above.

Using the “active” member count as reference population

Starting with LiquidFeedback version 4, whenever a relative quorum is configured, the reference (i.e. 100%) will be measured by the number of active participants in the system, which is the number of participants that have logged in within a configurable time frame (e.g. within the last year). So-called “membership” in subject areas will be completely removed. Instead it will be able to opt-out from receiving e-mail notificiations in particular subject areas, but this choice will not have any effect on the reference population. Only regular logins will be required for voters to be counted as part of the reference population.

Adaptively adjusting the admission quorum

LiquidFeedback 4 will also include a mechanism called “issue limiter”, which adaptively adjusts the admission quorum for issues based on the number of currently open issues that have already been admitted in the respective subject area. This way, the number of admitted issues in a subject area does not grow unboundedly if a certain fraction of the eligible voters attempts to post and support as many issues as possible. In theory, this enables LiquidFeedback to be used for groups of any size. [Finite]

An adaptive admission quorum can be abused in such a way that by posting and supporting many different issues, the quorum will automatically rise and prohibit other minorities from having their issues pass the quorum. Nonetheless, the advantages of an adaptive admission quorum seem to outweigh the disadvantages when comparing it to a proportional representation scheme. See [Finite] for a detailed discussion of this issue, including an elaboration how LiquidFeedback still assures certain minorities' rights in case of a dynamically adjusted admission quorum.

The basic principle behind the “issue limiter” is that increasing the number of open and admitted issues by a given absolute count increases the required supporter count by a certain (constant) factor. In turn, issues that are closed (e.g. because of finally having been voted upon) reduce the required supporter count by the same factor. This results in an exponential (or logarithmic) correlation between the number of open issues and the currently required supporter count to let a new issue pass to discussion phase.

Using S to denote the required supporter count, B₀ to denote the desired supporter count when no issues are open, and n as the number of open issues, the relation can be described as follows:

S = B₀ · f₁ⁿ

where f₁ ∈ ℝ⁺ is a configurable factor. In order to simplify configuration, the formula can also be expressed as:

S = B_N · f_N^{n/N - 1}

with an arbitrary N ∈ {1,2,3,4,…}, f_N = f₁^N, and B_N = B₀ · f_N. In this case, S is the actual required supporter count, B_N is the required supporter count if N issues were open, and f_N is a factor (or divisor) by which the supporter count is modified if N more (or less, respectively) issues are open.

Considering different runtimes

The described approach doesn't yet take into account that different issues may have different runtimes. Counterintuitively, open issues that have a shorter runtime should be weighted more (i.e. increase the required supporter count more) because an equillibrium of N open issues that have a short runtime require more interactions of the participants than N open issues with a longer runtime. Taking different runtimes into account, the number S of required supporters calculates as follows:

S = B_N · f_N^{n* / N - 1}

with

n* = ∑_i=1..n (d_i / D)^-a

where d_i is the total runtime of an issue i after admission for discussion phase (i.e. discussion time + verification time + voting time), D is a reference runtime (e.g. runtime of a default policy), and a ∈ [0,1] is an exponent selecting how much the runtimes of different issues are taken into account.

Choice between relative or absolute supporter count

While the exponential relationship between open issues and the required supporter count doesn't require taking the total number of active participants into account, the implementation of the issue limiter still allows to use a relative base quorum (Q_N) instead of an absolute number of required supporters (B_N). In this case, B_N = Q_N · M, where M is the total number of active participants (see section on “active” members above for a definition).

Choice between adaptive quorum, static quorum, or both

LiquidFeedback 4 will give organizations who are operating an installation of the software a choice to select whether an adaptive quorum (as explained above) or a static quorum (as implemented by LiquidFeedback version 1.0 through 3.2) will be used.

Also a combination of both mechanisms is possible if low activity shall not decrease the required supporter count boundlessly. However, when static quora are used, they will always be relative and refer to the number of currently active participants (e.g. the number of participants who logged into the system within the last year).

Acknowledgements

The development of LiquidFeedback's Issue Limiter was contributed to LiquidFeedback by FlexiGuided GmbH, Berlin and co-funded by the European Union's Horizon 2020 research and innovation programme under grant agreement n° 693514 (“WeGovNow”).

This project has received funding from the European Union's Horizon 2020 research and innovation programme under grant agreement No 693514.