Vermeidung Häufiger Fallstricke

Schreiben Sie Nicht Ohne Sinn

Eine häufiger Fehler bei der Beteiligung an einem Online Projekt ist zu denken, dass Sie auf alles reagieren müssen. Das müssen Sie nicht. Erstens wird es für gewöhnlich mehr Threads geben, als worüber Sie den Überblick behalten können, zumindest nachdem das Projekt die ersten paar Monate überschritten hat. Zweitens wird das meiste von dem was in den Threads geschrieben wird, für die Sie sich entschieden haben sie mit zu verfolgen, keine Antwort erfordern. Gerade Entwicklerforen neigen dazu von drei Arten von Nachrichten beherrscht zu werden:

  1. Nachrichten die etwas nicht triviales vorschlagen

  2. Nachrichten die Unterstützung oder Widerstand für oder gegen etwas ausdrücken was jemand anderes gesagt hat

  3. Zusammenfassende Nachrichten

Von diesen erfordert keiner an und für sich eine Rückmeldung, insbesondere wenn Sie sich auf der Grundlage von dem was Sie bisher in dem Thread gesehen haben, sicher sein können, dass jemand anderes wahrscheinlich sowieso das sagen wird, was Sie eh gesagt hätten. (Wenn Sie sich sorgen machen, dass Sie in einer Schleife gefangen werden, bei dem jeder auf den anderen wartet, weil sie die gleiche Taktik verfolgen, sollten Sie es nicht; es gibt fast immer irgend jemand der das Bedürfnis hat sich in die Schlacht zu stürzen. Fragen Sie sich erstens: Wissen Sie was Sie erreichen wollen? Und zweitens: Wird dieses Ziel nicht erreicht werden, ohne dass Sie etwas sagen?

Zwei gute Gründe Ihre Stimme bei einem Thread einzulegen, sind a) wenn Sie einen Fehler in einem Vorschlag sehen, und vermuten, dass Sie die einzige sind, die es sieht, und b) wenn Sie sehen, dass in der Kommunikation etwas schief läuft und Sie wissen, dass Sie es richten können indem Sie eine klärende Nachricht schreiben. Es ist im allgemeinen auch in Ordnung eine Nachricht zu schicken, nur um jemanden für etwas zu danken, oder um "Ich auch!" zu sagen, da ein Leser bei solchen Nachrichten sofort erkennen kann, dass sie keiner weiteren Antwort oder Handlung bedürfen und deshalb endet die geistige Anstrengung die sie erfordern sauber mit der letzten Zeile der Email. Selbst dann sollten Sie zwei mal darüber nachdenken, vor Sie etwas sagen; es ist immer besser Menschen wünschen zu lassen, dass Sie mehr schreiben, als dass die weniger schreiben. (Siehe den zweiten Teil von Anhang C, Warum sollte es mich kümmern, welche Farbe der Fahrradschuppen hat? für weiteres darüber wie man sich auf betriebsamen Email Verteilern verhalten soll.)

Produktive kontra Unproduktive Threads

Auf einem betriebsamen Email Verteiler haben Sie zwei Pflichten. Eines ist offensichtlich herauszufinden, worauf Sie achten müssen und was Sie ignorieren können. Das andere ist, sich derart zu verhalten, dass Sie es vermeiden Rauschen zu erzeugen: Sie wollen nicht nur, dass Ihre eigene Nachrichten ein hohes Signal/Rausch Verhältnis haben, sondern, dass Sie die Art von Nachrichten sind, die andere dazu anregen entweder Nachrichten mit einem ähnlich hohen Signal/Rausch Verhältnis zu schreiben, oder überhaupt nicht zu schreiben.

Um zu sehen wie Sie das erreichen können, lass uns den Kontext bedenken in dem es gemacht wird. Was sind einige der Ecksteine von unproduktiven Threads?

  • Argumente die bereits aufgeworfen wurden fangen an wiederholt zu werden, als ob der Absender denkt, dass keiner sie beim erstem mal gehört hat.

  • Eine Zunahme an Übertreibung und Beteiligung während die der Einsatz immer kleiner wird.

  • Eine Mehrheit der Kommentare stammt von Personen die wenig oder gar nichts machen, während diejenigen die dazu neigen Sachen erledigt zu bekommen ruhig sind.

  • Viele Ideen werden diskutiert, ohne dass klare Vorschläge gemacht werden. (Natürlich fängt jede interessante Idee als eine ungenaue Vision an; die wichtige Frage ist welche Richtung sie von da an einschlägt. Erscheint es so als ob der Thread die Vision in etwas konkreteres verwandelt, oder schweift es ab in unter Visionen, neben Visionen und Auseinandersetzungen über Grundsatzfragen?)

