Piratenwiki Mirror

Liquid Democracy/Weitere Gedanken zur Umsetzung

< Liquid Democracy

Diese Ausführungen sind Ergebnis einer Diskussion über eine mögliche Umsetzung des Liquid-Democracy-Prinzips innerhalb der Piratenpartei.

Ziel

  • eine Plattform zu schaffen, die Mechanismen enthält, um die 'Wisdom of Crowds' (Engl.) anzuzapfen.
  • Oder: ein selbstregulierendes politisches System.
  • Dabei soll die Argumentation in den Mittelpunkt gestellt werden, damit fruchtbare Diskussionen entstehen. Die Architektur des Systems sollte darauf abzielen, sachlichen Argumentationen den Vorrang zu geben.

Probleme (und Lösungsansätze)

  • das System soll transparent und gleichzeitig anonym sein.
    • zur Anonymität (bzw. Schutz der Privatsphäre): es ist die Entscheidung jedes Einzelnen, ob er sein Abstimmungsverhalten (teilweise) öffentlich machen will.
    • vgl. das 'Activity-Stream-Konzept' für Communities: alle Aktionen des Benutzers werden aufgezeichnet; diese Daten gehören nicht dem Betreiber, sondern dem Benutzer selbst. Dies ermöglicht es zB., in eine andere Community zu wechseln, ohne sämtliche Daten zu verlieren. In dieser Weise könnten wichtige Aktionen innerhalb der L-D-Plattform aufgezeichnet und (gar nicht/ teilweise/ bestimmten Personen/ vollständig) öffentlich gemacht werden, zB. tagging oder Abstimmen.
    • es bleibt das Problem der Ermittlung der Stimmenverteilung; diese müsste zentral erfolgen und auch extern in ihrer Gültigkeit überprüfbar sein. Dies ließe sich durch entsprechende technische Gestaltung ermöglichen. Der Source-Code eines solchen Systems müsste öffentlich sein; die Daten nicht. Denkbar wären auch Token-Systeme (Pseudonymisierung) oder (langfristig) die Umsetzung als P2P-Applikation.
    • Diese Probleme sollte man bei der Entwicklung und Evaluierung eines Prototyps im Hinterkopf behalten, auch wenn sie nicht alle auf einmal lösbar sind.
  • Wie verhindert man 'Mob-Erscheinungen' v.A. bei ideologisch-emotional besetzten Fragen? Damit hängt das Problem der manipulativen Presse-Berichterstattung zusammen. Herauszufinden wie das verhindert werden kann ist eines der Hauptziele des Experiments.
  • Spam-Problem bei Abstimmungsvorschlägen (wer kann Vorschläge einreichen und wie werden sie bearbeitet?).

Mechanismen

  • Tagging von
    • Abstimmungsfragen (z.B. um das Ressort zu bestimmen, zu dem eine bestimmte Frage gehört; dies ist wichtig für die Proxy-Auswahl)
    • Argumenten ('Killerargument'; 'sachlich'; 'Angstmache'; 'laberig';...)
  • Die Zugehörigkeit einer Frage zu einem bestimmten Ressort wird nach den Tags bestimmt (entweder nach dem Mehrheitsprinzip oder anteilig nach den Häufigkeiten). Problematisch könnte evtl. die Zuordnung der Tags zu bestimmten Ressorts (und damit die Zuordnung der Abstimmung zu bestimmten Stellvertretern) werden; hier könnte man Algorithmen einsetzen, um verwandte Tags zu bestimmen. Allerdings ergibt sich bei Tags erfahrungsgemäß schnell eine Taxonomie. Zudem sollte das System populäre Tags vorschlagen.
  • Vergabe (und Entzug) von Vertrauen an Stellvertreter (Proxies).
  • RSS-Feed mit Entscheidungen
  • Jeder kann Vorschläge einbringen. Diese werden dann zunächst einigen wenigen (zufällig ausgewählten) Benutzern zur Abstimmung vorgelegt und entsprechend der Entscheidung als Vorschlag angenommen oder nicht. Es könnte so etwas wie ein 'Mülleimer'-Tag geben ('diese Frage/ Abstimmung ist irrelevant').
  • Für jede Entscheidung/ Abstimmung gibts eine bestimmte Frist, innerhalb derer die Stimmen gezählt werden. Diese können je nach 'Impact' (Auswirkungen) der Entscheidung unterschiedlich sein.
  • Abstimmung: nach dem Lesen und ggf. Diskutieren kann der Benutzer seine Stimme abgeben.
  • Auch weiterhin muss die Verantwortung für bestimmte Bereiche eindeutig verteilt sein (jemand ist für die Pressearbeit zuständig, bis ihm das Vertrauen per Abstimmung entzogen wird), damit nicht jede kleine Entscheidung durch das System gehen muss und am Ende niemand wirklich verantwortlich ist.
  • Es muss 'Entschleunigungs'-Mechanismen geben: die gleiche Frage darf erst nach einer bestimmten Zeit erneut zur Abstimmung gestellt werden.

