Capitolo 6. Comunicazione

Non cadete nella trappola di scrivere tutto come se fosse un messaggio di testo per il telefono cellulare. Scrivete frasi complete, mettendo la maiuscola alla prima parola di ogni frase, e usate interruzione di paragrafo dove necessario. Ciò è fondamentale nelle email e in altri scritti strutturati. In IRC o forum similarmente effimeri, va generalmente bene lasciare perdere le maiuscole usare abbreviazioni di espressioni comuni eccetera. Soltanto non portate queste abitudini in forum più formali, persistenti. Email, documentazione, segnalazioni di bug, e altre forme di scrittura pensate per persistere dovrebbero essere scritte usando la grammatica e la sintassi standard, e avere una struttura narrativa coerente Questo non è perchè c'è qualcosa di interiormente buono nel seguire regole arbitrarie, ma piuttosto queste regole non sono arbitrarie: sono evolute nella forme attuali perchè rendono il testo più leggibile, e dovreste seguirle per questa ragione. La leggibilità  è desiderabile non solo perchè significa che più persone capiranno cosa scrivete, ma perchè vi fa apparire come il tipo di persona che usa del tempo per comunicare chiaramente: cioà  qualcuno a cui valga la pena dare attenzione.

Soprattutto per le email, gli sviluppatori esperti di open source hanno stabilito alcune convenzioni:

Mandare solo email di puro testo, no HTML, RichText, o altri formati che potrebbero essere opachi ad alcuni lettori di email di solo testo. Impostate le vostre righe per essere lunghe circa 72 colonne. Non andate oltre le 80 colonne, che sono diventate lo standard de facto della lunghezza di terminale (cioè alcuni usano terminali più larghi, ma nessuno ne usa di più stretti). Facendo le vostre righe un po' meno di 80 colonne, lasciate spazio per alcuni livelli di caratteri di citazione aggiunti nelle risposte di altri senza costringere alla riformattazione del vostro testo.

Usate vere interruzioni di linea. Alcuni programmi di mail fanno una specie di falsa delimitazione di riga, quindi quando state scrivendo una mail, il display mostra delle interruzioni di linea che in realtà  non ci sono. Quando la email viene spedita, potrebbe non avere le interruzioni di linea voi pensiate che abbia, e si disporrà  in maniera orrenda sugli schermi di un po' di gente. Se il vostro programma può usare false interruzioni di linea, cercate una qualche impostazione che possiate attivare per fare in modo di mostrare le vere interruzioni di linea quando scrivete.

Quando si includono output video, stralci di codice, o altro testo preformattato, delimitatelo chiaramente, così che anche un occhio pigro possa facilmente vedere i confini tra le vostre parole e il materiale che state evidenziando. (Non mi sarei mai aspettato di scrivere un consiglio come questo quando iniziai questo libro, ma più avanti su un gran numero di mailing list open source, ho visto gente mischiare testo da diverse fonti senza rendere chiaro cosa fosse cosa. L'effetto è molto frustrante. Rende i loro post decisamente più difficili da capire, e sinceramente fa vedere queste persone come un po' disordinate.)

Quando citate una email di qualcun altro, inserite le vostre risposte dove è più appropriato, in molti posti diversi se necessario, e tagliate via le parti della mail che non usate. Se state scrivendo un breve commento che riguarda all'intero messaggio, va bene anticipare il commento (cioè mettere la vostra risposta al di sopra del testo citato della email); altrimenti, dovreste prima citare la porzione rilevante del testo originale, seguita dalla vostra risposta.

