Diskussionsstand Mai 2011 nach Relaunch: Unterschied zwischen den Versionen

Version vom 25. Mai 2011, 18:15 Uhr

Bitte auffüllen! Danke.

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 Allgemein

• Ein neuer Weg in „Moderation von Entscheidungsprozessen und Ergebnisfindungsprozessen“
• „Gruppe von Menschen die versucht einen Entscheidungsprozess zu machen

• Was für Situationen gibt es, wo man sowas braucht?
• Was will ich entscheiden – gibt es Dinge, die ich ausschließen will

Anwendungsfälle: - Hochschule - Betrieb - In kleinen Gruppen, in riesigen Gruppen

- Ideenfindung - Ideenentwicklung - Diskussion - Abstimmung

3.2 Klein(Arbeits-)gruppen

3.3 Uni Heidelberg/StuRa

3.4 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
• In der Entwicklungsphase darf das System noch nicht starr sein, man muss Stimmen/votes hin oder her ziehen können wie man will
• Modulare Software + Trennung von Kern & Frontend & Tools (Funktionalitätserweiterung/anpassung an Anwendungsfeld) "eine Box mit verschiedenen Tools aus der man sich bedienen kann"--> soll so gemacht werden
• Es soll Diskussion strukturiert darstellen können
• Die Einstiegsmöglichkeit soll leicht sein, man muss die Hauptentscheidungslinien gut erkennen können

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?
• Phasen, die eine unterschiedliche bearbeitung eines problems ermögilchen: wenn wir sehen, dass neue aspekte rein kommen, dann geh ich nochmal ein paar schritte zurück
• Wissensdatenbank (Referenzen, Erläuterungen, auf die z.B. bei Argumentationen verwiesen werden kann) --> ist jedem Vorschlag angefügt - Gesamtwissensdatenbank?
• Vorschläge in Gruppen (im LD) geschlossen diskutieren, bevor sie „raus“ gehen. (in die LD Öffentlichkeit)
• Interesse haben, Interesse abonierern können?
  • Leute die irgendwo mitgearbeitet haben werden informiert, wenn da was bearbeitet wird
  • Ich möchte über alle Einzelheiten, oder über neue Versionen etc informiert werden.

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)
• 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)
• Ideenentwicklungstool (Ideenfindung) vs. Beschlussvorlagen und Textentwicklungstool --> muss alles können
• Ist es für viele Nutzern konzipiert, dann stärker vereinfacht, damit es benutzbar bleibt oder sollen nur wenige mitmachen können und „tiefer“ in Texte einsteigen? --> sollte beides können
• Probleme unterschiedlicher Komplexität, wie flexibel kann ein System sein und auf einfache und schwierige Dinge eingehen

Varianten

• Möglichkeit von Varianten
• Manche Entscheidungen zerlegen, Zwischenschritte
• Minimalkonsens sichern, weiter diskutieren
• Verschiedene Entscheidungen zusammenführen (Versionen verbinden?)
• Teilaspekte gegeneinander abwägen
• Möglichkeit von Methafragen: Verschiedene Schemata?, Vorschlag von Verfahren/Vorgehen soll möglich sein
• wie fasse ich 20 Vorschläge die sich nur minimal unterscheiden zusammen (Scheinalternativen)?

4.4 Fragen

„Was kann man tun, das man nicht erschlagen wird (von viel Text)“ „Was kann man tun, dass spätere Alternativen gegenüber etablierten nicht benachteiligt werden“ „Wie kann Meinungsbildung stattfinden, bevor (undurchdachte)Alternativen eingestellt werden?“ „Man sollte Vorschläge Stück für Stück diskutieren können.“ - Mehere Phasen? Zuerst grob, dann feiner? „Wie kann ich verhindern, dass es eine Flut von Vorschlägen gibt?“ 1. Entwicklungsphase nicht so starr, der und der Punkt ist strittig – daran kann man seperat weiter machen – einen eigenen Vorschlag dazu machen? „Datails von Grundsatzentscheidungen – wie trennt man das?“

5 Grundsätzliche Limitierungen

5.1 Entscheidungskonsequenz

Wie juristisch hart ist eine LD-Entscheidung?

• Inwiefern sind Vorschläge im Gesamtkontext (un)widersprüchlich?

=> es gibt keine objektive Gesetzgebung, also sind Widersprüche nur logisch Wie können sujektiv bedingte Widersprüche in LD berücksichtigt werden?

• Nehmen Institutionen die Ergebnisse an?

5.2 Anonymität vs. Nachvollziehbarkeit

5.3 Moderationsnotwendigkeit, begrenztes semantisches Verständnis der Technik

• System übernimmt Moderation? (gleichwertige Behandlung von Ideen)
• Allgemein: Spannungsfeld zwischen Moderation und keiner Moderation (wenn man ein hoch skalierendes Modell annimmt, darf die Moderation keine große Aufgabe sein...)
• wie ist die Berechtigung menschlicher Intervention (Moderation), wie werden ModeratorInnen ausgewählt? Was ist ihr Legitimation?
• Taktische Spielchen, „ich mache absichtlich einen schlechten Vorschlag“
• Trolle, Spamer, Beleidigungen, Rassismus, Sexismus...
• Regulationsmechanismus: User bewerten ob es an Fragestellung vorbei geht. „unsachlich“ (Spam) oder „Thema verfehlt“ => allgemein: „Relevanz für die Entscheidung“
• wie wird die Moderation legitimiert, muss aufgefordert werden, um in Aktion zu treten

5.4 Ansprüche an Verständlichkeit (Transparenz)

5.4.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

7 Visualisierung

7.1 Skizzen

8 Aktuell offen Fragen und nächste Arbeitsaufträge