Schwierige Leute

Schwierige Leute sind im Umgang in elektronischen Foren nicht einfacher als im echten Leben. Mit "schwierig" meine ich nicht "unhöflich". Unhöfliche Leute nerven, aber sie sind nicht unbedingt schwierig. Dieses Buch hat bereits behandelt, wie man mit denen umgeht: Machen Sie eine Bemerkung beim ersten mal, und ab dann, sollten Sie sie entweder ignorieren oder sie wie alle anderen behandeln. Wenn sie weiterhin unhöflich sind, werden sie sich meistens derart unbeliebt machen, dass sie keinen Einfluss auf andere im Projekt haben, also sind sie ein in sich abgeschlossenes Problem.

Die wirklich schwierigen Fälle sind Leute die nicht sonderlich unhöflich sind, die aber die Arbeitsabläufe im Projekt derart manipulieren oder missbrauchen, dass es die Zeit und Energie anderer auffrisst, dem Projekt jedoch keinen Nutzen bringt. [50].

Solche Menschen suchen oft nach Lücken in den Abläufen des Projekts, um sich selber mehr Einfluss zu verschaffen als es sonst der Fall wäre. Das ist viel heimtückischer als schlichte Unhöflichkeit, weil weder das Verhalten noch der Schaden für einen beiläufigen Beobachter offensichtlich ist. Ein klassisches Beispiel ist die Verschleppungstaktik bei der jemand (der sich natürlich immer so vernünftig wie möglich anhört) immer wieder behauptet, dass die Angelegenheit die zur Debatte steht, nicht für eine Klärung bereit ist und weitere mögliche Lösungen anbietet, oder neue Sichten auf alte Lösungen, wenn in wirklich derjenige merkt, dass ein Konsens oder eine Wahl sich langsam anbahnt, und ihm gefällt die Richtung nicht in der sie wahrscheinlich geht. Ein weiteres Beispiel ist, wenn eine Debatte die sich keinem Konsens annähert, die Gruppe aber versucht wenigstens die Eckpunkte der Meinungsverschiedenheit klar zu stellen und eine Zusammenfassung für alle zu produzieren, auf der sich alle von da an beziehen können. Der Quertreiber, der weiß, dass die Zusammenfassung zu einem Ergebnis führen könnte, welches ihm nicht gefällt, wird oft versuchen selbst die Zusammenfassung hinauszuzögern, indem er schonungslos die Fragen verkompliziert, was darin beinhaltet sein soll, entweder indem er Einspruch erhebt oder indem er unerwartete neue Punkte vorstellt.

Handhabung schwieriger Leute

Um solchem Verhalten entgegenzuwirken hilft es, die Mentalität derjenigen zu verstehen, die es ergreifen. Menschen machen es im Allgemeinen nicht bewusst. Keiner wacht morgens auf und sagt sich: "Heute werde ich Verwaltungsverfahren zynisch manipulieren, um ein irritierender Quertreiber zu sein". Statt dessen geht solches Verhalten oftmals ein halb paranoides Gefühl voraus, von den Interaktion und den Entscheidungen in der Gruppe ausgeschlossen zu werden. Die Person fühlt sich nicht ernst genommen, oder (in schwerwiegenderen Fällen), dass es fast schon eine Verschwörung gegen ihn ist – dass die anderen Mitglieder des Projekts sich entschieden haben, einen exklusiven Club zu bilden, in dem er kein Mitglied ist. Das rechtfertigt dann, in seinen Augen, die Regeln wörtlich zu nehmen und anzufangen die Abläufe des Projekts formal zu manipulieren, um alle anderen zu zwingen Ihn ernst zu nehmen. Im Extremfall, kann die Person sogar glauben, dass er einen einsamen Kampf ausficht, um das Projekt vor sich selbst zu retten.

Es liegt in der Natur solch eines Angriffs von innen, dass nicht jeder es zur gleichen Zeit bemerken wird, und manche werden es überhaupt nicht sehen, bis man ihnen aussagekräftige Beweise vorlegt. Das bedeutet, dass es eine Menge Arbeit sein kann es zu neutralisieren. Es reicht nicht sich selbst zu überzeugen, dass es passiert; Sie müssen genügend Beweise sammeln, um andere auch zu überzeugen, und dann müssen Sie diese Beweise wohl überlegt verbreiten.

