BE:Crews/Free.booter/liquidfeedback

LiquidFeedback

Idee der Liquid Democracy

Die Grundidee ist die Schaffung eines demokratischen Systems, in dem die meisten Fragen durch ein Referendum entschieden werden (oder die Ergebnisse des Referendums eine Handlungsempfehlung für Repräsentanten bilden). Da niemand über hinreichend Zeit und Kenntniss verfügen wird, um alle Fragen selbst zu entscheiden, ist eine weiterübertragbare themenspezifische Delegation des Stimmrechts möglich, die jederzeit widerrufen werden kann. Liquid Democracy ist auch als Delegated oder Proxy Voting bekannt. Unser Ansatz

Wir gehen davon aus, dass viele konkrete Vorschläge auch in Zukunft durch vergleichsweise kleine Teams und visionäre Einzelpersonen erarbeitet und weiterentwickelt werden. Dies halten wir nicht für kritikwürdig, solange sichergestellt ist, dass die Öffentlichkeit bzw. alle Mitglieder der jeweiligen Organisation

1. Kenntnis erlangen,
2. durch Feedback versuchen können, Einfluss auf die Weiterentwicklung eines Vorschlags zu nehmen,
3. bei Bedarf einen Alternativvorschlag einbringen können,
4. alle Interessierten an der abschließenden Abstimmung teilnehmen können.

Folgerichtig verfolgt unsere Implementation nicht das Ziel, die vielfältigen Möglichkeiten der menschlichen Zusammenarbeit abzubilden, sondern beschränkt sich bewusst auf die Organisation der Prozesse zwischen den Vertretern der einzelnen Vorschläge (im folgenden Initiativen genannt) und allen Stimmberechtigten. Prämissen

Unser System soll folgende Anforderungen erfüllen können:

1. Das Regelwerk soll ohne Moderatoren auskommen.
2. Die Prozesse sollen vollständig nachvollziehbar sein.
3. Im Diskussionsprozess sollen die Initiativen automatisiert Feedback über die Mehrheitsfähigkeit ihres Entwurfs erhalten. Vorbehalte sollen strukturiert erfasst werden, um den Initiativen konstruktiv Möglichkeiten zur Erreichung einer größeren Unterstützung aufzuzeigen. Dabei soll das Potential je auszuräumendem Vorbehalt bzw. Kombination von Vorbehalten quantifiziert werden.
4. Stimmberechtigte können Ihre Stimme delegieren. Für den Widerruf der Delegation ist die Ausübung des eigenen Stimmrechts hinreichend.

Prozessvarianten

Das Konzept lässt mehrere Prozessvarianten (Standardverfahren, Eilanträge usw.) zu, für die jeweils Voraussetzungen und Parameter zu definieren sind. Im folgenden soll exemplarisch nur ein Standardverfahren dargestellt werden. Alle genannten Zahlen (Schwellen und Zeiträume) sind von der Organisation zu definierende Parameter und werden hier nur zur besseren Verständlichkeit mit konkreten Werten belegt. Initiativen und Anträge

Im System gibt es eine Reihe von Politikfeldparlamenten, bei denen sich grundsätzlich jeder als Mitglied anmelden kann. Ein von einer Initiative eingebrachter Antrag wird dem zuständigen Politikfeldparlament zugeordnet und hat zunächst den Status „neu“. Weitere Initiativen können jederzeit alternative Vorschläge unterbreiten und als Gegenantrag zu einem der bestehenden Anträge referenzieren. Die Gesamtheit aller auf diese Weise verknüpften Anträge bildet eine Gruppe konkurrierender Anträge zum gleichen Thema. Dynamische Themenparlamente

Auch Stimmberechtigte, die nicht Mitglied des jeweiligen Politikfeldparlaments sind, können sich jederzeit an der Diskussion und späteren Abstimmung zu einem Thema beteiligen. Hierdurch werden sie zum Interessenten am Thema und sind den Mitgliedern des Politikfeldparlaments (in Bezug auf das Thema) gleichgestellt. Das bei Abstimmungen maßgebliche Themenparlament ergibt sich damit aus der Vereinigungsmenge der Mitglieder des Politikfeldparlaments und themenspezifischen Interessenten. Die Existenz eines Themenparlaments endet mit der Abstimmung zum jeweiligen Thema. Alle Mitglieder eines Politikfeldparlaments können auf Parlaments- und Themenebene, alle Interessenten auf Themenebene Standardverfügungen für die Ausübung ihres Stimmrechts treffen: Enthaltung, Ablehnung, Delegation an ein anderes Mitglied bzw. einen anderen Interessierten. Diese Delegation kann auch weitergereicht werden, gilt aber nur, wenn das Stimmrecht nicht durch den Vollmachtgeber selbst ausgeübt wird. Hierbei wird jeweils die gesamte Vollmachtskette (von unten nach oben) durchlaufen. Status „neu“

