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

[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.
Außerdem: Wieviele "Plugins" werden denn gerade entwickelt? Wir können doch froh sein, wenn wir zwei hinbekommen. 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.
Wobei ich gar nicht weiß, ob Du bei dem von Dir selbst ausgerufenen Wettbewerb überhaupt als Teilnehmer antreten wirst.

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 

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