Diskussionsstand LD: Unterschied zwischen den Versionen

Aus Wiki Studentische Mitbestimmung
Wechseln zu: Navigation, Suche
 
(2 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 10: Zeile 10:
 
*Wofür gelten Delegationen? Möglich für: Wahl, Interesse, Population, Unterstützung. Dabei ist auch nochmal über stimmverteilung bei Gruppendelegationen denken. --[[Benutzer:Chronial|Chronial]] 14:19, 2. Apr. 2010 (UTC)  
 
*Wofür gelten Delegationen? Möglich für: Wahl, Interesse, Population, Unterstützung. Dabei ist auch nochmal über stimmverteilung bei Gruppendelegationen denken. --[[Benutzer:Chronial|Chronial]] 14:19, 2. Apr. 2010 (UTC)  
 
*Das Projekt braucht einen Namen! --[[Benutzer:Chronial|Chronial]] 22:18, 11. Mai 2010 (UTC)
 
*Das Projekt braucht einen Namen! --[[Benutzer:Chronial|Chronial]] 22:18, 11. Mai 2010 (UTC)
 +
** LiquidCampus (Nicolas)
  
 
= Allgemeines  =
 
= Allgemeines  =
Zeile 130: Zeile 131:
  
 
= Gruppen  =
 
= Gruppen  =
 +
 +
Gruppenmodell 1 kann natürlich mit Verwaltungsmodell a und b und Gruppenmodell 2 kann auch mit Verwaltunsmodell a und b verwendet werden. Es ist vielleicht sinnvoll, das Ganze etwas modularer zu betrachten. [[Benutzer:Nicolas|Nicolas]] 09:49, 12. Mai 2010 (UTC)
  
 
{| width="100%" cellspacing="0" cellpadding="0" border="0"
 
{| width="100%" cellspacing="0" cellpadding="0" border="0"
Zeile 144: Zeile 147:
 
**Delegationen an Gruppe werden über Liste (evt. andere Methode) an Gruppenmitglieder weitergegeben  
 
**Delegationen an Gruppe werden über Liste (evt. andere Methode) an Gruppenmitglieder weitergegeben  
 
***Selbstverständlich können Gruppenmitglieder an sich gegenseitig delegieren  
 
***Selbstverständlich können Gruppenmitglieder an sich gegenseitig delegieren  
−
**Moderator verteilt Stimmen an Mitglieder  
+
**Moderator verteilt Stimmen an Mitglieder
−
*Wenn Gruppe in sich selbst delegiert, wird dieser Kreis erkannt und die verursacher bei der Aufteilung der Stimmen in der Gruppe nicht berücksichtigt.
+
**''Feststellung'': Wenn jemand an eine Gruppe delegiert, kann derjenige auch gleich an ein Mitglied delegieren, das die Mehrheitsmeinung vertritt. Wenn man die Möglichkeit einbauen würde, dass man an eine Entscheidung zum Thema an mehrere Person delegieren kann, wäre das sogar äquivalent mit Gruppen nach Modell 1.
−
 
 
−
=== Anlegen/Moderation  ===
 
−
 
 
−
*Gruppen für jeden gründbar, bekommen jedoch erst offiziellen Gruppenstatus (standardmäßig in Delegationenliste aufgeführt, etc.) ab einer Gewissen Anzahl an Mitgliedern/Anhängern (5?)
 
−
*Wer ist Moderator?
 
−
**Zuerst Gruppengründer
 
−
**Moderatoren können abtreten, weitere benennen
 
−
**Entfernung eines Moderatorstatus braucht Zustimmung aller Moderator
 
−
**Beendingung einer Mitgliedschaft (der Gruppe) baucht mehrheit der Moderatoren
 
−
**Moderatoren können nicht aus der Gruppe entfernt werden
 
  
 
=== Vorteile  ===
 
=== Vorteile  ===
Zeile 171: Zeile 164:
 
**''Kommentar: ''Dieses Szenario wirkt auf mich sehr konstruiert. Zum einen ist dies ein "Problem", das z.B. auch jede Fraktion im Budestag hat, zum anderen sollte ein Gruppe keine Meinungen Propagieren, zu denen nur 5 ihrer 9 Mitglieder stehen. --[[Benutzer:Chronial|Chronial]] 22:16, 11. Mai 2010 (UTC)  
 
**''Kommentar: ''Dieses Szenario wirkt auf mich sehr konstruiert. Zum einen ist dies ein "Problem", das z.B. auch jede Fraktion im Budestag hat, zum anderen sollte ein Gruppe keine Meinungen Propagieren, zu denen nur 5 ihrer 9 Mitglieder stehen. --[[Benutzer:Chronial|Chronial]] 22:16, 11. Mai 2010 (UTC)  
 
*Konsensorientierte Gruppe wird zu einem Mehrheitsmodell gezwungen, muss also abstimmen.  
 
*Konsensorientierte Gruppe wird zu einem Mehrheitsmodell gezwungen, muss also abstimmen.  
−
**''Kontra:'' Nach dem "Moderator verteilt Stimmen"-Ansatz ist dies nicht der Fall.<br>  
+
**''Kontra:'' Nach dem "Moderator verteilt Stimmen"-Ansatz ist dies nicht der Fall.<br>
−
**''Kontra:'' Würden nicht alles Mitglieder gleich abstimmen, wenn dieser&nbsp;"Konses" wirklich ein Konsens ist?<br>  
+
**''Kontra:'' Würden nicht alle Mitglieder gleich abstimmen, wenn dieser&nbsp;"Konses" wirklich ein Konsens ist?<br> (Doch, aber manche Leute regen sich schon auf, wenn sie nur das Wort "Abstimmung" hören)
 
*schwieriger zu implementieren, warum viel Aufwand in Implementierung stecken, was wir im RL eher aufweichen möchten?<br>
 
*schwieriger zu implementieren, warum viel Aufwand in Implementierung stecken, was wir im RL eher aufweichen möchten?<br>
 +
* Gruppenmoderator muss Mitglieder in die Gruppe aufnehmen und löschen (zusätzlich zu gruppeninternen Mailinglisten, Wikis ...) -> geringere Akzeptanz
  
 
| width="50%" valign="top" |
 
| width="50%" valign="top" |
Zeile 180: Zeile 174:
  
 
*LD-Gruppe ist Spiegelbild einer Gruppe, die sich real trifft.  
 
*LD-Gruppe ist Spiegelbild einer Gruppe, die sich real trifft.  
 +
*vielleicht auch als eine Art "Wahlprogramm" bezeichenbar
 
*Gruppe hat keine Mitglieder  
 
*Gruppe hat keine Mitglieder  
−
*Gruppe kann Anhänger haben  
+
*<strike>Gruppe kann Anhänger haben</strike>
 
*Gruppe ist wie eine Person ohne eigene Stimme, nur mit delegierten Stimmen  
 
*Gruppe ist wie eine Person ohne eigene Stimme, nur mit delegierten Stimmen  
 
*nur Moderator(enteam) kann abstimmen, hält sich an Beschluss der realen Gruppe (falls nicht -&gt; siehe Ruprecht)  
 
*nur Moderator(enteam) kann abstimmen, hält sich an Beschluss der realen Gruppe (falls nicht -&gt; siehe Ruprecht)  
Zeile 187: Zeile 182:
  
 
=== Anlegen/Moderation  ===
 
=== Anlegen/Moderation  ===
−
 
−
*Gruppen nur von <strike>Admins</strike> LD-Moderatoren einrichtbar (''Administrator ist eine technische Rolle'')
 
−
*Gruppe muss regelmässige Treffen nachweisen
 
−
*verhindert die Gefahr, dass reale Gruppe mit demselben Namen, nichts von der LD-Gruppe oder LD-System überhaupt weiß
 
  
 
=== Vorteile  ===
 
=== Vorteile  ===
  
−
*Mitgliederverwaltung entfällt komplett (sowohl für LD-Admins als auch für die Gruppenmoderatoren selbst).  
+
*Mitgliederverwaltung entfällt komplett (für die Gruppenmoderatoren).  
 
*Benutzer müssen nicht zeigen, in welchen Gruppen sie sind, um im RL in dieser abzustimmen.  
 
*Benutzer müssen nicht zeigen, in welchen Gruppen sie sind, um im RL in dieser abzustimmen.  
 
*Wahrung der Anonymität von Leuten, die in mehr als einer Gruppe sind  
 
*Wahrung der Anonymität von Leuten, die in mehr als einer Gruppe sind  
Zeile 202: Zeile 193:
  
 
*Gruppen werden zum Fraktionszwang gezwungen. Dies war der zentrale Grund für die Schaffung von&nbsp;Modell 1.<br>
 
*Gruppen werden zum Fraktionszwang gezwungen. Dies war der zentrale Grund für die Schaffung von&nbsp;Modell 1.<br>
−
*Erhöhter Aufwand für LD-Moderatoren.&nbsp; Modell 1 ist ein selbstläufer, braucht nur im Extremfall Eingriff (Jemand erstellt eine Gruppe mit unangemessenem Namen). Hier müssen die LD-Moderatoren:  
+
**Nein
 +
**Gruppenmitglieder können im LD-System getrennt von der Gruppe entscheiden
 +
**Wahlprogramm wäre vielleicht der treffendere Begriff
 +
*<strike>"Anhänger"-Feature hat für die Plattform keinerlei nutzen, ist komplett unnötiger Implementierungsaufwand.</strike>
 +
* Mehraufwand für LD-Moderatoren
 +
**Wenn die Mitgliederverwaltung für die Gruppe entfallen soll, müssen die LD-Mods auch Amok laufende Gruppenleiter checken. (Das wird die reale Gruppe auch melden können. Problem könnte eine inaktiv gewordene Gruppe sein, die nur noch aus dem Moderator besteht.)
 +
*Weiteres Problem dabei:&nbsp;Moderatoren haben (vorerst) keine Legitimation!
 +
**Moderatoren arbeiten im Namen der Gruppe und beziehen daher ihre Legitimation
 +
 
 +
|}
 +
 
 +
== Modell 3 ==
 +
* gar keine Gruppen
 +
 
 +
=== Vorteile ===
 +
* Gruppendenken wird aufgeweicht
 +
 
 +
=== Nachteile ===
 +
* Orientierungslosigkeit von Neulingen (An wen soll ich jetzt delegieren?)
 +
 
 +
=== Links ===
 +
https://lqpp.de/be/initiative/show/125.html<br/>
 +
https://lqpp.de/be/initiative/show/211.html
 +
 
 +
== Anlegen/Moderation ==
 +
 
 +
{| width="100%" cellspacing="0" cellpadding="0" border="0"
 +
|-
 +
| width="50%" valign="top" |
 +
=== Modell a ===
 +
 
 +
*Gruppen für jeden gründbar, bekommen jedoch erst offiziellen Gruppenstatus (standardmäßig in Delegationenliste aufgeführt, etc.) ab einer Gewissen Anzahl an Mitgliedern/Anhängern (5?)
 +
*Wer ist Moderator?
 +
**Zuerst Gruppengründer
 +
**Moderatoren können abtreten, weitere benennen
 +
**Entfernung eines Moderatorstatus braucht Zustimmung aller Moderator
 +
**Beendingung einer Mitgliedschaft (der Gruppe) baucht mehrheit der Moderatoren (bei Modell 1)
 +
**Moderatoren können nicht aus der Gruppe entfernt werden
 +
 
 +
==== Vorteile ====
 +
 
 +
==== Nachteile ====
 +
 
 +
| width="50%" valign="top" |
 +
 
 +
=== Modell b ===
 +
 
 +
*Gruppen nur von <strike>Admins</strike> LD-Moderatoren (''Das ist verwirrend: LD-Moderator, Gruppen-Moderator'') einrichtbar (''Administrator ist eine technische Rolle'')
 +
*Gruppe muss regelmäßige Treffen nachweisen
 +
*verhindert die Gefahr, dass reale Gruppe mit demselben Namen, nichts von der LD-Gruppe oder LD-System überhaupt weiß
 +
 
 +
==== Vorteile ====
 +
 
 +
*es existieren nicht 100 verschiedene Unsinn-Gruppen
 +
 
 +
==== Nachteile ====
 +
 
 +
*Erhöhter Aufwand für LD-Moderatoren.&nbsp; Modell a ist ein Selbstläufer, braucht nur im Extremfall Eingriff (Jemand erstellt eine Gruppe mit unangemessenem Namen). Hier müssen die LD-Moderatoren:  
 
**Die Gruppen auf Antrag anlegen<br>  
 
**Die Gruppen auf Antrag anlegen<br>  
−
**Überprüfen, ob sich die Gruppe wirklich real trifft  
+
**Überprüfen, ob sich die Gruppe wirklich real trifft (eigentlich nur wenn Verdacht besteht, dass das nicht der Fall sein könnte; genauso wie bei der FSK)
−
**Wenn die Mitgliederverwaltung für die Gruppe entfallen soll, müssen die LD-Mods auch amok laufende Gruppenleiter checken.
 
−
*Weiteres Problem dabei:&nbsp;Moderatoren haben (vorerst) keine Legitimation!
 
−
*"Anhänger"-Feature hat für die Plattform keinerlei nutzen, ist komplett unnötiger Implementierungsaufwand.
 
  
 
|}
 
|}
Zeile 289: Zeile 334:
 
*PHP, mit einem Framework, eventuell CakePHP<br>  
 
*PHP, mit einem Framework, eventuell CakePHP<br>  
 
*PostgreSQL. Unter anderem weil der LF-Kern in PostgreSQL geschrieben ist, und wir den nehmen wollen.
 
*PostgreSQL. Unter anderem weil der LF-Kern in PostgreSQL geschrieben ist, und wir den nehmen wollen.
 +
 +
= Lizenz =
 +
 +
*Open-Source-Lizenz?
 +
 +
= Organisatorisches =
 +
 +
* FSK-/StuRa-Antrag schreiben
 +
* Werbung machen und Überzeugungsarbeit leisten, damit der Antrag auch angenommen wird

Aktuelle Version vom 23. Mai 2010, 22:58 Uhr

Hier wird der Diskussionsstand zu den verschiedenen Aspekten der einzuführenden/entwickelnden LD-Lösung reflektiert. Um die Übersichtlichkeit zu erhöhen, bekommt jedes Unterthema einen getrennten Abschnitt. Die Quelle für die erste Version dieses Wikiartikels sind hier (.doc) zu finden.

(Ergänzung für MS-averse: (.pdf) )


1 Neuer Input

  • Wir sollten ein Mindestquorum für Initiativen einführen, dass bestimmt, ob eine Initiative hinterher überhaupt zur Abstimmung steht --Chronial 13:32, 26. Mär. 2010 (UTC)
  • Wofür gelten Delegationen? Möglich für: Wahl, Interesse, Population, Unterstützung. Dabei ist auch nochmal über stimmverteilung bei Gruppendelegationen denken. --Chronial 14:19, 2. Apr. 2010 (UTC)
  • Das Projekt braucht einen Namen! --Chronial 22:18, 11. Mai 2010 (UTC)
    • LiquidCampus (Nicolas)

2 Allgemeines

Es wird angestrebt ein eigenes System für das LD-Experiment zu entwickeln bzw. auf dem vorhandenen Kern von Liquid Feedback aufzubauen und diesen nach den hier folgenden Vorgaben massiv auf unsere Bedürfnisse zuzuschneiden und mit wichtigen Ergänzungen zu versehen.

In nächster Zeit soll aus diesem Diskussionsstand ein Pflichtenheft destilliert werden, mit dessen Hilfe weitere Unterstützung, vor allem (aber nicht nur) auf der technischen Seite zu gewinnen ist. ProgrammiererInnen sind also dringendst gesucht.

3 Eingangsseite

  • Bei Erstanmeldung Frage nach Pseudonym.
  • Einfache Auswahl für eher passive (Delegation)
  • und eher aktive Nutzer (Entscheidungen / Stimmabgabe)

3.1 Delegationen

Standarddelegation: Dropdown mit Gruppen und dem user bekannten Personen + „an andere Person delegieren….“

Delegationsbaum: Baum, der eine Übersicht über vergebene Delegationen anzeigt – mit Links auf die jeweiligen Seiten, auf denen diese Delegationen festgelegt werden können.

Delegierte Entscheidungen: Liste mit von Deleganten getroffene Entscheidungen.
Mit: Topic (Link), Entscheidung (Link), Zeitpunkt, Person/Gruppe (bei Gruppe noch wer aus der Gruppe, die entscheidung getroffen hat – nicht zu hervorgehoben, um User nicht zu verwirren – hier sollte auch eine Möglichkeit her, herauszufinden wie/ob diese Entscheidung weiterdelegiert wurde), Quelle der Delegation (Global, Themenbereich, Thema, Enscheidung)
Evenetuell keine Liste, sondern Gruppiert nach Themenbereichen / „Wie hat … für mich entschieden?“. Ansicht umschaltbar.

3.2 Entscheidungen / Stimmabgabe

  • Top 5 anstehende Entscheidungen (Kriterien: Aktualität / Anzahl Teilnehmender User)
  • Liste mit Themenbereichen -> Thema
  • Link zu „Alle in der Abstimmungsphase befindlichen Entscheidungen“

4 Themen

Es sind Themenbereiche zu definieren, die dann auch insgesamt delegierbar sein sollen.
Eine Themenliste muss einsehbar sein (Design vgl. LF)
Was gehört alles zu einem Thema:
Titel + Beschreibung des Themas. Von wem erstellt? - Anfänglich vom Eröffner des Themas, Bearbeitungsrecht kann jederzeit grundlos auf Moderator übertragen werden, damit dieser diese Beschreibung pflegt. Liste der Initiativen. Weitere Infos und Anregungen z.B. bei LiquidFeedback.

Konkretisierungen:

  • Haben keine eigene Existenz – entstehen mit Initiative, werden gelöscht wenn letzte Initiative gelöscht wird.
  • Titel und Beschreibung vom Ersteller der ersten Initiative, Bearbeitungsrechte auf Moderator übertragbar.
    • Beschreibung hat Änderungshistorie
    • Wird erste Initiative gelöscht, so erhalten/sehen Moderatoren eine Nachricht, dass das Thema einen neuen Titelpfleger benötigt
  • Automatische Übertragung des Rechts auf Ersteller der Initiative mit der meisten Unterstützung?
  • Interesse am Thema
    • Kann per Hand angemeldet werden
    • Wird automatisch angemeldet bei Aktion im Thema (genauer: Aktion bei beliebiger Initiative im Thema)
  • Auto-Ablehnung?
  • Themen durchlaufen Phasen, siehe Abschnitt Themen-Phasen

5 Themen-Phasen

  • Manche Phasen haben eine festgelegte Zeitdauer, welches durch das Entscheidungsgeschwindigkeits-Modell festgelegt wird.
    • Diese Modell wird vom Ersteller des Themas bestimmt.
      • Melche Modelle gewählt werden dürfen wird durch Regeln definiert (siehe auch Folie Schnellentscheide)
  • Beim Erstellen des Themas beginnt Automatisch die erste Phase:
  1. "Neu": Probephase. Alles ist erlaubt. Diese Phase dient dazu, zu überprüfen wie interessant das Thema ist. Um als relevant zu gelten, muss es eine Initiative geben, die eine ausreichende Menge an potenziellen Unterstützern hat.
  2. Zwei Möglichkeiten:
    1. "Geschlossen": Wenn die Akzeptanzzeit endet und die Bedigungen nicht erfüllt wurden wir das Thema geschlossen. Massives Neueröffnen von soeben geschlossenen Themen ist ein Regelverstoß und wird geahned (von Hand).
    2. "Diskussion": Wenn es innerhalb der Akzeptanzzeit zu einem Zeitpunkt eine Initiative gibt, für die das Verhältnis von potenziellen Unterstützern zu am Thema Interessierten und Themenbereichs-Mitgliedern eine festgelegte Schwelle überschreitet, kommt das Thema in die Diskussionsphase.
      • Weiterhin alles erlaubt
      • Diskussion kann beliebig lange dauern. Die nächste Phase wird unter bestimmten Bedingungen begonnnen (siehe Vote Now/ Vote later) – LF Konzept ist hier etwas verwirrend. Fällt uns was Besseres ein?
  3. "Eingefroren/Validierung": Das Thema wird zur Wahl vorbereitet. Nun darf keine Änderung an Initiativen mehr vorgenommen werden, aber es dürfen neue Initiativen eingebracht werden. Dies ist für den Fall, dass jemand kurz vor Phasenwechsel seine Initiative in einer unakzeptablen Weise verändert hat.
    1. Dauert eine festgelegte Zeit, danach automatischer Wechsel in nächste Phase
  4. "Wahl": Obvious. Dauert festgelegte Zeit.

6 Initiativen

  • Können von jedem angelegt werden
  • Können bis zur Abstimmungsphase angelegt werden
  • Diskussion über Initiativen nicht auf der Platform
    • Verringert Entwicklungszeit massiv (!)
    • Wir stellen separates Forum / Wiki (mit gelinkten User-Datenbanken) zur Verfügung.
      • Pro Forum da benutzerfreundlicher (jeder kennt Foren, wenige waren schon auf Wiki aktiv)
      • Keine andere Diskussionplatform, z.b. wegen user-accounts
  • Beschreibungsseite der Initiative gehört dem Ersteller
    • Ersteller kann weitere Autoren für die Beschreibungsseite angeben.
      • Dafür läd er sie ein – wenn sie annehmen, werden sie Autoren und werden auch als solche angezeigt.
    • Beschreibungsseite hat Änderungshistorie! (brauchen noch mehr Überlegung was Änderungen angeht)
  • Haben Unterstützer und Potentielle Unterstützer (siehe Glossar)
  • Haben Anregungen (siehe Abschnitt Anregungen)

7 Anregungen

  • Können bis Verifikationsphase einbracht/abgestimmt etc. werden. Danach freeze.
  • Titel + Beschreibung – mit Titel für easy User, und Beschreibung für Details
    • Optional Auswahl: „Diskussion aktivieren“ -> erstellt Thread im Forum und linkt auf ihn
  • Können nicht bearbeitet werden
    • Verwirrungsfaktor, Verwaltungsaufwand….
  • Jeder User bestimmt seine Einstellung zur Anregung:
    • Muss: User wird potentieller Unterstützer
    • Soll: User ist (bleibt) Unterstützer
    • Neutral: Keine Konsequenz
    • Soll nicht: Wie soll keine faktische Auswirkung
    • Darf nicht: User wird seine Unterstützung entziehen, wenn umgesetzt
  • Umsetzung wird von Usern bewertet
    • Text von LF gefällt
    • Bei gewissen Rating gilt es als umgesetzt => „Muss“ Voter werden zu Unterstützern, „Darf nicht“ Voter werden zu potentiellen Unterstützern

8 Wahl

  • Jeder Vorschlag bleibt eine gewisse Zeit (je nach Modell) im Wahlmodus
    • Nach dessen Ende -> Entscheidung
  • Entscheidungsmodell genau wie LF:
    • Man kann Initativen, die man unterstützenswert findet, ranken. Auserdem kann man Initativen ablehnen (und auch dort rankgen) oder sich zu einer Initiative enthalten.
    • Erster Check: Initiativen mit mehr Ablehnung als Zustimmung gelten als abgelehnt, fliegen raus.
    • Entscheidung: Nach Schulze-Methode
    • Entweder Mindestwahlbeteilgung, oder Auto-Ablehnen Feature

9 Entscheidungsgeschwindigkeit

  • Müssen wir Diskutieren!
  • Wie sind sie festzulegen, können Moderatoren sie ändern?

10 Moderatoren

  • Brauchen eigene Einstiegs-/Übersichtsseite?
  • Anfänglich von FSK bestimmt, später gewählt?
  • Können sich Bearbeitungsrecht für Themenbeschreibung holen.
  • Können Initiativen in bestehende Themen verschieben
  • Können Initiativen-Bearbeitungsrechte ändern – muss gut begründet sein.
  • Löschrechte???
  • Öffentlicher AktionsLog!

11 Gruppen

Gruppenmodell 1 kann natürlich mit Verwaltungsmodell a und b und Gruppenmodell 2 kann auch mit Verwaltunsmodell a und b verwendet werden. Es ist vielleicht sinnvoll, das Ganze etwas modularer zu betrachten. Nicolas 09:49, 12. Mai 2010 (UTC)

11.1 Modell 1

  • Mitgliedschaft verwaltet durch Gruppenmoderatoren
    • History über Änderungen, für jedes Mitglied / alle einsehbar
    • Gruppenmitgliedschaft bei Personen öffentlich deutlich vermerken
    • Zu werdendes Mitglied beantrag Mitgliedschaft, ein Moderator muss genehmigen
    • Keine Zwangsmitgliedschaften!
  • Verschiedene Modelle für Stimmverteilung:
    • Delegationen an Gruppe werden über Liste (evt. andere Methode) an Gruppenmitglieder weitergegeben
      • Selbstverständlich können Gruppenmitglieder an sich gegenseitig delegieren
    • Moderator verteilt Stimmen an Mitglieder
    • Feststellung: Wenn jemand an eine Gruppe delegiert, kann derjenige auch gleich an ein Mitglied delegieren, das die Mehrheitsmeinung vertritt. Wenn man die Möglichkeit einbauen würde, dass man an eine Entscheidung zum Thema an mehrere Person delegieren kann, wäre das sogar äquivalent mit Gruppen nach Modell 1.

11.1.1 Vorteile

  • Hierarchische oder undemokratische Gruppe wird zu einem Mehrheitsmodell gezwungen, muss also abstimmen.

11.1.2 Nachteile

  • folgendes Szenario führt zu Problemen:
    • Gruppe mit neun Mitgliedern: fünf Leute für Semesterticket, vier dagegen.
    • Zwischen Sitzung und Abstimmungsergebnis trifft Semesterticketbefürworterin Alice Bob, der sie vom Gegenteil überzeugt (vielleicht mit einem Argument, das in der Gruppe nicht bedacht wurde)
    • Was macht Alice bei Modell 1? Stimmt sie
      • für Semesterticket: Alice stimmt gegen ihre Meinung
      • gegen Semesterticket: Meinung der Gruppe springt um auf gegen Semesterticket, obwol sie eine andere Meinung propagiert hat
    • Kommentar: Dieses Szenario wirkt auf mich sehr konstruiert. Zum einen ist dies ein "Problem", das z.B. auch jede Fraktion im Budestag hat, zum anderen sollte ein Gruppe keine Meinungen Propagieren, zu denen nur 5 ihrer 9 Mitglieder stehen. --Chronial 22:16, 11. Mai 2010 (UTC)
  • Konsensorientierte Gruppe wird zu einem Mehrheitsmodell gezwungen, muss also abstimmen.
    • Kontra: Nach dem "Moderator verteilt Stimmen"-Ansatz ist dies nicht der Fall.
    • Kontra: Würden nicht alle Mitglieder gleich abstimmen, wenn dieser "Konses" wirklich ein Konsens ist?
      (Doch, aber manche Leute regen sich schon auf, wenn sie nur das Wort "Abstimmung" hören)
  • schwieriger zu implementieren, warum viel Aufwand in Implementierung stecken, was wir im RL eher aufweichen möchten?
  • Gruppenmoderator muss Mitglieder in die Gruppe aufnehmen und löschen (zusätzlich zu gruppeninternen Mailinglisten, Wikis ...) -> geringere Akzeptanz

11.2 Modell 2

  • LD-Gruppe ist Spiegelbild einer Gruppe, die sich real trifft.
  • vielleicht auch als eine Art "Wahlprogramm" bezeichenbar
  • Gruppe hat keine Mitglieder
  • Gruppe kann Anhänger haben
  • Gruppe ist wie eine Person ohne eigene Stimme, nur mit delegierten Stimmen
  • nur Moderator(enteam) kann abstimmen, hält sich an Beschluss der realen Gruppe (falls nicht -> siehe Ruprecht)
    • freies Mandat des Moderators sollte durch Delegation sichtbar gemacht werden

11.2.1 Anlegen/Moderation

11.2.2 Vorteile

  • Mitgliederverwaltung entfällt komplett (für die Gruppenmoderatoren).
  • Benutzer müssen nicht zeigen, in welchen Gruppen sie sind, um im RL in dieser abzustimmen.
  • Wahrung der Anonymität von Leuten, die in mehr als einer Gruppe sind
  • leicht zu implementieren (Gruppe ist Unterklasse von Person, oder hat gemeinsame Oberklasse mit Person)

11.2.3 Nachteile

  • Gruppen werden zum Fraktionszwang gezwungen. Dies war der zentrale Grund für die Schaffung von Modell 1.
    • Nein
    • Gruppenmitglieder können im LD-System getrennt von der Gruppe entscheiden
    • Wahlprogramm wäre vielleicht der treffendere Begriff
  • "Anhänger"-Feature hat für die Plattform keinerlei nutzen, ist komplett unnötiger Implementierungsaufwand.
  • Mehraufwand für LD-Moderatoren
    • Wenn die Mitgliederverwaltung für die Gruppe entfallen soll, müssen die LD-Mods auch Amok laufende Gruppenleiter checken. (Das wird die reale Gruppe auch melden können. Problem könnte eine inaktiv gewordene Gruppe sein, die nur noch aus dem Moderator besteht.)
  • Weiteres Problem dabei: Moderatoren haben (vorerst) keine Legitimation!
    • Moderatoren arbeiten im Namen der Gruppe und beziehen daher ihre Legitimation

11.3 Modell 3

  • gar keine Gruppen

11.3.1 Vorteile

  • Gruppendenken wird aufgeweicht

11.3.2 Nachteile

  • Orientierungslosigkeit von Neulingen (An wen soll ich jetzt delegieren?)

11.3.3 Links

https://lqpp.de/be/initiative/show/125.html
https://lqpp.de/be/initiative/show/211.html

11.4 Anlegen/Moderation

11.4.1 Modell a

  • Gruppen für jeden gründbar, bekommen jedoch erst offiziellen Gruppenstatus (standardmäßig in Delegationenliste aufgeführt, etc.) ab einer Gewissen Anzahl an Mitgliedern/Anhängern (5?)
  • Wer ist Moderator?
    • Zuerst Gruppengründer
    • Moderatoren können abtreten, weitere benennen
    • Entfernung eines Moderatorstatus braucht Zustimmung aller Moderator
    • Beendingung einer Mitgliedschaft (der Gruppe) baucht mehrheit der Moderatoren (bei Modell 1)
    • Moderatoren können nicht aus der Gruppe entfernt werden

11.4.1.1 Vorteile

11.4.1.2 Nachteile

11.4.2 Modell b

  • Gruppen nur von Admins LD-Moderatoren (Das ist verwirrend: LD-Moderator, Gruppen-Moderator) einrichtbar (Administrator ist eine technische Rolle)
  • Gruppe muss regelmäßige Treffen nachweisen
  • verhindert die Gefahr, dass reale Gruppe mit demselben Namen, nichts von der LD-Gruppe oder LD-System überhaupt weiß

11.4.2.1 Vorteile

  • es existieren nicht 100 verschiedene Unsinn-Gruppen

11.4.2.2 Nachteile

  • Erhöhter Aufwand für LD-Moderatoren.  Modell a ist ein Selbstläufer, braucht nur im Extremfall Eingriff (Jemand erstellt eine Gruppe mit unangemessenem Namen). Hier müssen die LD-Moderatoren:
    • Die Gruppen auf Antrag anlegen
    • Überprüfen, ob sich die Gruppe wirklich real trifft (eigentlich nur wenn Verdacht besteht, dass das nicht der Fall sein könnte; genauso wie bei der FSK)

12 Schnellentscheide

  • Zwei Arten von Schnellentscheiden:
    • Ultraschnell:
      • Nicht über LD, sondern wird von gewählter Person/Gruppe (je nach wichtigkeit der Entscheidung?) getroffen
    • Schnell:
      • Durchläuft die Phasen sehr schnell
      • Wird jedem User deutlich angezeigt (Startseite/Popup/Direkt auf Themenbereichsübersicht)
        • Anzeigelevel einstellbar
        • Solang keine Einstellungen getroffen wurde: eher geringes Level, wird allerdings durch Aktivität automatisch hochgestuft
  • Müssen gut begründet sein! (warum eilig?)
  • Harte Regelungen gegen Missbrauch

13 Nutzungslevel

  • Einteilung der User in 3 Nutzungslevel:
    • Desinteressiert: Gibt maximal ein paar Delegationen an. Wichtige Zielgruppe, da Mehrheit
      • Extrem einfache Möglichkeit nötig, Delegationen global und Themenbereichsbezogen einzurichten!
    • Interessiert: Delegiert hautptsächlich, nimmt schwach selbst an Entscheidungen teil.
      • Möglichkeit mit geringem Aufwand abzustimmen und sich über Initiativen zu Informieren
    • Aktiv: Delegiert wenig, nimmt stark an Entscheidungen teil.
      • Will vollen Zugang zu Möglichkeiten der LD. Nutzt Anregungen, ist evt. Mitglied in Gruppe.

14 Glossar

  • Gruppe
  • Person = User
  • Themenbereich: Grundsätzliche Themengruppierung, Wichtig für Übersichtlichkeit + Delegationen
    • Mitglieder: Kann jeder werden, haben automatisch Interesse an allen Themen des Bereichs
  • Thema: Eine konkrete anstehende Entscheidung
    • Population: Alle an einem Thema interessierte Personen. Das sind Mitglierder des Themenbereichs + interessierte.
  • Initiative: Eine Entscheidungsmöglichkeit innerhalb eines Themas (Wort gefällt mir nicht)
    • Unterstützer: Leute, die die Initiative in ihrer aktuellen Form unterstützen
    • Potentielle Unterstützer: Leute, die die Initiative unter Vorbehalt unterstützen.
      • Wichtig: Usern klar machen, dass dabei technisch kein Unterschied, sondern nur Feedback an Initiativen-Ersteller!
  • Interesse: Siehe Abschnitt Themen

15 Notes / Fragen

  • Die großen Infoboxen von Liquid-Feedback sind schön – so was brauchen wir auch
  • Zeitachse - SHOULD
  • Zentrale Aktivitätsmessung? (Methode zur Bestimmung des Aktivitätsgrades eines Users)
  • Todo: Übersichtsseite ähnlich Einstiegsseite von Liquid Feedback
  • Initiativen löschen? Wer, wie?
    • Kann man Initiativen noch zurückziehn, wenn das Thema in Verifikation ist?
    • Disksussion verschoben, aber wichtig
  • Advanced Mode, mit anderer Einstiegsseite und weniger agressiven Delegier Buttons.
    • Später drum kümmern
  • Dokumenten-Upload
    • Im Forum – nicht in der Platform
  • Einfache Funktion zur Beantragung von Gruppenmitgliedschaft
  • Spamschutz: wie contingent Table von LF. Limit auf
    • Initiativen erstellt in bestimmtem Zeitraum
    • Anregung erstellt in bestimmtem Zeitraum.
  • Wir brauchen Pseudonyme (bei erstanmeldung festzulegen)
  • Hinweis an User, wenn er Teil eines Delegationskreises ist.
  • Jeder User kann einstellen, wie lange von ihm getroffene Entscheidungen sichtbar bleiben sollen. Die Delegationskette wird dabei nur angezeigt, wenn alle Teile der Kette ihre entscheidung noch sichtbar halten wollen. Mindeszeit: 6 Monate.
  • Unsere Sprache ist sehr (!) wichtig – wir sollten uns über jedes Wort noch einmal Gedanken machen.
  • Klarer Hinweis an potentielle Trolle, dass sie ihre Rechte verlieren werden und nicht mehr am Diskurs teilnehmen können

16 Auto-Ablehnung

  • Keine Auto-Ablehnung
  • Mindestwahlbeteiligung:
    • Eine Entscheidung braucht einen gewissen Prozentsatz um gültig zu sein
      • Dieser Prozentsatz wird an der Population des Themas gemessen

17 Members(LF Konzept)

  • Bin mir nicht sicher über dieses Konzept – ist mir zu kompliziert und undurchsichtig. Scheint mir auch gefährlich (zu viele inaktive Mitglieder). Gibt es dafür vielleicht eine bessere Lösung.
  • Man kann Member eines Themenbereichs sein
    • Wenn man Interesse an einem Thema anmeldet ist das wie Member sein
    • Die Quote zur Anerkennung eines Themas (und zur Anerkennung der Endentscheidung) wird nur innerhalb der Members und interessierten bestimmt

18 Programmiersprache

  • PHP, mit einem Framework, eventuell CakePHP
  • PostgreSQL. Unter anderem weil der LF-Kern in PostgreSQL geschrieben ist, und wir den nehmen wollen.

19 Lizenz

  • Open-Source-Lizenz?

20 Organisatorisches

  • FSK-/StuRa-Antrag schreiben
  • Werbung machen und Überzeugungsarbeit leisten, damit der Antrag auch angenommen wird
Abgerufen von „https://agsm.stura.uni-heidelberg.de/index.php?title=Diskussionsstand_LD&oldid=3602“