Der Antrag verbleibt im Status „neu“ bis für das jeweilige Thema insgesamt ein signifikantes Interesse und eine realistische Aussicht auf Einigung besteht. Dies wird unterstellt, wenn ein einzelner Antrag zum Thema von bspw. 10% der Mitglieder des Themenparlaments als potentiell unterstützenswert gekennzeichnet wird. Gibt es mehrere konkurrierende Anträge, die ein Abstimmungsberechtigter grundsätzlich als unterstützenswert betrachtet, kann und soll er bis zur eigentlichen Abstimmung unabhängig von Präferenzen mehrere Anträge unterstützen. Bei Erreichen des Quorums durch einen der Anträge wird der Status aller Anträge zum Thema auf „in Diskussion“ geändert und es erfolgt eine Information aller Stimmberechtigten. Wird das Quorum nach z. B. einem Monat von keinem Antrag erreicht, fallen alle Anträge zum Thema in den Status „nicht relevant“ und werden nicht weiter bearbeitet. Status „in Diskussion“

Nach Erreichen des Status „in Diskussion“ beginnt eine bspw. dreimonatige Frist nach der in der Regel eine Abstimmung zum Thema stattfindet. Die Abstimmung kann früher erfolgen, wenn dies von der Mehrheit der Mitglieder des Themenparlaments befürwortet wird. Die Frist kann durch Mehrheitsvotum auch verlängert werden.

Die Unterstützerstimmen werden in das Feedbacksystem übernommen und gelten bis auf Widerruf als vorbehaltlose Unterstützung des Antrags. Hierbei geht es unabhängig von einer möglichen Präferenz nur um die Frage, ob der Antrag an sich ohne dies an weitere Bedingungen zu knüpfen als zustimmungsfähig betrachtet wird. Dies ist für alle Initiativen eine erste Indikation für die Mehrheitsfähigkeit des eigenen Vorschlags.

Teilnehmer, die einem Entwurf zustimmen könnten, sofern bestimmte Voraussetzungen erfüllt werden, können diese notwendigen Bedingungen formulieren und die Anforderung mit dem eigenen Stimmgewicht versehen. Sofern eine Anforderung bereits existiert, kann das eigene Stimmgewicht hinzugefügt werden. Bereits gestellte Anforderungen sind nach dem Stimmgewicht beginnend mit dem höchsten Gewicht sortiert. Um die Chance der Realisierung der eigenen Anforderung zu erhöhen, ist es sinnvoll, sich (wann immer möglich) einer bereits bestehenden Anforderung anzuschließen.

Die Initiativen können nun den möglichen Stimmenzuwachs bei zufriedenstellender Realisierung der Anforderungen abschätzen. Hierbei wird für eine Auswahl der Anforderungen errechnet, welcher maximale Zuwachs zu erwarten ist. Da es sich hier grundsätzlich um notwendige Bedingungen handelt, werden Stimmen eines Teilnehmers nur dann gezählt, wenn alle von diesem Teilnehmer gestellten Bedingungen in der jeweiligen Auswahl enthalten sind.

Neben den beschriebenen

• notwendigen Bedingungen für eine Zustimmung

(„bei Realisierung meiner Bedingungen würde ich zustimmen“)

haben wir zusätzlich aufgenommen:

• Indikation der Präferenzsteigerung

(„dies macht den Vorschlag noch unterstützenswerter“)

• Indikation der Präferenzsenkung

(„ich würde zwar weiterhin zustimmen, dies aber als Verschlechterung ansehen“)

• hinreichende Bedingung für das Entziehen der Zustimmung

(„bei Realisierung dieser Änderung ziehe ich meine Unterstützung zurück“).

Alle Initiativen arbeiten nun auf eine Verbesserung des eigenen Vorschlags in Bezug auf seine Mehrheitsfähigkeit hin. Wenn eine Initiative einen neuen Entwurf (neue Version des Antrags) veröffentlicht, bleiben die angegebenen Bewertungen zunächst unverändert, da davon auszugehen ist, dass die jeweilige Initiative den Antrag i. d. R. nicht in seiner Substanz antastet und auf eine Verbesserung hinarbeitet. Die Unterstützer werden über die Änderungen informiert (Versionsvergleich zwischen dem aktuellen Entwurf und dem Entwurf zum Zeitpunkt der letzten Sichtung) und können die Bewertung ändern. Das Feedback umfasst die folgenden Informationen:

• Zahl derzeit vorbehaltlosen Unterstützer
• Zahl der derzeit vorbehaltlosen Unterstützer, die den letzten Entwurf schon gesichtet haben
• Gesamtzahl der potentiellen Unterstützer.

Hinsichtlich der einzelnen Änderungsideen gibt es je Anregung Angaben über die Anzahl von Anhängern und Gegnern entsprechend der oben genannten Feedback-Klassifizierung.

Auch in dieser Phase können weitere Initiativen Anträge erstellen. Sofern eine Kopie einer beliebigen Version eines vorhandenen Antrags als Ausgangsbasis genutzt wird, werden die zugewiesenen Bewertungen allerdings nicht vererbt. Abstimmung

