Diskussionsstand Mai 2011 nach Relaunch: Unterschied zwischen den Versionen
Kai (Diskussion | Beiträge) |
Nico (Diskussion | Beiträge) |
||
| Zeile 1: | Zeile 1: | ||
Bitte auffüllen! Danke. | Bitte auffüllen! Danke. | ||
| + | |||
| + | = Professionalisierung/Projektcharakter = | ||
| + | |||
| + | == Finanzierung über Stiftung == | ||
| + | |||
| + | == Leitung == | ||
| + | |||
| + | == Zeitrahmen == | ||
| + | |||
| + | == Start im Sommer, vorl. Zeitplan bis Ende 2011 == | ||
| + | |||
| + | == 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. | ||
= Vorhandene Systeme / praktische Beispiele = | = Vorhandene Systeme / praktische Beispiele = | ||
| Zeile 6: | Zeile 20: | ||
=== PHP, PostGreSQL, Lua === | === 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. | ||
== Entscheidungsmethoden == | == Entscheidungsmethoden == | ||
=== Condorcet (Schulze) === | === 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. | ||
== Technische Ansätze == | == Technische Ansätze == | ||
| Zeile 23: | Zeile 48: | ||
== Große Organisationen (Unternehmen, Parteien) == | == Große Organisationen (Unternehmen, Parteien) == | ||
| − | = | + | = Fähigkeiten von LD = |
| − | + | * es mussen laufend „Abstimmungen“ möglich sein | |
| − | + | * „Evolution der Idee“ (22.3.) Minimalkonsens? Varianten zusammen führen... → Scheinalternativen | |
| − | + | * Transparenz der Entscheidung → graphische Aufarbeitung | |
| − | + | * Einbindung von „realen“ Diskussionen | |
| − | + | * Diskussion & Abstimmungen in Gruppen / AG / Treffen (offline-Ergebnisse müssen zurück gespiegelt werden) | |
| − | + | * „Startseite“ mit Anderungsmeldungen + Beobachten (→ untersch. Formen des Interesses) | |
| − | + | * wenig Moderation / selbstregulierend | |
| − | + | * wie wird die Moderation legitimiert, muss aufgefordert werden, um in Aktion zu treten | |
| − | + | * Listen (von Themen, Vorschlägen etc.) ordnen über versch. Attribute (Beliebtheit, Neuigkeit) | |
| − | + | * 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) | |
| − | + | * Problemerörterungsphase (infos sammeln vor Entscheidungen) erst denken, dann handeln | |
| + | * Modulare Software + Trennung von Kern & Frontend & Tools (Funktionalitätserweiterung/anpassung an Anwendungsfeld) | ||
| + | * 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) | ||
| + | * Wissensdatenbank (Referenzen, Erläuterungen, auf die z.B. bei Argumentationen verwiesen werden kann) | ||
= Grundsätzliche Limitierungen = | = Grundsätzliche Limitierungen = | ||
| Zeile 48: | Zeile 80: | ||
=== Limitierung der Ausdrucksmöglichkeiten (flexibel nach Anwendung und Phasen) === | === Limitierung der Ausdrucksmöglichkeiten (flexibel nach Anwendung und Phasen) === | ||
| + | |||
| + | = Visualisierung = | ||
| + | |||
| + | == Skizzen == | ||
= Aktuell offen Fragen und nächste Arbeitsaufträge = | = Aktuell offen Fragen und nächste Arbeitsaufträge = | ||
Version vom 25. Mai 2011, 17:40 Uhr
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.3.1 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
- es mussen laufend „Abstimmungen“ möglich sein
- „Evolution der Idee“ (22.3.) Minimalkonsens? Varianten zusammen führen... → Scheinalternativen
- Transparenz der Entscheidung → graphische Aufarbeitung
- Einbindung von „realen“ Diskussionen
- Diskussion & Abstimmungen in Gruppen / AG / Treffen (offline-Ergebnisse müssen zurück gespiegelt werden)
- „Startseite“ mit Anderungsmeldungen + Beobachten (→ untersch. Formen des Interesses)
- wenig Moderation / selbstregulierend
- wie wird die Moderation legitimiert, muss aufgefordert werden, um in Aktion zu treten
- Listen (von Themen, Vorschlägen etc.) ordnen über versch. Attribute (Beliebtheit, Neuigkeit)
- 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)
- Problemerörterungsphase (infos sammeln vor Entscheidungen) erst denken, dann handeln
- Modulare Software + Trennung von Kern & Frontend & Tools (Funktionalitätserweiterung/anpassung an Anwendungsfeld)
- 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)
- Wissensdatenbank (Referenzen, Erläuterungen, auf die z.B. bei Argumentationen verwiesen werden kann)