[Talk-de] Workshop - Zielsetzung

[Frederik Ramm]

Hallo,

    prima, dass Sven das in die Hand nimmt mit der Workshop-Planung.

Ich wollte eben auf die Wikiseite einen Passus ueber "Zielsetzung" 
einfuegen, aber dann dachte ich, das waere doch etwas vermessen von mir, 
meine Vorstellung einfach so da hin zu schreiben - daher mal hier.

Meiner Ansicht nach kann so ein Workshop-Wochenende zwei ganz 
unterschiedliche gute Ergebnisse haben:

1. Die Leute lernen sich mal persoenlich kennen und wissen fortan auf 
der Mailingliste besser einzuschaetzen, was der andere meint (und dass 
er doch nicht so ein Idiot ist, wie man immer dachte, oder so ;-). Man 
weiss, wen man mal schnell anmailen kann, wenn es ein bestimmes Problem 
gibt, oder wen man am ehesten zum Mitmachen bei einem Miniprojekt 
bewegen kann - das ist Oel im Projekt-Getriebe.

2. Man arbeitet konzentriert an konkreten Problemen und kriegt sie 
geloest, oder legt zumindest den Grundstein dafuer, sie in den Wochen 
nach dem Workshop zu loesen.

Beides ist weitgehend unabhaengig voneinander moeglich, aber beides 
konkurriert natuerlich um die Zeit bei so einer Veranstaltung - waehrend 
man konzentriert am Problem arbeitet, lernt man nicht die anderen 
kennen, die konzentriert im Raum nebenan an einem anderen Problem 
arbeiten. Ich bin kein erfahrener Konferenz-Organisator, aber ich denke 
mal, die richtige Balance zu finden, gehoert irgendwie zum Programm dazu.

Aus diesem Wettbewerb um die Zeit ergibt sich auch der "worst case": 
Naemlich, dass wir die Gelegenheit zum Kennenlernen versaeumen, weil 
jede Gruppe verbissen an ihrem Workshopthema haengt, zugleich am Ende 
aber nichts produziert ausser einem Wunschzettel ("die Renderer sollten 
A, die Editoren sollten B, die Mapper sollten C, und dann wuerde alles 
gut werden!").

Ich wuerde mir wuenschen, dass die einzelnen Workshops, wo immer das 
inhaltlich moeglich ist, ein relativ autonomes Ergebnis erzielen - 
irgendwas, was sie selbst vorbereiten und umsetzen. Das Ergebnis von so 
einem Workshop sollte sein: "WIR finden dies, WIR machen jetzt jenes, 
und WIR kuemmern uns drum, dass die Software angepasst wird, damit das 
auch alles geht". Schlimmstenfalls faehrt das Team damit irgendwann an 
die Wand, weil es irgendwas falsch eingeschaetzt hatte, aber dann haben 
wenigstens alle gelernt, wie es nicht geht. Ich denke, so ein Workshop 
hoert nicht am Sonntag mittag auf - ich finde es wichtig, dass jeder, 
der bei so einem Workshop mitmacht, auch die Verantwortung mit 
uebernimmt, dass die Ergebnisse umgesetzt werden. Das ist jetzt meine 
ganz persoenliche Meinung, aber *ich* wuerde formulieren: Wir suchen 
keine Leute, die mal fuer ein Wochenende vom Olymp herabsteigen und uns 
ihre tollen Ideen offenbaren, sondern Leute, die ernsthaft auch ueber 
das Wochenende hinaus an dem Thema weiterarbeiten wollen.

Es muss ja nicht am Wochenende selbst irgendein vorzeigbares Programm 
entstehen. Aber nur funktionierender Code hat in diesem Projekt 
Autoritaet. Wenn wir uns hinsetzen und das tolle neue Tagging-Schema 
fuer Innenstadt-Barbecues entwickeln und dazu eine Wikiseite schreiben, 
ist das genausowenig "beschlossen" oder "gueltig" wie irgendein 
Proposal, das ein Newbie einen Tag spaeter schreibt. Wenn nichts 
Greifbares herauskommt, dann wird jedes Diskussionsergebnis schon nach 
wenigen Wochen wieder im Rauschen der Mailingliste verpuffen.

Vielleicht waere es gut, wenn jeder Workshop eine klare Zieldefinition 
haette. "In diesem Workshop wollen wir dies und das Problem loesen. Ziel 
ist, bis <zum Ende des Wochendes|zum Monatsende|zum Jahresende> dies und 
jenes zu erreichen." - Wobei man natuerlich aufpassen muss, nicht zu 
sehr einzuschraenken, worum es geht - eventuell hat ja einer der 
Teilnehmer gleich zu Anfang eine so umwerfende Idee, dass man alles ganz 
anders machen will.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"