Scegliete attentamente l'oggetto delle vostre email. E' la riga più importante della vostra email, perchè permette ad ogni altra persona nel progetto di decidere se leggerla o meno. I moderni software di lettura email organizzano gruppi di messaggi correlati in thread, che possono essere definiti non solo da un oggetto comune, ma da vari altri header (che a volte non sono mostrati) Ne consegue che se un thread inizia ad andare verso un nuovo argomento, potete—e dovreste—aggiustare di conseguenza l'oggetto quando rispondete. L'integrità  del thread sarà  preservata, grazie a quegli altri header, ma il nuovo oggetto aiuterà  la gente che cerca un'idea del thread a sapere che il soggetto è cambiato. Similarmente, se davvero volete iniziare un nuovo argomento, fatelo mandando una nuova email, e non rispondendo a email esistenti e cambiandone l'oggetto. Altrimenti, la vostra email sarebbe ancora raggruppata con quelle dello stesso thread a cui state rispondendo, e quindi confonderebbe la gente nel pensare che sia su qualcosa che non è. Di nuovo, la pena non sarebbe solo lo spreco del loro tempo, ma la piccola falla nella vostra credibilità  come qualcuno spigliato nell'uso dei mezzi di comunicazione.

Email ben formattate attraggono i lettori, ma il contenuto li mantiene. Nessun insieme di regole fisse può garantire un buon contenuto, certo, ma ci sono alcuni principi che lo rendono possibile.

Rendete le cose facili ai vostri lettori. Ci sono tonnellate di informazioni in giro in ogni progetto open source attivo, e non ci si può aspettare che i lettori siano familiari con la maggior parte dell'informazione—infatti, non ci si può aspettare che sappiano come diventarne familiari. Ovunque possibile, i vostri messaggi dovrebbero fornire informazione nella forma più appropriata per i lettori. Se dovete usare due minuti in più per cercare una URL di un particolare thread negli archivi della mailing list per risparmiare ai lettori di farlo, ne vale la pena. Se dovete spendere 5 o 10 minuti riassumendo le conclusioni fino a questo punto di un thread complesso, così da dare alla gente un contesto in cui capire il messaggio,allora fate così. Pensatela in questo modo: più un progetto ha successo, più alto sarà  il rapporto lettori per scrittore in ogni dato forum. Se ogni messaggio che pubblicate è visto da n persone, allora quando n cresce, la convenienza di fare uno sforzo extra per risparmiare tempo a questa gente sale con lui. E quando la gente vi vede imporre a voi stessi questo standard, lavorerà  per fare altrettanto nelle loro comunicazioni. Il risultato è, idealmente, un aumento dell'efficienza globale del progetto: quando c'è una scelta tra che n persone facciano uno sforzo e una persona farlo, il progetto preferisce la seconda ipotesi.

Non perdetevi in iperboli. Esagerare nei messaggi in linea è una tipica corsa alle armi. Per esempio, una persona che segnala un bug potrebbe preoccuparsi che gli sviluppatori non gli presteranno sufficente attenzione, quindi lo descriverà  come un problema serio e bloccante che sta impedendo a lui (e a tutti i suoi amici/colleghi/cugini) di usare il software in maniera produttiva, quando è soltanto una piccola noia. Ma l'esagerazione non è limitata agli utenti—i programmatori a volte fanno lo stesso durante dibattiti tecnici, in particolare quando il disaccordo è su di una questione di gusto piuttosto che di correttezza:

Lo stesso sentimento in realtà  diventa più forte quando espresso in maniera meno netta:

Non sarete in grado di liberarvi completamente dalle iperboli, e in generale non è necessario. Rispetto ad altre forme di cattiva comunicazione, l'iperbole non è globalmente dannosa—danneggia principalmente chi la fa. I destinatari possono compensarla, soltanto il mittente perde un po' più credibilità  ogni volta. Quindi, per l'amore della vostra stessa influenza nel progetto, provate a stare nel lato della moderazione. In questo modo, quando voi avete bisogno di fare un'affermazione forte, la gente vi prenderà  seriamente.

Controllate due volte. Per ogni messaggio più lungo di un paragrafo di media grandezza, rileggetelo dall'inizio alla fine prima di mandarlo ma dopo che pensate di averlo finito una prima volta. Questo è un consiglio noto a chiunque abbia seguito lezioni di composizione, ma è soprattutto importante nelle discussioni online. Dato che il processo di comporre online tende ad essere altamente discontinuo (durante la scrittura di un messaggio, potreste aver bisogno di andare indietro e controllare altre email, visitare alcune pagine web, usare un comando per catturare il suo output di debug eccetera) è incredibilmente facile perdere il vostro senso di posizione nella narrazione. I messaggi che sono stati composti in maniera discontinua e non controllati prima di essere inviati sono spesso riconoscibili come tali, soprattutto dallo smarrimento ( o così si dovrebbe sperare) dei loro autori. Prendetevi del tempo per rivedere cosa mandate. Più i vostri messaggi stanno assieme strutturalmente, più saranno letti.

