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

[Frauke Mattfeldt <mattfeldt AT karten-verlag.de>]

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

Am 27.01.2013 01:49, schrieb Alexander Praetorius:

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]

Okee. Dann bitte macht die Standards. Ich bin aber nicht dazu bereit noch zig UML-Diagramme zu erstellen oder sonstwie hunderte von Stunden zusätzlich in einen Standard zu investieren. Es sei denn ihr bezahlt mich dafür.
Du hast ja gesagt, dass jedes Tool sich in diesem Wettkampf selbst um die Finanzierung kümmern sollte, was ich im Übrigen auch asig fand.
Ich befürchte einfach, dass ihr hier die Relativitätstheorie mit hochgestochenen Terminologien beschreiben wollt während am Ende nix anderes rauskommt als 1+1=2

 

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.

Es geht nicht um einen kooperativen Wettbewerb. Es geht darum, dass sich ein paar Trottel für lau den Arsch aufreißen, während andere zugucken, labern und profitieren wollen.

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.

Ich empfinde es übrigens als Unverschämtheit, wenn jemand fordernd meint: "Rück mal Deinen Quellcode raus" und mir nichts als Gegenleistung dafür anbietet. Ich mag Tauschgeschäfte, aber keine ewig-fordernde Schlaraffenlandmentalität.

Ich hab letzten Donnerstag mein Büro leer geräumt, weil ich meine Selbständigkeit aufgeben werde. Ich bin nicht dafür geschaffen, weil die Leute alles umsonst haben wollen bzw. die Preise ins unermessliche gesunken sind, für immer weniger Geld immer mehr verlangt wird und ich auch keinen Bock mehr habe immer neue Aufträge reinholen zu müssen, um das zu kompensieren.
Das macht keinen Spaß und ist nicht zu leisten. Ich muss mich also jetzt um was anderes kümmern. Entsprechend hab ich keine Kapazitäten mehr frei, um mich auch noch um Standards zu kümmern.
Du sprachst vom App-Store: Du willst die Tools also künftig in einem App-Store anbieten?

Also, wie gesagt: Ich frag mich zwischenzeitlich einfach nur noch, warum ich das eigentlich mache. Meine Vision in dieser Hinsicht zerbröckelt auch mehr und mehr an der Realität.

Und: Wenn es tausend Tools gibt, wieso habt ihr nicht schon längst die genommen und mal damit angefangen einen Standard zu bauen? Ihr redet hier doch schon seit zwei Jahren oder so. Verstehe ich nicht. Wieso soll ich jetzt noch UML-Diagramme erstellen und sonstiges, um so einen Standard auf die Beine zu stellen? Ihr hättet doch längst mit den 1000en von Tools, die es angeblich gibt, anfangen können mit der Entwicklung. Außerdem hätte ich kein Tool machen müssen, wenn's schon 1000 andere gibt, die super-gut sind.

Ich als Tool-Entwickler bin letztendlich an meinem Tool interessiert. Da geht es auch mehr um Inhalte. Ich muss mich nicht auch noch mit der Abstraktion der Abstraktion rumschlagen, oder?

Ich hätte mich auch gefreut, wenn in Bezug auf die Entwicklung des Tools etwas mehr Feedback aus der tollen MFT-Gruppe gekommen wäre, d.h. ein wenig Mitdenken, wenn es schon um Kooperation geht. Außer Marc, Wolfgang und Torsten, hat es scheinbar keiner getestet.

Die meisten wollen doch nur labern und warten drauf, dass ihnen am Ende die gebratenen Tauben in den Mund fliegen. Und dann können sie immer noch behaupten, dass ihnen die Taube nicht schmeckt. Vermutlich wie beim LQFB - und das wird letztendlich ja auch von keinem genutzt. Da kann man sich Zugänge aber auch kaufen, habe ich gehört. 20 Stück für 50 Euro oder so  - vermutlich die Verzweiflung der Entwickler oder der Piratenpartei, keine Ahnung, in punkto Finanzierung.

Nach zwei Monate langem hardcore-Programmieren neben Geldverdienaufträgen, bin ich einfach auch erschöpft, wenn nicht irgendwann auch mal was zurück kommt. Stattdessen sehe ich hier neue Forderungen auf mich zukommen in Richtung Standard-Entwicklung. Ich mach das aber nicht.

Wär gut, wenn man wirklich eine Gruppe wäre. Einer hätte sich ja auch ums Geld reinholen kümmern können - oder z.B. Du, Alex, hättest ja auch die _javascript_-Anteile übernehmen können. Das wolltest Du aber nicht. Stattdessen meintest Du nur, dass sich die Tools noch gegenseitig im Wettbewerb um Spenden kümmern sollten - also auch hier: Gegeneinander-Mentalität. Wobei Du selbst ja gar nicht dazu bereit bist auch nur eine Zeile Code zu investieren.

Ich habe dem "Framework" meine Datenbank geschickt. Das muss reichen. Wenn ich den Quell-Code offenlegen soll, will ich dafür bezahlt werden. Meinetwegen auch in Naturalien. Mitarbeit wäre auch okee, wenn es was bringt. Aber ich will was dafür haben und nicht noch irgendwelche Diagramme zusätzlich erstellen sollen, damit andere Leute die Prozesse kapieren, die ich mir durch intensive DenkARBEIT und Hirnverknotung ausgedacht und programmiert habe, um dann in hochgestochener Art und Weise damit klugzuscheissen und das Ganze als ihren neuen Standard verkaufen zu können.

Wo lebst Du eigentlich? Auf dem Mond? Haltet ihr mich für bescheuert?

Ich habe kein Interesse an einem Standard. Ich will ein Tool bauen, was funktioniert. Gerne auch mit anderen zusammen, die ihre Aspekte mit einbringen (Plugin-Idee) und man daraus ein funktionierendes Ganzes macht. Mehr aber nicht. Interessant fände ich in Punkto Vernetzung noch, wenn unterschiedliche Server, auf denen dieselbe(!) Plattform läuft ihre Daten austauschen könnten, um eine dezentrale Datenspeicherung zu ermöglichen. Alles andere interessiert mich aber nicht in Hinblick auf das Tool - das habe ich auch schon mehrfach gesagt. Ich hab auch eine Ahnung davon, wie das funktionieren könnte - aber dafür ist es noch zu früh für das Tool. Mit einem Standard hat das gar nichts zu tun. Trotzdem kann es Open Source sein. Aber nicht für nix und nicht so, dass ich alles machen muss und andere dann der Meinung sind, dass sie sich was Tolles ausgedacht haben, nur weil sie gut darin sind neue Wortkreationen zu erschaffen.
Ich mag es lieber klar und deutlich und so, dass man sich auch verstehen kann. Also dann...

Frauke

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  ***********************************************