Una trappola comune nella partecipazione a progetti in rete è pensare che dobbiate rispondere a tutto. Non dovete. Prima di tutto, solitamente ci saranno più thread che vanno avanti di quelli a cui potete star dietro, almeno dopo che il progetto ha passato i primi suoi mesi. Secondo, anche nei thread a cui avete deciso di partecipare, la maggior parte delle cose che la gente dice non avrà bisogno di risposta. I forum di sviluppo in particolare tendono ad essere dominati da tre tipi di messaggi:

Nessuno di questi richiede inerentemente di risposta, in particolare se potete essere sicuri, basandovi sull'esperienza accumulata nei thread, che qualcun altro probabilmente dirà comunque cosa avreste detto. (Se siete preoccupati di essere presi in un ciclo di attesa-attesa perchè anche tutti gli altri stanno usando la stessa tattica, non siatelo; c'è praticamente sempre qualcuno là fuori che si sentirà di saltare nel mucchio.) Una risposta dovrebbe essere motivata da un proposito definito. Innanzitutto chiedetevi: sapete cosa volete raggiungere? E poi: non sarà raggiunto a meno che voi diciate qualcosa?

Due buone ragioni per aggiungere la vostra voce ad un thread sono a) quando vedete un difetto in una proposta e sospettate di essere l'unico a vederlo, e b) quando vedete che sta succedendo qualche equivoco tra altri, e sapete che potete appianarlo con un messaggio chiarificatore. Va solitamente bene fare un messaggio per ringraziare qualcuno per aver fatto qualcosa, o per dire "Anche io!", affinchè un lettore possa capire facilmente che tale messaggio non ha bisogno di nessuna risposta o ulteriore azione, e quindi lo sforzo mentale richiesto dal messaggio finisce nettamente quando il lettore arriva all'ultima riga delle email. Ma anche allora, pensateci due volte prima di dire qualcosa; è sempre meglio lasciare la gente desiderare che voi postiate di più invece che di meno. (Vedete la seconda metà di Appendice C, Perchè dovrebbe importarmi di che colore sia la rastrelliera? per ulteriori pensieri su come comportarsi su mailing list trafficate.)

Su una mailing list trafficata, avete due imperativi. Uno, ovviamente, è capire di cosa avete bisogno di seguire e cosa potete ignorare. L'altro è di comportarvi in modo da evitare di causare rumore: non solo volete che i vostri messaggi abbiano un alto tasso segnale/rumore, volete anche che siano quel tipo di messaggio che stimola altra gente a scrivere con un simile tasso segnale/rumore o non scrivere per niente.

Per vedere come fare ciò, considerate il contesto in cui avviene. Quali sono alcuni dei segnali di un thread improduttivo?

Solo perchè un thread non è produttivo non basta per stabilire che sia una perdita di tempo. Potrebbe trattare un argomento importante, nel qual caso il fatto che non si stia risolvendo rende tutto più problematico.

Guidare un thread verso l'utilità senza essere pressanti è un'arte. Non funzionerà semplicemente consigliando alla gente di smettere di perdere il loro tempo, o chiedendo loro di non scrivere a meno di avere qualcosa di costruttivo da dire. Potreste, certo, pensare queste cose privatamente, ma se lo dite ad alta voce allora sarete offensivi. Invece, dovete suggerire le condizioni per ulteriori progressi—dare alla gente una strada, un sentiero da seguire che porta ai risultati che volete, pur senza sembrare di stare dettando la strada. La distinzione è principalmente di tono. Per esempio, questo non va bene:

Mentre questo è buono:

Confrontate il secondo approccio con il primo. Il secondo modo non traccia una linea tra voi e gli altri, nè li accusa di procedere in una discussione a spirale. Parlo di "noi", che è importante sia che abbiate o meno partecipato veramente nel thread in precedenza, perchè ricorda a tutti che anche quelli che sono stati in silenzio fino ad ora possono ancora contribuire al risultato del thread. Descrive perchè il thread non sta andando da nessuna parte, ma lo fa senza peggiorazioni o giudizi—spassionatamente preciso solo alcuni fatti. Più importante, offre un corso positivo di azioni, così che invece di sentirsi come se la discussione sia stata troncata (una restrizione verso cui potrebbero solo tentare di ribellarsi), la gente si sentirà come se fosse stata loro offerto un modo di portare la conversazione ad un livello più costruttivo. Questo è uno standard che la gente vorrà naturalmente raggiungere.