Dopo aver scritto migliaia di messaggi, probabilmente noterete il vostro stile diventare conciso. Questa sembra essere la norma nella maggior parte dei forum tecnici, e non c'è nulla di sbagliato di per sè. Un grado di concisione che sarebbe inaccettabile nelle normali interazioni sociali è semplicemente la normalità  per chi ha a che fare con il free software. Qui c'è una risposta che una volta presi da una mailing list su qualche CMS (content management system) ben in evidenza:

Puoi spiegare un po' di più esattamente qual'è il tuo problema,eccetera?

Anche:

Che versione di Slash stai usando? Non l'ho capito dal tuo precedente messaggio.

Esattamente, come hai fatto il build del codice apache/mod_perl?

Hai provato la patch di Apache 2.0 di cui si è parlato su slashcode.com?

  Shane

Ora, questo è conciso! Nessun saluto, nessuna firma a parte il nome, e il messaggio stesso è solo un serie di domande poste nel modo più compatto possibile. La sua unica frase dichiarativa era una implicita critica al mio messaggio originale. Eppure, fui felice di vedere la email di Shane, e non presi la sua concisione come segno di nient'altro se non essere una persona occupata. Il mero fatto che stava chiedendo domande, invece di ignorare il mio messaggio, significava che voleva spendere del tempo sul mio problema.

Tutti i lettori reagiranno positivamente al suo stile? Non necessariamente; dipende dalla persona e dal contesto. Per esempio, se qualcuno ha appena scritto riconoscendo di aver fatto un errore (magari aveva segnalato un bug), e sapete dalla vostra esperienza passata che questa persona tende ad essere un po' insicura, allora mentre potreste scrivere una risposta compatta, dovreste fare in modo di completarlo con un qualche tipo di presa di coscienza dei suoi sentimenti. Il grosso della vostra risposta può essere una precisa, ingegneristica analisi della situazione, concisa quanto volete. Ma alla fine, scrivete qualcosa che indichi che la vostra concisione non deve essere presa per freddezza. Per esempio, se avete appena dato una gran quantità  di consigli esattamente su come la persona deve riparare il bug, poi concludete con "Buona fortuna, <il vostro nome>" per indicare che gli augurate del bene e che non è pazzo. Uno smiley strategicamente piazzato o altro genere di emoticon può a volte essere anche abbastanza per rassicurare un interlocutore.

Può sembrare strano focalizzarsi tanto sui sentimenti dei partecipanti quanto sulla superficie di cosa dicono, ma per dirla semplicemente, i sentimenti condizionano la produttività . I sentimenti sono importanti anche per altre ragioni, ma anche limitandoci a livelli puramente utilitaristici, possiamo notare che persone infelici scrivono software peggiore, e meno. Data la natura ristretta della maggior parte dei media elettronici, comunque, non ci sarà  spesso alcuna indicazione di come una persona si sente. Dovrete farvi una educata idea basata su a) come la maggior parte della gente si sentirebbe in quella situazione, e b) cosa sapete di questa particolare persona da passate interazioni. Alcune persone preferiscono un atteggiamento diretto, e trattare semplicemente con chiunque come fossero faccia a faccia, con l'idea che se un partecipante non tira fuori che si sente in un particolare modo, allora uno non ha modo di trattare con lui come dovrebbe. Non seguo questo approccio, per alcune ragioni. Uno, la gente non si comporta così nella vita reale, quindi perchè dovrebbero online? Due, dato che la maggior parte delle interazioni avviene in forum pubblici, la gente tende ad essere ancora più riservata nell'esprimere emozioni che se fosse in privato. Per essere più precisi, spesso vogliono esprimere emozioni dirette agli altri, come gratitudine o rabbia, ma non emozioni dirette verso se stessi, come insicurezza o orgoglio. Comunque, la maggior parte degli umani lavora meglio quando sanno che gli altri sono al corrente del loro stato di pensiero. Prestando attenzione a piccoli indizi, potete solitamente indovinare giusto la maggior parte delle volte, e motivare la gente a rimanere coinvolta ad un livello maggiore di quello che altrimenti farebbero.