Proxies (Stellvertreter)

  • Voraussetzung, um Proxy werden zu können, ist die Veröffentlichung der Entscheidungshistorie (wie hat jemand sich bei früheren Abstimmungen entschieden?) inkl. der Begründungen (aufgrund von welchen Argumenten hat man sich entschieden?). (Eventuell sollte man den Veröffentlichungszwang nicht auf alle Entscheidungen beziehen, damit weiterhin in bestimmten Wahlen geheime Abstimmungen möglich sind, z.B. in Entscheidungen wo die Person sonst befangen wäre?)
  • Proxies werden entweder generell oder nach Ressorts bestimmt; bzw. eine Mischung aus beiden: es gibt einen Generalstellvertreter, der für alle Themen zuständig ist außer für die, für die es einen eigenen Stellvertreter gibt.
  • 'Fallbacks': Wenn ich nicht abstimme, soll X für mich entscheiden.

Nächste Schritte

  • Mock-up von Version 2.0 (mit vielen Features und schöner Oberfläche) erstellen (wie könnte eine L-D-Plattform aussehen) und Partner für die Umsetzung gewinnen.
  • Tagging von Abstimmungen und Argumenten könnte zunächst einfach als Wiki-Seite umgesetzt werden.
  • Generell sollte das System zu Anfang so einfach wie möglich sein. Dadurch werden Experimente und ein evolutionärer Entwicklungsprozess ermöglicht. Zunächst sind nur folgende Features notwendig:
    • Abstimmen
    • Stimme an Proxy geben (generell oder für einzelne Bereiche)


Notizen

  • Entscheidungen sollte konsistent sein; kann das funktionieren, wenn man in jedem Ressort einen anderen Stellvertreter entscheiden lässt? Man könnte dem entgegenhalten, dass eine solche konsistente, in sich stimmige Politik auch bisher nicht wirklich existiert, sondern nur scheinbar. Wichtig erscheint es uns, dass man hier nicht aus Angst argumentiert. Zudem sollte eine komplette Delegation an einen Stellvertreter (oder auch: eine Partei) auch weiterhin sehr einfach möglich sein, möglicherweise als Default.
  • Haushalt: wie werden zum Beispiel durch Entscheidungen nötig gewordene Mehr-Ausgaben gegenfinanziert? Negativbeispiel ist die aktuelle Situation in Kalifornien: Im Haushalt Kaliforniens klafft eine Lücke von 21,3 Milliarden Dollar, und alle Versuche, sie zu schließen, sind gescheitert. Mitschuld daran ist auch das System der direkten Demokratie, auf das Kalifornien so stolz war in besseren Zeiten. Vergangene Woche lehnten die Bürger Beschlüsse ihrer Politiker ab, die den Staat solvent halten sollten, zumindest bis Ende des Jahres. Sechzig Prozent der Wähler sagten nein zu höheren Steuern, niedrigeren Ausgaben und mehr Staatsschulden. Quelle: Sueddeutsche[1]. Sollten bei Gesetzesaenderungen gleich die noetigen Veraenderungen etwa im Steuersatz mitbeschlossen werden? Das waere der Transparenz und Konsitenz finanzieller Entscheidungen sicher foerderlich, bedingt aber ein flexibles Steuersystem.
  • Vertrauen: technisch entweder 1 oder 0 --> Graph mit eindeutigen Entscheidungskriterien.
  • vgl. Wikipedia: sie hat in kurzer Zeit den Bereich der Wissensproduktion und -konsumption umgekrempelt; das gleiche müssten wir mit der Demokratie machen. Vielleicht könnte man Jimmy Wales als Unterstützer gewinnen und das ganze als Wikimedia-Projekt durchführen (interessant wäre der L-D-Mechanismus auch für Abstimmungen innerhalb der Wikipedia zB. über Löschkandidaten).