Nur weil ein Thread an Anfang nicht produktiv ist, bedeutet es nicht, das es eine Zeitverschwendung ist. Es kann sich um ein wichtiges Thema drehen, bei dem die Tatsache, dass es nicht vorankommt um so beunruhigender ist.

Einen Thread in eine nützliche Richtung zu führen, ohne aggressiv zu sein, ist eine Kunst. Es wird nicht funktionieren, Leute einfach abzumahnen, ihre Zeit nicht zu verschwenden, oder Sie darum zu bitten nicht zu schreiben, es sei denn Sie haben etwas konstruktives beizutragen. Es mag natürlich sein, dass Sie das privat denken, aber wenn Sie es laut sagen, werden Sie beleidigend sein. Statt dessen, müssen Sie Bedingungen für den weiteren Fortschritt vorschlagen— geben Sie den Leuten eine Route, einen Weg welcher zu den Ergebnissen führt, die Sie haben wollen, jedoch ohne dass Sie sich anhören, als würden Sie das Verhalten Diktieren. Der Unterschied liegt größtenteils im Ton. Folgendes ist zum Beispiel schlecht:

Diese Diskussion führt nirgendwo hin. Können wir bitte dieses Thema so lange fallen lassen, bis jemand einen Patch hat, um einen der Vorschläge zu implementieren? Es hat keinen Sinn immer wieder die gleichen Sachen zu sagen. Code spricht lauter als Worte, Leute.

Wohingegen folgendes gut ist:

Verschiedene Vorschläge wurden in diesem Thread gemacht, bei keinem wurden aber die Details ausgearbeitet, zumindest nicht so weit um darüber abzustimmen. Trotzdem sagen wir derzeit nichts neues; wir wiederholen einfach nur was vorher schon gesagt wurde. Derzeit wäre es also wahrscheinlich das beste, wenn die folgenden Nachrichten entweder ausgearbeitete Vorschläge beinhalten, oder einen Patch. Dann hätten wir wenigstens etwas festes worauf wir reagieren könnten (d.H. Konsens über den Vorschlag erreichen oder den Patch anwenden und Testen).

Vergleichen Sie die zweite Herangehensweise mit der ersten. Die Zweite zieht keinen Strich zwischen Ihnen und die anderen, noch beschuldigt es Sie die Diskussion zu verzetteln. Es ist die Rede von "wir", was wichtig ist, ob Sie vorher tatsächlich an dem Thread beteiligt waren oder nicht, da es alle daran erinnert, dass selbst diejenigen die bisher ruhig geblieben sind, trotzdem noch einen Anteil an seinem Ausgang haben. Sie beschreibt warum der Thread nirgendwo hinführt, macht es aber ohne Abwertungen oder Verurteilungen —es hält lediglich leidenschaftslos einige Tatsachen fest. Am wichtigsten, bietet es eine positive Vorgehensweise an, damit die Leute nicht das Gefühl bekommen, als würde die Diskussion abgebrochen werden (eine Maßnahme gegen der man nur versucht sein kann zu rebellieren), sondern als ob Ihnen eine Möglichkeit angeboten wird die Unterhaltung auf eine konstruktivere Ebene zu führen. Das ist ein Standard den Leute natürlich erfüllen werden wollen.

Sie werden nicht immer wollen, dass ein Thread es auf die nächste höhere konstruktive Ebene schafft—manchmal werden Sie einfach nur wollen das er verschwindet. Der Sinn von Ihrer Nachricht ist dann, das eine oder das andere herbeizuführen. Wenn Sie schon an der Art wie der Thread bisher verlaufen ist, erkennen können, dass keiner die von Ihnen vorgeschlagenen Maßnahmen wirklich machen wird, haben Sie den Thread effektiv beendet ohne dass es danach aussieht. Es gibt natürlich keinen narrensicheren Weg einen Thread zu beenden, und selbst wenn es den gäbe, würden Sie ihn nicht einsetzen wollen. Die Beteiligten aber darum zu bitten, entweder sichtbaren Fortschritt zu machen, oder aufzuhören Nachrichten zu schicken, ist wenn Sie es diplomatisch anstellen, ohne weiteres vertretbar. Hüten Sie sich jedoch davor Threads voreilig zu schließen. Eine gewisse Menge an spekulativem Gerede kann, je nach Thema, produktiv sein, und darum zu bitten, dass man es zu schnell klärt, wird den kreativen Ablauf ersticken, und Sie zusätzlich als ungeduldig erscheinen lassen.

