Quelltext der Seite BE Diskussion:Liquid Democracy — Anforderungen, Betrieb und Sicherheitsrichtlinien

== Kritik: web-basiert ist unsicher ==
''Vorsicht: Anforderungen nicht zu hoch stellen, sonst wird eine Implementierung nie fertig oder verschlingt unangemessen viele Ressourcen!''
:Sicher, aber wenn man in den Parlamentsbetrieb geht, wird man die ganze Sache nochmal neu aufrollen müssen, denn [[Benutzer:LynX/Demokratie_2.0|web-basierte Applikationen können einfach nicht wirklich sicher gemacht werden]]. Am Schluss könnte nur ganz selten hier und da manipuliert werden, und der einfache Pirat, der aufschreit, wird als Denunziant diffamiert. Gerade wir Piraten sollten unsere Apps auf eine höheren Sicherheitsniveau bauen, als eine durchschnittliche Firma oder Bank. Es geht hier schließlich auf absehbare Zeit um reale Beschlüsse mit realen politischen Folgen, sei es in Münster, in Berlin, im Landtag NRW oder im Bundestag.  <small>[[User:lynX|&mdash;lynX]]</small>
::Meiner Meinung nach sind Firewalls, Code-Reviews, etc. nur ein Weg um Betriebsstörungen durch Hacker zu erschweren. Manipulationen 100%ig ausschließen können diese Maßnahmen nicht – dazu ist das gesamte technische System viel zu komplex. Wenn Webapplikationen unsicher sind, welche Art von Programmen wären denn dann sicher? Der Einsatz eines dezentralen Systemes, welches sich z.B. auf mathematische Verschlüsselungsverfahren verlässt, erhöht zumindest die Komplexität noch weiter. Aufgrund nicht auszuschließender Manipulationen werden andere Organe nicht verpflichtet, Entscheidungen des Systemes umzusetzen. In unserem [[BE:Satzungsänderungsvorschläge zur Umsetzung von Liquid Democracy#§ 13 LIQUID DEMOCRACY|Entwurf für die Satzung]] heißt es: ''"Alle Organe und Mandatsträger sind grundsätzlich dazu angehalten, jedoch nicht verpflichtet, sich entsprechend dieser getroffenen Entscheidungen zu verhalten."'' Natürlich ist es im Sinne der Basisdemokratie wünschenswert dennoch möglichst verlässliche Ergebnisse zu ermitteln. Deshalb haben wir folgendes gefordert: ''"Die Berechnungsgrundlagen von Abstimmungsergebnissen oder Antragsbewertungen müssen jedem Benutzer des Systems mindestens 23 Wochen nach Abschluss des jeweiligen Themas (z. B. durch eine endgültige Abstimmung) zur Verfügung gestellt werden. In den Berechungsgrundlagen sind Namen oder Pseudonyme der Abstimmenden und bei Stimmübertragung auch die der Delegierenden enthalten. [...] Die Information darüber, welche alten Pseudonyme welchem Mitglied zugeordnet waren, sind in Form einer Papierakte für 3 Jahre aufzubewahren. Die Landesmitgliederversammlung kann beantragen, dass diese Papierakte von der Wahlkommission geprüft wird."''. Vorstand und Mandatsträger werden sich entsprechend ihrer Umsetzung der Beschlüsse aus Liquid Democracy insbesondere bei den jeweils nächsten internen Wahlen verantworten müssen. Diese Personenwahlen finden natürlich außerhalb von Liquid Democracy statt, da sie nach [http://bundesrecht.juris.de/partg/__15.html PartG §15] und [http://bundesrecht.juris.de/partg/__17.html PartG §17] geheim sein müssen. BTW: Ich persönlich möchte mir (derzeit) weder von der Piratenpartei noch von einer anderen Partei vorschreiben lassen, welche Programme ich auf meinem Computer zu installieren habe ;-)  --[[Benutzer:Jbe|Jbe]] 18:37, 3. Nov. 2009 (CET)

== Falscher Zeitpunkt ==

Ich halte es für fatal, zu diesem Zeipunkt überhaupt Regeln und Satzungsvorschläge für Liquid Democracy festzulegen. Der Einführungsprozess von Liquid Democracy in der Piratenpartei sollte durch empirische Erfahrungen mit unterschiedlichen Implementationen geprägt sein und nicht aus irgendwelchen abstrakten Ideen entstehen. Die so gefassten Regeln sind auf jeden Fall verdammt dazu, fehlerhaft zu sein und basieren auf zu provisorischen Vorstellungen davon, was LD überhaupt sein und leisten kann. 

Das Bestreben, LD von Anfang an bürokratisch zu verankern entspringt vermutlich aus der Idee, dass ein unkontrollierter Testbetrieb keinerlei Verbindlichkeit entfalten könnte. Diese Idee ist falsch, denn eine Wirkung auch von Test-LDs entsteht ja schon durch die Teilnahme vieler Piraten, nicht erst durch die Nennung in irgendeiner Satzung. Gleichzeitig geht man so nicht das Risiko ein, bei einer gescheiterten Einführung mit eigenartigen LD-Fragmenten in der Satzung sitzen zu bleiben. --[[Benutzer:Pudo|Pudo]] 01:10, 4. Nov. 2009 (CET)

== Gleiche Wahl == 

Wie kann man von gleicher Wahl sprechen, wenn durch Stimmdelegationen offensichtlich ein ungleiches Stimmgewicht einzelner Teilnehmer zustande kommt? Man braucht ziemlich viel Phantasie um auf eine Konstruktion zu kommen, in der Delegated Voting einer "gleiche Wahl" entspricht. --[[Benutzer:Pudo|Pudo]] 01:10, 4. Nov. 2009 (CET)

: Ich denke man kann durchaus von gleicher Wahl sprechen: Es hängt ja nicht davon ab, wieviel Gewicht die Abstimmung eines einzelnen hat, sondern vielmehr davon, dass alle mit den gleichen Chancen im System arbeiten. Jeder darf, wenn er will, abstimmen, mit seiner einen Stimme. Delegated Voting bedeutet in diesem Falle nur, dass ich mich zum einen der Meinung des Delegaten anschließe und zum anderen meine Stimme automatisch angelehnt an sein Abstimmungsverhalten abgebe. Ich habe zu jeder Zeit die Möglichkeit die Entscheidung, dies zu widerrufen und somit immer Kontrolle über meine Stimme. (Will sagen: Es ist ja nicht wie 1920 - weil ich angesehener Fabrikbesitzer bin, habe ich mehr Stimmen als meine Mitarbeiter) --[[Benutzer:Hdready|HDready]] 01:32, 4. Nov. 2009 (CET)

== Veröffentlichung von Abstimmungergebnissen == 

Der Abschnitt ist undeutlich. Es wird nicht klar, wann bei terminierten Wahlen wie welche Daten bekannt gegeben werden. Ich würde raten: 

* Nach erfolgter Abstimmung 
* i.d.R. sofort, maximal nach 23 (WTF?!?) Wochen
* als vollständige Angabe, also inklusive Entscheidung, Name/Pseudonym und Delegation

So richtig? Wenn ja: Was soll das bewirken? Ich komme irgendwie auf kein sinnvolles Bot-Verhalten, das hier schädlich wäre...

Das einzige für mich vorstellbare Ziel ist, eine gegenseitige Beeinflussung der Abstimmenden zu verhindern. Warum muss diese Beeinflussung aber verhindert werden? Könnte sie nicht ein konstruktiver Teil der Auseinandersetzung sein? Gegen die massenhafte Mobilisierung von Wählern für eine Position spricht übrigens ebenfalls nichts, man nennt das "Wahlkampf" ;-) 

Die Forderung nach einer geheimen Abstimmung macht allerdings gleichzeitig eine Diskussion des Delegationssystems notwendig: 
* Darf ich nicht wissen, was mein Delegat gewählt hat? 
* Darf ich nicht wissen, ob mein Delegat gewählt hat? 
* Müssen die Delegationsdaten (i.e. der Graph) permanent geheim gehalten werden? Schließlich entsprechen meine Delegationen an einen bekannten Vertreter einer bestimmten Position einer Stimme für diese Position? 
* Kann ich die Stimme meines Delegaten überschreiben?
* Müssen durch Delegation entstandene Stimmen in randomisierten, zeitlichen Intervallen abgegeben werden um eine Zuordnung zum Delegaten zu vermeiden? 

Diese Punkte sind nicht alle essentiell, aber die Machbarkeit der vorliegenden Regeln sollte irgendwie dargestellt werden --[[Benutzer:Pudo|Pudo]] 01:10, 4. Nov. 2009 (CET)

== Administration == 

Den Text finde ich hochideologisch und den Versuch die Moderation einer so komplexen Software in 4 Sätzen abzuhandeln nicht ausreichend. Wie wäre es, am laufenden System herauszufinden welche Mechanismen benötigt werden? Außerdem würde ich auf die unangemessene Verwendung des juristischen Terms "Zensur" verzichten. Alternativ kann man natürlich an dieser Stelle Drittwirkung diskutieren aber irgendwas sagt mir, dass es hier darum nicht wirklich ging ;-) --[[Benutzer:Pudo|Pudo]] 01:10, 4. Nov. 2009 (CET)

: Mir war das mit der Zensur gar nicht aufgefallen. Aber ja, Mechanismen findet man im laufenden Betrieb. Wie ist es beispielsweise mit der gemeinsamen Arbeit an einem Vorschlag zu einem Problem, wenn niemand editieren darf? Schicken wir uns dann nebenbei Mails "editier mal das so um"? Viel interessanter ist hier doch, wie bei einem Wiki History & Benachrichtigung als mögliche Tools zu haben, und jeder darf editieren, solang noch nicht abgestimmt wird. So kann ich jederzeit den Urzustand wiederherstellen, aber habe dennoch die Möglichkeit, konstruktive und vor allem notwenige Änderungen von anderen zuzulassen. Das nimmt auch eine Menge Arbeit von den Admins, da jeder Initiator eines Vorschlags zum Wächter dessen wird und so enger in die LD eingebunden wird - auch in die administrative Seite des Tools. --[[Benutzer:Hdready|HDready]] 01:44, 4. Nov. 2009 (CET)