Certo non voglio dire che il vostro ruolo sia di essere un terapista di gruppo, aiutanto costantemente tutti a rimanere in contatto con i loro sentimenti. Ma facendo molta attenzione ai percorsi sul lungo periodo del comportamento umano, inizierete ad avere un'idea di loro come individui anche se non li avete mai incontrati faccia a faccia. Ed essendo sensibile al tono del vostro scrivere, potete avere una sorprendente influenza su come gli altri si sentono, per il bene finale del progetto.

Una delle caratteristiche distintive della cultura open source è la sua nozione di cosa costituisce maleducazione e cosa no. Mentre le convenzioni descritte in seguito non sono peculiari dello sviluppo di software libero, nè del software in generale— dovrebbero essere familiari a chiunque lavori in matematica, scienze dure, o discipline ingegneristiche—il software libero, con i suoi confini porosi e il costante afflusso di nuove leve, è un ambienete dove la gente non abituata a queste convenzioni si contri con loro.

Cominciamo con le cose che non sono maleducate:

Il criticismo tecnico, anche quando diretto e non filtrato, non è maleducato. Invece, può essere una forma di adulazione: la critica sta dicendo, per implicazione, che vale la pensa prendere seriamente in considerazione il suo bersaglio, e vale la pena spenderci un po' di tempo. Vale a dire, più sarebbe stato facile ignorare il post di qualcuno, più diventa un complimento prendere del tempo per criticarlo (ovviamente a meno che la critica diventi un attacco ad hominem o qualche altra farma di palese maleducazione).

Anche domande grezze e spoglie, come quelle di Shane a me nella mail prima citata, non sono maleducate. Domanede che in altri contesti sembrano fredde, retoriche o persino ironiche, sono spesso intese come serie, e non hanno nessun obbiettivo nascosto tranne ottenere informazioni il più velocemente possibile. La famosa domanda del supporto tecnico "Il tuo computer è attaccato alla corrente?" è un classico esempio di questo. La persona di supporto davvero ha bisogno di sapere se il tuo computer è attaccato alla corrente, e dopo i primi giorni di lavoro, si è stancato di premettere alla domanda qualche educato preambolo ("Chiedo scusa, vorrei soltanto farle alcune semplici domande per escludere alcune possibilità. Alcune di queste sono molto elementari,ma mi aiuti..."). A questo punto, non gli interessano più i preamboli, chiede direttamente: è attaccato o no? Domande simili sono fatte di continuo nelle mailing list di software libero. L'intento non è insultare il destinatario, ma per escludere velocemente le spiegazioni più ovvie ( e magari le più comuni). I destinatari che capiscono questo e rispondono di conseguenza, guadagnano punti nell'ottenere una visione ampia senza chiedere pressantemente. Ma i destinatari che reagiscono male non devono essere neanche esclusi. E' solo uno scontro di culture, non è colpa di nessuno. Spiegate amabilmente che le vostre domande (o critiche) non avevano significati nascosti; erano solo tesi ad ottenere (o trasmettere) informazioni nel modo più efficiente possibile, nient'altro.

Cos'è allora maleducato?

