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

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

Hi Alex,

Ich schrieb:
> 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.

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

Das liegt glaube ich gaaanz dicht beieinander!

Was wären für Dich z.B. mögliche Transaktion im Kontext des übergeordneten 
Prozesses?

Cheers
marc

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

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


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