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

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

Am 27.01.2013 22:24, schrieb marc:
> Hi Frauke,
>
> dazu fällt mir spontan folgendes ein:
> http://www.myvideo.de/watch/8290858/Gereizt
>
> Cheers
> marc

Scheiße, ja! Stimmt! ;-)


> -----Original Message----- From: Frauke Mattfeldt
> Sent: Sunday, January 27, 2013 4:33 PM
> To: ag-meinungsfindungstool AT lists.piratenpartei.de
> Subject: Re: [Ag Meinungsfindungstool] qKonsens, Probble, 
> fundiert-entscheiden, d!sco und der Common Discussion Standard (CDS*)
>
> Am 27.01.2013 15:37, schrieb marc:
> > Hi Alex + Frauke,
> >
> > mein E-Mail-Client erlaubt mir leider keine einfache Kommentierung...
> > ...daher einfach jetzt mal die drei Punkte so:
> >
> > 1) Die Idee mit dem Standards in anderen AGen durch Interviews 
> > einsammeln finde ich super! Bitte macht das! Ich würde mich gerne 
> > beteiligen habe aber die Implementierung des Core Prototypen höher 
> > priorisiert.
>
> "Bitte macht das"? Bitte implementiere mal Deinen Core Prototypen,
> anstatt immer nur klug daher zu reden.
>
> > 2) Was haltet Ihr davon, wenn QKonsens nicht als eigenes Plug-In oder 
> > konkret in qprobble sondern als Basisfunktionalität des Frameworks 
> > implementiert wird? Das könnte z.B. eine JSNode Implementierung sein, 
> > welche dann von allen Plug-Ins genutzt werden kann. Die Daten werden 
> > über die Web API des Frameworks oder im jeweiligen Tool zur 
> > Weiterverarbeitung gespeichert.
> Was haltet IHR davon... das und das zu machen ... mach doch selber mal
> was, anstatt nur rumzulabern und irgendwelche Bildchen und
> Wortschöpfungen zu produzieren, mit denen keiner was anfangen kann.
>
> > 3) Das Geschäftsmodell für Ideen- und Veränderungsmanagement in 
> > Unternehmen ist glaube ich ein riesiger Zukunftsmarkt. Gerade die 
> > global agierenden Unternehmen investieren immer mehr Zeit und Geld in 
> > den Ausbau der Beteiligung Ihrer Angestellten. Das machen sie 
> > natürlich nicht um Basisdemokratie in den Unternehmen einzuführen, 
> > sondern um die brach liegenden Ideenpotentiale der Mitarbeiter zu 
> > heben. Auch ist der steigende Kostendruck und weitere 
> > Flexibilisierung in Zukunft nur noch durch geordnete 
> > Veränderungsprozesse in großer Skalierung (Multinationale Konzerne) 
> > handhabbar. Hier wird es für die Unternehmen immer essentieller die 
> > Meinungen und Bedürfnisse der Belegschaft ermitteln zu können. Das 
> > ist der konkrete Anwendungsfall in der Wirtschaft. Macht was draus ;o)
>
> Schon wieder "Macht was draus". Wer sagt, dass ich was machen will? Ich
> werde morgen in die Karibik fahren und mich in die Hängematte legen. So
> sieht das aus!
> Und wenn ich wieder da bin, ist hoffentlich die
> Prototype-Plugin-Ontology-International-Discussion-Standard-UML-Machine
> fertig gebaut!
>
> Cheers,
> Frauke
>
> > Cheers
> > marc
> >
> > P.S. @Alex: Ich bin Micro$oftie und habe mit Java nix am Hut...
> >
> >
> > -----Original Message----- From: Alexander Praetorius
> > Sent: Sunday, January 27, 2013 2:03 PM
> > To: Piraten AG Meinungsfindungstool
> > Subject: Re: [Ag Meinungsfindungstool] qKonsens, Probble, 
> > fundiert-entscheiden, d!sco und der Common Discussion Standard (CDS*)
> >
> >
> > 2013/1/27 Frauke Mattfeldt <mattfeldt AT karten-verlag.de>
> >
> >
> > 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:
> >
> >
> >
> > 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.
> >
> >
> > [alex]
> > Ist doch ok. Verlangt niemand.
> > Ich hab blos versucht zu erklären worum es geht.
> > Nicht jedem macht jede Art von Arbeit spaß.
> > [/alex]
> >
> >
> > Es sei denn ihr bezahlt mich dafür.
> >
> >
> > [alex]
> > Wer wünscht sich das nicht.
> > Unser System ist leider totally broken :-)
> > Das ist überhaupt der eigentliche Grund für die Piratenpartei.
> > Die einzige Chance das zu beheben ist irgendwie Basisdemokratie an 
> > den Start zu bekommen.
> >
> > Ich habe angefangen bei MehrDemokratie e.V. und kurz danach bei Liqd 
> > e.V. und habe Adhocracy als Softwaretool ausprobiert.
> > Danach war ich bei Occupy und habe dort Adhocracy, Bettermeans.org, 
> > und diverse Projektmanagementtools, darunter auch Redmine ausprobiert.
> >
> > Als nächstes bin ich dann zu metagovernment.org und dort immer noch 
> > aktiv.
> > Votorla macht super Fortschritte und wird vielleicht wesentlich 
> > schneller das Ziel erreichen, das die AG MFT ebenfalls anstrebt.
> > Dort habe ich diverse Prototypen, unter anderem das Tool "Vilfredo 
> > goes to Athens", aber insgesamt bestimmt mehr als ein dutzend Tools 
> > ausprobiert und viele weitere überflogen.
> >
> > Jetzt bin ich bei den Piraten und schaue mir die Nutzung von LQFB an 
> > und von den Tools 
> > Wiki,Forum,Mailingliste,Etherpads,Mumble,Antragserstellungstool 
> > usw... in Kombination.
> >
> > Und du programmierst Probble. Dann gibt es da noch 
> > fundiert-entscheiden.de
> >
> > Ich habe mit einigen Studenten in Frankfurt am Main eine Initiative 
> > für Entrepreneurship gegründet und dementsprechend tauchen auf meinem 
> > Schirm ständig Startups auf und da ist alle paar Wochen mal eins 
> > dabei das irgendwie ein Projektmanagementtool bzw. ein 
> > Diskussionstool aufpoppen lässt um ganz simple Probleme zu lösen.
> >
> > Jedes Tool hat leicht unterschiedliche Einsatzorte und Hintergründe.
> >
> > SO, DAS IST DER GRUND WARUM ICH KEINE LUST HABE EINFACH IRGENDEIN 
> > TOOL MAL EBEN SO ZU PROGRMAMIEREN.
> >
> > Ich hab gesehen wie Progrmamierer Zeit in Tools stecken.
> > Du sagst die Realität weckt dich und die ist ja ach so hart und es 
> > gibt kein Geld und Kunden wollen alles umsonst und so... kann ich was 
> > dafür? Kann die AG was dafür? Denkst du das ist unter anderem ein 
> > Phänomen warum es Piraten gibt??
> >
> > Die AG hat keine Mittel um dich bezahlen zu können. Aber wir sitzen 
> > alle mehr oder weniger im gleichen Boot.
> > Ich glaube der Ansatz einfach ein Tool zu programmieren wird nicht 
> > weit führen.
> > Was genau kann Probble, was nicht auch mit Adhocracy möglich wäre?
> > Was kann Probble das nicht mit LQFB funktioniert?
> >
> > Kann ich das was Probble kann nicht auch mit einfachen Tools 
> > simulieren? (Wiki, Malingliste, Doodle, Umfragetools, usw... + ein 
> > bisschen Disziplin in der Benutzung?)
> >
> > Glaubst du Piraten werden sich MASSENHAFT bei Probble anmelden und es 
> > ausprobieren?
> > Wie sind da deine bisherigen Erfahrungen?
> > Was glaubst du sind die Gründe dafür das es noch nicht so läuft wie 
> > du hoffst? Ist die Welt daran schuld?
> > Vielleicht bin ich auch schon durch so bittere Einsichten gegangen 
> > wie du. Es ist nicht so leicht.
> > [/alex]
> >
> >
> >
> > 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.
> >
> >
> > [alex]
> > Glaube nicht das ich sowas gesagt habe. Verstehe nicht in welchem 
> > Zusammenhang
> > [/alex]
> >
> >
> > 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
> >
> >
> > [alex]
> > Ja, das befürchtest du und ich kann dir da auch wenig zu sagen.
> > Als HTML von Tim Berners Lee erfunden wurde oder als XML als Standard 
> > ausgearbeitet wurde. Hättest du das auch sagen können. Hast du 
> > schonmal XML geparst bzw. in irgendeiner Form genutzt? Oder JSON? 
> > oder sonstige Standards?
> > Was wäre wenn es die nicht gäbe??
> > Unter Umständen hängt der Erfolg des Webs GENAU damit zusammen, dass 
> > es diese Standards gibt.
> > Ohne diese Standards gäbe es nur ein Internet in dem jede Anwendung 
> > ihre eigenen Methoden hätte um über das WAN zu anderen Computern zu 
> > verbinden.
> > Das wäre ja super... Am besten brauchen wir auch kein TCP/IP 
> > Protokoll, kann sich doch jeder sein eigenes Protokoll ausdenken.
> >
> > Du bist grade irgendwie frustriert, aber du musst es nicht an der AG 
> > ablassen.
> > Die kann auch nichts dafür das die Welt hart und ungerecht ist.
> > [/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.
> >
> >
> > 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.
> >
> >
> > [alex]
> > :-)
> > Ja und Nein.
> > Du hast Recht, aber woran liegt das? Es liegt an unserem allseits 
> > geliebten "Broken System". Denkst du etwa diejenigen die Mittel 
> > hätten für solche Entwicklungsarbeit bezahlen zu können hätten ein 
> > Interesse? Nein. Die sind zufrieden und verstehen nicht warum es 
> > sowas braucht.
> > Die Zielgruppe der Software sind vorallem jene, die meinetwegen viele 
> > Bedürfnisse haben, aber nicht die finanziellen Mittel um daraus 
> > Bedarf zu machen.
> > Es gibt leider niemanden der solche Entwicklungsarbeit bezahlen könnte.
> >
> > Jeder tut das was er kann und von dem er glaubt das es weiterhilft.
> > Diejenigen die zuschauen tun vielleicht andere wichtige Arbeit, 
> > zumindest aber sitzen sie bis es eine tolle Lösung gibt im gleichen 
> > Boot und kommen nicht voran.
> >
> > Nicht jeder ist in jeder Entwicklungsmethode so wirklich Firm.
> > Marc ist Javaentwickler.
> > Du arbeitest mit PHP.
> > Ich bin ex-Java und versuche auf Javascript only umzusteigen, denn 
> > das bietet die größte Flexibilität.
> > [/alex]
> >
> >
> >
> >
> >
> > 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.
> >
> >
> > [alex]
> > Das ist der Hintergrund von Open Source.
> > Wir sind hier nicht in der Wirtschaft wo es um Geld geht.
> > Geld ist hier keins vorhanden, nur Bedürfnisse und die Vision die 
> > Verhältnisse zu ändern.
> > Es gibt nicht beides.
> > Entweder du machst das woran du glaubst, wirst mies bezahlt, aber 
> > hast die Chance am Wandel mitzuwirken, oder du orientierst dich am 
> > Geld und bewirbst dich auf Jobs in denen du Anforderungen vorgesetzt 
> > bekommst und dafür auch gut bezahlt wirst.
> > Von dem Geld kannst du dann gut leben und das solange bis du ersetzt 
> > wirst oder aus anderen Gründen rausfliegst. ...naja, du musst es 
> > selber wissen.
> > Wenn du nicht an OPEN SOURCE glaubst bist du bei den Piraten falsch.
> > [/alex]
> >
> >
> >
> >
> > 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.
> >
> >
> > [alex]
> > Ich kenne unglaublich viele Menschen die in der gleichen Situation sind.
> > Broken System und so.... sorry, mein Beileid (auch wenn das nicht 
> > satt macht)
> > [/alex]
> >
> >
> > 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.
> >
> >
> > [alex]
> > Bevor man etwas programmiert muss man sich überlegen WAS man 
> > programmierne will.
> > Wenn du einfach drauflosprogrammierst und dann anpasst, dann ist das 
> > einfach eine andere Art zu denken. Du lernst dann beim machen, und 
> > programmierst 10 mal neu, verwirfst oder machst weiter. Während 
> > diejenigen die diskutieren eben konzeptionell dabei lernen.
> > Beide Methoden sind gut.
> > Votorola zb. macht beide Methoden parallel.
> > Dahin müssen wir meiner Meinung nach auch kommen.
> >
> > Ein Tool im Alleingang zu programmieren ist leicht. Du kannst alle 
> > Entscheidungen treffen.
> > Das Risiko ist das es hinterher keiner nutzt.
> > Ein Tool im Konsens mit den späteren Nutzern zu entwickeln ist etwas 
> > anderes.
> >
> > Wenn du darauf Lust hast, wäre ich dabei.
> > Wir tingeln durch die AGs und fragen sie nach ihren Arbeitsmethoden, 
> > interviewen und nehmen Anforderungen auf. Deal?
> > Auf Grundlage solcher Anforderungen zu entwickeln wäre ich bereit.
> >
> > Nebenbei kann man sehen wie man dabei Standards aus diesem Projekt 
> > generiert oder an theoretische Überlegungen anpasst.
> > [/alex]
> >
> >
> >
> >
> > Du sprachst vom App-Store: Du willst die Tools also künftig in einem 
> > App-Store anbieten?
> >
> >
> > [alex]
> > Das Framework wird eine Art kostenloser App-Store sein.... zb. wie 
> > bei Browser Extensions.
> > Plugins kann man dazuschalten oder entfernen.
> > [/alex]
> >
> >
> >
> > 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.
> >
> >
> > [alex]
> > Angebot wäre Anforderungen im Interview mit AGs aufzunehmen.
> > Wenn du weitere Zielgruppen siehst die sogar kaufen würden, kann man 
> > die auch interviewen. Meinetwegen geht man den Startupweg für so ein 
> > Projekt.
> >
> > Das heisst wir beginnen mit einem BUSINESS MODEL CANVAS und dem 
> > sogenannte CUSTOMER DEVELOPMENT PROCESS :-) ...Das heisst Kunden bzw. 
> > spätere Nutzer so lange interviewen bis man versteht was die brauchen.
> >
> > Ich sehe nur 2 sinnvolle Wege.
> > 1. Standards entwickeln um verschiedenste Toolentwickler in ein Boot 
> > zu holen.
> > 2. Nutzer/Kunden kennenlernen und auf dieser Basis vorpreschen 
> > (Standards folgen später)
> > [/alex]
> >
> >
> >
> > Und: Wenn es tausend Tools gibt, wieso habt ihr nicht schon längst 
> > die genommen und mal damit angefangen einen Standard zu bauen?
> >
> >
> > [alex]
> > Jedes Tool ist anders und keins überzeugend.
> > Nutzt man ein Tool hat man sofort den LOCK IN Effekt. Man kann nicht 
> > einfach das Tool wechseln ohne alle Nutzer zu verlieren die mit einem 
> > das Tool nutzen.
> > Alle müssten wechseln und man ist darauf angewiesen welche Features 
> > die Entwickler bereit sind zu implementieren.
> >
> > Ja, ich habe schon echt viele Gespräche mit Entwicklern hinter mir um 
> > die zu fragen warum sie nicht kooperieren usw.. usw... tja, deren 
> > Argumente waren so ähnliche wie deine.
> > [/alex]
> >
> >
> > 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?
> >
> >
> > [alex]
> > Seit einem Jahr maximal.
> > Am Anfang stand nichts und erstmal die Frage worum es hier überhaupt 
> > gehen soll.
> > Wenn du keinen Fortschritt siehst kann ich dazu nichts sagen.
> > Keiner macht das hier 24/7 Hauptberuflich und ein Markt gibt es für 
> > solche Systeme nicht, weil keiner der sie gerne hätte das Geld zum 
> > bezahlen hat.
> > Trotzdem könnte man sich die Mühe machen zu suchen ob es nicht doch 
> > einen Markt gibt und ein Business Model für so ein Tool
> > [/alex]
> >
> >
> > 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.
> >
> >
> > [alex]
> > Hättets du auch nicht. Es gibt schon 1000ende von Tools.. naja 
> > zumindest 100derte.
> > Du hattest halt deine eigene Idee wie das aussehen soll.
> > Und den qKonsens gibt es so direkt auch noch nicht als Tool.
> > Insofern ist das doch cool :-)
> > [/alex]
> >
> >
> >
> >
> >
> > 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?
> >
> >
> > [alex]
> > Ja, verbreitete Sichtweise. Genau das haben die 100derten Tools die 
> > alle kaum Userbase hatten auch gesagt. Der Ansatz lohnt sich maximal 
> > dann, wenn man konkrete zahlende Kunden hat, ansonsten kommt man 
> > wahrschienlich nicht sehr  weit.
> > Sich auf gemeinsame Standards zu einigen ist hingegen eine 
> > kooperative Methode.
> > Das was du als Sichtweise gegeben hast ist die kurzsichtige Sicht, 
> > nach der die meisten agieren und die automatisch zu Konkurrenz führt, 
> > egal ob du oder andere das wollen oder nicht.
> > [/alex]
> >
> >
> >
> > 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.
> >
> >
> > [alex]
> > Das sind doch schon 3. Ist doch nicht so schlecht.
> >
> > Nochwas, ich bin inzwischen der Meinung, dass Grundlage eines 
> > konkreten Tools ein Mediawiki sein sollte das man aufbohrt (zumindest 
> > muss das Tool zu einem Wiki kompatibel sein)
> > Diesen Ansatz verfolgt Votorola.
> > Auch fundiert-entscheiden.de ist ein Wikiansatz.
> > Die Piraten benutzen als zentrales System das Wiki.
> >
> > Jedes Tool, das nicht auf diese Technologie aufsetzt wird zum 
> > Inseldasein verdammt bleiben.
> > Nutzt man das Wiki als Grundlage, so hat man zumindest schonmal einen 
> > Standard der defacto sehr weit verbreitet ist.
> >
> > Kannst du dich also auf Mediawiki einlassen und auf Javascript? :-)
> > [/alex]
> >
> >
> >
> >
> >
> > 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.
> >
> >
> > [alex]
> > Wo hast du denn das her, dass angeblich PiratenLQFB Zugänge käuflich 
> > wären.
> > Da glaube ich nicht dran. Das wäre ja auch extrem alamierend.
> > [/alex]
> >
> >
> >
> > 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.
> >
> >
> > [alex]
> > Niemand zwingt dich zum implementieren von Standards wenn du nicht an 
> > diese glaubst.
> > Ich glaube selber auch nicht so sehr an den DISCO Ansatz per se, 
> > sondern an die Zusammenarbeit mit konkreten anderen Tools und dem 
> > einigen auf Standards :-)
> > Das heisst wir brauchen ein konkretes eigenes Tool oder mehrere und 
> > müssen uns AKTIV mit anderen Tools abstimmen um uns kompatibel zu 
> > machen.
> >
> > Wärst du bereit dich mit nodeJS auseinanderzusetzen und auf Basis von 
> > reinem Javascript ein Tool aufzubauen?
> > Da wäre ich sofort dabei.
> > [/alex]
> >
> >
> >
> >
> >
> > 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.
> >
> >
> > [alex]
> > WTF?!?
> > Wo hab ich gesagt die Tools sollen sich um Spenden kümmern? Kann mich 
> > niemals erinnern das es dazu irgendne Diskussion gab und in welchem 
> > Zusammenhang das gewesen sein soll.
> > Du hast nicht gefragt was das programmieren des Javascriptanteils 
> > angeht.
> > Ich wusste nicht das es da was zu tun gibt.
> >
> > Ich bin außerdem nicht davon überzeugt einfach irgendein TOOL zu bauen.
> > Wenn, dann entweder aufgrundlage von abgesprochenen Standards und 
> > Konzepten, ODER aufgrundlage eines CUSTOMER DEVELOPMENT PROCESS, also 
> > konkrete spätere Anwender interviewen und auf Grundlage des Feedbacks 
> > das Tool voranzutreiben.
> >
> > Gerne auch potentiell zahlende Nutzergruppen.
> > Du bist so eine Motzliese manchmal :-) Sprich doch einfach mit mir.
> > [/alex]
> >
> >
> >
> >
> > 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.
> >
> >
> > [alex]
> > Hmm, vielleicht hast du Recht. Ich bin der Meinung durch die 
> > jahrelange Beschäftigung mit dem Thema, das ich einen ganz guten 
> > Einblick habe was für Tools es gibt und welche nicht.
> > Man könnte tatsächlich ein Startup daraus machen, aber dazu müsste 
> > man natürlich klären wo Bedarf (Kaufkraftgestützte Bedürfnisse) für 
> > so ein Tool bestehen.
> >
> > Prinzipiell natürlich innerhalb von Unternehmen, aber da hängt dann 
> > mehr dran als nur Basisfeatures. Das könnte man aber als 
> > Ausgangspunkt nehmen um eine kostenlose Open Source Basisversion 
> > anzubieten :-)
> > Die über die Businesskunden generierten Revenuestreams kann man 
> > nutzen um die Entwicklung von Standards voranzutreiben.
> > Ich bin überzeugt vom Open Source Gedanken und erkläre dir auch 
> > gerne, warum Open Source im Freemium Sinn im Grunde im Business Fall 
> > nichts anderes ist als eine kostenlose 30-Tage-Tetsversion ;-)
> > [/alex]
> >
> >
> >
> >
> > 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?
> >
> >
> > [alex]
> > :-)
> > Ja ich verstehe. Du hast kein Geld. Ich hab kein Geld. Alle haben 
> > kein Geld und die die Geld haben sparen es. Bleibt nur der Weg zum 
> > Entrepreneur zu werden und das Hobby zum Beruf zu machen. Wenn du 
> > Lust hast Skypen wir mal.
> > Mir geht es nicht um ein Freelancerdasein bzw. Einzelunternehmer 
> > sondern um Startup.
> > Das heisst den Aufbau eines Unternehmens aus einer Idee heraus die 
> > "Weltverbesserungspotential" hat ;-)
> > Ist machbar, aber speziell bei der Frage "Diskussionstool" habe ich 
> > kaum eine Idee wie man das monetisieren könnte.
> > Diejenigen die eins brauchen können sind meist von ihren 
> > Anforderungen so aufgestellt, dass es den basisdemokratischen 
> > Grundgedanken korrumpiert. Das machtes echt schwierig.
> > ...aber vielleicht nicht unmöglich. Prinzipiell könnten Parteien 
> > interessiert sein und NGOs. Man muss sich mal umhören und interviewen.
> > Vorher sollten wir uns aber mal kurz darüber unterhalten welche 
> > grundlegenden Features du essentiell findest und wie du dir ein 
> > solches Tool vorstellst.
> >
> > Probble fand ich bei weitem nicht überzeugend von der Benutzbarkeit.
> > qProbble hab ich nohc nicht angeschaut.
> > Lass doch mal bei Gelegenheit Skypen
> > [/alex]
> >
> >
> >
> >
> >
> > 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.
> >
> >
> > [alex]
> > Das ist nicht nur interessant sondern meiner Meinung nach ein 
> > essentiell wichtiges Feature.
> > [/alex]
> >
> >
> > 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...
> >
> >
> > [alex]
> > Ich hätte auch Lust mal ein bisschen zu programmieren und damit 
> > Fakten zu schaffen statt immer nur rumzulabern ;-)
> > Das von dir oben genannte Feature ist mir aber wichtig.
> > "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."
> >
> > Das muss von Anfang an dabei sein, UND:
> > Das Tool muss sowohl auf einen Server, als auch auf einem normalen 
> > Desktoprechner ganz simpel laufen können. (zb. auch als Browserplugin)
> >
> > Also die Auswahl der zugrundeliegenden Technologie halte ich für 
> > wesentlich und PHP ist da nichts in dem ich irgendwie viel Sinn sehe.
> > Wenn du Lust hast und ernsthaft überlegen magst wie man mit oder ohne 
> > Piraten aus sowas Geld machen kann und ein Startup hochzieht, dann 
> > lass uns mal skypen.
> > [/alex]
> >
> >
> >
> >
> >
> >
> > 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)