Re: [Ag Meinungsfindungstool] qKonsens, Probble, fundiert-entscheiden, d!sco und der Common Discussion Standard (CDS*)

[Alexander Praetorius <citizen AT serapath.de>]

2013/1/26 Frauke Mattfeldt <mattfeldt AT karten-verlag.de>

Am 26.01.2013 15:27, schrieb Alexander Praetorius:

Ich glaube persönlich, das die Definition eines Workflows nicht hilfreich ist.

Die konkreten Tools a.k.a Plugins sind es die evolutionär ausknobeln wollen welche Workflows die sinnvollsten sind.

Je nach "Problemdomäne" wird es unterschiedliche Diskussionsarten geben.
jede Diskussionsart bringt andere Probleme mit sich.
Was es braucht ist Plugins als Hilfsmittel um diese Probleme zu lösen, d.h. um ein oder mehrere Teilschritte in einem Workflow zu binden.

Was wir brauchen wäre vielleicht die Definition minimaler bzw. atomistischer Transaktionen, grob analog dem Konzept wie es bei Datenbanken der Fall ist.

Ein Plugin, welches ein oder mehrere Teilschritte eines Workflows abbildet muss mit einem solchen atomistischen Zustand starten und in einem enden.

Das ist glaube ich alles was wir leisten können. Der Rest wird dann im Wettbewerb konkreter Tools geleistet werden.

Mal davon abgesehen, dass ich Dich nicht verstehe bei dem, was Du schreibst (ist mir mal wieder zu hoch):
Bei dem Konkurrenzmist werde ich nicht mitmachen. Nicht in diesem Rahmen. Da habe ich keinen Bock drauf.

[alex]
Stell dir vor du schreibst eine App für einen Appstore. Das ist total leicht, weil gewisse Standards vorgegeben sind und deine App konkurriert mit allen anderen Apps im Store.

Stell dir vor du schreibst eine Webapplikation. Du kannst auf all den Standards aufbauen, HTML, Javscript, CSS, diverse andere W3C Standards... Du kannst das als Framework betrachten und deine Webapplikation ist das Plugin.

Wenn man nun die konkrete "Domain" eingrenzt auf alles was mit "Demokratie/Diskutieren/Abstimmen" usw... zu tun hat, kann man hierfür speziellere Standards im Sinne eines Frameworks ausarbeiten, also die extrem allgemeinen Formate wie HTML, _javascript_ und CSS....

Ist so ein Framework vorhanden, dann wird es viel viel leichter "Diskussionstools" und ähnliches mit wenig Aufwand am laufenden Band zu produzieren.

[/alex]

 

Außerdem: Wieviele "Plugins" werden denn gerade entwickelt? Wir können doch froh sein, wenn wir zwei hinbekommen.

[alex]

Andere Frage, weisst du wieviele Abstimmungstools weltweit ständig produziert werden?
Jeder erfindet das Rad neu und alle sind sie "closed systems", die keine Export und keine Importmöglichkeiten anbieten. Was wäre wenn ich aus einer bestehenden Liquid Feedback Instanz alle Daten und User in mein eigenes Tool übertragen will oder zumindest mit meinem Tool eine andere Benutzeroberfläche für die darunterliegenden Inhalts und Userdaten anbieten will?

...unmöglich! Jeder baut seine Inseln mit seinem xten eigenen Abstimmungstool.
Das gilt auch für probble.
Wenn es nicht Menschen gegeben hätte, die sich Standards wie HTML und CSS oder auch Programmiersprachen ausgedacht hätten, dann hätte jeder das Rad wieder neu erfinden müssen.

Also wenn man schon probble oder qprobble entwickelt, dann ist es ganz wichtig, das man parallel dazu offene Standards mitschleift.
[/alex]

 

Das macht aber aus meiner Sicht keinen Sinn. Dann kann man den Plugin-Kram auch gleich in die Tonne treten und zwei konkurrierende Tools draus machen, wenn man scharf auf Wettbewerb ist.

