Zurück zur Wiki-Seite der AG Meinungsfindungstool:
http://wiki.piratenpartei.de/AG_Meinungsfindungstool
synchrone/mündl. Kommunikation:
Mumble-Raum AG Meinungsfindungstool [Pfad: Bund/Arbeitsgemeinschaften/Technik (IT)]
Mumble-Direktlink: http://is.gd/yN0dgS
Dies ist ein Notizpad und keine offizielle Äußerung der Piratenpartei!
This is a note pad and NOT an official statement of the Pirate Party!
Mumble-Arbeitstreffen der AG Meinungsfindungstool:
Dienstag, den 15.07.2014, 21:00 - 22:30 Uhr
== Teilnehmer ==
- bloxx
- Merkbefreiter
- Wolfgang
- /
- DerThomas
- Jano
== Agenda ==
Wir befinden uns in der Prototyp-Implementierungsphase.
Top 1 - Informationen aus den Teams - kurzer Austausch:
Ausgangspunkt: Letztes Treffen (08.07.2013) - https://meinungsfindungstool.piratenpad.de/ep/pad/view/ro.7bcZ$Xa2uwGGC3n4k8CwmAcy/latest
- Ontology Definition Team
- Abgeschlossen
- In Arbeit
- Diskussion zum Themenbaum (Eltern-Kind-Beziehung / Relationen)
- Nächste Schritte: (HELP WANTED!)
- Feature: Unique Constraints auf einzelnen Eigenschaften ermöglichen, um z.B. Namen/Aliase für User datenbankseitig eindeutig zu bekommen.
- Refactoring: Funktionalitäten im OntologyContext sauber trennen zwischen Entitäten (Deklaration und Konfiguration) und allgemeiner Persistenz (SetCurrentOriginator, AddChangeDetail und SaveChanges).
- Legende zu den einzelnen Ontologie Entitäten aus OWL erstellen.
- Gruppendefinition innerhalb der Ontologie:
- sollten wir zwei Typen von Gruppen unterscheiden (offene Gruppen und definierte Gruppen (authentifizierte (Triggerwarnung!) Mitglieder))?unbedingt!
- Vorschlag:
- offene Gruppe bezieht sich auf Topic (das vorschreibt, was reingehört) - ihr gehören faktisch alle ihm zugehörigen Posts an
- geschlossene Gruppe bezieht sich auch auf Topic, aber nur die Posts der Mitglieder zu dem Topic erscheinen in der Gruppe
- Probleme: Lesen/Schreiben? Definition? implizit/explizit?
- Jetzt gerade noch nicht wichtig bzw. führt jetzt zu weit+1+1
- Ist die Authentifizierung Aufgabe der Ontologie? (OpenID / PiratenID)
- Muss wohl leider so sein: Sonst kann sich jeder als jemand anders ausgeben!+1
- User/Origin
- Themenkomplex Authentifizierung/Gruppen/Berechtigungen
- qKonsens-spezifisch
- ==> zumindest mal unterschiedliche Gruppentypen versuchen herausarbeiten!
- wie werden Bewertungen innerhalb von Gruppen abgebildet bzw. aggregiert?
- persönliche Meinung (Individuum)
- gemeinsamer Standpunkt (Gruppe) incl. Verständigung über vorh. Dissens!!
- Abgleich mit eDialogus http://www.imc.com.gr/ontologies/eDialogos/consensus/#overview
- Abgleich mit WikiArguments
- Abgleich mit Findeco
- Abgleich mit Multilectics
- Abgleich mit qKonsens
- Abgleich mit Votorola: http://zelea.com/w/Stuff:Votorola/glossary
- Abgleich mit Vilfredo
- Abgleich mit X-Tree-M
- Offene Fragen
- Definition der Begriffe innerhalb der Ontologie: http://meinungsfindungstool.piratenpad.de/disco-Ontologie-Begriffe
- Sollen Textformatierungen (Markup) in der Ontologie (Datenbank) gespeicher werden?
- Problem: HTML ist nur eine möglich Auszeichnungssprache für Textformatierungen. Wahrscheinlich müssten wir etwas abstrakteres wie z.B. Wiki Markup nutzen und entsprechende Konvertierungen anbieten.
- Sind dadurch Javascript-Angriffe auf die Plugins möglich ?
- Was wird an Formatierungsmöglichkeit benötigt?
- Prototype Core Team
- Abgeschlossen:
- In Arbeit:
- Web API: IIS Konfiguration anpassen, sodass der Application Pool nicht nach 20 Minuten automatisch recycled wird und der Datenzugriff performant bleibt. Momentan dauer der erste Zugriff (nach dem recyclen nach 20 Minuten Inaktivität) unverhältnismäßig lange.
- Warte bitte noch vor dem nächsten Upload - Die Bewertungsskala auf dem Server ist gerade noch auf (-3) bis (+3) eingeschränkt, das muss ich davor noch auf (-6) bis (+6) erweitern. Damit ein Upload reicht...
- JavaScript Library:
- Neue Version der d!sco Client Library basierend auf JayData implementieren.
- Vereinfacht den Zugriff auf die d!sco Daten dramatisch, da das gesamte Entitäten-Modell der Ontology aus den Metadaten der Ontologie generiert wird!
- Abhängigkeit zu datajs Bibliothek ebenfalls über RequireJS verwalten
- jsfiddle.net-Demos
- Nächste Schritte:
- Web API: Kleiner Refactorings, wie z.B. OntologyContext Klasse aufteilen usw.
- Allgemein: Aufgaben an denen im Rahmen der AG MFT mitgearbeitet werden kann auf die Wiki Seite setzen - direkt mit einem Klick ==> erst auf CodePlex, dann ins Wiki.
- Ontology Explorer: Anreicherung der generierten Web API Dokumentation mit individueller Beschreibung.
- Wie es scheint, kann die automatisch generierte Dokumentation nicht verwendet werden, da diese sehr fehlerhaft ist.
- Es muss eine komplett manuelle Web API Dokumentation erstellt werden!
- Offene Fragen:
- Prototype Plug-In Team
- Abgeschlossen:
- In Arbeit:
- X-Tree-M ("eXtended-TREE-method")
- Parent path in Win Explorer style -> stable but not working completely -> not uploaded yet
- Problem when creating new items -> latest item ID not taken from good source
- qKonsens
- d!scoArguments:
- Seite 'Discussion': Speicherung (PATCH) der durch Drag-And-Drop als Pro- oder Kontra geänderten ReferenceType Beziehung.
- Seite 'Discussion':
- Nächste Schritte:
- X-Tree-M:
- bringe Beispielinhalte zum Thema "Basisdemokratie-Strukturen" in meine lokale Datenbank
- Multi-Selektion per Shift-Taste
- mehrere Parent-Items + entspr. Copy-by-Reference-Operation -> Speicherung des bevorzugten Default-Parents per Cookie für leichteres Hochhangeln
- jQuery: http://learn.jquery.com/about-jquery/how-jquery-works/
- Selektion mit Pfeiltasten
- ggf. stärkere Einrückung
- Logging für Fehler-Erfassung (z.Zt. noch abstürzende Selektierung)
- Prüfung der XML-Datenbank-Daten per Programm
- Probble-Funktionalität einbauen
- Integration von DISCO-Datenbank, sobald Client Library einen passablen Stand erreicht hat und qKonsens mit Multilectics harmoniert
- History
- trying to implement a more comprehensive Cookie to enable version check
- qKonsens-Roadmap: https://meinungsfindungstool.piratenpad.de/qkonsens-roadmap
- Multilectics:
- Sofort nach qKonsens
- Filter- und Sortierungsmöglichkeiten.
- Meta-Diskussion unter den Posts (siehe stackoverflow.com)
- Startseite(n), Themen-Browser, Gruppen-Mgr_innen
- Themengruppen. (=Topics)
- User.
- Vertrauenspersonen.
- Edit-Funktion
- in gaaanz weiter Zunkunft:
- Manifest (Einzel- oder Gruppenstandpunkt): EtherPad-Like?
- d!scoArguments:
- Seite 'Diskussion': Layout dynamisieren.
- Seite 'Diskussion': Daten laden.
- Offene Fragen:
- Communication Team:
- Abgeschlossen:
- In Arbeit:
- d!sco Proof of Concept (Aufbereitung der User-Case-Studie)
- Entwurf fertig stellen und formal überarbeiten = "Selbstverständnis d. AG"
- Zwischenstand - User-Case-Studie:
- 17.06.2014 - Bzgl. Anbau einer theoretischen Erklärung vorweg lief bis jetzt nur Informationen sammeln und aufbereiten und Brainstorming...
- Archiv fertig durchgekämmt
- Jetzt trage ich gerade unterschiedliche Quellen zusammen, die Problemaufrisse bzgl. der jetzigen Diskussionskultur darstellen; als nächstes wird dann abgewogen, was die 5 fatalsten Mängel unserer Diskussionskultur sind, und die werden dann narrativ zu einer TOP 5 zusammengeschnürt
- Erhielt E-mail von Jano; sie hat für den 01. Juli zugesagt
- Nächste Schritte:
- @Slash ==> E-Democracy Talk mit Votorola und Blinap organisieren??
- Wiki-Redesign
- Sticky-Thread für's Forum
- Funding
- Englische Erklärung als Zusammenfassungs-Schnitt erstellen & veröffentlichen
- Eingehende Vorgehensweise:
- gesondertes Treffen
- im Vorfeld dessen sich Notizen machen, wie man schneiden würde
- Notiz-Überschneidungen werden genommen
- Offene Fragen:
- Consensus Tool Team:
1. Bei vielen Problemstellungen ist schon im Vorfeld klar, aus sachlichen, logischen oder Gründen der Realisierbarkeit, wieviele Lösungen gewinnen können bzw. auch dass es dazu mehrere Unterprobleme gibt. Zumindest sollte klar sein, in welchem Prozessschritt (Problemklärung, Diskussion, Sortierung, Bewertung) man sich befindet.
Beispielsweise ist die Hauptfragestellung zur Wahl eines Vorstands untergliederbar in mehrere Teilfragestellungen für die jeweils nur eine Lösung gewinnen kann. In dem Fall wäre das ein Konsens-Café mit 3 bis x Teilfragestellungen (Vorsitzender, stellv. Vorsitzender, Schatzmeister usw.) und jeweils einer Lösung.
- Bei einer Haushaltskonsensierung zB würde auch eine Abstimmung für vorher festgelegte Bereiche gemacht und man kann dann die Verhältnisse der Bewertungen als Eingabe für die einzelnen Haushaltsberechnungen als politische Vorgaben und Bedarfsnormen heranziehen. In dem Fall würde man keine Angaben zur Anzahl der Gewinner-Antworten benötigen.
- Es gibt zudem auch Problemstellungen (zum Beispiel bei der Konsensierung von Programmen, Manifesten, Bündnisforderungskatalogen etc., die wiederum aus mehreren Zwischenschritten bestehen: Forderungen konsensieren, Textbausteine konsensieren, Endprodukt abstimmen), in denen man erstmal akzeptable Lösungsbänder auf Thesenebene generiert/konsensiert, die dann für übergeordnete Zielstellungen zu Textabschnitten weiterverarbeitet werden. Dieses könnte dann im weiteren Verlauf von einfachen Argumenten hin zu übergeordneten Textbausteinen fortgeführt werden, in der es vor allem um die Formulierung und Einbettung der Argumente geht und bspw. unterschiedliche Formulierungen logisch und formal äuivalenter Argumentationen miteinander verglichen werden, um dann final wiederum die beste Lösung des Gesamtswerks abzustimmen, falls es mehrere gibt.
2. Es kann auch in Frage gestellt werden, ob die Abfrage nach der Anzahl schon so früh im Prozess gestellt werden muss/sollte. Im Grunde kann man einerseits sagen, dass dies eines der Merkmale ist, die eine genaue Problemdefinition und die Beschreibung des Zwecks der Diskussion- und Entscheidungsprozesses ausmachen. Andererseits muss das aber auch nicht festgelegt werden, falls es den Teilnehmern nur darum geht, unterschiedliche Meinungsbilder einzuholen.
3. Vor allem die statistische Auswertung in der Bewertungsergebnisse bei vollständigen Konsensierungen orientiert sich daran, ob mehrere Ergebnisse oder eine Art Lösungsband generiert werden soll oder ob ein Konsens für eine Lösung erreicht werden soll. Bei einem Lösungsband mit der Maßgabe eines absoluten oder relativen Konsens, oder dass alle Lösungen über einer bestimmten Zumutbarkeitsgrenze liegen, bspw. um ein vorläufiges Thesenpapier und in späteren Schritten ein Programm oder Manifest zu konsensieren, wird statistisch sicher gestellt, dass keine Lösungen drin sind, die negativ bewertet wurden (absoluter Konsens), die sich nicht signifikant nach oben von Null oder dem Wert der Nulllösung unterscheiden oder die signifikant über einem bestimmten Quorum o. Konsensmaßstab (z.B. 75% Zustimmung oder min. 20% besser als Nulllösung etc) liegen. Wenn nur eine Lösung gewinnen kann, wird sicher gestellt, dass die beste Lösung sich statistisch signifikant von der zweitbesten Lösung unterscheidet (multiple Mittelwertsvergleiche), die ähnlich hoch bewertet wurde usw..
- Was ist der Unterschied zwischen Konsensverfahren und Diskussionstool ? Ich frag' mich halt, warum man als Nutzer 2 mal auswählen muss, einmal Konsensverfahren und dann Diskussionstool, anstatt dass man nur 1 mal auswählt, nämlich Diskussionstool, und sich damit dann automatisch für ein gewisses Konsensverfahren entschieden hat. Warum ist da 'ne Trennung ? Muss da 'ne Trennung sein ? Oder ist das Hierachisch zu verstehen, also man wählt ein Konsensverfahren aus, und dann wird einem im Anschluss ein Bündel an unterschiedlichen Diskussionstools präsentiert, die quasi eine Umsetzung jenes Konsensverfahrens darstellen ?
(Jano) 1. Diskussion- und Konsensphase sind m.M.n. zwei klar von einander zu trennende Prozessschritte mit qualitativ unterschiedlichen Zielstellungen, wobei es jedoch in beiden Bewertungsprozesse gibt.
2. Im Prozesschritt, der Diskussion geht es darum einen gemeinsamen (intersubjektiven) Problemraum zu entwickeln und geeignete Lösungsoptionen zu generieren, die im nächsten Schritt in einen fairen Ideenwettbewerb treten sollen. Das Ziel dieses Prozesses ist es also ein gemeinsames Verständnis und auch einen Minimalkonsens bzw. eine klare Definition darüber zu haben, was eigentlich das Problem ist und durch welche Merkmale/Ziele sich eine geeignete Lösung kennzeichnet. Zudem muss auch sicher gestellt werden, dass alle genug (annehmbare) Infos über die Lösungsvorschläge haben, um diese qualifiziert und selbstgesteuert bewerten zu können.
Schließlich muss sicher gestellt werden, dass die durch den Konsensprozess in den vergleich gestellten Lösungsoptionen gleichwertig bzw. äquivalent sind. Dies soll letztendlich durch die Abbildung des Diskussionsergebnisses und die Sortier- / Optimierungsphase gewährleistet werden.
3. Im Prozessschritt der Konsensierung gibt es qualitativ andere Parameter, durch die bestimmt wird, welches Ergebnis gewinnt bzw. welche Lösungsoptionen vom inhaltlichen her die vorgegebenen Qualitätsstandards erreichen. Qualitätsstandards, die sich auf das Ausmaß des angestrebten Konsens beziehen bzw. welche Lösungsoptionen in die weitere Optimierung miteinfließen. Ergebnis des Diskussionsprozesses ist einerseits eine Liste von Vorschlägen, die in der Sortierphase für eine gültige Messung in ein adäquates Format gebracht wird und andererseits je nach Konsensapplikation in einem bestimmten Format bewertet wird und iterative Optimierungsprozesse durchlaufen kann.
Je nach Auswahlkriterium werden also unterschiedliche Listen an akzeptablen bis konsensorientierten Lösungen produziert, mit denen dann der Prozess wiederholt oder nächste Arbeitsschritte hin zum Endprodukt eingeleitet werden.
4. Zudem ist es in Bezug auf die Beeinflussung (Verfälschung und Manipulation) des Diskussions- und Abstimmungsprozesses nicht angezeigt, diese beiden Phasen zu vermischen.
Zwischenfazit (Jano): Diskussion und finale Bewertungs-/Abstimmungsphase sind aus Gründen der Manipulation und aufgrund dessen, dass sich beide Prozesse durch unterschiedliche Zielstellungen sowie Qualitäts- bzw. prozessuale Kriterien definieren, voneinander zu trennen. Daher bietet es sich an, für jede Phase getrennt Module zu entwickeln und in Kombination und einzeln zu testen.
- Das klingt sehr nach unserer Trennung von Diskussions- und Beschlusssystemen...
Problem: Die Gesamtheit möglicher Gestaltungsmöglichkeiten und Kriterien (die es größtenteils in ihrer Überlegenheit erst zu testen gilt) könnte den einfachen User überfordern.
Lösung: Man könnte hier über die grafische Symbolisierung der Besonderheiten der jeweiligen Tools Entscheidungshilfen oder auch umfassender, an übergeordneten Fragestellungen/Kriterien orientierte Gesamtlösungen mit Zusätzen wie Switchen zwischen alternativen Darstellungsmöglichkeiten anbieten, in denen Parameter aufgrund der Zweckbeschreibung schon festgesetzt sind, sodass der User höchstens ein paar einfache Fragen beantworten muss, z.B. bzgl. der Lösungsanzahl und Konsensualität (Quorum, ja nein, welches?, Quorum für prinzipielle Zulassung von Vorschlägen etc.) von gültigen Ergebnissen und der Frage, ob ein Vergleich zum Status Quo erfolgen soll. Außerdem bietet sich ein Erklärbärvideo an, um die theoretischen, praktischen und sozialen Mindestvoraussetzungen zur Bedienung von D!SCO sicher zustellen oder auch eine Art Qualifikationstest für User anzubieten, die dann den Moderatorenstatus in den Diskussionen einnehmen können, um die formale Qualität des Diskussions- und Abstimmungsprozesses zu sichern.
- Woran soll man eigentlich konkret im laufenden Prozess merken, dass es besser wäre, das Konsensverfahren zu wechseln ?
1. Die Verwendung der Diskussions-, Darstellungs- und Bewertungsmodule orientiert sich einerseits daran, in welchem Prozessschritt hin zum Endprodukt man sich befindet. Man kann hier einerseits zwischen einfachen programmtechnischen Prozessschritten unterscheiden: Problemklärung, Diskussion, Sortierung, Bewertung). Häufig ergibt sich erst durch die Spezifikation von komplexeren Problemen (Problemklärung) und durch die logische oder analytische und vergleichende Auseinandersetzung mit den Lösungsansätzen (Diskussion und Sortierung), welche Teilfragestellungen bzw. welche Lösungsansätze nicht als äquivalent einzuschätzen sind. Lösungsansätze also, die von einer Antragskommission als "nicht konkurrierend" eingeschätzt werden würden und daher in getrennten Wahlgängen (unabhängigen oder zusammenhängenden Teilfragestellungen (> Konsens-Café) zu bewerten sind.
2. Vorauslaufende Problemklärungsprozesse können bewerkstelligt werden über das kürzere Verfahren der Auswahlkonsensierung, mit dem Merkmale für IST- und SOLL-Zustand (Minimalkonsens) und allgemeingültige Kriterien für die Lösungen konsensiert werden können. Ob sich sinnvolle Teilfragestellungen ergeben, hängt in vielen Fällen davon ab, wie genau das Problem vorher spezifiziert wurde, z.B. in Bezug auf die gewünschte Lösungsqualität. Letztere kann sich unterscheiden, in Bezug auf verschiedene abstrakte Kriterien, z.B. proximal vs. distal, kurz- vs. langfristig, regional vs. global etc. und in Bezug auf die Zielkriterien (zB Lernziele, Wirkfaktoren), die mit einer Maßnahme zur Problemlösung angestrebt werden.
Je genauer und je vollständiger also das Problem (zu verändernde Merkmale des IST-Zustandes, angestrebte Merkmale des SOLL-Zustandes) und die (Qualitäts-) Merkmale akzeptabler Lösungen) im Vorfeld definiert werden, desto höher die Wahrscheinlichkeit, dass die Lösungsoptionen vergleichbar bzw. äquivalent sind und auch desto mehr Klarheit darüber, ob im nächsten Schritt ein Konsens-Café mit mehreren zusammenhängenden Teilfragestellungen oder einfaches/vertieftes Konsensieren mit einer Fragestellung angezeigt ist.
Empfehlenswert erscheint es daher v.a. bei komplexen Problemen erstmal die Merkmale und Unterziele (Minimalkonsens, Auswahlkonsensieren) zu definieren, die man verändern bzw. erreichen will, um einen gemeinsamen Problemraum zu haben und darauf aufbauend das Lösungen auf Basis zu konsensieren.
3. Zudem kommt es auf die Komplexität sowohl des Problems als auch dessen Bedingtheit oder Zusammensetzung an bzw. auch welche (ggf. heterogene) Sichtweisen auf das Problem entwickelt werden etc.., ob sich eine übergeordnete oder eine Bearbeitung in zusammenhängenden Teilfragestellungen anbietet.
4. Bei der Unterscheidung von vertieftem Konsensieren und Konsens Café durch die Anzahl zusammenhängender Teilprobleme, können sich weiterhin an verschiedenen Stellen des Prozesses (Diskussions- und Sortierphase) Wechselsituationen ergeben. Hier kann man zum Beispiel einerseits Infos aus der Argumentestruktur ziehen und andererseits aus Bewertungsangaben zu den Argumenten in der Sortierphase gewinnen.
5. Langfristig kann man für dieses Problem auch eine mathematische Lösung anstreben. Mittels Faktorenanalyse kann man zum Beispiel ermitteln, in wiefern ein Satz von Aussagen gemeinsamen oder unabhängigen latenten Faktoren zugrunde liegt. Eine Reihe von Verfahren bieten sich hier für die Zukunft an, die man unter dem Stichwort "Multidimensionale Skalierung" zusammenfasst. Damit kann man Aussagen oder Objekte aufgrund von Ähnlichkeits- oder Unähnlichkeitsmaßen gruppieren und erhält dadurch gute Übersichten über die Zusammenhänge bzw. die räumliche Verteilung bestimmter Teilprobleme/Objekte nach bestimmten Kriterien (Sortierphase). Damit hätte man dann ein objektives Vorgehen, anhand dessen man erkennen kann, wann bestimmte Teilprobleme, Zielstellungen oder Lösungsansätze unabhängig voneinander und daher nicht vergleichbar sind, falls Uneinigkeit in der Gruppe besteht. Ob man es mit einem übergeordneten Problem (Generalfaktor) oder mehr oder weniger verbundenen Teilproblemen handelt, würde sich also in der Phase des Sortierens statistisch aufzeigen lassen, wenn man zB die Lösungen nach verschiedenen Kriterien bewerten und multidimensional skalieren lässt.
- Und wie soll jener Wechsel dann ausgestaltet sein ? Ist immer parallel ein Wechsel-Knopf mit Erläuterung eingeblendet, wann gewechselt werden sollte ? Oder wird dieser nur in einer gewissen Diskussionssituation eingeblendet ?
In der Phase der Problemklärung ist zu empfehlen, die Bestimmungsstücke zur Problemdefinition via Minimalkonsensbildung oder Konsens-Café (IST, SOLL, Qualitätsmaßstab) zu klären. Wenn es eine klare Problemdefinition gibt, kann es sein, dass Teile des Problems über unterschiedliche Maßnahmenbündel/Zielstellungen erreicht werden müssen, die in getrennten Fragestellungen bearbeitet werden, aber miteinander in einer gewissen Abhängigkeit stehen. ... Aktuell scheint mir das angebracht, den "Wechselknopf" parallel anzubieten...
- Warum muss man da augenscheinlich Zeiträume angeben ?
problemabhängig
verfahrensabhängig
aufgrund einer möglichst sauberen Trennung von Diskussions- und Abstimmungsphase, die ist aber auch gewährleistet, wenn man eine Sortier- bzw. Optimierungsphase zur Vorbereitung der Abstimmung zwischenschiebt
- Man könnte all die Phasen, die zur Diskussion gehören, ja auch parallel laufen lassen, damit, wo nötig, immer Korrekturen vorgenommen werden können, oder?
- Wie im beidseitigem Interesse am besten in d!sco abbilden? Möglichkeiten:
- Plug-In
- Gerüst
- mit verlaufsführender Struktur
- und nur gewissen Plug-Ins
- ?
- Nächste Schritte:
- Umsetzung:
- Es muss eine Auswahl an Diskussionstools getroffen werden, die für die Umsetzung des Konsenstools am geeignetsten sind ~ hat irgendwie was von Puzzle-Zusammensetzen...
- Hierzu wird eine Sichtung vorhandener Diskussionstools durchgeführt und parallel dazu eine Kriterien-Check-Liste – https://meinungsfindungstool.piratenpad.de/Consent-Tool-Team – erstellt. Die Sichtung wird in 3 Runden gestaffelt, die immer weitere Kreise ziehen:
- 1. Runde: Diskussionstools, die von der AG MFT entwickelt werden
- 2. Runde: Diskussionstools, auf deren d!sco-Integration man sich verständigt hat
- 3. Runde: Diskussionstools des e-Democracy-Talks, die noch nicht im Rahmen der vorherigen beiden Runden gesichtet wurden
- Findet sich für Teile des Konsenstools nach den 3 Runden und Internetrecherche kein passendes Diskussionstool, muss es unter Zuhilfenahme der Kriterien-Check-Liste erstellt werden
- Vorstellung von Theorie und Vorhaben auf einer der kommenden Mumblesitzungen der progressiven Plattform, insofern diese eben jene Aspekte bemängeln oder anstreben, die durch die neuen Konsensverfahren gelöst werden können, sodass ein erhöhtes Interesse auch für die Erprobung erwartet werden kann
- Hab ich mich auch schon umgeschaut, aber den nächsten Termin nicht rausgefunden...
- überlegen, inwiefern Liquid Feedback in d!isco eingebunden werden kann, um Befürwortern Übergang zu erleichtern
- Dann müssten wir uns aber auch um Beschlusssysteme kümmern (disco = discussion ontology). Meinungen?
- LQFB hat sicher auch Anteile eines Diskussionssystems
- Beratung zur Neugründung der AG Bundesregenerierung, die u.a. auch andere AGs reaktivieren soll
- Gestaltung der Zusammenarbeit mit der AG Basisentscheid
- Offene Fragen:
- Stationenkonzept/Prozessschritte
- d!sco Delta (Toolanalyse - Umfrage)
- Allgemeine Aufgaben
- Abgeschlossen:
- In Arbeit:
- Nächste Schritte:
- Offene Fragen:
Top 2 - Diverse Themen
Verfahren für eine ThemenwahlKooperation PPlattform- Sollen wir ein neues Consensus Tool Team bilden?
- Vorschlag: Consens Team und Theoriediskussion asynchron per Pad, Wiki, qKonsens etc. fortführen und nur bei wichtigen Punkten im Mumble ansprechen
- Wie in der letzten Grundsatzdiskussion?
- Neuer Vorschlag: "Workflow Team"
- Jana's Konzept unterteilen in:
- 1) Systemrelevante Zuordnung (Info-, Diskussion- und Beschlusssystem)
- 2) Methodische Anteile
- 3) Prozessorientierung (Workflow Ontologie)
== Beschlüsse / Decisions ==
== Nächste Themen / Next Topics ==
- DerThomas: Themenbaum - Konzept Querschnittsthemen vorstellen (nächste Woche)
- Jano & Wolfgang: Vorbereitung Umfrage/Klassifizierung/Einordnung von Tools
- Verfahren für eine Themenwahl
- Kooperation PPlattform
- Die Grundidee um folgende Synopsis erweitern, damit wird in einem Satz alles wichtige gesagt:+
- EN: Our aim is to enhance online deliberation by defining an internet based system that ensures a corruption-, hierarchy- and authority- free discourse due to its open and decentralized nature.
- DE: Unser Ziel ist es, online Diskurse und Meinungsfindungsprozesse zu verbessern indem wir ein Internet basiertes System definieren, das korruptions-, hierarchie- und autoritätsfreie Diskurse aufgrund seines offenen und dezentralen Charakters gewährleistet.
- Neben dem wichtigen Punkt der Herrschaftsfreiheit etc. sollte wohl auch das Problemfeld um die Strukturierung von Diskussionen drin sein
- Datenbankupdates sind momentan immer noch nicht inkrementell möglich, d.h. bei einem Update der Ontologie muss immer die Datenbank komplett platt gemacht werden (alle eingegebenen Daten gehen dabei verloren! Initialisierung mit Seed-Daten)
== Nächster Termin / Next Date ==
- Dienstag, den 22. Juli 2014, 21 Uhr im Mumble-Raum "AG Meinungsfindungstool"
== Sitzungsende / End of Session ==