Notizen für einen Testlauf

Hier ist der Testlauf

  • Weglassen:
    • Endgültige Lösung für alle Probleme finden
    • Anonymisierung -> später lösen
    • Authorisierung -> später zuschalten falls/sobald notwendig
    • Schickes Interface
    • Globales Proxysystem
  • Ziele:
    • Eine konkrete, einfache, interne Implementierung, an der wir über Liquid Democracy lernen können
    • Rausfinden, was auf eine entsprechende Seite muss?
    • Rausfinden wie das optimal strukturiert ist.
    • Arbeitsablauf für Liquid Democracy im Wiki finden

Wie kommt es zu einer Wikiseite mit Abstimmung

  • Anträge stellen durch Anlegen der Seite
  • Phasenweiser Ablauf:
    • Diskussion und Erstellung der Abstimmung
      • Jeder kann auch schon für bestimmte Beiträge oder Beitragende abstimmen (als proxy)
    • Freeze: 24 Stunden (mit Ankündigung -> Mail) in denen jeder seine Stimme prüfen kann

Wikiseite einer Abstimmung

  • Thema:
  • Fragestellung:
  • Fragesteller:
  • Proxy Bereich: Jeder der einem Proxy seine stimme geben will, trägt ihn hier ein und hängt seine Stimme an
  • Standpunkte:
  1. Erster
  2. Zweiter
  3. Dritter
  4. Stimmabgabe über Signatur
    1. Proxyfunktion über eingerückte Signatur
  • Ergebnis:

Kopie von Jan Huwalds Gedanken zur Umsetzung

Ursprünglich geplant als Vorbereitung der Strategietagung 2007, dort aber nicht thematisiert.

Roadmap Liquid Democracy

Mögliche Zielstellungen (als Begründungen für LD):

  • maximale Beteiligungsmöglichkeit für (einfache) Mitglieder bei Vermeidung der Skalierungsprobleme direkter Demokratie
  • Reduktion von Unstetigkeiten klassischer Wahlen (insb. durch Einmaligkeit der Wahlen)
  • Wahl von Themen, statt Personen


Die Einführung von Liquid Democracy hat drei mittelmäßig zusammenhängende Dimensionen:

  • juristisch: das Verfahren muss bei Wahlzulassungskommissionen als frei, geheim und nachvollziehbar anerkannt werden (zusammen mit dem demokratischen Aufbau der Partei)
  • technisch: Algorithmen, Protokolle und Software werden zur Wahl benötigt
  • soziologisch: der Umgang mit LD, Formen der zugehörigen Meinungsäußerungen, mögliche Einschränkungen bei verfügbaren Wahloptionen und Granularität der Wahlen, Fristen und Parameter der Wahlverfahren ... kurz: Erfahrung mit dem Wahlsystem im Parteialltag