[alex]
Nein.
Du wirfst Konkurrenz mit Kooperation durcheinander.
Bei Konkurrenz ist das wesentliche Merkmal, das alle Seiten persönliches Leistungspotential in destruktive Verhaltensweisen binden, nämlich um sich zu schützen gegen "Angriffe" des anderen und um selbst "Angriffe" zu fahren, d.h. um Markteinstiegsbarrieren aufzubauen.

Öffnen man hingegen freiwillig sein eigenes System und macht die Standards transparent, dann muss nicht jeder das Rad neu erfinden, sondern kann andocken an das was bereits existiert und diejenigen die eine Sache gestartet haben können profitieren davon.

Glaubst du die Einführung von W3C Standards, wie HTML, CSS, XML, RDF, usw.. hat denen die sich die Mühe gemacht haben das auszudenken geschadet? Ist nicht die Vielfalt des Internets die auf diesen Standards basiert eine Bereicherung?
[/alex]


 

Wobei ich gar nicht weiß, ob Du bei dem von Dir selbst ausgerufenen Wettbewerb überhaupt als Teilnehmer antreten wirst.

[alex]

Klar, würde ich gerne.
Ich sehe nur keinen Sinn darin jetzt ein Tool zu programmieren, denn es gibt schon viele gute Tools die alle auf Inselsystemen aufbauen.
Ich möchte nicht immer wieder das Rad neu erfinden und viele eigene Lösungen zusammenklatschen, sondern auf Standards aufbauen um, wenn sich mir neue Erkenntnisse erschliessen, das nach und nach sinnvoll weiterzubauen.

Ich habe viele gute Ideen wie die Benutzerinteraktion aussehen muss und das an sich ist schon eine Wissenschaft für sich. Es ist zuviel sich auch noch darüber Gedanken zu machen wie man das ganze möglichst ohne Machtkonzentration open source und Peer2Peer-verteilt hinbekommt, wie man Daten sinnvoll speichert das sie nicht verloren gehen, usw.. usw...
Es geht ja nicht um ein abgeschottetes Inselsystem.
Zu irgendeinem Zeitpunkt wird es so sein, dass ich in die geschaffenen Standards soviel Vertrauen aufgebaut habe, das ich mich an meinen eigenen Tool-Entwurf wage.

Also als Daumenregel geht es mir darum zu vermeiden einen Weg zu gehen, dem andere nicht folgen können. Das heisst einen Weg der "closed source" ist und der zwangsläufig dazu führt, das andere das Rad neu erfinden müsen und Silos aufgebaut werden in der sich mehr oder weniger zufällig einer durchsetzt und alle anderen ALLES investment verlieren.
Das ist dann was eigentlich Konkurrenz ist.
Genau das muss verhindert werden.
Es geht um einen kooperativen Wettbewerb, bei dem sich die Beste Lösung durchsetzen mag, aber alle Wettbewerber auf Basis der besten Lösung direkt aufbauen können, weil sie bereits verstehen wie die Beste Lösung funktioniert, weil sie offen ist und auf gemeinsamen Standards beruht. Ohne diese müssen sie sich nämlich erstmal mühsam einlernen und das ist klassisch aufgrund der "closed system mentalität" nicht möglich.

Das macht dann den Verlust im Toolwettbewerb zu einem schmerzhaften Verlust, während ein Verlust im Toolwettbewerb mit offenem Ansatz einen persönlichen Gewinn bringt, weil man nun einfach das beste Tool nutzen kann und darauf aufbauend weitermacht.
Man kann ganz einfach voneinander lernen.
[/alex]
 

Um so mehr atomistische Zustände wir haben, um so mehr Freiheiten für die Pluginentwicklung.

2013/1/26 Frauke Mattfeldt <mattfeldt AT karten-verlag.de>