Wenn man bedenkt wie viel Arbeit es ist dagegen anzukämpfen, ist es oft besser, es einfach eine Weile lang zu tolerieren. Betrachten Sie es als eine parasitäre aber leichte Krankheit: Wenn es nicht zu sehr das Projekt behindert, kann das Projekt es sich leisten infiziert zu bleiben, und Medizin könnte schädliche Nebenwirkungen haben. Wenn es jedoch zu schädlich wird um es zu tolerieren, dann ist es Zeit etwas dagegen zu machen. Fangen Sie an Notizen und Muster zu sammeln, die Sie erkennen. Stellen Sie sicher Verweise auf die öffentlichen Archive mit einzubeziehen – das ist eines der Gründe warum das Projekt alles protokolliert, also können Sie sie genau so gut auch nutzen. Sobald Sie einen guten Fall aufgebaut haben, fangen Sie an private Unterhaltungen mit den anderen Beteiligten am Projekt zu führen. Sagen Sie ihnen nicht was Sie beobachtet haben; statt dessen, fragen Sie zuerst, was sie beobachtet haben. Das kann Ihre letzte Gelegenheit sein, ungetrübte Rückmeldung zu erhalten, wie andere das Verhalten des Störenfrieds sehen; wenn Sie erst einmal angefangen haben öffentlich darüber zu reden, werden die Meinungen polarisiert werden und keiner wird sich daran erinnern können wie er vorher darüber gedacht hat.

Wenn private Diskussionen darauf hindeuteten, dass zumindest ein paar andere das Problem sehen, dann ist es Zeit etwas zu unternehmen. Ab dann müssen Sie wirklich vorsichtig sein, denn es ist sehr leicht für diese Person es danach aussehen zu lassen als würden Sie unfairerweise auf ihr herum hacken. Was immer Sie auch tun, beschuldigen Sie sie nicht, die Abläufe im Projekt arglistig missbraucht zu haben, paranoid zu sein oder im Allgemeinen, alles was Sie vermuten, dass es wahrscheinlich wahr ist. Ihre Strategie sollte es sein, sowohl vernünftiger und eher besorgt um das Wohl des Projekts zu sein, mit dem Ziel entweder das Verhalten der Person zu reformieren, oder Sie dazu zu bringen permanent zu verschwinden. Abhängig davon, ob andere Entwickler, und Ihr Verhältnis mit ihnen, kann es vorteilhaft sein, zuerst im privaten Verbündete zu sammeln. Oder auch nicht; dass kann auch nur Feindseligkeit hinter den Vorhängen erzeugen, wenn Leute denken, dass Sie eine nicht angemessene flüster-Kampagne ergreifen.

Denken Sie daran, dass obwohl die andere Person vielleicht derjenige ist, die sich zerstörerisch verhält, werden Sie diejenige sein, die zerstörerisch erscheint, wenn Sie eine öffentliche Beschuldigung machen, welche Sie nicht untermauern können, und es so sanft wie möglich sagen, aber trotzdem noch direkt sind. Sie werden die betreffende Person vielleicht nicht überzeugen können, aber das ist in Ordnung, so lange Sie alle anderen Überzeugen können.

Fallbeispiel

Ich erinnere mich nur an eine Situation, in mehr als 10 Jahren Arbeit an freier Software, wo die Sachen derart schlimm wurden, dass wir tatsächlich jemanden darum bitten mussten, komplett seine Nachrichten einzustellen. Wie es so oft der Fall ist, war er nicht unhöflich, und wollte aufrichtig hilfreich sein. Er wusste nur nicht wann er schreiben sollte und wann er es lieber lassen sollte. Unsere Mailinglisten waren für die Öffentlichkeit frei zugänglich, und er schrieb so oft Nachrichten, und stellte bei so vielen verschiedenen Themen Fragen, dass es für die Gemeinschaft zu einem Problem im Geräuschpegel führte. Wir hatten bereits versucht, ihn nett darum zu bitten etwas mehr vor seinen Nachrichten nach Antworten zu recherchieren, aber es zeigte keine Wirkung.

Die Strategie die letztendlich funktionierte, ist ein perfektes Beispiel, wie man einen starken Fall aufbaut, basierend auf neutralen und messbaren Daten. Einer unserer Entwickler schürfte etwas in den Archiven herum, und schickte dann im privaten folgende Nachricht an ein paar Entwickler. Der Übeltäter (der dritte Name in der nachfolgenden Liste, hier als "H. Mustermann" aufgeführt) hatte eine sehr kurze Geschichte mit dem Projekt und hatte weder Code noch Dokumentation beigetragen. Trotzdem war er die drittaktivste Person auf den Mailinglisten:

Von: "Brian W. Fitzpatrick" <fitz@collab.net>
An: [... Liste der Empfänger wegen Datenschutz ausgespart...]
Betreff: Der Energieabfall in Subversion 
Datum: Mit, 12 Nov 2003 23:37:47 -0600