Per lo stesso principio per cui un dettagliato criticismo tecnico è una forma di adulazione, non fornire critica di qualità può essere un insulto. Non intendo semplicemente ignorare il lavoro di qualcuno, sia esso una proposta, un cambiamento al codice, la segnalazione di un nuovo problema o altro. A meno che non abbiate esplicitamente promesso in anticipo una risposta dettagliata, va solitamente bene semplicemente non rispondere per niente. La gente assumerà che non avevate tempo di dire nulla. Ma se rispondete, non risparmiate; prendete il tempo per analizzare davvero le cose, fornire esempi concreti dove appropriato, spulciare negli archivi per cercare post correlati nel passato eccetera. O se non avete tempo di imbarcarvi in questo tipo di sforzo, ma tuttavia avete bisogno di scrivere qualche tipo di risposta veloce, allora scrivetelo apertamente nel messaggio ("Penso che ci sia un problema registrato per questo, ma sfortunatamente non ho avuto il tempo di cercarlo, mi dispiace"). La cosa principale è riconoscere l'esistenza della norma culturale, o assecondandola o riconoscendo apertamente di non aver avuto tempo. In entrambi i modi, la norma è rispettata. Ma non rispettarla, allo stesso tempo non spiegando perchè non l'avete fatto, è come dire che la discussione (e coloro che vi partecipano) non valeva il vostro tempo. E' meglio mostrare che il vostro tempo è prezioso essendo chiari che essendo pigri.

Ci sono certamente molte altre forme di maleducazione, ma la maggior parte di queste non sono peculiari del software libero, e il senso comune è una sufficiente guida per evitarle. Vedete anche sezione chiamata «Stroncate sul Nascere la Scortesia» in Capitolo 2, Partenza, se non l'avete ancora fatto.

C'è una regione nel cervello umano che è dedicata in maniera specifica al riconoscimento delle facce. E' informalmente nota come 'area fusiforme della faccia', e le sue capacità sono nella maggior parte innate, non imparate. Ne consegue che riconoscere gli individui è talmente una capacità cruciale per la sopravvivenza che abbiamo sviluppato hardware specializzato per farlo.

La collaborazione basata su Internet è quindi psicologicamente strana, perchè implica una stretta collaborazione tra esseri umani che non riescono praticamente mai ad identificarsi l'un l'altro con i metodi più naturali ed intuitivi: il riconoscimento facciale innanzitutto, ma anche il suono della voce, la postura eccetera. Per compensare a questo, provate ad usare un nome immagine consistente ovunque. Potrebbe essere la parte iniziale del vostro indirizzo email (la parte prima del simbolo @), il vostro username IRC, il nome che usate nei commit, lo username del tracciamento dei problemi, eccetera. Questo nome è la vostra "faccia" online : una breve stringa identificativa che provvede ad alcuni degli stessi usi della vostra vera faccia, anche se sfortunatamente non stimola lo stesso hardware integrato nel cervello.

Il nome immagine dovrebbe essere qualche permutazione intuitiva del vostro nome reale (il mio, per esempio, è "kfogel"). In alcune situazioni sarà comunque accompagnato dal vostro nome completo, per esempio nelle testate delle email:

From: "Karl Fogel" <kfogel@whateverdomain.com>

In realtà, ci sono due cose in questo esemio. Come menzionato prima, il nome immagine rimanda al nome reale in modo intuitivo. Inoltre, il nome reale è reale. cioè non è qualche appellativo costruito come:

From: "Fantastico Hacker" <fantasticohacker@undominio.com>

C'è un famosto fumetto di Paul Steiner, del 5 luglio 1993 uscito sul The New Yorker, che mostra un cane loggato ad un computer, guardare in basso e dire ad un altro in modo cospirativo: "In Internet, nessuno sa che sei un cane". Questo tipo di pensiero risiede probabilmente dietro a molte delle identità da fighi, auto-esaltanti che la gente si dà in rete—come se chiamarsi "Fantastico Hacker" farà davvero credere alla gente di esserlo. Ma il fatto rimane: anche se nessuno sa che sei un cane, sei ancora un cane. Una fantastica identità online non impressiona mai i lettori. Invece, li fa pensare che sei più forma che sostanza, o semplicemente che sei insicuro. Usate il vostro vero nome per tutte le interazioni, o se per qualche ragione avete bisogno di anonimato, allora costruite un nome che sembri come un nome perfettamente reale, ed usatelo consistentemente.