Erwarten Sie von keinem Thread, dass er sofort aufhört. Es wird wahrscheinlich immer noch ein paar Nachrichten nach Ihrem geben, entweder weil sie sich in der Leitung begegnet sind, oder weil Leute immer das letzte Wort haben wollen. Das ist nichts, worüber Sie sich Sorgen machen müssten und Sie müssen nicht erneut ein Schreiben schicken. Lassen Sie den Thread einfach auslaufen, oder nicht auslaufen wie immer der Fall auch sein mag. Sie können nicht die absolute Kontrolle haben; andererseits, können Sie über viele Threads gesehen, eine statistisch signifikante Wirkung zu haben.

Je Weicher Das Thema, Desto Länger Die Debatte

Obwohl Diskussionen bei jedem Thema mäandrieren können, geht die Wahrscheinlichkeit dafür hoch wenn die technische Schwierigkeit runter geht. Schließlich ist die Anzahl der Teilnehmer die mitkommen können um so kleiner, je schwieriger das Thema ist. Diejenigen die es können, sind wahrscheinlich die erfahrensten Entwickler, die bereits tausende male vorher an solchen Diskussionen teilgenommen haben, und wissen, welches Verhalten wahrscheinlich zu einem Konsens führt, mit dem alle leben können.

Konsens ist deshalb am schwersten zu erreichen bei technischen Fragen die einfach zu verstehen sind und bei dem man leicht eine Meinung haben kann, sowie bei "weichen" Themen, wie Organisation, Öffentlichkeitsarbeit, Finanzierung, usw. Menschen können sich ewig über solche Themen unterhalten, da es keine nötige Qualifikationen dafür gibt, keine klaren Möglichkeiten um zu entscheiden (selbst im Nachhinein) ob eine Entscheidung richtig war oder falsch, und weil es manchmal eine erfolgreiche Taktik ist einfach länger zu warten als andere Diskussionsteilnehmer.

Das Prinzip, dass die Menge an Diskussion umgekehrt proportional dazu ist, wie komplex das Thema ist, hat es schon lange gegeben, und ist informell unter dem Begriff Bikeshed Effect (de. Fahrrad Schuppen Effekt) bekannt. Hier ist die Erklärung von Poul-Henning Kamp davon, aus einem nunmehr berühmten Email an BSD Entwickler:

Es ist eine lange Geschichte, bzw. eher eine alte Geschichte, aber sie ist in Wirklichkeit ziemlich kurz. C. Northcote Parkinson schrieb Anfang der 1960'er ein Buch namens "Parkinsons Gesetz", welches eine Menge Einblicke in die Dynamik von Verwaltung beinhaltet.

[...]

Bei dem spezifischen Beispiel welches mit einem Fahrrad Schuppen zu tun hat, ist die andere entscheidende Komponente ein Atomkraftwerk, was schätze ich die Zeit in der das Buch geschrieben wurde widerspiegelt.

Parkinson zeigt, wie Sie zu einem Vorstand gehen können und Zustimmung für den Bau einer multi-millionen oder gar Milliarden Euro teuren Atomkraftwerk bekommen können, wenn Sie aber einen Fahrradschuppen bauen wollen, werden Sie sich in endlosen Diskussionen verzetteln.

Parkinson erklärt, dass das daran liegt, dass ein Atomkraftwerk so gewaltig, so kostspielig und so kompliziert ist, das Menschen es nicht begreifen können, und eher als es zu versuchen, fallen Sie auf die Annahme zurück, dass jemand anderes bereits alle Details überprüft hat vor es so weit gekommen ist. Richard P. Feynmann gibt in seinen Büchern ein paar interessante und treffende Beispiele die mit Los Alamos zu tun haben.

