As discussed in the previous article “LiquidFeedback: Gamification of Politics?”, LiquidFeedback has been compared with online games. While we, the developers, didn't intend to incorporate game elements in LiquidFeedback, certain features of the software turned out to give people a game-like incentive to participate. While such incentives obviously can have positive effects on the motivation, thinking of democracy as a game (and of voters as players) should rather be seen ambivalent since in a game we may experiment with different strategies, including very risky ones, as there is no effect on the real world. As explained in the previous article, the effects are normally bound to the game. However, when applying game strategies to real-world politics, the outcome may rule about people's lives.
Whether we like game aspects being part of democratic decision-making or not, research in social choice theory and game theory has shown that decision-making can be described as a game. This article shall provide a short introduction to the theoretic aspects behind it, and it shall explain how those aspects have influenced the design of LiquidFeedback.
As an introduction, let's begin with a gedankenexperiment (thought experiment). Imagine we have an organization planning their annual member meeting. Because the meeting lasts a whole day, a meal shall be served for lunch. The organization has an executive board deciding on such issues. This board consists of 3 people, each of them representing a different wing of the organization. The members of the executive board need a majority (i.e. 2 people) to make a decision. Let's further assume that we have 1 week left until the food supplies must be ordered. Any decision on the menu can also be changed (requiring 2 members of the board), as long as it's done before the deadline. Finally we assume, that the status quo is to serve meat, since that's what has been served last year.
The members of the executive board get the following recommendations from the members of their wing:
This example is the most simple example for a so-called Condorcet's paradox and has also been given as an example in our book [PLF, p.95].
Assuming the status quo is “meat”, then it would be clever of Bob and Chris to team up in order to change the plan to serve fish since both Bob and Chris will please their wing by such a decision.
After such a decision has been made, “fish” will be the new status quo. In this case, however, it would be clever of Alice and Bob to unite against Chris in order to change the plan to serve vegetarian food as both their wings prefer vegetarian food over fish.
Eventually, “vegetarian” is the new status quo, in which case Alice and Chris may team up in order to change the plan to serve meat (again).
As easily seen, a cycle may arise:
This cycle could be endless, unless there is a deadline like in our thought experiment.
The outcome of our thought experiment depends on the last approved motion prior the deadline. Therefore, the following factors may influence the success of the participants:
Even if our initial goal was a democratic decision of the executive board, in the end we face a system which rather reminds us of games: speed, readiness to assume risk, teams, and the ability to assess other participants' abilities and their preferences and knowledge.
One might assume that this effect only exists when there is a tie between three groups of exactly the same size. But as the following example will show, it is a more general effect:
Also in this case an endless cycle is possible:
Therefore, even if the decision is not made by a small number of people and there is no tie (all groups have different sizes), such a cycle may still arise.
Of course, this model is still a simplification of real-world processes, as not every member will recklessly undo a previously made decision just to optimize their personal outcome. Nevertheless, the occurrence of this effect is possible in every system where a majority of eligible voters may overthrow a decision. [Note: Even worse: it has been shown that, under certain circumstances, if the number of voting options grows to infinity, the probability that all voting options can be cycled through majority decisions tends towards 100%. For further reading we suggest [McKelvey], [Bell], and [Schofield]. See also [Chaos].]
In a fair process for decision-making, we do not want the outcome of decision processes to be dependent on deals and tactics; instead we aim for a decision-making process that is based purely on people's opinions and their quantified numbers. Therefore, we decided to include a preferential voting system when creating LiquidFeedback. Here, voters may state all their preferences, and then, when the voting is closed, all those preferences are counted at once using a preferential voting scheme. In case of LiquidFeedback, the Schulze method is used for that purpose.
Given the example in Figures 3 and 4 and using the Schulze method to count the winner, the majority (B+C=60%) preferring “fish” to “meat” is smallest, thus ignored, and “meat” is declared winner since this result is most stable (the smallest majority is ignored).
This approach doesn't force people to make tactical decisions when casting their ballots. While the voter is not forced to act strategically, it is still possible to cast dishonest preferences to overtrump another group and thus increase the individual satisfaction with the results.
In this case, there is a majority (B+C=60%) that (according to the cast ballots) prefers “fish” to any other option. “Fish” would win in this case, which is better than “meat” for group B. Thus, group B gained an advantage by casting their ballot dishonestly.
Such strategic maneuvers come with a risk: Let's assume group C will change their opinion in the following year, but group B keeps doing their trick, not knowing about the change of opinions in group C:
In this case, the tactical move of group B backfires to them: it causes “fish” to win also in the following year, even if there were real majorities to choose “vegetarian” over “meat” (B+C=60%) and “vegetarian” over “fish” (A+B=75%). But group B lied regarding their preferences, and thus “fish” is chosen as winner again, even if 75% would have preferred “vegetarian” food in the second year.
In the year 1973 it has been proven with the Gibbard-Satterthwaite theorem that all preferential voting systems are prone to tactical voting.[Gibbard] Even though it's not possible to completely eliminate tactical voting, we tried to minimize tactical advantages in LiquidFeedback. By hiding the preferential ballots until the voting is closed, the voters' behavior is less predictable. Therefore, voting in a tactical manner becomes more risky.
The combination of a preferential voting system along with hiding the ballots until voting is closed, aims to make the voting procedure more fair and less game-like – at least to an extent that is possible given the constraints of the Gibbard–Satterthwaite theorem.
It should be noted that hiding the ballots is a (potential) threat to the fairness of the process: voters who gain prior access to the cast ballots of other voters (e. g. through administrator access or hacking) could use this knowledge to cast a strategically optimized ballot. This undermines the principle that every voter is treated equal, and it may not be noticable by the participants.
Fortunately, this is only a limited problem. First of all, knowledge of the cast ballots only yields an advantage if there is a Condorcet's paradox, and it may only be used to favor those candidates that are part of this paradox (i. e. an attacker cannot cause an arbitrary motion to win). Secondly, the attacker either has a small voting weight compared to the other participants or would need to share the secret knowledge in which case detection of the manipulation is possible.
In order to fix this loophole, we may be tempted to disclose the cast ballots as soon as they are submitted to the system, hoping that this ensures equal chances for every participant. The result, however, would – in the best case – be a situation where some of the voters cast their ballot during the last seconds before the poll is closed, based on the ballots of other voters. This would privilege those voters who are able to sit patiently in front of their computer while the poll ends (a bit like people who give their bid on eBay during the last seconds of an auction). In the worst case, a huge number of voters would create agents (bots) that do the voting in the last second, privileging those with the best internet connection, which is certainly not democratic at all. A game solely played by bots may be academically interesting, but it is certainly nothing to base our democracy on. It should be noted that using a non-preferential voting system like approval voting, score voting, or even plurality voting can't solve the problem either. Also in those cases, depending on who teams up with whom, the system may lead to a different voting result.
Cryptographic protocols could be used to prevent administrators from peeking into ballots prematurely. But also those methods may be circumvented by attackers (e. g. using malware or backdoors in soft- and hardware). We thus have to accept that the Gibbard–Satterthwaite theorem can influence the fairness of electronic voting – fortunately only to a limited extent.
Decision-making is not just about voting: prior voting, either the participants or a request commission or moderator must determine which questions are to be voted on. If this process is not carried out by the participants themselves but by a moderator or request commission, then this moderator or request commision may have a huge influence on the outcome of the decision-making process:
A moderator who has complete control over the agenda (and who has complete knowledge about the participants' preferences) can possibly manipulate a decision-making process in such way that any outcome is possible. (For further references see [Schofield, p.196].)
LiquidFeedback, however, doesn't rely on a request commission or moderator but utilizes a collective moderation process that consists of a structured discussion where all participants have equal rights and decide on which proposals shall finally be eligible for the final voting procedure. Technically speaking, this procedure is also a (continuous) voting process. Therefore, our previous considerations regarding tactical voting apply to the discussion process as well.
Due to its purpose, it will not be possible to hide users' feedback during the discussion process: participants must be able to see how many other people support their proposals and what change requests those people post, and they must also be able to see how many people support those change requests. Without such quantification processes, a nondiscriminatory discussion process would not be possible, since noisy minorities would gain an unfair advantage.[PLF, p.84]
Out of this necessity to publish any quantified data during discussion (and with regard to the Gibbard–Satterthwaite theorem), LiquidFeedback is not designed to express preferences amongst competing proposals (called “initiatives”) during discussion. Instead, it is only possible to express support for an initiative without indicating the preference during discussion.
In LiquidFeedback, those initiatives become eligible for final voting which pass a certain supporter quorum. Therefore, the support of initiatives effectively has an influence on the outcome of the final voting, and our previous considerations regarding tactical maneuvers and bots apply during the discussion process as well. The problem, however, is limited because we usually do not demand a majority but only a smaller quorum (e.g. 10%) during discussion. That means, a minority (of e.g. 10%) supporting a group of initiatives will ensure that these initiatives get into final voting regardless of any other participants' tactical maneuvers.
In case of LiquidFeedback, also another factor lessens the problem of tactical maneuvers: LiquidFeedback aims only for those application areas where a recorded vote is intended.[PLF, p.56] Beside dealing with the Wahlcomputerproblem (the problem that electronic voting can't be secret and verifiable at the same time), this brings another advantage about: By connecting every cast ballot or granted supporter vote with the respective participant and by publishing this data, the participants' behavior doesn't just have an impact on the outcome of the voting process, but participants will have to take responsibility for their actions, including those actions where a tactical decision was being made. This has both an effect during discussion as well as during final voting. While it is arguable whether such disclosure really reduces the usage of tactical voting, it is a fact that in a truly secret ballot any strategic behavior can't be traced back to the player, which in turn might seduce participants to apply risky and/or unfair strategies in order to gain an unfair advantage.
Decision-making always incorporates elements of gaming, and advantages through tactical behavior may never be outruled completely. Nevertheless, we should design decision-making processes in such way that the results depend mostly on the participants' views and not on strategic capabilities. While LiquidFeedback contains several elements that may remind of online games, it was designed thoroughly to restrain participants from taking personal advantage through strategic behavior.
Democracy may be seen as a game – or not, but in any case it needs strict rules to stay as fair as possible. Even if in some games it may be entertaining if the “game master” has a huge influence on the course of the game, for democracy this isn't acceptable. Instead, we need a system where everyone is treated equally.