Non vorrete sempre portare un thread al prossimo livello di costruttività—a volte vorrete solo farlo finire. Il proposito del vostro messaggio allora è fare uno o l'altro. Se potete dire dal modo in cui il thread è andato fino ad allora che nessuno da veramente facendo i passi che suggerite, allora il vostro messaggio effettivamente chiude il thread senza sembrare di farlo. Di certo non c'è nessun modo a prova di idiota per chiudere un thread, e anche se ci fosse, non vorreste usarlo. Ma chiedere ai partecipanti o di mostrare progressi visibili o di smettere di scrivere è perfettamente difendibile, se fatto diplomaticamente. Siate comunque attenti nel fermare prematuramente i thread. Un po' di chiacchiere possono essere produttive, a seconda dell'argomento, e chiedere che sia risolto troppo velocemente soffocherà il processo creativo, così come vi farà sembrare impazienti.

Non aspettatevi che un thread si stoppi all'istante. Ci saranno comunque ancora alcuni messaggi dopo al vostro, sia perchè le mail si saranno incrociate nell'instradamento, o perchè la gente vuole avere l'ultima parola. Questo non è nulla di cui preoccuparsi, e non avete bisogno di scrivere di nuovo. Lasciate la gente calmarsi, o non calmarsi, a seconda dei casi. Non potete avere completo controllo; dall'altro lato, potete aspettarvi di avere statisticamente un effetto significativo su molti thread.

Anche se la discussione può deviare su ogni argomento, la probabilità di deviazione sale quando la difficoltà tecnica di un argomento diminuisce. Dopo tutto, maggiore è la difficoltà tecnica, meno partecipanti potranno veramente seguire cosa sta succedendo. Quelli che possono essere gli sviluppatori più esperti, che hanno già preso parte in queste discussioni migliaia di volte in precedenza, e sanno che tipo di comportamento può portarli ad ottenere quel consenso con cui ognuno può andare avanti.

Quindi, il consenso è più difficile da ottenere nelle questioni tecniche che sono semplici da capire ed è facile farsi un'opinione, ed in argomenti "leggeri" come l'organizzazione, la pubblicità, i fondi, eccetera. La gente può partecipare a queste discussioni sempre, poichè non sono necessarie qualifiche per farlo, nessun modo chiaro per decidere (anche dopo) se una decisione sia stata giusta o sbagliata, e perchè aspettare più a lungo degli altri partecipanti alla discussione è a volte una tattica vincente.

Il principio che la quantità di discussione è inversamente proporzionale alla complessità dell'argomento ha circolato per molto tempo, ed è noto informalmente come l'Effetto Bikeshed. Segue la spiegazione di Poul-Henning Kamp, da un messaggio ora famoso fatto agli sviluppatori BSD:

