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

["marc" <marc AT merkstduwas.de>]

Hi Alex,

aus meiner Sicht sollen die zu definierenden - oder besser; die in der 
Realität zu findenden und abzubildenden - Workflows nicht einschränkend 
sondern begleitend und anleitend nutzbar sein. Bei optimaler Unterstützung 
des übergreifenden Prozesses ist maximaler Freiheitsgrad anzustreben.

Allerdings glaube ich nicht, das der übergeordnete Prozess der der 
Problemlösung sondern der der Willensbildung ist. Probleme zu lösen ist 
"nur" ein spezifischer Aspekt dieses Prozesses und wird daher idealerweise 
als Plug-In abgebildet.
Es gibt Workflows (Abläufe) im Willensbildungsprozess, welche gar kein 
Problem als Ausgangssituation, sondern als möglichen Zwischenschritt, lösen 
müssen, um überhaupt zum Ziel zu gelangen.

Der eigentliche Prozess der Willensbildung ist mMn auch mit DISKURS 
gleichzusetzen. Es wird gerne davon gesprochen, dass zu einem bestimmten 
Anlass ein Diskurs in der Gesellschaft stattfinden soll, um z.B. den Umgang 
mit Andersartigkeit zu bestimmen.

Aus meiner Sicht ist der Diskurs im Idealfall durch einen Ausgangspunkt (dem 
Anlass) und einen Endpunkt (dem Ergebnis des Diskurses) klar definiert, 
wobei das Erreichen des Endpunktes nicht nur durch die Ausführung einzelner 
Schritte erfolgen, sondern z.B. auch durch setzen einer Bedingung 
herbeigeführt werden kann. Auch was konkret als Ergebnis eines Diskurses 
zählt, ist für jeden Diskurs aufs neue zu bestimmen.

Die Ausführung der einzelnen Schritte - innerhalb des Diskurses - erfolgt 
nicht immer sequentiell, sondern kann auch parallel erfolgen.

Meine Hoffnung ist es, dass einzelne Schrittfolgen zusammenfassbar und/oder 
verallgemeinerbar sind und somit als Teil des "Common Discussion Standard" 
die Workflows definieren könnten.

Cheers
marc

-----Original Message----- 
From: Alexander Praetorius
Sent: Saturday, January 26, 2013 3:27 PM
To: Piraten AG Meinungsfindungstool
Subject: Re: [Ag Meinungsfindungstool] qKonsens, Probble, 
fundiert-entscheiden, d!sco und der Common Discussion Standard (CDS*)


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.

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] mailto:alexander.praetorius 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