Es können verschiedene Wahlsysteme implemtiert werden. Wir haben uns für die Implementierung der Präferenzwahl nach der Schulze-Methode entschieden. Die Schulze-Methode erfüllt eine Reihe von Kriterien, insbesondere das Monotonie-Kriterium (kein direktes negatives Stimmgewicht) und die Klonresistenz (das Erstellen verschiedener Antragsvarianten zur gleichen Grundidee führt insgesamt zu keinem Vorteil oder Nachteil).

Neu in LiquidFeedback Core Beta 4: Je nach gewählter Prozessvariante wird die Änderung von Anträgen durch die jeweiligen Initiativen für eine bestimmte Zeit (bspw. 3 Tage) vor dem Beginn der Abstimmphase unterbunden; neue Anträge dürfen jedoch noch eingebracht werden. Auf diese Weise soll die Macht der Initiatoren durch die Möglichkeit von Antragsänderungen in letzter Minute eingeschränkt werden, da in diesem Falle noch vor Beginn der Abstimmung Unterstützungen zurückgezogen bzw. Konkurrenzanträge eingebracht werden können.

Mit Beginn der Abstimmphase können keine weiteren Anträge mehr eingebracht werden und Anträge die zu diesem Zeitpunkt ein von der Prozessvariante vorgeschriebenes Unterstützerquorum nicht erreicht haben scheiden aus. Zwischen den verbleibenden Anträgen findet eine (z. B. 2-wöchige) Abstimmung statt, während der Anträge mittels Zustimmungs­präferenzen, Enthaltungen oder Ablehnungen bewertet werden können. Auch abgelehnte Vorschläge können auf Wunsch in eine Präferenz­reihenfolge gebracht werden, damit keine Motivation zur Zustimmung oder Enthaltung für das “kleinere Übel” entsteht.

Im Rahmen der Auszählung wird zunächst die Gesamtzahl der Zustimmungen und Ablehnungen ermittelt und die nicht mehrheitsfähigen Anträge werden gestrichen. Die verbleibenden Anträge werden mittels Schulze-Methode in eine Rangreihenfolge gebracht. Der Antrag mit dem höchsten Rang gilt als angenommen. Im Falle des Gleichstandes zweier Anträge gewinnt der Antrag mit einem besseren Verhältnis von Zustimmungen zu Ablehnungen. Besteht immer noch Gleichstand gewinnt der zuerst eingebrachte Antrag. Geheimhaltung und Offenlegung

Nach der Abstimmung sollten alle Abstimmdaten offengelegt werden (namentliche Abstimmung). Dies gilt auch für die Informationen darüber, wer mit wessen Vollmacht gestimmt hat. Auf diese Weise kann jeder Teilnehmer selbst die Korrektheit der Ergebnisse überprüfen.

Da auch das Erreichen von Quoren Auswirkungen auf die Abstimmungen hat, wird zum Zeitpunkt der Annahme oder Ablehnung eines Themas sowie zum Beginn der Abstimmungsphase eine Momentaufnahme der Unterstützer samt erteilter Vollmachten erstellt. Die Daten dieser „Snapshots“ sollten den Benutzern des Systems ebenfalls zur Einsichtnahme zur Verfügung gestellt werden.

Unter Verweis auf das Gibbard-Satterthwaite-Theorem bzw. das General Impossibility Theorem von Arrow plädieren wir jedoch während des Abstimmprozesses für eine organisatorisch sichergestellte Geheimhaltung von Zwischenergebnissen zur Verhinderung von Wahlmanipulationen (z. B. durch Bots). Obwohl die Schulze-Methode vergleichsweise rebust gegen taktisches Wählen ist, kann nicht ausgeschlossen werden, dass das Ergebnis verfälscht werden könnte, wenn die Zwischenergebnisse weitläufig bekannt sind. Technische Realisierung

Die gesamte beschriebene Logik (der Kern) wurde in Form von Datenbankviews und Datenbanktriggern realisiert. Als Datenbanksystem wurde PostgreSQL gewählt, das unter BSD-Lizenz zur Verfügung steht. Die prozeduralen Komponenten wurden in PL/pgSQL implementiert. Erforderliche Sicherheitsmechanismen (Anmeldung, Sessionmanagement etc.) müssen im Rahmen des Frontends oder einer entsprechenden Schicht umgesetzt werden.

Auf den Kern aufbauend arbeiten wir derzeit an einer Referenzimplementation eines Frontends. Der Kern kann jedoch auch von anderen Frontends genutzt werden. Hinsichtlich der Programmiersprache für das Frontend gibt es keine Restriktionen, sofern die verwendete Sprache über eine PostgeSQL-Zugriffsbibliothek verfügt. Für die Programmiersprache C liefert PostgreSQL bereits eine Zugriffsschnittstelle unter BSD-Lizenz mit. Für praktisch alle weiteren relevanten Sprachen sind Wrapper-Bibliotheken vorhanden.