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, über die Sie den Überblick behalten können, zumindest nachdem das Projekt die ersten paar Monate überschritten hat. Zweitens wird das meiste in den Theras bei denen Sie sich entschieden haben, sie zu verfolgen, keiner Antwort erfordern. Gerade Entwicklerforen neigen dazu von drei Arten von Nachrichten beherrscht zu werden:

Von diesen erfordert keine 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. (Machen Sie sich keine Sorgen, dass Sie in einer Schleife gefangen werden, bei dem jeder auf den anderen wartet, weil jeder die gleiche Taktik verfolgt; es gibt fast immer Irgendjemanden 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, der 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 E-Mail. Selbst dann sollten Sie zwei mal darüber nachdenken, bevor 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 Mailverteilern verhalten soll.)

Auf einem betriebsamen Mailverteiler haben Sie zwei Pflichten. Eines ist 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 es 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, lassen Sie uns den Kontext bedenken in dem so etwas passiert. Was sind einige der Ecksteine von unproduktiven Threads?

Nur weil ein Thread anfangs nicht produktiv ist, bedeutet es nicht, das es 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:

Wohingegen folgendes gut ist:

Vergleichen Sie die zweite Herangehensweise mit der ersten. Die Zweite zieht keinen Strich zwischen Ihnen und die anderen, noch beschuldigt es die Teilnehmer 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. Die Nachricht beschreibt warum der Thread nirgendwo hinführt, macht es aber ohne Abwertungen oder Verurteilungen – es hält lediglich leidenschaftslos einige Tatsachen fest. Am wichtigsten ist, dass es eine positive Vorgehensweise anbietet, anstatt dass man das Gefühl bekommt, als würde die Diskussion abgebrochen werden (eine Maßnahme die dazu verleiteten dürfte zu rebellieren), man wird es als eine Möglichkeit ansehen, wird die Unterhaltung auf eine konstruktivere Ebene zu führen. Dies ist ein Normwert den man natürlich erfüllen will.

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 Ihrer geben, entweder weil Sie gleichzeitig mit jemand anderem gepostet haben, 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.

Obwohl Diskussionen bei jedem Thema mäandrieren können, geht die Wahrscheinlichkeit dafür hoch sobald die technische Schwierigkeit runter geht. Schließlich ist die Anzahl der Teilnehmer die dem Thema folgen können um so kleiner, je schwieriger das Thema ist. Diejenigen die dann folgen 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 denen 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 Qualifikation 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 allgemein unter dem Begriff Bikeshed Effect (de. Fahrradschuppen-Effekt) bekannt. Hier ist die Erklärung von Poul-Henning Kamp davon, aus einer nunmehr berühmten E-Mail an BSD-Entwickler:

(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 Senior-Entwickler – die Personen deren Nachrichten am meisten Gewicht tragen – dazu überreden, frühzeitig Ihre Pinsel nieder zu legen, damit zumindest sie nicht zum Rauschen beitragen. Fahrradschuppen-Anmal-Partys werden nie komplett verschwinden, aber Sie können sie verkürzen und weniger häufig machen, indem Sie das Bewusstsein für sie in der Projektkultur verinnerlichen.

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 alle 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 keinen Algorithmus gibt, um überzeugend zu demonstrieren, dass die eine oder andere Seite richtig ist.

Eine verbreitete, aber nicht zufriedenstellende Art, wie 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.

Bei der Bitte das Thema fallen zu lassen ist das andere Problem, dass der Status Quo es einer Seite erlauben würde, den Sieg durch Untätigkeit zu erklären. Und in manchen Fällen ist der Status Quo sowieso nicht akzeptabel: Alle sind sich darüber einig, dass irgendeine Entscheidung getroffen, irgendeine Maßnahme ergriffen werden muss. Das Thema fallen zu lassen, wäre schlimmer für alle als 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 tendieren zu 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) sowie ein paar andere Themen. 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 irgendeine 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 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, 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 weder wahrscheinlicher oder unwahrscheinlicher, dass Sie das Ergebnis, das Sie ursprünglich wollten erreichen, 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 um gegen die Argumente der Gegenseite zu argumentieren. 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 Sprache, 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 irgendeinem 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.

Bei jedem Mailverteiler 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 E-Mails ü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 machen mitzuverfolgen wer was wann gesagt hat. Sie werden nur den instinktiven Eindruck haben, dass das Thema sehr kontrovers ist, und warten, bis die Aufregung sich gelegt hat.

Sehr klar zu Belegen, wie klein die tatsächliche Anzahl der Dissidenten ist im Vergleich zu denen die zustimmen ist die beste Art gegen diesen Effekt anzukommen. 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 haben 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 der viel Lärm gemacht wird, aber nicht klar ist, ob die meisten die Angelegenheit als ein echtes Problem ansehen. Nach einer gewissen Zeit, wenn Sie darüber einstimmen, dass die Meldung keiner Reaktion wert ist, und sehen können, dass sie es nicht geschafft hat an Zug zu gewinnen (selbst wenn es eine Menge E-Mails 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, es 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.