Diskussionsstand Mai 2011 nach Relaunch
Bitte auffüllen! Danke.
Inhaltsverzeichnis
1 Professionalisierung/Projektcharakter
1.1 Finanzierung über Stiftung
1.2 Leitung
1.3 Zeitrahmen
1.4 Start im Sommer, vorl. Zeitplan bis Ende 2011
1.5 Open Source
Da unser Projekt zur Transparenz von Entscheidungsprozessen beitragen soll, muss diese Transparenz logischerweise auch in unserer Software gewährleistet sein. Deshalb soll unser Projekt ein freies Software-Projekt werden und ausschließlich auf freien Komponenten aufbauen. Außerdem soll unsere Software auf möglichst vielen Plattformen lauffähig sein.
2 Vorhandene Systeme / praktische Beispiele
2.1 Verwendete Programmiersprachen (Vor-/Nachteile)
2.1.1 PHP, PostGreSQL, Lua
Warum PostgreSQL? PostgreSQL ist ein freies, objektrelationales Datenbankmanagementsystem, das wir dazu verwenden, um die Daten des Systems zu speichern. Es ist lauffähig auf vielen Unix-Plattformen (darunter auch Linux), auf Mac OS X und Windows und bietet Schnittstellen zu vielen Programmiersprachen, darunter auch PHP. Im Gegensatz zu MySQL unterstützt PostgreSQL auch Constraints vollständig, um die referenzielle Integrität der Daten sicherzustellen. Unsere Wahl fiel auf PostgreSQL, da wir für unser Projekt ein professionelles, freies Datenbankmanagementsystem verwenden möchten. Nicht zuletzt basiert der Kern von Liquid Feedback, den wir für unser Projekt verwenden möchten auf PostgreSQL.
Warum PHP? PHP ist eine freie objektorientierte Skriptsprache, die hauptsächlich zur Erstellung dynamischer Webseiten oder Webanwendungen verwendet wird. Es ist lauffähig auf vielen Unix-Plattformen (darunter auch Linux), auf Mac OS X und Windows und bietet eine breite Datenbankunterstützung, darunter auch PostgreSQL. Die aktuelle Version von PHP verwendet als Zeichensatz ausschließlich Unicode, wodurch die Software problemlos auf Sprachen mit nichtlateinischer Schrift angepasst werden kann. (hm, PHP 6 ist anscheinend noch nicht fertig). Außerdem stehen aufgrund der weiten Verbreitung von PHP zahlreiche Funktionsbibliotheken zur Verfügung.
2.2 Entscheidungsmethoden
2.2.1 Condorcet (Schulze)
Condorcet-Methode: -> Wahlmethoden, bei dem der Wähler Kandidaten nach dem Rang ordnet -> Es wird ein Sieger ermittelt, indem immer 1 gegen 1 gespielt wird, der der alles gewinnt ist Sieger -> Methoden unterscheiden sich, wenn es keinen Sieger gibt
Schultze Methode: Die momentan am meisten genutze Condorcet Methode. Kandidaten können auf den gleichen Rang gesetzt werden. Auswertung über einen Graphen.
2.3 Technische Ansätze
2.4 Kern-Plugin-Struktur, um die Flexibilität für die Anwendungsszenarien zu erhalten
3 Anwendungsszenarien
3.1 Klein(Arbeits-)gruppen
3.2 Uni Heidelberg/StuRa
3.3 Große Organisationen (Unternehmen, Parteien)
4 Fähigkeiten von LD
4.1 geklärtes
- es müssen laufend „Abstimmungen“ möglich sein --> diese Interaktivität ist durch das bewerten von Argumenten und Vorschlägen gegeben
- Modulare Software + Trennung von Kern & Frontend & Tools (Funktionalitätserweiterung/anpassung an Anwendungsfeld) --> soll so gemacht werden
4.2 teilweise geklärtes
- Transparenz der Entscheidung → graphische Aufarbeitung --> durch Vorschlagsbaum im Prozess, aber wie ist es hinterher mit Ergebnissen und wie lange sollen Ergebnisse sichtbar bleiben?
- „Evolution der Idee“ (22.3.) Minimalkonsens? Varianten zusammen führen... → Scheinalternativen --> muss noch verbessert werden
- „Startseite“ mit Anderungsmeldungen + Beobachten (→ untersch. Formen des Interesses)
- wenig Moderation / selbstregulierend
- Listen (von Themen, Vorschlägen etc.) ordnen über versch. Attribute (Beliebtheit, Neuigkeit) --> ist durch die pull down Menüs gegeben, welche Attribute?
- Problemerörterungsphase (infos sammeln vor Entscheidungen) erst denken, dann handeln --> 3 Phaseneinteilung, was sind die Kriterien zum Übergang?
- Wissensdatenbank (Referenzen, Erläuterungen, auf die z.B. bei Argumentationen verwiesen werden kann) --> ist jedem Vorschlag angefügt - Gesamtwissensdatenbank?
4.3 ungeklärtes
- soll man bei einem Vorschlag eine zusätzliche Kategorie haben wie "Rahmenbedingungen" wo z.B. gesetzliche Bestimmungen zum Thema oder der finanzielle Rahmen o.ä. aufgelistet sind?
- Möglichkeit von Umfragen - oder wird das schon über die Vorschlagsmöglichkeit abgedeckt?
- Einbindung von „realen“ Diskussionen
- Diskussion & Abstimmungen in Gruppen / AG / Treffen (offline-Ergebnisse müssen zurück gespiegelt werden)
- wie wird die Moderation legitimiert, muss aufgefordert werden, um in Aktion zu treten
- Transparenz / Übersichtlichkeit des Systems aus Sicht des Benutzers
- Anmeldung versch. Interessenebenen
- (autom.) Strukturierung bei Argumentationen
- Bei Vorschlägen: alte Versionen / Neue Versionen → Verhaltnis / Neutralitat wahren (vgl. LF Problem des frühen Interesses)
- Textentwicklung vs. Ideenentwicklung vs. Verteilte Entscheidungsprozesse (untersch. Juristischer Härte)
- gruppeninterne (von außen nicht sichtbare) Diskussionsmoglichkeit (limitierte eigene LD-Instanz fur Gruppe)
- Visualisierung von Vorschlagsbaumen
- Pseudonymisierung (vgl. Transparenz) vs. Verifikation des Nutzers
- Strukturierung von Diskussionen (gerade bei vielen Nutzern müssten sich die möglichen Strukturen automatisch verengen)
5 Grundsätzliche Limitierungen
5.1 Anonymität vs. Nachvollziehbarkeit
5.2 Moderationsnotwendigkeit, begrenztes semantisches Verständnis der Technik
5.3 Ansprüche an Verständlichkeit (Transparenz)
5.3.1 Limitierung der Ausdrucksmöglichkeiten (flexibel nach Anwendung und Phasen)
6 Grundsätzliche Gedanken
Schwarmintelligenz nutzen ... interessanter Link in dem auch zu einer Studie weiterverlinkt wird: http://www.spiegel.de/wissenschaft/mensch/0,1518,762837,00.html Diese Studie gibt Antwort auf die Frage, ob während einer Abstimmung Zwischenergebnisse geliefert werden sollten (--> nein!).
Es wäre auch gut Funktionen ins System einzubauen wie "jemandem anderen etwas zeigen" oder Kommentare und Vorschläge zu "posten" ... um damit den gleichen Effekt wie bei Twitter zu erzielen: wichtige Sachen verbreiten sich schneller