Also: Unten stehts ja doch ansatzweise.
Mir geht es nicht darum:
Du schreibst "Wir müssen einen für Diskussionen übergreifenden Prozess definieren". Es geht ja nicht um Diskussionen, sondern darum, Probleme zu lösen, d.h. in einem gemeinsamen Prozess (über das Internet) Lösungen zu entwickeln, letztendlich auch über diese Lösungen demokratisch abzustimmen zu können, Meinungsbilder zu entwickeln usw. Es geht also um einen Problemlöseprozess, in dem es unterschiedlichste Aspekte und Methoden gibt, oder auch: Stationen - die sich gegenseitig ERGÄNZEN oder Teil des Gesamtprozesses sind.
Das bedeutet in der Tat, dass, wenn man mit mehreren Tools oder Plugins arbeitet, ein übergreifender Prozess definiert werden muss, der sich am besten auf EINER Benutzeroberfläche abbilden lässt. Das bedeutet, dass es in dem übergreifenen Prozess mehrere untergeordnete Prozesse gibt, die jeweils eine "Station" in einem Problemlöseprozess abbilden, wobei sie nicht unbedingt alle zwingend sein müssen (Plug-In-Idee).
Daher benötigen wir einen übergeordneten Prozess. Der macht aber nur Sinn, wenn wir mehrere Gruppen haben, die jeweils an einem untergeordneten Prozess arbeiten und diese Prozesse dann zusammen bringen wollen. Ideen für Einzelprozesse hatten wir genug. Aber wir haben es bisher zum einen versäumt, diese Leute auf einen gemeinsamen Prozess "einzuschwören", als auch, überhaupt erstmal einen übergeordneten Prozess zu definieren.
Dieser übergeordnete Prozess müsste aber am Anfang stehen und nicht am Ende.
Außerdem schien es noch kompliziert zu sein, sich auf eine Programmiersprache zu einigen usw. wobei das ggf. nicht unbedingt nötig ist. Allerdings muss sich alles im Netz auf ein und derselben Benutzeoberfläche abbilden lassen. Es ist doch bekloppt zwischen unterschiedlichen "Bildschirmen" hin und her switchen zu müssen.
Ich denke also schon, dass es da einen Unterschied in der Denkweise und im Ansatz gibt.
Frage ist auch, wer was programmieren würde. Das würde dann aus meiner Sicht im nächsten Schritt kommen. Ich hatte aber nicht das Gefühl, dass viele Leute "Hier" geschrien haben, als es darum ging. Tolle Ideen habe es aber genug.

Am 26.01.2013 14:47, schrieb Frauke Mattfeldt:

Hallo Marc,
wenn Du mein Geschreibsel schon ungefragt auf die Mailingliste setzt, dann zensiere doch bitte nicht die entscheidenden Punkte, auf die ich hinaus wollte, raus.
Die Sache mit den Workflows, Ontologie und so verstehe ich nicht, habe ich auch noch nie verstanden. Mir muss man das immer in einfacher verständlicher, am besten deutscher Sprache erklären, damit sich Bilder dazu in meinem Kopf entwickeln. Mir ist das alles zu abstrakt. Sorry.


Am 26.01.2013 14:03, schrieb marc:

Hi Frauke, Wolfgang und der ganze Rest,

ich musste jetzt mal die Mailingliste mit ins Boot holen ;o)
Es hatten sich zu viele interessante Informationen angesammelt. Ich hoffe
das geht in Ordnung.


HINWEIS: Auch wenn das jetzt eine ätzend lange E-Mail geworden ist, würde
ich mich freuen, wenn wir über die einzelnen Punkte Einigkeit erzeugen
könnten!


Zur Info an die Mailingliste. Es geht um den qprobble-Test:
http://www.karten-verlag.de/qprobble/

Anmerkungen zu den Tests werden hier gesammelt:
http://meinungsfindungstool.piratenpad.de/ProbbleAnregungen


Frauke schrieb:

marc schrieb:

@Frauke: Erstes Fazit: bisher saubere Umsetzung - Gratulation! Aber es
gibt auch noch sehr sehr sehr viel in Richtung Usability und Ergonomie
zu tun! Als wichtigsten FIX sehe ich die Möglichkeit zur Verknüpfung
an. Ohne Verknüpfung kann glaube ich nicht wirklich Mehrwert entstehen...

