A Finite Discourse Space for an Infinite Number Of Participants

LiquidFeedback's proposition development and decision making system has been designed with the goal of allowing a huge number of participants to take part in a structured discussion process and to make decisions without the need for a moderator or request commission with special privileges, [PLF] [QA1, question 6] and LiquidFeedback has already been successfully used with several thousand participants in the context of a political party. [Kling] Nevertheless, theoretic considerations in the past revealed that the LiquidFeedback proposition development and decision making process does not scale where the number of participants grows ad infinitum. [Evolution, p.33, p.40] While these limitations have been of theoretic nature without any effect on real life scenarios (to the knowledge of the authors of this article), future applications of the LiquidFeedback process in bigger scenarios might create practical implications of these shortcomings. Therefore, we want to present a modification of the LiquidFeedback proposition development process to allow for a potentially unlimited number of active participants while keeping the system usable and ensuring that minorities can still present their positions in an appropriate way.

Previous work

When we consider the “discourse space” in real-life discussions, we are faced with its limitations regarding space and time: space in regards to how many people fit in a room or conference hall, for example, and time in regards to how much time the discussion takes for everyone to contribute their point of view (while the other participants should be listening). Using electronic media as discourse space, it seems like we can completely overcome the limits of the discourse space in the digital world, because an internet-based system like LiquidFeedback allows to have a huge amount of proposals to be discussed in parallel. But we demand from a truly democratic system that every participant should have the ability to directly influence every decision made, even if Liquid Democracy and thus LiquidFeedback does allow for a division of labor among the participants. This being said, and considering that the participants have only limited resources regarding their engagement in the system, it is still necessary to employ algorithms which relieve the participants from the need to deal with an unlimited number of proposals and instead allow the participants to focus on the most important issues without risking to abstain from a decision due to accident or overload.

It is noteworthy that a simple limit of the number of proposals posted by a single person in a given time frame (which is one of the measures currently implemented by LiquidFeedback) cannot limit the number of proposals posted in a given time in the system if we assume that the number of participants shall be allowed to grow ad infinitum (which is the presumption of this article). [Evolution, p.33, p.40]

For our further considerations, we shall first have a look at the LiquidFeedback process for proposition development and decision making:

1. admission phase (e.g. 4 weeks), <1st quorum for issue>, 2. discussion phase (e.g. 8 weeks), 3. verification phase (e.g. 4 weeks), <2nd quorum for each initiative>, 4. voting phase (e.g. 4 weeks).

Figure 1: The four phases of LiquidFeedback's proposition development and decision making process

Each issue in LiquidFeedback (which may consist of one or more competing proposals, which are called initiatives) can pass the four phases. In admission phase, at least one initiative in an issue must reach a given quorum of supporters (first quorum) in order to proceed to discussion phase. In order to avoid vote-splitting or tactical considerations, each participant may support as many initiatives as one wants to. The first quorum is intended to reduce the potential workload of the other participants by discussing only matters that are at least demanded by a given fraction of participants. Despite this first quorum, the number of proposals in discussion phase could unfortunately grow beyond any limit if we assume that a minority of a size bigger than the first quorum might keep supporting more and more initiatives.

Furthermore, the number of issues in admission phase is not reduced by this quorum at all since the first quorum can only reduce the number of issues in discussion, verification, and voting phase. As we still want minorities smaller than the first quorum to be able to put up their proposals for discussion (either in admission phase or as competing initiatives in existing issues which have passed the first quorum), LiquidFeedback employs sophisticated algorithms to ensure that minorities get a fair display position within the list of issues in admission phase (“Proportional Runoff” algorithm) and the list of initiatives within an issue (“Harmonic Weighting” algorithm). By assigning display positions in a proportional fashion, these algorithms ensure that minority viewpoints cannot be drowned by noisy minorities (or majorities) which support a huge number of other initiatives.

The algorithms are explained in detail in the book “The Principles of LiquidFeedback” [PLF] and also in the article “The Evolution of Proportional Representation in LiquidFeedback” [Evolution]. A numeric example is given in Appendix A and B of [PLF].