These: Erfahrungsschwerpunkte müssen in der chronologischen Reihenfolge technisch -> soziologisch -> juristisch erlernt werden.
Begründung:

  • ohne die Software können keine Demokratieexperimente stattfinden
  • die juristische Verankerung von LD in der Satzung darf erst nach ausgiebigen Erfahrungen erfolgen; demokratische Handlungsfähigkeit, der Schutz vor ungewollten Oligarchien, sowie die bloße Durchführbarkeit hängen von den Gepflogenheiten und Parametern der LD ab. Diese müssen sich erst praktisch bewähren


In Konsequenz folgender Vorschlag einer Roadmap Liquid Democracy:

Typ technisch soziologisch juristisch
Meinungs-
bilder

Direkte Demokratie in Einzelapplikationen:

  • Votingforum
  • Digg für Blogs/Inhalte der Website
  • Sensibilisierung der Piraten für häufigere Entscheidungen
  • Diskussion ...
    • ... des Wahlverhaltens
    • ... der Meinungsverzerrung durch gezielte Fragestellung
    • ... der Auswirkung von Artikelselektion auf die Artikelinhalte
Informell bindend

Einführung eines eigenständigen Proxyvotingsystems

  • variabel in Wahlmodi
  • gekoppelt an eindeutige, anonyme Mitgliederauthentifikation
  • Debatte über Kompetenz
    • welche Ressoirs sollen per LD entschieden werden? (zB. Programmvorschläge, Pressemitteilungen, Personalfragen, Finanzielles)
    • wie stehen LD-Entscheidungen zum Parteiprogramm in Relation?
    • wie werden Entscheidungen umgesetzt / kontrolliert?
  • Evaluation verschiedener Abstimmungsmodi
    • wer darf Abstimmungen einleiten?
    • welcher Form bedürfen diese?
  • sukzessive Integration des Wahlsystems in die Geschäftsordnung (da gültig, aber leicht zu ändern)
Formell bindend
  • Integration von LD ins Parteiprogramm
  • Export(angebot) für LD an andere Parteien und Organisationen
  • Integration von LD in die Satzung
    ggf. zweistufig erst in eine Landessatzung, dann Bundessatzung für frühzeitige, externe, juristische Prüfung

Lw's Gedanken zu LD

Als Piratenpartei, die wehement für mehr Transparenz und damit auch gegen Wahlmaschinen eintritt, sollten wir höllisch aufpassen, dass uns hier keine Panne passiert. Ich halte es für prinzipiell unmöglich, freie, gleiche und geheime Wahlen mittels Computer durchzuführen - so sehr ich mir das Gegenteil wünschen würde.

Anders sieht es bei offenen Abstimmungen aus. Hier könnte ich mir sehr wohl vorstellen, dass jeder Bürger über seinen gewählten Proxy vor Ort, selbst oder durch einen beliebigen anderen Proxy an einer namentlichen Abstimmung im Bundestag teilnimmt. Wie bei geheimen Abstimmungen GG Art. 38 Abs. 1 wieder mehr Gültigkeit gewinnen kann (Gewissen statt Fraktionszwang und versprochene Aufsichtsratsposten), weiß ich leider auch nicht, diese braucht es aber leider auch. Wenn ich als Mieter nicht in Frage komme, weil mein Abstimmungsverhalten dem Vermieter nicht passt, ist da was falsch gelaufen.