Ja. Das sehe ich ganz genau so. Du meinst die Verknüpfungsfunktion der
Kernaussagen? Da mache ich mich dann als nächstes dran!

Genau. Aber eigentlich möchte ich jedes Element verknüpfen können. Es müsste
nur klar sein, welche Elemente miteinander in direkter und welche "nur" in
indirekter Beziehung zueinander stehen können/dürfen.


Frauke schrieb:

marc schrieb (im Pad):

USABILITY: Es fällt mir schwer den Überblick zu bekommen! Und ich
habe erst 1 Ist-Zustand, 1 Fragestellung, 1 These und 1 Kontraagrument.

Lichtblick ist der Übersichtsgraph:
http://www.karten-verlag.de/qprobble/question/structure/56/showGraph/
Den Übersichtsgraph würde ich zum zentralen Orientierungspunkt machen.
- bessere Visualisierung: im Graphen onHover Description einblenden
- Direktes bearbeiten/bewerten der Elemente
- Direktes neu hinzufügen von Elementen zu einzelnen Elementen im Graph

Zudem finde ich auch, dass es zu viel ist, wenn in der Suche die ganzen
Thesen, Ideen, IST-Zustände usw. angezeigt werden. Die Frage wäre, ob
man zusammenhängende Themenkomplexe irgendwie zusammen fassen und dann
zusammengefasst in der Suche auftauchen lassen könnte. Sonst wird es bei
zu vielen Themen (Thesen, Ideen, Fragestellungen) einfach zu viel. Oder
was meint ihr? Habt ihr da Ideen?

Frauke schrieb:

marc schrieb:

was hältst Du von der Idee, die Funktionalität nur Schrittweise für
den Benutzer zur Verfügung zu stellen. Momentan ist das echt ein
Expertentool - das versteht wahrscheinlich niemand fürchte ich.

Vielleicht ist das was Du Stationen nennst genau das, was ich mit
einzelnen Workflow Templates abbilden würde. Es gibt verschiedene
'Stationen' die ein Element im Workflow durchlaufen kann.

Hallo Marc,
"Stationen" hatte ich deshalb geschrieben, weil Wolfgang und ich schon
mal drüber gesprochen hatten und er gesagt hat, dass das Wort "Element"
nicht passend sei. Wir kamen dann auf das Wort "Stationen".
Elemente (Stationen) sind bei mir:

- IST-Zustand
- These
- Fragestellung
- Idee
- Konzept
- Projekt
- Petition
- Ziel

Vorher gab's im probble ja nur IST-Zustände und Ideen, wobei auch die
Ideen sich auf einen IST-Zustand beziehen mussten. Letztendlich ging es
also immer nur von einem IST-Zustand aus.
Grundidee, es anders zu machen war, dass jemand vielleicht eine Idee
einstellen will - ohne dazu einen IST-Zustand einzustellen. So nach dem
Motto "Ich hab da ne tolle Idee". Jetzt kann man auch mit einer These,
einer Fragestellung usw. anfangen und die einzelnen Element miteinander
verknüpfen. So hatte ich mir das gedacht. D.h. man kann eine Idee
einstellen und die dann später mit einem oder mehreren IST-Zuständen
verknüpfen - oder man kann einen IST-Zustand mit mehreren Ideen, Thesen,
Zielen usw. verknüpfen. Letztendlich sind alle Elemente miteinander
verknüpfbar.
Ich finde es aber auch unübersichtlich so, wie es jetzt ist. Vor allem
nervt es, wenn alles in der Suche auftaucht. Das sieht man ja jetzt schon.

Frauke schrieb:

marc schrieb:

Das über die momentan Oberfläche zu ermitteln scheint mir fast
aussichtslos. Ist es Dir möglich eine State Machine
(http://en.wikipedia.org/wiki/UML_state_machine) für die aktuelle
Implementierung zu erstellen? Ich denke das wäre auch für eine
Diskussion über die Zusammenhänge und den Prozess hilfreich.

Was meinst Du?

Was ich meine ist, dass es ja eine Tool-Idee "Thesis" gab, dann die
Idee von Karsten, probble, qkonsens usw. -> aber wir haben keinen
gemeinsamen Prozess draus gemacht.
Außerdem gibt es wohl sonst niemanden, der das programmieren will
(zum Beispiel das Tool "thesis").
Erst dann macht aus meiner Sicht die Framework-Idee und auch der
ganze UML-Kram Sinn.

Aber genau darum geht es doch, denke ich. Wir müssen einen für Diskussionen
übergreifenden Prozess definieren, aber eben auch inklusive der Daten und
ihrer Bedeutung. Das ist für mich der von uns und allen Beteiligten und
Interessierten zu definierende "Common Discussion Standard", von dem ich an
der einen oder anderen Stelle bereits sprach.


Common Discussion Standard (CDS*) == Ontology + Workflows


FRAMEWORK (CORE)

d!sco Core ist der/die Prototyp/Referenzimplementierung für das Framework.
Es besteht aus der Ontologie und einem Teil der Workflows, implementiert
also den "Common Discussion Standard" nicht vollständig.

Die Web API des d!sco Core Prototypen ermöglicht den Plug-Ins die Teilnahme
an den Core Workflows UND den Zugriff auf die gemeinsamen Daten, welche
immer in Form und Bedeutung der Ontologie vorliegen.


PLUG-INS

Jedes MFT Tool, welches sich dem "Common Discussion Standard" anschließt und
somit CDS konform ist, wird d!sco Plug-In genannt. Die Plug-Ins müssen die
d!sco Ontology und Teile der d!sco Workflows implementieren.

d!sco Plug-Ins bilden in ihrer Implementierung in der Regel spezielle
Diskussionsmethoden ab und können daher auch über den CDS hinaus eigene
Daten und Workflows definieren.


ONTOLOGY

Mit der d!sco Ontology haben wir bereits angefangen einen Teil des CDS zu
definieren. Die Ontologie definiert das gemeinsame Vokabular aller d!sco
Plug-Ins und dient dem Datenaustausch.


WORKFLOWS

Jetzt müssen wir uns langsam an die Frage der Workflows heranwagen. Hier
wird es mMn genauso Gemeinsamkeiten in den Prozessen geben, welche wir in
die d!sco Workflows übernehmen können. Wahrscheinlich ist dies auch eher ein
globaler, zusammenführender Workflow, welcher die einzelne Stufen der
Diskussion toolübergreifend verbinden kann.

Dabei werden einige d!sco Workflows direct durch den d!sco Core
bereitgestellt, während andere durch die d!sco Plug-Ins implementiert werden
müssen. Die d!sco Workflows teilen sich also in Core Workflows und Plug-In
Workflows auf.

Eine der vordringlichsten Fragen lautet mMn in welcher Form wir jetzt diese
d!sco Workflows definieren wollen.


Cheers
marc


*  CDS meint hier NICHT "Credit Default Swap" ;o)

--
Ag-meinungsfindungstool mailing list
Ag-meinungsfindungstool AT lists.piratenpartei.de
https://service.piratenpartei.de/listinfo/ag-meinungsfindungstool

--

Best Regards / Mit freundlichen Grüßen

***********************************************

Alexander Praetorius

Rappstraße 13

D - 60318 Frankfurt am Main

Germany

[skype] alexander.praetorius

[mail] citizen AT serapath.de

[web] http://wiki.piratenpartei.de/Benutzer:Serapath 

***********************************************

--
Ag-meinungsfindungstool mailing list
Ag-meinungsfindungstool AT lists.piratenpartei.de
https://service.piratenpartei.de/listinfo/ag-meinungsfindungstool

--

Best Regards / Mit freundlichen Grüßen

***********************************************

Alexander Praetorius

Rappstraße 13

D - 60318 Frankfurt am Main

Germany

[skype] alexander.praetorius

[mail] citizen AT serapath.de

[web] http://wiki.piratenpartei.de/Benutzer:Serapath 

***********************************************