User:ThomasvonderElbe GmxDe/Votorola
Votorola ist eine LD-Software zur Realisierung von Abstimmungen/Wahlen sowie zur Strukturierung des politischen Diskurses - in beliebiger Größenordnung (lokal, national, global).
Bei Interesse, Fragen oder Anregungen meldet Euch bitte bei mir.
Evtl. ist auch die Diskussionsseite von Interesse.
Oder der Vergleich mit 16 anderen Tools: hier
Contents |
Bereichs-Delegierung
Bei Votorola ist die Möglichkeit der Stimmen-Delegierung über mehrere Abstimmungen hinweg vorgesehen (bis jetzt aber noch nicht implementiert). Diese “Bereichs-Delegierung” dient der Erleichterung der “Abstimm-Arbeit”.
Beispiel:
X erhält meine Stimme für alle Abstimmungen im Bereich Ökologie, Y für alle Abstimmungen im Bereich Steuern und das Bündnis "Greenpeace" erhält meine Stimme für alle Abstimmungen, die für ihr Bündnis-Ziel wichtig sind. Auch innerhalb einer Abstimmung ist diese Form der arbeitsteiligen Delegierung möglich (und implementiert), muss aber von der kommunikativen Delegierung (siehe unten) unterschieden werden.
Andere Tools, die Bereichs-Delegierung unterstützen: Adhocracy, LiquidFeedback
Andere Tools, die Bereichs-Delegierung ablehnen: Candiwi, NationBuilder, Vipa
Funktionsweise innerhalb einer Abstimmung
Was die Funktionsweise innerhalb einer Abstimmung betrifft, gibt es offenbar zwei grundlegende Konzepte im LD-Bereich:
- 1. viele Menschen arbeiten an wenigen Entwürfen
- 2. wenige Menschen arbeiten an (jeweils einem von) vielen Entwürfen
Beispiel-Tools:
- zu 1. Adhocracy, Candiwi, LiquidFeedback, NationBuilder, Vipa, ...
- zu 2. Votorola
Beides hat Vorteile, bringt aber auch spezifische Probleme, die gelöst werden müssen:
Darstellung zu 1.:
Viele Menschen stimmen jeweils für wenige Entwürfe. Das Problem ist, das Feedback vieler Menschen sinnvoll zu strukturieren.
LiquidFeedback versucht das über abstimmbare Änderungsvorschläge zu realisieren.
Darstellung zu 2.:
Votorola: Wenige Menschen arbeiten an jeweils einem Entwurf.
Das wird möglich durch die sogenannte “kommunikative Delegierung”. Sie ist nur innerhalb einer Abstimmung möglich, im Gegensatz zur “Bereichs-Delegierung”(siehe oben). Der Delegierungsbaum der Bereichs-Delegierung über mehrere Abstimmungen hinweg, würde quasi senkrecht auf dem Bild rechts stehen.
Beispiel:
Innerhalb der Abstimmung zum BGE schließe ich mich mit Gleichgesinnten zu einer Gruppe zusammen. Wir delegieren all unsere Stimmen an einen Vertreter, der uns (mit seinem Entwurf) gegenüber anderen Gruppen vertreten soll. Uns ähnlich gesinnte Gruppen haben auch ihre Vertreter, die sich mit unserem Vertreter zusammenschließen. Diese Gruppe von Vertetern bestimmt nun ihrerseits einen Vertreter ... usw. usw.
So entsteht innerhalb jeder Abstimmung ein Delegierungsbaum bzw. eine Landkarte politischer Meinungen.
Diese Karte wird sich anfangs sehr dynamisch verändern: manche Gruppen lösen sich auf und andere bilden sich neu. Zwischen einer Gruppe und ihrem Vertreter, also an den Verzweigungen des Baumes wird diskutiert und verhandelt. Nach dem Schema: „Wenn Du unseren Vorschlag nicht übernimmst, delegieren wir unsere Stimmen an jemand anderen! ...“
Der Text bzw. die Ideen fließen so von den Blättern zum Stamm und umgekehrt.
Je "reifer" eine Abstimmung wird, desto statischer wird die Karte und die Liste der End-Entwürfe wird kürzer. D.h. das System neigt zur Bildung von Konsens.
Votorolas Grundsätze
Jede Liquid-Democracy-Software wird gemessen an der Freiheit, die sie ihren Nutzern läßt und dem Maß an Mitbestimmung, das sie ihnen ermöglicht.
Deshalb der Ansatz von Votorola: Minimum an Begrenzungen und Regeln! Maximale Verflüssigung!
1. in jeder Abstimmung kann jeder eine eigene Position haben und diese auch jederzeit verändern.
2. jeder kann seine eigene Stimme und seine erhaltenen Stimmen an jeden weiterdelegieren.
3. man wird dabei nicht gezwungen, seine eigene Position aufzugeben.
4. mit den Stimmen der eigenen Wähler im Rücken, kann man seinen Vertreter zu Veränderungen bewegen.
5. jeder kann jederzeit seine Stimme(n) zurückziehen oder verschieben.
Testphase
Momentan laufen Alpha-Tests, d.h. das grundlegende Design wird getestet. Alle wesentlichen Funktionen stehen zur Verfügung, aber es geht im Moment noch nicht vordergründig um bequeme Bedienbarkeit, ... (u.a. läuft die Test-Software aufgrund alter Hardware ziehmlich langsam.) Alle 4 Stunden erfolgt ein Snapshot, d.h. die systemübergreifende Stimmenauszählung.
Zum Testen haben wir eine Abstimmung zum Bedingungslosen Grundeinkommen ins Leben gerufen.
Im Stimmen-Browser auf einen Kandidaten klicken, zeigt alle Wähler an, die für ihn gestimmt haben. So kann man durch den Delegierungs-Baum browsen, sich von Ast zu Ast, von Zweig zu Zweig hangeln. Der Link direkt vor dem Namen des Kandidaten/Wählers führt zu seinem Positionsentwurf in der Wiki.
Über Hilfe (rechts oben) gibt es auch eine deutsche Hilfeseite. Dort sind die Schritte zum Umstellen auf Deutsch, Einloggen, Wählen, eigene Position verfassen usw. beschrieben.
Einsatz von Votorola
Votorola ist im Moment eher als Ergänzung zum herkömmlichen Wahlsystem gedacht, nicht als Ersatz. D.h. egal was die online-Ergebnisse sind, müssten diese noch per Zettel und Kreuz bestätigt werden. Dadurch können wesentliche Sicherheitsprobleme umgangen werden, ohne dass auf die Vorzüge der Liquid Democracy verzichtet werden muss. (Dies gilt zumindest solange, wie noch keine Lösung für das generelle Problem geheimer E-Wahlen gefunden wurde.)
Technische Aspekte
- beliebig austauschbare Module: Vote-Engine, User-Interface, Wähler-Register, Diskussionsmedium, Difference-Engine, Auto-Caster, Vote-Mirror ...
- Webanwendung, Java
- webserverseitiger Tomcat-Server, Linux als Betriebssystem
- Datenbanksystem PostgreSQL
- beliebige Skalierbarkeit durch dezentrale pyramidenförmige Serverstruktur
Offene Architektur
Wir unterstützen die Entwicklung einer offenen LD-Architektur, wo alle einzelnen Tools nebeneinander existieren können, ohne um Wähler konkurrieren zu müssen. Ein gemeinsames Wähler-Register und ein Tool zur Stimmen-Spiegelung stellt sicher, dass die eigene Stimme auch in allen anderen Plattformen gezählt wird, egal wo man gewählt hat. Die einzelnen Tools können weiterhin um Nutzer konkurrieren, aber nicht mehr um Wähler. Dadurch wird eine Spaltung der LD-Bewegung verhindert.
Hier ist unser Vorschlag: Open Architecture
Wähler-Registrierung
Zur Wohnsitz-spezifischen Wähler-Registrierung schlagen wir ein Trust Network (Vertrauens-Netzwerk) vor. Es ist als Prototyp in Kürze fertig.
Grundgedanke: Über ein Netzwerk verbürgen sich die Wähler gegenseitig für ihre Authentizität. D.h. sie verbürgen sich dafür, dass ein bestimmter Nutzername (oder email-adresse, etc.) wirklich zu einer real existierenden Person im Nachbarhaus gehört. Deren bürgerlicher Name bleibt dabei ungenannt. Lediglich die Verbindung von email-adresse und Wohn-Adresse wird öffentlich bezeugt.
Funktionsweise: Jeder Wähler beginnt mit einem Trust-Level von 0. Wenn sich jemand mit einem Trust-Level von 1 für ihn verbürgt, steigt auch sein Trust-Level auf 1. Um auf Level 2 zu gelangen braucht er zwei Bürgen, die beide schon auf Level 2 sind. Um auf 3 zu gelangen braucht er 3 Bürgen, die alle drei schon auf Level 3 sind usw.
Jeder kann sich für beliebig viele andere in einem Umkreis von N Kilometern verbürgen.
Schutz vor Sockenpuppen: Da die Verbindung von Wohn-Adresse und email-adresse öffentlich wird ( = Stadtplan mit eingezeichneten email-adressen), fällt es früher oder später auf, wenn 5 Leute in der 1-Raum-Nachbarwohnung, in einem leerstehenden Haus oder einer nicht existierenden Adresse angemeldet sind. Diejenigen, die sich für diese Sockenpuppen verbürgt haben, sind offensichtlich Betrüger. Und diejenigen, die sich für diese Betrüger verbürgt haben, sollte man vielleicht auch mal ansprechen - zumindest, damit sie ihre Bürgschaft zurückziehen. Gleichzeitig bzw. alternativ kann man Doubt-Signale an solche User heften, um andere (bzw. letztendlich den Registrar) auf sie aufmerksam zu machen. Doubt-Signale sind nur Hinweise und vermindern nicht das Trust-Level.
Stellschrauben für die Sicherheit: Je höher man das geforderte Trust-Level für eine Abstimmung ansetzt und je kleiner der geographische Radius ist, in dem Bürgschaften gültig sind, desto geringer die Wahrscheinlichkeit von Sockenpuppen.
Organisation: Das Vertrauens-Netzwerk einer Stadt wird von den ersten LD-Pionieren dieser Stadt selbst aufgesetzt. Der anfängliche Administrator "injeziert" die ersten Trust-Level ins Netz. Von dort verbreitet es sich ja dann von selbst. Dieser Administrator könnte z.B. vorab von diesen Pionieren gewählt werden, d.h. er sollte vertrauenswürdig sein. Bei "Fehlverhalten" kann er ja später jederzeit "liquide" abgewählt werden. Auch später benötigte Registrare (mehrere pro Stadt) können von den Nutzern selbst gewählt werden.
Anonymisierung: Der bürgerliche Name spielt in dem System ja sowieso nirgends eine Rolle (d.h. er wird nirgends eingegeben). Aber es gibt die Verbindung von Wohn-/email-adresse einerseits und Wahlverhalten andererseits. Für den Anfang ist nicht geplant, diese Verbindung zu anonymisieren. Es scheint aber über die Institution der Registrare ermöglicht werden zu können. Überlegung: eine Person benutzt zum Abstimmen eine andere email-adresse als zur Wohnort-Verifizierung und der Registrar verbürgt sich für die (nicht öffentliche) Identität hinter beiden. Anonymität würde also nicht technisch über komplizierte kryptographische Methoden erreicht, sondern würde getragen von Vertrauen/Kontrolle der Wähler gegenüber ihrem gewählten Registrar.
Mehr hier (engl.)
und hier (engl.)