Using these algorithms for a proportional representation, LiquidFeedback ensures that all minorities can put up their point of view for discussion and will get a fair display position, hence a fair chance to campaign for their position within the system, even under the condition of noisy minorities being present, who post a potentially unlimited number of other viewpoints. A short proof regarding the Harmonic Weighting algorithm can be found in [PLF, p.78].

While it is up to the participants to deal or not to deal with any issues in the admission phase (the only consequence of not dealing with an issue in admission phase is that it could be canceled and not be voted upon), participants must be more cautious with issues that have proceeded to discussion phase. In discussion phase, each issue is of importance because it may progress to voting phase and can result in an actual decision being made. Therefore, the “Proportional Runoff” algorithm is not applied for sorting issues that are in discussion, verification, or voting phase. [PLF, subsection 4.10.3] [Evolution] LiquidFeedback instead relies on the first and second supporter quorum to limit the potential workload of the participants.

In the following two sections we shall have a look at the effect of the first and second supporter quorum.

First quorum (as of LiquidFeedback 3.0)

As already mentioned in this article and as noted in [Evolution], the simple mechanism of a first supporter quorum does not prevent a discussion system to be flooded with a potentially unlimited number of proposals under the assumption that the number of participants grows without bound. To give an example: if the first supporter quorum is set to 10%, a minority of the size of 11% of the participants could flood the system with a potentially unlimited number of proposals. This even holds if each participant is limited in regards to the number of proposals he or she may post within a given time frame, assuming the total number of participants is not limited. Since any issue that is admitted for discussion phase requires attention of the participants, we can conclude that the mechanism of the first supporter quorum does not scale if the number of participants grows ad infinitum.

Second quorum (as of LiquidFeedback 3.0)

The second quorum filters those alternative proposals, which do not have enough supporters at the beginning of the final voting phase. If an initiative doesn't have enough supporters, it will not be eligible for final voting. Here as well as in regards to the first quorum, it is possible for each participant to support as many alternative initiatives as he or she desires. (This is necessary to fulfill the Independence of Clones criterion.) [PLF, p.74, p.87] The second supporter quorum filters the number of issues and initiatives but also does (like the first supporter quorum) not impose a hard limit on the number of proposals. Therefore, a potentially unlimited number of alternative initiatives could enter the voting procedure hence appear on the ballot during voting. Considering appropriate changes to the user interface, this is not a real problem because the most relevant proposals will be listed first on the virtual ballot due to the Harmonic Weighting algorithm. A user interface might offer to disapprove a potentially unlimited number of alternative proposals in bulk. Minorities' rights would not be affected, because the Harmonic Weighting algorithm respects minorities in a proportional fashion when determining their display position on the ballot.

Scalability of LiquidFeedback 3.0

While the algorithms employed by LiquidFeedback successfully scaled for several thousand participants, it has been shown that the mechanism of the first supporter quorum does not necessarily scale if the number of participants grows ad infinitum. In the remainder of this article, we will propose a way to modify the mechanism of the first supporter quorum in such way that the proposition development and decision making process of LiquidFeedback also scales in cases where the number of participants grows beyond any previous limit.

Proportional representation and free-riding

An early proposal to solve the described limitation of scalability (in regards to the first supporter quorum) has already been outlined in [Evolution]: “One possible approach […] is to not limit the number of proposals that are posted by each participant, but instead to limit the number of proposals that are allowed to proceed from admission phase to discussion phase for each subject area within a given time frame. In regard of the issues that are allowed to proceed, the limitation mechanism would need to provide a proportional representation of the participants. The development of such an algorithm may be interesting for future versions of LiquidFeedback and other electronic participation systems.” Jan Behrens, author of that article and co-author of this article, thus demanded that any system which limits the number of issues proceeding from admission phase to discussion phase (previously limited by the first quorum as explained above) must ensure a proportional representation of the participants.

