Non è più facile avere a che fare con gente difficile nei forum elettronici di quanto lo sia di persona. Per "difficile" non intendo "maleducata". La gente maleducata è fastidiosa, ma non necessariamente difficile. In questo libro si è già discusso di come trattarli: commentare la maleducazione la prima volta, e da allora in poi, o ignorarli o trattarli come chiunque altro. Se continuano ad essere maleducati, si renderanno di solito così impopolari da non avere influenza su altri nel progetto, quindi sono un problema che si circoscrive da sè.
I casi veramente difficile sono persone che non sono apertamente maleducate, ma che manipolano o abusano dei processi del progetto in un modo che finisce col costare tempo ed energia di altra gente, pur non portando alcun beneficio al progetto. Questa gente spesso cerca punti limite nelle procedure del progetto, per darsi più influenza di quella che altrimenti avrebbero. Questo è molto più insidioso della mera maleducazione, perchè nè il comportamento nè il danno che causa è evidente all'osservatore casuale. Un classico esempio è il guerrigliero, in cui qualcuno (sempre sembrando il più ragionevole possibile) continua a sostenere che il problema in discussione non è pronto per una soluzione, e propone molte possibili soluzioni, o nuovi punti di vista su vecchie soluzioni, quando cosa sta davvero succedendo è che capisce che un consenso o uno scontro sta per formarsi, e non gli piace dove il problema è andato a finire. Un altro esempio è quando c'è un dibattito che non convergerà ad un consenso, ma il gruppo cerca almeno di chiarificare i punti di disaccordo e produrre un riassunto per chiunque si aggiunga da quel momento in poi. L'ostruzionista, che sa che il riassunto potrebbe portare ad un risultato che non gli piace, spesso proverà a ritardare il sommario, complicando sempre di più le domande di cosa dovrebbe esserci, o obbiettando a consigli ragionevoli o introducendo nuovi e inaspettati punti.
Per contrastare tale comportamento, aiuta capire la mentalità di coloro che lo adottano. Solitamente la gente non lo fa di proposito. Nessuno si sveglia al mattino e dice a se stesso: "Oggi cinicamente manipolerò i form procedurali per essere un irritante ostruzionista." Piuttosto, tali azioni sono spesso precedute da una sensazione semi-paranoica di essere tagliato fuori dalle interazioni e decisioni del gruppo. La persona sente che non sarà presa in considerazione seriamente, o (nei casi più gravi) che c'è quasi una cospirazione contro di lui—che gli altri membri del gruppo hanno deciso di formare un club esclusivo, di cui lui non è membro. Questo allora giustifica, nella sua mente, il prendere le regole alla lettera e procedere in una manipolazione formale delle procedure del progetto, per farsi prendereseriamente in considerazione da tutti gli altri. In casi estremi, la persona può persino pensare che sta combattendo una battaglia solitaria per salvare il progetto da se stesso.
E' la natura di questo tipo di attacco dall'interno che non tutti lo noteranno nello stesso momemento, e certa gente potrebbe non vederlo del tutto a meno che presentato con forte evidenza. Questo significa che neutralizzarlo potrebbe essere un bel po' di lavoro. Non è abbastanza persuadere voi stessi che sta succedendo; dovete trovare abbastanza prove anche per persuadere gli altri, e poi dovete far conoscere queste prove in modo intelligente.
Dato che è così tanto lavoro combattere, è spesso meglio tollerarlo giusto un po'. Pensatelo come una malattia da parassiti, ma leggera: se non è troppo debilitante, il progetto può permettersi di rimanere infetto, e le medicine avrebbero dolorosi effetti collaterali. Comunque, se tollerarla diventa troppo dannoso, allora è il momento di agire. Iniziate a prendere appunti sulle modalità che vedete. Fate in modo di includere riferimenti agli archivi pubblici—questa è una delle ragioni per cui il progetto registra le cose, così potete anche usarle. Una volta che avete costruito un buon caso, iniziate ad avere conversazioni private con altri partecipanti al progetto. Non dite loro cosa avete osservato, piuttosto, chiedete prima a loro cosa hanno osservato. Questa potrebbe essere la vostra ultima possibilità di avere un riscontro non filtrato di come gli altri vedono il comportamento di chi crea problemi; una volta che iniziate a parlarne apertamente, l'opinione diventerà polarizzata e nessuno sarà in grado di ricordare cosa avesse pensato in precedenza riguardo al problema.
Se le discussioni private indicano che almeno anche qualcun altro vede il problema, allora è il momento di fare qualcosa. Questo è quando dovete diventare veramente cauti, perchè è molto facile per questo tipo di gente cercare di far sembrare come se li steste criticando ingiustamente. Qualunque cosa facciate, non accusateli mai di abusare in modo malizioso delle procedure del progetto, di essere paranoici, o, in generale, di tutte le altre cose che sospettate siano probabilmente vere. La vostra strategia deve essere di sembrare sia più ragionevole e più concentrato con la salute generale del progetto, con l'obiettivo di o riformare il comportamento della persona, o farlo andare via in maniera definitiva. A seconda degli altri sviluppatori, e della vostra relazione con loro, potrebbe essere vantaggioso prima cercare alleati privatamente. O potrebbe non esserlo; potrebbe solo creare malumori dietro le quinte, se la gente pensa che stiate intraprendendo una impropria campagna silenziosa.
Ricordate che anche se l'altra persona potrebbe essere uno che si comporta in maniera distruttiva, voi sarete quelli che appaiono distruttivi se fate una pubblica accusa da cui non potete tornare indietro. Siate sicuri di avere molti esempi per dimostrare quello che state dicendo, e ditelo il più gentilmente possibile pur essendo diretti. Magari non persuaderete la persona in questione, ma va bene fino a quando persuadete tutti gli altri.
Ricordo solo una situazione, in più di 10 anni di lavoro nel software libero, dove le cose si fecero così cattiva che dovemmo chiedere tutti insieme a qualcuno di smettere di scrivere. Come spesso accade, non era maleducato, e sinceramente voleva solo essere d'aiuto. Solo non sapeva quando scrivere e quando non scrivere. Le nostre mailing list sono aperte al pubblico, e lui stava scrivendo così spesso, e chiedendo domande su così tanti argomenti diversi, che stava diventando un problema di rumore per la comunità. Avevamo già provato a chiedergli gentilmente di fare un po' più di ricerca di risposte prima di scrivere, ma non aveva avuto effetto.
La strategia che alla fine funzionò è un perfetto esempio di come costruire un caso robusto su dati neutrali e in quantità. Uno dei nostri sviluppatori fece un po' di scavi negli archivi, e poi mandò il seguente messaggio privatamente a pochi sviluppatori. L'imputato (il terzo nome nella lista sotto, mostrato qui come "J. Random") aveva una storia molto breve nel progetto, e non aveva contribuito codice nè documentazione. E comunque era il terzo più attivo produttore di messaggi sulla mailing list:
From: "Brian W. Fitzpatrick" <fitz@collab.net>
To: [... lista dei destinatari omessa per riservatezza ...]
Subject: Il Lavandino dell'energia di Subversion
Date: Wed, 12 Nov 2003 23:37:47 -0600
Negli ultimi 25 giorni, i sei maggiori produttori di messaggi sulla mailing list svn
[sviluppatori|utenti] sono stati:
294 kfogel@collab.net
236 "C. Michael Pilato" <cmpilato@collab.net>
220 "J. Random" <jrandom@problematic-poster.com>
176 Branko Čibej <brane@xbc.nu>
130 Philip Martin <philip@codematters.co.uk>
126 Ben Collins-Sussman <sussman@collab.net>
Vorrei dire che cinque di queste persone stanno contribuendo a Subversion, che
raggiungerà 1.0 nel prossimo futuro.
Vorrei anche dire che una di queste persone sta consumando in maniera consistente il tempo
e l'energia degli altri 5, per non dire della mailing list intera,
quindi (magari non intenzionalmente) rallentando lo sviluppo di Subversion. Non ho
fatto un'analisi di tutti i thread, ma facendo il vgrep delle mie mail di Subversion si vede
che ogni mail di persona ha ricevuto risposta almeno una volta da almeno 2 delle altre 5 persone
della lista sopra.
Penso che qui sia necessario qualche tipo di intervento radicale, anche se faremo scappare
via la persona sopracitata. Carinerie e gentilezze si sono già dimostrate senza effetto.
dev@subversion è una mailing list per facilitare lo sviluppo di un sistema
di controllo di versione, non una sessione di terapia di gruppo.
-Fitz, che prova a guadare attraverso tre giorni di email svn che ha lasciato accumulare
Anche se potrebbe non sembrare così a prima vista, il comportamento di J.Random era un classico esempio di abuso delle procedure di progetto. Non stava facendo nulla di ovvio come provare a sabotare un voto, ma stava abusando della politica della mailing list di affidarsi sulla auto moderazione dei suoi membri. Abbiamo lasciato al giudizio di ogni individuo quando scrivere messaggi e su quali argomenti. Quindi, non avevamo procedure di ricorso per gestire qualcuno che o non aveva, o non usava, tale giudizio. Non c'era alcuna regola a cui riferirsi e dire che il tizio la stava violando, eppur tutti sapevano che il suo frequente scrivere messaggi stava diventando un problema serio.
La strategia di Fitz era, in retrospettiva, da maestro. Ha trovato un esempio dannatamente fondato, ma poi l'ha distribuito discretamente, mandandolo prima alle poche person il cui supporto sarebbe stato la chiave per ogni azione drastica. Si sono trovati d'accordo che qualche tipo di azione era necessaria, e alla fine abbiamo chiamato J. Random al telefono, descritto il problema a lui direttamente, e gli abbiamo chiesto semplicemente di smetterla di scrivere messaggi. Lui non ha mai veramente capito il perchè; se fosse stato in grado di capire, probabilmente avrebbe fin dall'inizio usato un criterio adeguato. Ma accettò di smettere di scrivere, e la mailing list tornò ad essere utilizzabile. Parte del motivo per cui questa strategia ha funzionato, magari, è stata l'implicita minaccia che avremmo potuto iniziare a limitare i suoi messaggi usando il software di moderazione solitamente usato per prevenire lo spam (vedi sezione chiamata «Prevenire lo spam» in Capitolo 3, L'Infrastruttura Tecnica ). Ma la ragione per cui eravamo in grado di avere questa opzione di riserva è stata il fatto che Fitz ha in primo luogo trovato il necessario supporto nelle persone importanti.