Ein Fahrradschuppen andererseits kann jeder übers Wochenende bauen und trotzdem noch genügend Zeit übrig haben um das Spiel im Fernsehen zu schauen. Egal wie gut Sie sich vorbereiten, egal wie vernünftig Sie bei Ihrem Vorschlag also sind, irgend jemand wird die chance ergreifen um Ihnen zu zeigen, dass er seine Arbeit macht, dass er aufpasst, dass er da ist.

In Dänemark nennen wir das "seinen Fingerabdruck hinterlassen". Es geht um den persönlichen Stolz und Ansehen, es geht darum irgendwo drauf zeigen zu können und zu sagen "Da! Das habe ich gemacht". Es ist ein starker Wesenszug bei Politikern, aber auch in den meisten Menschen vorhanden, wenn sie dazu die Gelegenheit bekommen. Denken Sie einfach an Fußabdrücke im nassen Zement.

(Seine komplette Nachricht ist auch sehr lesenswert. Siehe Anhang C, Warum sollte es mich kümmern, welche Farbe der Fahrradschuppen hat?; siehe auch http://bikeshed.com.)

Jeder der jemals an der Entscheidungsfindung in einer Gruppe beteiligt war, wird erkennen worüber Kamp redet. Es ist jedoch für gewöhnlich unmöglich alle zu überreden es zu vermeiden Fahrradschuppen anzumalen. Das beste was Sie machen können, ist darauf hinzuweisen, dass das Problem existiert sobald es auftaucht, und Ihre höher rankigen Entwickler—die Personen dessen Nachrichten am meisten Gewicht tragen— dazu überreden frühzeitig Ihre Pinsel nieder zu legen, damit zumindest sie nicht zum Rauschen beitragen. Fahrrad anmal Feten werden nie komplett weggehen, aber Sie können sie verkürzen und weniger häufig machen, indem Sie das Bewusstsein in der Kultur des Projekts über das Problem vergrößern.

Vermeiden Sie Heilige Kriege

Ein heiliger Krieg ist eine Debatte, die oft aber nicht immer über eine relativ unbedeutende Angelegenheit geführt wird, welche nicht anhand der Vorzüge verschiedener Argumente zu klären ist, bei dem aber Leute leidenschaftlich genug sind um trotzdem weiter darüber zu argumentieren, in der Hoffnung das ihre Seite sich durchsetzen wird. Heilige Kriege sind nicht ganz das selbe wie das Anmalen von Fahrradschuppen. Leute die Fahrradschuppen anmalen sprechen für gewöhnlich schnell Ihre Meinung (weil sie es können), fühlen sich aber nicht sonderlich stark an diese Meinung gebunden, und werden manchmal sogar andere, nicht kompatible Meinungen äußern, um zu zeigen, dass Sie all Seiten der Angelegenheit verstehen. Bei einem heiligen Krieg hingegen, wird Verständnis für andere Seiten als Schwäche aufgefasst. Bei einem heiligen Krieg, weiß jeder, dass es eine richtige Antwort gibt; sie sind sich nur nicht darüber einig welche es ist.

Wenn ein heiliger Krieg erst einmal angefangen hat, kann es im allgemeinen nicht zur Zufriedenheit von allen aufgelöst werden. Es nützt nichts während einem heiligen Krieg darauf hinzuweisen, dass man sich in einem heiligen Krieg befindet. Jeder weiß das schon. Ein leider häufiges Merkmal von heiligen Kriegen sind Meinungsverschiedenheiten über die Frage ob die Debatte sich überhaupt durch weitere Diskussion auflösen lässt. Von außen betrachtet, ist es klar, dass keine Seite die Meinung der anderen ändert. Von innen betrachtet, benimmt sich die andere Seite stumpfsinnig und denkt nicht ganz klar, sie kommt aber vielleicht zur Besinnung, wenn man sie nur genügend einschüchtert. Ich sage jetzt nicht, dass es nie eine richtige Seite bei einem heiligen Krieg gibt. Manchmal gibt es eine—und natürlich ist es bei denen an den ich bisher teilgenommen habe immer meine gewesen. Das macht aber keinen Unterschied, weil es kein Algorithmus gibt, um überzeugend zu demonstrieren, dass die eine oder andere Seite richtig ist.

Eine verbreitete, aber nicht zufriedenstellende Art, indem Leute versuchen heilige Kriege zu lösen, ist zu sagen "Wir haben bereits viel mehr Zeit und Energie bei der Diskussion hiervon verbraucht, als es wert ist! Können wir es bitte einfach fallen lassen"? Es gibt dabei zwei Probleme. Erstens wurde diese Zeit und Energie bereits aufgebracht, und sie kann nie wieder zurückgewonnen werden—die einzige Frage die jetzt noch übrig bleibt ist, wieviel mehr man investieren muss? Wenn einige Personen der Meinung sind, dass nur ein wenig mehr Diskussion das Thema zum Abschluss bringen wird, dann macht es immer noch Sinn (aus ihrer Sicht) weiter zu machen.

Das andere Problem bei der Bitte das Thema fallen zu lassen ist, dass es gleich das gleiche ist als würde man eine Seite, den Status Quo, erlauben den Sieg durch Untätigkeit erklären zu lassen. Und in manchen Fällen, weiß man schon, dass der Status Quo sowieso nicht akzeptabel ist: Alle sind sich darüber einig, dass irgend eine Entscheidung getroffen, irgend eine Maßnahme ergriffen werden muss. Das Thema fallen zu lassen, wäre schlimmer für alle als es für irgendjemand wäre den Streit aufzugeben. Da das Dilemma aber für alle gleichermaßen gilt, ist es immer noch möglich ewig darüber zu streiten, was getan werden soll.

Wie sollten Sie als heilige Kriege handhaben?

Die erste Antwort ist, die Dinge so einzurichten, dass sie gar nicht erst passieren. Das ist nicht so hoffnungslos wie es sich anhört:

Sie können einige immer wiederkehrende heilige Kriege vorausahnen: Sie neigen über Themen wie Programmiersprachen, Lizenzen (siehe „Die GPL und Lizenz-Kompatibilität“ im Kapitel Kapitel 9, Lizenzen, Urheberrecht, und Patente), Änderung des reply-to Feldes (siehe „Die große "reply-to" Debatte“ im Kapitel Kapitel 3, Technische Infrastruktur), und ein paar andere Themen auf zu tauchen. Jedes Projekt hat auch ein oder zwei ganz eigene heilige Kriege, womit langjährige Entwickler schnell vertraut werden. Die Techniken um heilige Kriege aufzuhalten, oder zumindest ihren Schaden zu begrenzen, sind überall ziemlich die gleichen. Selbst wenn Sie sich sicher sind, dass Ihre Seite recht hat, versuchen Sie irgend eine Möglichkeit zu finden um Mitgefühl und Verständnis für die Argumente die die anderen Seite macht auszudrücken. Oftmals ist das Problem bei einem heiligen Krieg, dass weil jede Seite ihre Mauern so hoch wie möglich gebaut hat, und klar gemacht hat, dass jede andere Meinung schlichtweg albern ist, wird Kapitulation oder die Änderung seiner Meinung psychologisch unerträglich: Es wäre nicht nur ein Geständnis, dass man falsch lag, sondern sich sicher gewesen zu sein und trotzdem falsch. Sie können dieses Geständnis für die andere Seite schmackhaft machen können, ist indem Sie selber Ungewissheit zeigen—gerade indem Sie zeigen, dass Sie die Argumente die sie machen verstehen und sie zumindest vernünftig finden, wenn auch nicht ganz überzeugend. Zeigen Sie eine Geste, welche Raum lässt, für eine gegenseitige Geste lässt, und die Situation wird sich gewöhnlich verbessern. Es ist nicht mehr oder weniger wahrscheinlich, dass Sie das Ergebnis welches Sie haben wollen, zumindest können Sie dadurch aber unnötigen Kollateralschaden an der Moral des Projekts vermeiden.

Wenn ein heiliger Krieg nicht vermieden werden kann, entscheiden Sie sich frühzeitig wie sehr sie die Sache kümmert, und seien Sie bereit öffentlich aufzugeben. Wenn Sie das tun, können Sie sagen, dass Sie aussteigen, weil ein heiliger Krieg es nicht wert ist, drücken Sie dabei aber keine Bitterkeit aus und nutzen Sie die Gelegenheit nicht als eine letzte Gelegenheit auf die Argumente der Gegenseite. Aufzugeben ist nur effektiv wenn es taktvoll gemacht wird.

Heilige Kriege über Programmiersprachen sind ein Spezialfall, da dazu neigen sehr technisch zu sein, dennoch fühlen sich viele Leute qualifiziert an Ihnen teil zu nehmen, und der Einsatz ist sehr hoch, da das Resultat bestimmen kann, in welcher Sprache ein Großteil des Codes vom Projekt geschrieben wird. Die beste Lösung ist es, die Sprache frühzeitig zu wählen, mit Unterstützung durch einflussreiche Entwickler, und es dann auf der Grundlage zu verteidigen, dass sie sich alle wohl fühlen in dieser Sprache zu schreiben, nicht auf der Grundlage, dass es besser ist als irgend eine andere Sprach, die man sich statt dessen hätte aussuchen können. Lassen Sie die Unterhaltung nie zu einem akademischen Vergleich verschiedener Programmiersprachen verfallen (das scheint, aus irgend ein Grund, besonders of zu passieren, wenn jemand Perl aufbringt); das ist einfach ein Thema des Todes in welches Sie sich weigern müssen hineingezogen zu werden.

Für ein eher historischen Hintergrund über heilige Kriege, siehe http://catb.org/~esr/jargon/html/H/holy-wars.html, und die Veröffentlichung von Danny Cohen welches den Begriff populär http://www.ietf.org/rfc/ien/ien137.txt.

Der "Lauten Minderheit" Effekt

Bei jedem Email Verteiler ist es leicht für eine kleine Minderheit den Eindruck zu erwecken, dass eine Menge Dissens gibt, indem Sie den Verteiler mit einer Menge langer Emails überfluten. Es ist ein eine art Obstruktionspolitik, mit dem Unterschied, dass der Eindruck von ausgedehntem Dissens noch stärker ist, da es auf eine beliebige Anzahl einzelner Nachrichten aufgeteilt ist und die meisten Leute werden sich nicht die Mühe mache mitzuverfolgen wer was wann gesagt hat. Sie werden nur den instinktiven Eindruck haben, dass das Thema sehr kontrovers ist, und warten biss die Aufregung sich gelegt hat.

Die beste Art gegen diesen Effekt anzukommen sehr klar zu Belegen, wie klein die tatsächliche Anzahl der Dissidenten ist im Vergleich zu denen die zustimmen. Um die Ungleichheit zu vergrößern, sollten Sie im privaten Leute ansprechen die größtenteils ruhig geblieben sind, von denen Sie aber vermuten, dass Sie der Mehrheit zustimmen. Sagen Sie nichts, was darauf hindeutet, dass die Dissidenten absichtlich versucht hatten den Eindruck den sie hinterlassen zu verstärken. Wahrscheinlich war das nicht der Fall, und selbst wenn, gäbe es keinen strategischen Vorteil darauf hinzuweisen. Alles was Sie tun müssen, ist eine Gegenüberstellung der echten Zahlen, und Leute werden erkennen, dass ihr intuitiver Eindruck der Situation nicht der Wirklichkeit entspricht.

Dieser Ratschlag gilt nicht nur für Angelegenheiten mit klaren Positionen für oder gegen etwas. Sondern für jede Diskussion bei dem viel Lärm gemacht wird, aber nicht klar ist, dass die meisten die Angelegenheit die zur Debatte steht als echtes Problem ansieht. Nach einer gewissen Zeit, wenn Sie darüber einstimmen, dass die Meldung keine Reaktion wert ist, und sehen können, dass es es nicht geschafft hat an Zug zu gewinnen (selbst wenn es eine Menge Emails hervorgebracht hat), können Sie einfach öffentlich feststellen, dass es keinen Zug gewinnt. Wenn der "Laute Minderheit" Effekt aufgetreten war, wird Ihre Nachricht wie eine Atemzug frischer Luft wirken. Der Eindruck den die meisten Leute bisher von der Diskussion hatten, wird etwas düster gewesen sein: "Hmm, is scheint eine große Sache zu sein, weil es wirklich eine Menge Nachrichten gibt, aber ich sehe keinen echten Fortschritt". Indem Sie erklären, wie die Art der Diskussion es hat scheinen lassen, als wäre es stürmischer als in Wirklichkeit, werden Sie es im Nachhinein eine neue Gestalt geben, wodurch Leute ihr Verständnis von dem was passiert ist neu gestalten können.