Re: [Ag Meinungsfindungstool] Ideenfindung vs. Meinungs-/Entscheidungsfindung und darüber hinaus

[Slash <pirate_slash AT yahoo.com>]

Aber, aber; nicht so beißlustig, Leute.

Ich persönlich befürworte ebenfalls Tagging. Aber wenn man Kategorien
macht, ist es doch naheliegend, die gleichen Kategorien zu verwenden,
die schon beim Bundes-LQFB existieren, also:

http://oi45.tinypic.com/o55lqg.jpg

Mir ist bei dem Thema Kategorien wichtig, das nichts ausgeschlossen
wird und keine Ideologie reinspielt; was ich sehr ungern sehen
würde wäre, wenn aus der Summe der Kategorien hervorginge,
dass das Diskussionssystem nur Anträge produzieren soll, und kein
Raum für offene philosophische Fragen gelassen wird.
Das ist mir eigentlich dahingehend das wichtigste:
Das strukturell jeder Frage Raum gelassen wird...

Ansonsten bitte ich, wieder zurück zum Thema zu gelangen.

Dazu werde ich mal die imho wichtigsten Abschnitte zitieren und
mein Feedback zu diesen geben.

Karsten Weihe schrieb:

> Mein Gedanke dahinter ist: Wenn wir noch mehr als bisher Systeme nach
> ihren Intentionen differenzieren, dann erübrigen sich wahrscheinlich
> die meisten kontroversen Diskussionen. Und die Gemeinsamkeiten kommen
> klarer heraus, denn verkürzt gesagt: Für zwei Systeme derselben
> Kategorie muss man Input mit Input und Output mit Output vergleichen.
> Für zwei Systeme, so dass A auf B aufbaut, muss der der Output von B
> mit dem Input von A verglichen werden.

Karsten Weihe schrieb:
> 1. Tools A und B erfüllen dieselbe Intention. Dann sind Inputs von A
> mit Inputs von B bzw. Outputs von A mit Outputs von B in
> Übereinstimmung zu bringen.
>
> 2. Die Intention von Tool A folgt im Meinungsbildungsprozess auf die
> Intention von Tool B, dann sind Outputs von B mit Inputs von A in
> Übereinstimmung zu bringen.

Das versteh' ich irgendwie nicht ganz.
Nehmen wir mal an, die Diskussion muss prozessualer betrachtet werden
und in diesem Zusammenhang kommt A vor B...
wäre es dann nicht logischer, dass die prozessübergreifende
Abstimmung zwischen den Tools - falls man denn sowas will - dann
zwischen As Output und Bs Input erfolgt ?

Der Ablauf wäre ja folgender:

A Input >>> A Output >>> B Input >>> B Output

Dieser Übergriff, dass man As Input mit B Output abgleicht, ist für
mich gerad' logisch nicht nachvollziehbar

So, und grundsätzlich:
Ich muss sagen, dass ich mir da nicht so sicher bin, ob ein
prozessübergreifender Abgleich so gut ist...
ich halte es für wichtig, die Entwickler bei der Entwicklung ihrer 
Plug-ins so wenig wie möglich in irgend eine Richtung zu zwängen.

Aber auch ich hab' im Verlaufe der Zeit festgestellt, dass sich der
Diskussionsprozess in mehrere Abschnitte gliedert; ich bin dahingehend
bislang zu folgendem Ergebnis gekommen:

Diskussions-Prozess = ]Informieren[ ->*Offene 
Fragen/Erörtern(fundiert-entscheiden.de) -> 
Ja/Nein-Fragen/Argumentieren(wikiarguments) -> Positionsbildung(votorola) 
-> Entscheidungsbildung(votorola) ->* ]Beschluss(LQFB)[

Aber ich muss auch ehrlich gesagt sagen:
Unabhängig von diesen Gedanken hab' ich meine Zweifel, dass
sich solche Überlegungen erwähnenswert in der Praxis niederschlagen.
Jedes Plug-In benutzt eine spezifische Gruppe an Entitäten, die
Teilmenge des Frameworks ist.
Wenn 2 Plug-ins die gleiche Entität verwenden, nutzen sie gemeinsam
die Daten jener Enität, die durch den Input beider Plug-Ins anfallen;
und das unabhängig von prozessualen Betrachtungen; und wenn nicht,
dann nicht.

Ja, so ist das halt...

und seitens des Nutzers hat man eine Oberfläche mit z.B. 5 Knöpfen,
von denen jeder für ein Plug-In steht, und der Nutzer schaltet weiter,
wie es ihm richtig erscheint.
Bei Kenntnis über die Funktionsweise mehrerer Plug-Ins kann jene
Entscheidung durchaus sich aus prozessualen Abwägungen heraus
entwickeln...

ja, und... so ist das halt...

also, ich seh' da wenig Spielraum und Nutzen darin, die Plug-Ins
prozessual in einander zu verzahnen (das mein' ich wertungsfrei);
als höchstes der Gefühle könnt' ich mir noch vorstellen, dass man
jene Erkenntnisse über die unterschiedlichen Prozess-Phasen in
die Gliederung der Knöpfe einfließen lässt.

Ich bleib' mal bei besagtem Beispiel:

Nicht:
Plug-In A - Plug-In B - Plug-In C - Plug-In D - Plug-In E

Sondern:

Diskussions-Phase 1:
Plug-In C - Plug-In E

Diskussions-Phase 2:
Plug-In A - Plug-In D

Diskussions-Phase 3:
Plug-In B

Aber das ist ja jetzt keine sehr intensive prozessuale
Querverbindung zwischen den Plug-Ins (oder doch ?)

Viele Grüße,
/ aka Oliver