(Vale anche la pena leggere il suo messaggio completo. Vedete Appendice C, Perchè dovrebbe importarmi di che colore sia la rastrelliera?; o anche http://bikeshed.com.)

Chiunque abbia mai preso regolarmente parte in qualche gruppo di decision riconoscerà di cosa Kamp sta parlando. Comunque, è solitamente impossibile persuadere tutti di evitare di disegnare rastrelliere. La cosa migliore che possiate fare è precisare che il fenomeno esiste, quando vedete che sta succedendo, e persuadere gli sviluppatori anziani—le persone i cui messaggi hanno maggior peso—di posare i loro pennelli presto, così almeno loro non contribuiscono al rumore. Dipingere rastrelliere non scomparirà mai del tutto, ma potete renderlo più breve e meno frequente diffondendo la coscienza del fenomeno nella cultura del progetto.

Una Guerra Santa è una disputa, spesso ma non sempre riguardo ad un problema relativamente secondario, in cui la gente si sente abbastanza appassionata da continuare a discutere in ogni caso nella speranza che la loro parte prevalga. Le guerre sante non sono come dipingere rastrelliere. La gente che dipinge rastrelliere è solitamente rapida nel saltare su con un'opinione (perchè loro possono), ma non se ne sentiranno necessariamente convinti, infatti potranno a volte esprimere altre opinioni incompatibili, per mostrare che capiscono tutti i versi del problema. In una guerra santa, d'altro canto, capire le altre posizioni è un segno di debolezza. In una guerra santa, tutti sanno che c'è Una Risposta Giusta; solo non sono d'accordo su quale sia.

Una volta che una guerra santa è iniziata, in genere non può essere risolta accontentando tutti. Non fa bene puntualizzare, nella mischia di una guerra santa, che una guerra santa è in corso. Tutti lo sanno già. Purtroppo, un tratto comune delle guerre sante è il disaccordo sulla domanda se la disputa è risolvibile continuando la discussione. Visto da fuori, è chiaro che nessuno schieramento sta cambiando le idee dell'altro. Visto da dentro, l'altro schieramento è ottuso e non sta pensando in modo chiaro, ma ci potrebbero arrivare se pressati abbastanza. Ora, non sto dicendo che non ci sia mai uno schieramento giusto in una guerra santa. A volte c'è—nelle guerre sante a cui ho partecipato, è sempre stato il mio ovviamente. Ma non importa, perchè non c'è un algoritmo per dimostrare in modo convincente che uno schieramento o l'altro abbia ragione.

Un modo comune ma non soddisfacente con cui la gente prova a risolvere le guerre sante è dire "Abbiamo già speso più tempo ed energia discutendo ciò di quanto ne valga la pena! Possiamo per favore semplicemente lasciare stare?" Ci sono due problemi in questo. Primo, questo tempo e questa energia sono già stati spesi e non potranno mai essere recuperati— l'unica domanda è quanto altro sforzo rimane? Se certa gente pensa che solo ancora un poco di discussione porterà il problema alla fine, allora ha ancora senso (dal loro punto di vista) continuare.

L'altro problema nel chiedere di lasciare perdere il problema è che questo è spesso equivalente a permettere ad uno schieramento, lo status quo, di dichiarare la vittoria per mancanza di azioni. E in alcuni casi, lo status quo è comunque noto per essere inaccettabile: tutti sono d'accordo che qualche decisione deve essere presa, qualche azione intrapresa. Lasciare il soggetto sarebbe peggio per tutti di quanto lo sarebbe per qualcuno lasciare perdere. Ma dato che il dilemma si applica ugualmente a tutti, è comunque possibile finire a discutere per sempre su cosa fare.

So how should you handle holy wars?

Allora come dovreste trattare le guerre sante?

La prima risposta è fate in modo che non succedano. Non è una cosa così senza speranza come sembra:

Potete anticipare alcune guerre sante standard: tendono a venire fuori sui linguaggi di programmazione, licenze (vedi sezione chiamata «La GPL e la compatibilità di Licenza» in Capitolo 9, Licenze, Diritti d'Autore e Brevetti), blocco dei reply-to ( vedi sezione chiamata «Il grande dibattito sul 'Rispondi A'» in Capitolo 3, L'Infrastruttura Tecnica ), e alcuni altri argomenti. Ogni progetto solitamente ha una sua guerra santa o due, con cui gli sviluppatori di lunga data diventeranno presto familiari. Le tecniche per fermare le guerre sante, o almeno limitarne i danni, sono sempre le stesse ovunque. Anche se siete convinti che il vostro schieramento abbia ragione, cercate di trovare qualche modo di esprimere simpatia e comprensione per gli argomenti che l'altro schieramento propone. Spesso il problema in una guerra santa è che poichè ogni schieramento ha costruito le proprie mura le più alte possibile, e reso chiero che ogni altra opinione è pura follia, l'atto di arrendersi o cambiare la propria idea diventa psicologicamente intollerabile: sarebbe l'ammissione non solo di aver sbagliato, ma di essere stati certi e comunque aver sbagliato. Il modo in cui potete rendere questa ammissione accettabile per l'altro schieramento è di esprimere voi stessi qualche dubbio—precisamente mostrando che capite gli argomenti che stanno facendo e trovarli almeno interessanti, se non alla fine convincenti. Fate un gesto che dia spazio per un gesto reciproco, e solitamente la situazione migliorerà. Non sarà più facile nè difficile raggiungere il risultato tecnico che volevate, ma almeno potete evitare inutili danni morali al morale del progetto.

Quando una guerra santa non può essere evitata, decidete presto quanto ci tenete, e poi vogliate pubblicamente lasciarla perdere. Quando fate così. potete dire che vi tirate indietro perchè non ne vale la pena, ma non esprimete amarezza e non usate l'occasione per un ultimo colpo agli argomenti dello schieramento opposto. Lasciare perdere è efficace solo quando fatto con grazia.

Le guerre sante sui linguaggi di programmazione sono un po' un caso speciale, perchè spesso sono altamente tecnici, e comunque molte persone si sentono qualificate a prenderne parte, e la posta è molto alta, dato che il risultato può determinare in quale linguaggio una buona parte del codice del progetto sarà scritta. La soluzione migliore è scegliere presto il linguaggio, con l'appoggio degli influenti sviluppatori iniziali, e poi difenderlo per il fatto che è quello per cui siete a vostro agio ad usarlo, non sul fatto che è meglio di qualche altro linguaggio che avrebbe invece potuto essere usato. Non lasciate mai degenerare la conversazione in un confronto accademico sui linguaggi di programmazione ( che sembra accadere in particolare spesso quando qualcuno tira fuori Perl, per qualche ragione); è l'argomento mortale in cui dovete semplicemente rifiutarvi di farvi trascinare.

Per una maggiore conoscenza delle guerre sante, vedi http://catb.org/~esr/jargon/html/H/holy-wars.html, e l'articolo di Danny Cohen che rese popolare il termine, http://www.ietf.org/rfc/ien/ien137.txt.

In ogni discussione su mailing list, è facile per una piccola minoranza dare l'impressione che ci sia un grande problema di dissenso, inondando la mailing list con numerose lunghe email. E' un po' come una guerriglia, tranne il fatto che l'illusione di dissenso diffuso è persino più potente, perchè è divisa in un arbitrario numero di messaggi discreti e la maggior parte della gente non si preoccuperà di tenere traccia di chi ha detto cosa, quando. Avranno la vaga impressione che l'argomento è molto controverso, aspetteranno che la confusione finisca.

Il modo migliore per contrastare questo effetto è puntualizzare chiaramente e fornire prove a supporto di quanto piccolo sia il vero numero dei dissidenti, rispetto a quelli che sono d'accordo. Per incrementare la disparità, potreste voler chiedere privatamente alla gente che è stata quasi sempre zitta, ma che sospettate che sarebbe d'accordo con la maggioranza. Non dite nulla che suggerisca che i dissidenti volessero deliberatamente provare ad accrescere l'impressione che stavano dando. Ci sono possibilità che non lo facessero, e se anche lo avessero fatto, non c'è nessun vantaggio strategico nel puntualizzarlo. Tutto ciò di cui avete bisogno è mostrare i veri numeri in un confronto faccia a faccia, e la gente capirà che la loro percezione della situazione non corrisponde alla realtà.

Questo consiglio non vale solo per problemi con chiare posizioni pro e contro. Vale in ogni discussione dove c'è confusione, ma non è chiaro che la maggior parte della gente consideri il problema in discussione un vero problema. Dopo un po', se siete d'accordo che il problema non vale l'azione, potete vedere che ha fallito nell'ottenere seguito (anche se ha generato molte email), potete semplicemente osservare pubblicamente che non c'è seguito. Se l'effetto "minoranza rumorosa" ha lavorato, il vostro messaggio sembrerà come un respiro di aria fresca. L'impressione della maggior parte della gente della disussione fino a quel momento sarà stata in qualche modo confusa: "Huh, di sicuro sembra che ci sia qualche grosso problema qui, perchè ci sono molti messaggi, ma non riesco a vedere succedere nessun progresso". Spiegando come la forma della discussione la faccia apparire più turbolenta di quando sia davvero, gli date retrospettivamente una nuova forma, in cui la gente può rivedere la propria comprensione di cosa ne veniva fuori.