Sicher muss man mit einer Art hash-Code, somit anonymisiert, abstimmen können; und sicher macht a) eine Meinungsbildung b) Qualitätsmanagement von Verwaltung und Politik und c) Stimmabgabe _per Internet_ Sinn. Aber wenn jemand mit letzter Klarheit belegen kann, dass c) nicht sauber machbar ist, dann reichen mir auch a) und b), dann muss ich eben zum Kreuzchen-Machen in eine Wahlkabine gehen. Recht nachvollziehen kann ich die _grundsätzliche_ Argumentation gegen Wahlcomputer (immer noch) nicht. Konkrete Anwendungen sollten freilich in jedem Einzelfall aufmerksam und kritisch betrachtet werden. --Bernd 18:39, 12. Jan. 2008 (CET)
"_grundsätzliche_ Argumentation gegen Wahlcomputer": Hier kann ich nur eine grundsätzliche Argumentation gegen Wahl per Internet von zu Hause aus geben. Wenn ich meine Stimme nachprüfbar geben kann, dann kann ich meine Stimme auch verkaufen oder zu einer Abstimmung genötigt werden. (Ein Problem, das viele auch bei der Briefwahl sehen. Im Jahr 2005 waren 18,6% der abgegebenen Stimmen Briefwahlstimmen) Gemeinsam mit dem, der ein Interesse an meiner Abstimmung hat, führe ich das Prozedere durch. Damit ist die Wahl nicht frei. (Mich würden Meinungen zu http://www.bingovoting.de/index.html interessieren.)--Lw 20:02, 12. Jan. 2008 (CET)

Schoen Gedanken zu LD

Die Integration von Liquid Democracy ins Parteistatut

1. Anforderungen des Parteiengesetzes

Die Wahl von Vorständen und die Nominierungen für öffentliche Ämter sind in geheimer Wahl durch die entsprechenden Gremien (Parteitage) vorgeschrieben (Wahlkommission, Wahlzettel / Briefwahl, offline-Wahl). Daraus folgt die Frage nach einem anerkannten und „zulässigen“ online-Wahlverfahren.

Inhaltliche Entscheidungen werden in der Regel vom Parteitag getroffen, auf dem zum jetzigen Zeitpunkt alle Mitglieder stimmberechtigt sind, da noch kein Delegiertensystem installiert wurde.

Wenn wir dies auf unsere Liquid Democracy- Vorstellungen übertragen folgt für mich daraus:

  • Alle Mitglieder sind stimmberechtigt
  • Aus Politikfeldern werden Anträge an den Parteitag
  • Damit Anträge auf die Tagesordnung kommen und behandelt werden, sollte ein Quorum festgelegt werden.
  • Für Anträge, die auf die Tagesordnung gelangt sind, sollte eine Abstimmungfrist eingeführt werden.
  • Vom Parteitag angenommene Anträge, sollten dann öffentlich weiter behandelt werden können.
  • Da dieser Prozess kontinuierlich stattfinden soll, müsste der Parteitag online in Permanenz tagen.


2. Notwendige Änderungen des alten Parteistatut

Der Konflikt verläuft an der Schnittstelle offline / online Abstimmung

a) Sachentscheidungen => der Parteitag tagt praktisch in Permanenz. Nach dem Parteiengesetz muss der Parteitag mindestens alle zwei Jahre zusammen treten.

b) Personalentscheidungen => Wahlverfahren, Wahlperioden,

c) Finanzentscheidungen => transparente „Kassen / Konten“

d) Vorstandsentscheidungen => rein administrativ ?


3. Neues Parteistatut

a) Es sollte ein Passus eingesetzt werden, der definiert ab welchen Voraussetzungen der Parteitag online in Permanenz tagt (was nicht ausschließt, dass auch offline Sitzungen veranstaltet werden können).

b) Es sollte eine für den online in Permanenz tagenden Parteitag adäquate Geschäftsordnung beschlossen werden.

c) Sollte ein online Wahlverfahren – für die leider vorgeschriebenen Personalwahlen – vorgeschlagen werden.

d) Es sollte noch ein Verfahren entwickelt werden, wie Vorstandsentscheidungen in den Prozess integriert werden können.

Ich hoffe das reicht als Diskussionsanregung erst mal aus.

Abgerufen von „https://wikimirror.piraten.tools/wiki/index.php?title=Liquid_Democracy/Weitere_Gedanken_zur_Umsetzung&oldid=55519273“