While proportional representation is a desirable property to support minorities with displaying their viewpoints, it has to be noted that proportional representation comes at the price of encouraging tactical maneuvers known as “free-riding”. [Evolution] Proportional representation in regards to admitting proposals for further discussion means that 10% of the participants may put up to 10% of proposals to discussion in a given time frame. While this sounds fair at a first glance, a deeper look reveals a problem: if a group may only put a limited number of proposals to discussion with their voting weight, it is advisable for that group to only vote for (i.e. support) those proposals which really need additional voting weight in order to be admitted for further discussion. In other words: “If enough other people support X, then I won't support X even if I want X to be admitted for further discussion, because not supporting X increases the number of other proposals I may promote successfully.” In the context of Single Transferable Vote systems, this effect is also known as “Hylland free-riding”. [Hylland, p.150-151] [Schulze2] Numerous attempts have been made to avoid free-riding in proportional representation voting schemes, most notably a counting scheme known as “Schulze STV” invented by Markus Schulze (who also invented the “Schulze method”). [Note: “Schulze STV” and the “Schulze method” are two distinct vote counting schemes. The first is creating a proportional representation of the voters by electing a number of candidates, and the second is a single-winner election method.] However, while Markus Schulze shows that “Schulze STV” reduces the ability of Hylland free-riding (as well as vote management) to a minimum, he notes that the problem of Hylland free-riding cannot be solved completely if a proportional representation is desired:

We may assume that it is also not possible for the LiquidFeedback proposition development process to limit the number of issues being admitted for further discussion while respecting the support of the participants in a proportional manner and at the same time avoiding the problem of free-riding. [Note: A formal proof transferring the statement from the domain of Single Transferable Voting systems (STV) to the domain of LiquidFeedback's proposition development and decision making system is still outstanding.]

Trade-off

If proportional representation and avoiding the ability of free-riding are mutually exclusive, then we must weigh the impact of sacrificing either one.

Sacrificing proportional representation in regards to which issues are admitted for further discussion in LiquidFeedback appears to be a violation of LiquidFeedback's goal to protect minorities. However, even if a minority (or majority) could keep another smaller minority from having their supported proposals admitted for further discussion (beyond admission phase), minorities could still put up their points of view to discussion in admission phase. Any participant may post an initiative which is at least discussed during the admission phase, which is then sorted using the Proportional Runoff algorithm. Because competing initiatives pass the four phases together, any participant may also post alternative views to those initiatives which have proceeded for further discussion (and may later proceed to verification and voting phase). These alternative views are sorted using the Harmonic Weighting within each issue, hence ensuring that each minority may put up their opinion to be displayed as prominent as the size of the minority suggests. Every minority still gains proportional representation in each issue, and even new issues (i.e. initiatives that are not competing with any other existent initiative) can be put up for discussion by minorities at least in the admission phase.

Provoking free-riding, to the contrary, results in an unequal treatment of the voters. Those voters who honestly support all the proposals they want to vote upon would be punished for expressing their true wishes. Voters who support proposals in a strategic way gain advantages. Unless the supporter votes were cast hidden (which is not desirable during admission phase), some of the participants might even use automatic scripts (bots) to optimize their supporter votes for admitting initiatives for final voting. [GoD] This would certainly violate democratic standards. While advantages through tactical behavior can never be outruled completely, LiquidFeedback aims to reduce the possibility of tactical voting. [PLF, section 4.14] The problem of Hylland free-riding is only avoidable if we abstain from demanding a proportional representation of the voters in regards to which issues are admitted for further discussion.

These considerations in mind, we propose to sacrifice proportional representation when designing a process to limit the number of issues being admitted for further discussion and voting, hereby revising the concluding statement in [Evolution]. This allows for a protection against free-riding techniques in regards to which issues are allowed to progress to discussion phase. Proportional representation will still be applied when sorting issues in admission phase as well as for sorting initiatives within an issue (as already implemented since LiquidFeedback 2.2 and explained in [PLF]). The minorities' rights to adequately present their proposals within the proposition development and decision making process is thus still warranted.

A simple solution

Because proportional representation is not a goal when limiting the number of issues (for the reasons explained above), an algorithm to limit the number of issues that are in discussion, verification, or voting phase in LiquidFeedback is easy to design: a simple solution to this problem is to dynamically adjust the first quorum depending on the number of issues currently open in discussion, verification, and voting phase. As the number of issues in those phases increases, the first supporter quorum would increase as well, hence leading to an equilibrium where the number of open issues in the system does not grow infinitely.

The algorithm in detail

Assuming the reader is familiar with all concepts presented in [PLF, chapter 4], we propose a modification to the LiquidFeedback process as follows. The first supporter quorum will be dynamically determined based on the number of issues currently in discussion, verification, and voting phase (i.e. the number of open issues that are neither closed nor in admission phase). As explained in the next section (“Dimensions of the discourse space”), the algorithm may be applied per subject area, per policy (selected rules of procedure), per organizational unit, or a combination thereof. We define ‘N’ as the number of issues currently in discussion, verification, or voting phase.

The first quorum Q₁ then calculates as follows:

Q_1 := max(Q_pol, Q_dyn) with Q_dyn := (N+1) * Q_nom if N < a Q_dyn := [ ((N+1)-a) * 50% + (b-(N+1)) * Q_nom ] / (b-a) if N >= a and N < b Q_dyn := [ ((N+1)-b) * 100% + (c-(N+1)) * 50% ] / (c-b) if N >= b and N < c Q_dyn := infinity if N >= c T_max := T * (Q_1 / Q_pol)^beta and Q_pol: a constant value defined by the used LiquidFeedback policy (the policy's issue quorum), a, b, c: natural numbers (issue counts) with a <= b <= c, Q_nom: the quorum necessary to get an issue admitted to enter discussion phase when a-1 issues are currently open in discussion, verification, or voting phase, T_min: minimum admission time, T: maximum admission time if Q_1 = Q_pol, β: admission phase timing exponent.

Figure 2: Calculation of dynamic quorum

An example is given in the following Figure 3:

Q_pol = 30%, a = 30, b = 50, c = 125, Q_nom = 10%. X-axis reaches from 0 to 125 initiatives. Y-axis reaches from 0% to 100%. N = 0 , Q_dyn = 0.33% , Q_1 = 30.00% ; N = 1 , Q_dyn = 0.67% , Q_1 = 30.00% ; ... N = 28 , Q_dyn = 9.67% , Q_1 = 30.00% ; N = 29 , Q_dyn = 10.00% , Q_1 = 30.00% ; N = 30 , Q_dyn = 12.00% , Q_1 = 30.00% ; ... N = 38 , Q_dyn = 28.00% , Q_1 = 30.00% ; N = 39 , Q_dyn = 30.00% , Q_1 = 30.00% ; N = 40 , Q_dyn = 32.00% , Q_1 = 32.00% ; ... N = 48 , Q_dyn = 48.00% , Q_1 = 48.00% ; N = 49 , Q_dyn = 50.00% , Q_1 = 50.00% ; N = 50 , Q_dyn = 50.67% , Q_1 = 50.67% ; ... N = 123 , Q_dyn = 99.33% , Q_1 = 99.33% ; N = 124 , Q_dyn = 100.00% , Q_1 = 100.00% ; N = 125 , Q_dyn = infinity, Q_1 = infinity.

Figure 3: Example of dynamic quorum

An issue may proceed from admission phase to discussion phase if (a) the issue has spent a minimum time of T_min in admission phase, and at the same time (b) one of its alternative initiatives has a supporter count (including potential supporters, see [PLF, p.61, p.67]) of at least Q₁ multiplied with the reference population for that issue (see [PLF, section 4.9] for a definition of the reference population). If multiple issues fulfill this requirement, only that issue that belongs to the initiative with the highest quotient of supporters to the reference population is proceeding to discussion phase. (The creation time of the issues may serve as a tie-breaker.) Afterwards the dynamic quorum Q_dyn (and thus Q₁) is recalculated. Then, another issue may pass from admission to discussion phase if the newly calculated dynamic quorum is still reached by another initiative. The process is repeated until no issue reaches the dynamic quorum anymore. Finally all issues which are still in admission phase and which have been in that phase for a duration of at least T_max will be canceled by the system. The whole algorithm is executed at a regular interval.

The exponent β can be set to 1 to dynamically extend the admission phase proportionally when Q₁ is rising. This feature is intended to compensate a rising quorum by giving minorities a better chance to reach that quorum. Setting β to zero, in contrast, will result in a constant maximum length of the admission phase.

Introducing a minimum admission time T_min allows people who either delegate their vote in a subject area or for the organizational unit, or who are not member of the subject area (and thus do not belong to the reference population when a new issue is created) to intervene before a potentially big number of issues is accepted for entering discussion phase. Intervention is possible by revoking one's delegation, and/or by enlisting in a subject area or declaring interest in an issue, hence increasing the reference population (see [PLF, section 4.9]). First of all, this compensates effects previously observed in LiquidFeedback where some participants with a high number of delegations could instantly lift an initiative's supporter count beyond the first quorum by simply supporting an initiative of a new issue (which inherits any existing delegations from the subject area). Secondly, this allows people who are not members of the subject area to intervene by enlisting in the subject area if they see that the participants in that subject area flood the system.

Dimensions of the discourse space

The algorithm may be applied per subject area, per policy (selected rules of procedure), or per organizational unit. This choice determines how ‘N’ is defined; e.g. if we apply the algorithm per subject area, then ‘N’ is the number of open issues in that subject area which are not in admission phase. If we apply the algorithm per policy, then ‘N’ is the number of open issues not being in admission phase using this policy. We can also apply the algorithm to different sets of tuples of subject areas, policies, and/or organizational units (while for each set ‘i’ of tuples, we define a_i, b_i, c_i, and Q_nom,i). Even overlapping sets are thinkable, in which case we should determine the highest Q_dyn, i.e. Q₁ := max(Q_pol, max(Q_dyn,i)) (for all matching ‘i’).

It is thus possible to shape the dimensions of the discourse space. For example, an organization might decide to generally not discuss more than 150 issues in parallel, but also not more than 15 issues together in the areas “Education” and “Research”. More complex setups are thinkable. Some organizations could use this feature to ensure that certain kinds of proposals do not stop other kinds of proposals being discussed and decided upon (e.g. a big number of issues regarding amendments to the statutes of an organization does not increase the quorum for other issues).

Vulnerability through flooding?

While it is possible that a minority keeps another smaller minority from having their supported issues in admission phase proceed to discussion phase (by simply supporting a huge amount of initiatives in separate issues, thus increasing the number of issues in discussion, verification, and voting phase, and thus increasing the dynamically adjusted first supporter quorum), any sufficiently larger group can still get further issues to be admitted for discussion phase. In other words: a minority cannot lift the required quorum much higher than their own size. For example, a minority consisting of 10% of the participants could deter a 9% minority from discussing their issues beyond admission phase, but those 9% could still use the admission phase to promote their proposals in order to gain a supporter quorum greater than 10%, hence allowing for a final decision during voting phase (after discussion and verification phase).

Technical challenges

LiquidFeedback currently relies on a background process, which counts the votes for each issue, one issue after the other. In order to provide a fair process where no issue is favored to any other issue, all issues that may influence each other's dynamic quorum have to be tested for their eligibility at the same time. Since the calculation requires some time to compute, a snapshot must be taken of the supporter situation of all those issues at once.

Such behavior might be achieved by processing all open issues in admission phase at the same time in a single database transaction. In case of the current implementation of LiquidFeedback, however, it might be problematic due to PostgreSQL's way of locking: database locks won't be released until the transaction has finished. Therefore, “snapshot synchronization functions” should be utilized instead. We refer to section 9.26.5 of the PostgreSQL manual, version 9.4 for further information on this issue. [PostgreSQL]

Regarding huge numbers of initiatives, a practical problem might be the non-linear (yet polynomial) run time of the Proportional Runoff and Harmonic Weighting algorithms. Further research might reduce computational complexity, or not. Either way, the practical scaling of such a system by employing methods like clustering, etc. goes beyond the scope of this article.

Summary

It may be surmised that it is impossible to extend LiquidFeedback with a proportional algorithm to select issues that may progress from admission to discussion phase without the side effect of potentially favoring voters that employ free-riding techniques to maximize their influence. We therefore proposed a non-proportional algorithm that allows a potentially unlimited number of participants to take part in the proposition development and decision making process while limiting the number of open issues, so that each single individual or a small group of individuals may still work on all issues in the system, in a subject area, or within an organizational unit.

Applying these modifications to LiquidFeedback would empower a potentially unlimited number of participants to engage in a self-organized discussion process which meets highest democratic standards while maintaining feasibility even if the number of participants grows beyond any limits.