Oltre a tenere il vostro nome immagine consistente, ci sono alcune cose che potete fare per renderlo più attraente. Se avete un titolo ufficiale (per esempio "dottore", "professore", "direttore"), non ostentatelo, nè menzionatelo tranne quando è direttamente rilevante nella conversazione. Il mondo hacker in generale, e la cultura del software libero in particolare, tende a vedere l'esposizione del titolo come esclusiva e segno di insicurezza. Va bene se il vostro titolo appare come parte del blocco di firma standard alla fine di ogni email, solo non usatelo mai come mezzo per rinforzare la vostra posizione in una discussione—il tentativo garantisce fuoco di risposta. Volete la gente che rispetta voi, non il titolo.

Parlando dei blocchi di firma: manteneteli brevi e gradevoli, o meglio ancora, inesistenti. Evitate ingombranti disclaimer legali alla fine di ogni email, specialmente quando esprimono sentimenti incompatibili con la partecipazione ad un progetto di software libero. Per esempio, il seguente classico appare alla fine di ogni messaggio che un particolare utente manda su una pubblica mailing list di cui faccio parte:

OSSERVAZIONE IMPORTANTE

Se avete ricevuto questa email per errore o volete leggere il nostro disclaimer
per le email e la politica di monitoraggio, per favore fate riferimento sotto o contattate
il mittente.

Questa comunicazione proviene da Deloitte & Touche LLP.  Deloitte &
Touche LLP è una società a responsabilità limitata registrata in Inghilterra e Galles con
il numero registrato OC303675. Una lista dei nomi dei membri è disponibile
per ispezioni a Stonecutter Court, 1 Stonecutter
Street, London EC4A 4TR, United Kingdom, la sede principale dell'attività ed ufficio registrato. 
Deloitte & Touche LLP è autorizzato e regolato dalla Financial Services Authority.

Questa comunicazione e tutti gli allegati contengono
informazioni che sono confidenziali e possono essere legalmente protette.
Sono per l'uso esclusivo dei destinatari. Se non siete il destinatario, per favore
notate che ogni forma di comunicazione, pubblicazione, copia o uso di questa comunicazione
o delle informazioni contenute o degli allegati è strettamente proibita e può essere illegale.
Se avete ricevuto questa comunicazione per errore, per favore rimandatela con "ricevuta per errore"
come oggetto a to IT.SECURITY.UK@deloitte.co.uk e poi cancellate la email e distruggetene ogni copia.

Non si può garantire che le comunicazioni email siano sicure e senza errori,
dato che le informazioni possono essere intercettate, corrotte, stralciate, perse,
distrutte, in ritardo o incomplete, o contenenti virus. Non ci assumiamo
la responsabilità di nessuno di questi fatti o delle loro conseguenze. Chiunque comunichi
con noi via email accetta il rischio di farlo.

Quando inviate ai nostri clienti, tutti le opinioni o i consigli contenuti in questa
email ed ogni allegato sono soggetti ai termini e alle condizioni espresse nella lettera
di ingaggio del cliente in uso a Deloitte & Touche LLP.

Opinioni, conclusioni e altre informazioni in questa email e tutti gli allegati che non
riguardano gli affari ufficiali della ditta non sono da lei forniti nè supportati.

Per qualcuno che si mostra appena per chiedere qualcosa ogni tanto, questo enorme disclaimer sembra un po' strano ma probabilmente non fa male. Comunque, se questa persona volesse partecipare attivamente al progetto, questa sbrodolata legale inizierebbe ad avere effetti più insidiosi. Manderebbe almeno due segnali potenzialmente distruttivi: primo, che questa persona non ha pieno controllo dei suoi strumenti—è intrappolato in qualche programma di posta aziendale che appioppa un noioso messaggio alla fine di ogni email, e non ha avuto modo di evitarlo— e, secondo, che ha poco o nessun supporto organizzativo per le sue attività di software libero. Si che l'organizzazione chiaramente non gli ha impedito di lasciare messaggi sulle mailing list, ma ha fatto sembrare i suoi messaggi nettamente ostili, come se il rischio di far uscire informazioni confidenziali debba smorzare tutte le altre priorità.

Se lavorate in un'azienda che insiste nell'aggiungere tali blocchi di firma a tutte le email in uscita, allora cercate di avere un account email gratis come, per esempio, gmail.google.com, www.hotmail.com, o www.yahoo.com, e usare questo come indirizzo per il progetto.