In den letzten 25 Tagen, waren die folgenden 6 Personen auf den svn
[dev|users] Verteilern am aktivsten:

    294  kfogel@collab.net
    236  "C. Michael Pilato" <cmpilato@collab.net>
    220  "H. Mustermann" <hmustermann@problemposter.com> 
    176  Branko Čibej <brane@xbc.nu>
    130  Philip Martin <philip@codematters.co.uk>
    126  Ben Collins-Sussman <sussman@collab.net>

Ich würde sagen, dass fünf dieser Personen etwas zu Subversion 
beitragen, welches bald Version 1.0 erreichen wird.

Ich würde auch sagen, dass einer dieser Personen beständig Zeit und 
Energie von den anderen 5 wegnimmt, gar nicht erst von dem Verteiler
insgesamt zu sprechen, und dadurch (wenn auch unbeabsichtigt) die
Entwicklung von Subversion ausbremst. Ich hab keine Analyse der
Threads gemacht, aber ein vgrep meiner Subversion-Mails sagt mit, dass
auf jede E-Mail von dieser Person, mindestens ein mal von mindestens zwei
der anderen fünf Entwickler geantwortet wurde.

Ich denke das irgendein radikaler Eingriff hier nötig ist, selbst wenn
wir die angesprochene Person verschrecken. Nettigkeiten und 
Freundlichkeit haben bereits keine Wirkung gezeigt.

dev@subversion ist ein Mailverteiler um die Entwicklung eines
Versionsverwaltungsystems zu unterstützen, keine Gruppentherapie.

-Fitz, im Versuch durch drei Tage an SVN-Mails durchzuarbeiten, welche
 er angehäuft hat

Obwohl es zuerst nicht so aussehen mag, war das Verhalten von H. Mustermann ein klassisches Beispiel für den Missbrauch von Abläufen im Projekt. Er hat nichts offensichtliches gemacht, wie eine Abstimmung hinauszuzögern, sondern machte sich die Richtlinie des Verteilers zunutze, dass Mitglieder selber die Moderatoren sind. Wir überließen es dem Urteilsvermögen von jedem einzelnen, wann man zu welchen Themen etwas schreibt. Wir hatten deshalb nichts worauf wir zurückgreifen konnten, bei jemand der ein solches Urteilsvermögen entweder nicht hatte, oder nicht benutzte. Es gab keine Regel auf die wir hätten verweisen konnten und sagen konnten, dass dieser Kerl es gebrochen hat, jeder wusste jedoch, dass seine häufigen Nachrichten zu einem echten Problem wurden.

Die Strategie von Fitz war, im Nachhinein, meisterhaft. Er sammelte eindeutige und messbare Beweise, verteilte sie dann aber diskret, indem er sie zuerst an ein paar Leute sandte, deren Unterstützung bei jeder drastischen Maßnahme entscheidend wäre. Sie stimmten überein, dass irgend eine Maßnahme nötig war, und schließlich riefen wir J. Random telefonisch an, beschrieben ihm direkt das Problem, und baten ihn darum, seine Nachrichten einfach einzustellen. Er hat niemals wirklich verstanden warum; wenn er dazu in der Lage gewesen wäre, dann hätte er wahrscheinlich schon am Anfang ein angemessenes Urteilsvermögen aufgebracht. Er willigte aber ein, seine Nachrichten einzustellen, und die Mailinglisten wurden wieder brauchbar. Dass diese Strategie funktionierte, lag wohl zum Teil auch an der impliziten Drohung, dass wir seine Nachrichten auch durch die Moderations-Software hätten eingrenzen können, die normalerweise dazu benutzt wird, Spam zu verhindern (siehe „Schutz vor Spam“ im Kapitel Kapitel 3, Technische Infrastruktur). Der Grund warum wir diese Option als Rücklage hatten, war das Fitz die nötige Unterstützung zuerst von entscheidenden Personen gesammelt hatte.



[50] Für eine ausführliche Diskussion einer Subspezies dieser Personen, siehe:Help Vampires: A Spotter's Guide. Um Hoy zu zitieren: "Es ist so normal, dass man seine Uhr danach stellen mann. Der Zerfall einer Community ist genauso vorhersagbar wie der Zerfall von nuklearen Isotopen. Sobald ein Open Source Projekt, Sprache usw. seine Halb- wertszeit erreicht, kommen sie und nehmen das Leben aus der Community. Sie sind die Vampire der Hilfe. Und ich bin hier um sie zu stoppen…"