Comunicazione
L'abilità di scrivere chiaramente è forse la più importante capacità
che uno possa avere in un ambiente open source. Sulla lunga distanza, importa
più del talento nella programmazione. Un bravo programmatore con pessime capacità
di comunicazione fare una sola cosa per volta, e comunque avere dei problemi a
convincere altri a prestargli attenzione. Ma un pessimo programmatore con buone
capacità comunicative può coordinare e persuadere molte persone a fare molte
cose diverse, quindi avere un effetto significativo sulla direzione e sulla forza
del progetto.
Non sembra esserci molta correlazione, in nessuna direzione, tra l'abilità
di scrivere buon codice e l'abilità di comunicare con i propri simili. C'è una qualche
correlazione tra la buona programmazione e una buona descrizione dei problemi tecnici, ma
descrivere problemi tecnici è solo una piccola parte della comunicazione in un progetto.
Molto più importante è l'abilità di identificarsi con la audience di qualuno, di vedere i propri
post e commenti come altri li vedono, e di fare in modo che altri vedano i loro post con
simile oggettività .
Altrettanto importante è notare quando un certo mezzo di comunicazione non sta più
lavorando bene, magari perchè non scala al crescere del numero di utenti, e prendere
tempo per farci qualcosa.
Tutto questo è in teoria ovvio—cosa lo rende difficile in pratica
è che gli ambienti di software libero sono
practice is that free software development environments are
incoerentemente diversi sia nelle audience che nei meccanismi di comunicazione.
Un certo pensiero deve esserre espresso in un messaggio sulla mailing list, come
annotazione nel bug tracker o come commento nel codice? Quando rispondere ad una domanda
in forum pubblico, quanta conoscenza si può assumere esistere dal lato di chi legge, dato che
"chi legge" non sempre è solo chi ha posto la domanda all'inizio, ma tutti quelli che potrebbero
vedere la risposta?
Come possono gli sviluppatori stare in contatto costruttivo con gli utenti, senza essere
sommersi dalle richieste di funzionalità , scarne segnalazioni di bug e chiacchiera generale?
Come dire quando un canale ha raggiunto i limiti della sua capacità , e cosa farci?
Le soluzioni a questi problemi sono solitamente parziali, perchè ogni singola soluzione
è alla fine resa obsoleta dalla crescita del progetto o dai cambiamenti nella struttura del progetto.
Sono anche spessoad
hoc, perchè sono improvvisato risposte a situazioni dinamiche.
Tutti i partecipanti possono diventare consci di quando e come la comunicazione può crollare,
ed essere coinvolti nelle soluzioni. Aiutare la gente a fare questo è una grossa parte della gestione
di un progetto open source. Le sezioni che seguono trattano sia di come portare avanti la propria comunicazione.
e di come rendere una priorità la cura dei meccanismi di comunicazione per tutti nel progetto.
C'è stata un po' di interessante ricerca accademica su questo argomento; per esempio vedi
Group Awareness in Distributed Software
Development di Gutwin, Penner, e Schneider. Questo articolo è stato online per un po', poi non disponibile,
quindi online di nuovo a .
Quindi provate lì prima, ma siate pronti ad usare un motore di ricerca se si è di nuovo spostato.
Sei quello che scrivi
Considerate questo: la sola cosa che ognuna sa di voi su Internet viene
da quello che scrivete, o cosa altri scrivono di voi. Potrete essere brillanti,
attenti e carismatici di persona—ma se le vostre email sono confusionarie
e non strutturate, la gente assumerà che siate così. O magari siete davvero confusionari
e disordinati di persona, ma nessuno ha bisogno di saperlo, se i vostri messaggi sono lucidi
e informativi.
Dedicare un po' di cura alla vostra scrittura vi ripagherà enormemente.
Lo smanettone di lunga data di free software Jim Blandy racconta la seguente storiella;
Nel 1993, stavo lavorando per la Free Software Foundation,
e stavamo facendo il beta testing della versione 19 di GNU Emacs.
Facevamo un rilascio della beta all'incirca ogni settimana, e la gente
la provava e ci mandava le segnalazioni di bug. C'era questo tizio ch
nessuno di noi aveva mai incontrato di persona ma che faceva un gran lavoro:
le sue segnalazioni di bug erano sempre chiare e ci portavano dritti al problema,
e quando ci forniva un fix lui stesso, era quasi sempre corretta. Era incredibile.
Prima che la FSF possa usare codice scritto da qualcun altro, dobbiamo fargli fare
alcune pratiche legali per assegnare i diritti di copyright per quel codice alla FSF. Solo
prendere codice da perfetti sconosciuti e buttarlo lì è la ricetta per un disastro legale.
Ho mandato una email al tizio con le pratiche, dicendo, "Qui ci sono
alcune pratiche di cui abbiamo bisogno, qui c'è cosa significa, firmi questa, fai firmare
al tuo datore di lavoro quest'altra, e poi possiamo iniziare a integrare i tuoi fix. Grazie mille."
Mi risponde dicendo "Non ho un datore di lavoro."
Allora gli dico, "OK, va bene, fallo firmare dalla tua università e mandacelo indietro."
Dopo un po' mi risponde di nuovo e dice, "Bè, veramente... ho tredici anni e vivo con i miei genitori."
Dato che il ragazzino non scriveva come un tredicenne, nessuno sapeva che lo fosse. In seguito ci sono alcuni
modi per far fare una buona impressione anche alla vostra scrittura.
Struttura e Formattazione
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.
Contenuto
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:
"Fare in questo modo renderebbe il codice totalmente
illegibile. Sarebbe un incubo mantenerlo, rispetto alla proposta di
J. Random..."
Lo stesso sentimento in realtà diventa
più forte quando espresso in maniera meno netta:
"Funziona, ma non è ideale in termini di leggibilità e mantenibilità , io penso.
La proposta di J.Random evita questi problemi perchè..."
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.
Tono
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.
Riconoscere la maleducazione
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
in
, se non l'avete ancora fatto.
Facce
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, ,
, o , e usare questo come indirizzo per il progetto.
Evitare le Trappole Comuni
Non mandare messaggi senza motivo
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:
Messaggi che propongono qualcosa di non banale
Messaggi che esprimono supporto od opposizione a qualcosa che qualcun
altro ha detto
Messaggi di ricapitolazione
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 per ulteriori pensieri su come comportarsi su mailing list trafficate.)
Thread Produttivi vs Thread Improduttivi
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?
Argomenti che hanno già iniziato ad essere ripetuti, dato che
chi ha scritto pensa che nessuno li abbia sentiti la prima volta.
Aumento dei livelli di iperbole e coinvolgimento dato che
i limiti si fanno sempre più stretti.
Una preponderanza di commenti di persone che fanno poco
o niente, mentre le persone che tendono a fare le cose sono in silenzio.
Molte idee discusse senza che una chiara proposta sia stata fatta.
(Certo, ogni idea interessante nasce da una visione imprecisa; la domanda importante è in
quale direzione si va da lì. Il thread sembra voler cambiare la visione in
qualcosa di più concreto, o stanno nascendo sotto-visioni, visioni laterali e dispute ontologiche?)
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:
Questa discussione non sta andando da nessuna parte. Possiamo per favore
abbandonare questo argomento finchè qualcuno ha una patch per implementare una di queste
proposte? Non c'è ragione per continuare a girarci attorno dicendo le stesse cose. Il
codice parla più forte delle parole, gente.
Mentre questo è buono:
Molte proposte sono passate in questo thread, ma
nessuna ha avuto tutti i dettagli definiti, almeno non abbastanza
per un voto si/no. Comunque non stiamo dicendo nulla di nuovo ora;
stiamo solo ripetendo cosa è stato detto prima. Quindi la cosa migliore
sarebbe probabilmente che i prossimi messaggi contengano o una completa
specifica delle funzionalità proposte, o una patch. Quindi almeno avremmo una
azione definita da compiere (cioè avere consenso sulla specifica, o applicare
e testare la patch).
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.
Più semplice l'argomento, più lungo il dibattito
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:
E' una lunga storia, o meglio è una vecchia storia, ma in realtà
è abbastanza breve. C. Northcote Parkinson scrisse un libro nei primi anni 60, chiamato
"Parkinson's Law" ("Legge di Parkinson"), che contiene molti aspetti delle dinamiche della
gestione.
[...]
Nello specifico esempio che coinvolge la rastrelliera delle biciclette,
l'altro componente vitale è una centrale atomica, penso che questo illustri l'età del libro.
Parkinson mostra come puoi andare nell'ufficio del direttore e ottenere
l'approvazione per costruire una centrale atomica da milioni o persino miliardi di dollari,
ma se volete costruire una rastrelliera per le biciclette sarete bloccati in discussioni
senza fine.
Parkinson spiega che questo accade perchè una centrale atomica è così vasta,
così costosa e così complicata che la gente non può percepirla, e piuttosto che provarci,
ricadono nell'assunzione che qualcun altro abbia controllato tutti i dettagli prima di andare
così avanti. Richard P. Feynmann da alcuni esempi interessanti e molto pertinenti, riguardanti
Los Alamos nei suoi libri.
Dall'altro lato una rastrelliera per bici. Chiunque può costruirne una in un fine settimana,
e ancora avere il tempo di guardare la partita in TV. Quindi non importa quanto ben preparato, quanto
ragionevole con la vostra proposta, qualcuno coglierà la possibilità di mostrare che sta facendo il suo
lavoro, che sta prestando attenzione, che èqui.
In Danimarca lo chiamiamo "lasciare l'impronta". Riguarda l'orgoglio personale e il prestigio,
si tratta di essere in grado di indicare da qualche parte e dire "Qui! io l'ho fatto."
E' un importante tratto nei politici, ma presente in molta gente se viene data l'occasione. Pensate ai passi
nel cemento fresco.
(Vale anche la pena leggere il suo messaggio completo. Vedete ; o anche
.)
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.
Evitare le Guerre Sante
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
in ), blocco dei reply-to ( vedi
in
), 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 , e l'articolo di Danny Cohen
che rese popolare il termine, .
L'Effetto "Minoranza Rumorosa"
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.
Gente Difficile
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.
Gestire la Gente Difficile
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.
Caso di Studio
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
in
). 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.
Gestire la Crescita
Il prezzo della crescita è pesante nel mondo dell'open source. Come il vostro software diventa più popolare, il numero di persone che compaiono alla ricerca di informazioni cresce in modo sensazionale, mentre il numero delle persone in grado di dare le informazioni cresce molto meno lentamente. Inoltre, anche se il rapporto fosse uniformemente bilanciato, ci sarebbe tuttavia un problema fondamentale di scalabilità col modo in cui la maggior parte dei progetti open source gestiscono le comunicazioni. Considerate le mailing list, per esempio. La maggior parte dei progetti hanno una mailing list per le domande degli utilizzatori generici—a volte il nome delle mailing list è “utilizzatori”, “discutere”, “aiuto”, o qualcos'altro. Qualunque sia il nome, il proposito della mailing list è sempre lo stesso: fornire un posto dove la gente possa ricevere risposta alle sue domande, dove gli altri osservano e (presumibilmente) assorbono conoscenze dall'osservazione di questi scambi.
Queste mailing list funzionano molto bene fino a poche migliaia di utilizzatori e/o fino a un paio di centinaia di post al giorno. Ma circa dopo di ciò il sistema incomincia a collassare, perché ogni iscritto vede ogni post. Se il numero dei post alla mailing list incomincia a superare quello che ogni singolo lettore può elaborare in un giorno, la mailing list diventa un carico per i suoi membri. Immaginate, per esempio, che Microsoft abbia una tale mailing list per Windows XP. Windows XP ha centinaia di milioni di utenti; se anche un decimo dell'1% ha domande in un periodo di ventiquattrore, allora questa ipotetica mailing list riceverebbe centinaia di migliaia di post al giorno! Una tale mailing list non potrebbe mai esistere, perché nessuno vorrebbe rimanere iscritto ad essa. Questo problema non è limitato alle mailing list; la stessa logica si applica ai canali IRC, ai forum di discussioni online, indubbiamente ad ogni sistema in cui un gruppo ascolta domande dagli individui. Le implicazione sono sinistre: l'usuale modello open source di supporto in parallelo di massa non si adegua ai livelli necessari per la dominazione del mondo.
Non ci sarà nessuna esplosione quando il forum raggiungerà il punto di rottura. Ci sarà solo un silenzioso effetto di reazione negativa: la gente si cancella l'iscrizione dalle mailing lists, o lascia il canale IRC, o in ogni caso smette di infastidire facendo domande, perché possono vedere che non saranno ascoltati in tutto il rumore. Nella misura in cui sempre più la gente fa questa scelta altamente razionale, l'attività dei forum sembra restare in un livello manovrabile. Ma esso rimane in un livello manovrabile precisamente perché la gente razionale (o almeno con esperienza) ha incominciato a guardare altrove per le informazioni—mentre la gente inesperta rimane dentro e posta continuamente. In altre parole, l'effetto a senso unico di continuare a usare modelli di comunicazioni non ampliabili quando il progetto cresce è quello che la qualità delle domande e delle risposte tende a scendere, il che fa sembrare che i nuovi utilizzatori sono più muti di quanto erano soliti essere, mentre nei fatti probabilmente non lo sono. E' solo che il rapporto beneficio/costo dell'usare questi forums ad alta popolazione scende, così naturalmente quelli con esperienza incominciano per primi a guardare altrove per le risposte. Adattare il meccanismo delle comunicazioni in modo che faccia fronte alla crescita del progetto quindi comporta due strategie:
Riconoscere quando parti particolari di un forum
non stanno soffrendo la crescita illimitata, anche se il forum nella sua interezza la sta soffrendo, e separare quelle parti per creare dei nuove forum specializzati (cioè non permettete che il buono sia trascinato in basso dal cattivo).
Assicurarsi che ci siano fonti di informazione automatizzate disponibili, e che siano mantenute organizzate, aggiornate, e facili da trovare.
La strategia (1) non è difficile di solito. La maggior parte dei progetti partono con un solo forum principale: una mailing list di discussioni generali, nella quale possono essere discussi idee di funzionalità, questioni di progettazione, e problemi di codice. Chiunque sia coinvolto nel progetto è nella mailing list. Dopo un po', di solito diventa chiaro che la mailing list si è evoluta in varie sotto mailing list distinte basate sull'argomento. Per esempio, alcune discussioni sono chiaramente sulla progettazione e sullo sviluppo; altre sono domande degli utilizzatori della varietà “Come faccio X”; può darsi che ci sia una terza famiglia di argomenti centrati sull'elaborazione dei report di bug e su richieste di accrescimento; e così via. Un dato individuo, certo, potrebbe partecipare a molti differenti tipi di discussioni, ma la cosa importante è che non ci sia una grande quantità di sovrapposizioni fra i tipi stessi. Essi potrebbero essere suddivisi in mailing list separate senza causare una pericolosa balcanizzazione, perché le discussioni raramente attraversano i limiti dell'argomento.
In realtà fare queste divisioni è un processo in due tempi. Voi create la nuova mailing list (o il canale IRC, o qualunque altra cosa sia) e poi spendete quanto tempo sia necessario nel rimproverare e nel ricordare alla gente di usare appropriatamente i nuovi forum. Il secondo passo può durare settimane, ma alla fine la gente si farà l'idea. Voi dovete semplicemente considerare importante dirlo a chi invia che il post è stato inviato alla destinazione sbagliata, e farlo in modo visibile, in modo che gli altri siano incoraggiati ad essere di aiuto nell'instradamento. E' anche utile avere una pagina web che fornisca una guida a tutte le mailing list disponibili; la vostra risposta può far riferimento a quella pagina web e, come premio, il destinatario può imparare qualcosa sul cercare nelle linee guida prima di postare.
La strategia (2) è un processo continuo che dura il tempo di vita del progetto e coinvolge molti partecipanti. Certo è in parte questione di avere la documentazione aggiornata (vedere
in
) e assicurarsi di indirizzare la gente lì. Ma è anche molto più di questo; le sezioni che seguono discuteranno questa strategia in dettaglio.
Uso Ben Visibile degli Archivi
Tipicamente tutte le comunicazioni in un progetto open source (eccetto talvolta le conversazioni IRC) vengono archiviate. Gli archivi sono pubblici e vi si possono fare ricerche, e hanno una stabilità informativa: cioè, una volta che un dato pezzo di informazione è registrato in un particolare indirizzo, rimane in quell'indirizzo per sempre.
Usate questi archivi quanto più è possibile, e quanto più in modo visibile possibile. Anche quando sapete la risposta spontanea a qualche domanda, se pensate che c'è un riferimento nell'archivio che contiene la risposta, spendete tempo a riportarla alla luce e fornitela. Ogni volta che fate ciò in modo visibile, qualche persona imparerà che ci sono gli archivi lì, e che cercare in essi può produrre risposte. Anche, riferendovi agli archivi invece di riscrivere il consiglio, rafforzate una norma sociale contro la duplicazione delle informazioni. Perché avere la stessa risposta in due posti differenti? Quando il numero di posti in cui essa può essere trovata è tenuto al minimo, le persone che le hanno trovate prima è molto probabile che ricordino cosa cercare per trovale di nuovo. Riferimenti ben collocati, possono anche contribuire alla qualità dei risultati della ricerca in generale, perchè essi rafforzano il ranking della risorsa obiettivo nei motori di ricerca di Internet.
Ci sono volte in cui la duplicazione delle informazioni ha senso, comunque. Per esempio, supponete che ci sia già una risposta negli archivi, non vostra, che dice:
Pare che in vostri indici di Scanley si siano imbrogliati. Per ripararli fate questi passi:
1. Spegnete il server di Scanley.
2. Fate girare il programma 'sbroglia' che si carica con Scanley.
3. Avviate il server.
Allora, mesi dopo, vedete un altro post che indica che gli indici di qualcuno si sono imbrogliati. Cercate negli archivi e vien fuori la vecchia risposta di sopra, ma vi rendete conto che sono mancanti alcuni passi (forse per errore, o perché il software è cambiato da quando quel post fu scritto). Il modo classico di gestire ciò è postare un nuovo, più completo set di istruzioni, e rendere obsoleto il vecchio post menzionandolo:
Pare che in vostri indici di Scanley si siano imbrogliati. Vedemmo questo problema nel lontano Luglio, e J. Casuale postò una soluzione a http://blahblahblah/blah. Sotto c'è una completa descrizione di come sbrogliare i vostri indici, basata sulle istruzioni di J. Casuale ma che le estende un poco:
1. Spegnete il server di Scanley.
2. Diventate l'utilizzatore col quale il server di Scanley gira.
3. Come tale utilizzatore fate girare il programma 'sbroglia' per gli indici.
4. Fate girare Scanley a mano per vedere se gli indici funzionano ora.
5. Riavviate il server.
(In un mondo ideale, sarebbe possibile attaccare una nota al vecchio post, che dica che c'è una informazione più fresca e che punti al nuovo post. Comunque non so di un nuovo software per l'archiviazione che offra una funzionalità “obsoleto per”, forse perchè sarebbe leggermente complessa da implementarsi in un modo che non violi l'integrità dell'archivio in quanto registrazione parola per parola. Questa è un'altra ragione perché creare pagine dedicate con risposte alle domande comuni è una buona idea).
Negli archivi probabilmente si ricerca di più per risposte a domande tecniche, ma la loro importanza per i progetto va ben al di là di questo. Se le linee guida formali di un progetto sono la sua legge statutaria, gli archivi sono la sua legge comune: una registrazione di tutte le decisioni prese e di come sono arrivate là. In ogni discussione ricorrente è quasi obbligatorio oggigiorno partire con una ricerca nell'archivio. Questo ti permette di incominciare una discussione con un sommario dello stato corrente delle cose, di anticipare obiezioni, di preparare i rifiuti, e possibilmente di scoprire degli angoli a cui non avevate pensato. Anche, gli altri partecipanti si aspetteranno che abbiate fatto una ricerca nell'archivio. Anche se le discussioni precedenti non andarono da nessuna parte, voi dovreste includere dei puntatori ad esse quando balza si di nuovo l'argomento (così la gente può guardare da sé) che non a) andarono da nessuna parte e probabilmente diranno ora ciò che non è stato detto prima b) che voi avete fatto i vostri compiti, e quindi state probabilmente dicendo cose che non sono state dette prima.
Trattate Tutte le Risorse Come un Archivio
Tutti i precedenti consigli si applicano a più che ai soli archivi delle mailing lists. L'avere particolari pezzi di informazione in stabili indirizzi che si possono trovare convenientemente dovrebbe essere un principio organizzativo di tutte le informazioni del progetto. Lasciatemi portare le FAQ del progetto come caso di studio.
Come la gente usa le FAQ?
Essi vogliono cercare in esse per parola e frase.
Essi vogliono guardarle per assorbire informazioni senza necessariamente guardare per risposte a domande specifiche.
Essi si aspettano dei motori di ricerca come Google per conoscere il contenuto delle FAQ, così le ricerche possono dar luogo a nuove voci nelle FAQ.
Essi vogliono essere in grado condurre altre persone direttamente a specifiche voci nelle FAQ.
Essi vogliono essere capaci di aggiungere materiale nuovo alle FAQ, ma notate che questo avviene molto meno spesso di quanto siano cercate le risposte—Le FAQ sono molto spesso più lette che scritte.
Il punto 1 implica che le FAQ dovrebbero essere disponibili in una sorta di formato testuale. I punti 2 e 3 implicano che le FAQ dovrebbero essere disponibili in una pagina Html, con il punto 2 che indica addizionalmente che l'Html dovrebbe essere creato per la leggibilità (cioè, vorrete qualche controllo sul loro aspetto e percezione), e dovrebbero avere una tavola dei contenuti. Il punto 4 significa che ad ogni nuova voce delle FAQ dovrebbe essere assegnata una
ancora con nome, un tag che permette alla gente di raggiungere una particolare locazione nella pagina. Il punto 5 significa che i file sorgenti delle FAQ dovrebbero essere disponibili in un modo adatto (vedere in
), in un formato che sia facile da editare.
Ancore con nome e attributi ID
Ci sono due modi per ottenere che il browser salti ad un determinata locazione: le ancore con nome e gli attributi id.
Una ancora con nome è appunto un normale elemento Html (<a>...</a>), ma con un attributo “name”:
<un name=”miaetichetta”>...</a>
Versioni più recenti di Html supportano un attributo id generico, che può essere attaccato ad un elemento Html, non solo <a>. Per esempio:
<p id=”miaetichetta”>...</p>
Ambedue gli attributi id e le ancore con nome sono usati nello stesso modo. Uno aggiunge un segno hash e l'etichetta a un URL per far si che il browser salti dritto a quel punto nella pagina:
http://myproject.example.com/faq.html#miaetichetta
Virtualmente tutti i browsers supportano le ancore con nome; la maggior parte dei browsersa moderni supportano l'attributo id. Per farlo funzionare con sicurezza io raccomanderei di usare sia le ancore con nome da sole
sia gli attributi id insieme (con la stessa etichetta per ambedue in una data coppia, certo). Le ancore con nome non possono essere a chiusura automatica, anche se non c'è testo dentro l'elemento, voi lo potete scrivere in una forma di due tipi:
<a name="mia etichetta"></a>
...sebbene normalmente ci sarebbe lì qualche testo, come il titolo di una sezione.
Se usate l'ancora con nome o l'attributo id, o ambedue, ricordate che l'etichetta non sarà visibile a qualcuno che osserva verso quella locazione senza usare l'etichetta. Ma una tale persona potrebbe voler scoprire l'etichetta di una locazione particolare, in modo che possa inviare per email l'URL di una risposta delle FAQ a un amico, per esempio. Per aiutarlo a fare questo aggiungete un attributo title allo stesso elemento(i) a cui aggiungeste il “nome” e/o l'attributo id, per esempio:
<a name=”miaetichetta” title=”miaetichetta”>...</a>
Quando il puntatore del mouse viene mantenuto sopra il testo all'interno dell'elemento con l'attributo id, la maggior parte dei browsers esporranno un piccolo box di popup che mostra il titolo, Io di solito includo il segno hash, a ricordare all'utilizzatore che ciò è quello che metterebbe alla fine dell'URL per saltare dritto a q uesta locazione la prossima volta.
Formattare così le FAQ è solo un esempio di come rendere presentabile una risorsa. La stesse qualità la ricerca diretta, la disponibilità nei principali motori di ricerca di Internet, la facilità di consultazione, la stabilità referenziale, a e (dove applicabile) l'editabilità—si applicano si applicano ad altre pagine web, all'albero del codice sorgente, al tracciatore di bug, ecc.. Appunto avviene che la maggior parte delle mailing list che archiviavano il software molto tempo fa si resero conto dell'importanza di queste qualità, che il motivo per cui le mailing list tendono ad avere queste funzionalità alla nascita, mentre altri formati possono richiedere qualche sforzo extra da parte di quelli che hanno la manutenzione
( discute come suddividere il carico della manutenzione fra molti volontari).
La Tradizione della Codifica
Nella misura in cui un progetto acquista anzianità e complessità, la quantità di dati che ogni partecipante che arriva deve assorbire cresce. Coloro che sono stati col progetto per lungo tempo saranno in grado di imparare, e inventare, le convenzioni del progetto nella misura in cui andarono avanti. Essi spesso non saranno consapevolmente al corrente di quale enorme corpo di tradizione hanno accumulato, e possono essere sorpresi di fronte a quanti passi falsi sembrano fare i nuovi arrivati. Certo, il fatto non è che i nuovi arrivati siano di qualche qualità inferiore di prima; è che essi sono di fronte a un più grande carico di acculturazione rispetto ai nuovi arrivati del passato.
L'anzianità che il progetto accumula è tanta nel comunicare e nel preservare le informazioni quanta essi ne hanno negli standard del codice e altre minuterie tecniche. Noi abbiamo dato un'occhiata a tutti e due i tipi di standard in
in e
in
rispettivamente e gli esempi sono dati lì. Ciò di cui tratta questa sezione è come mantenere le linee guida aggiornate nella misura in cui il progetto si evolve, specialmente le linee guida su come sono trattate le comunicazioni, perché queste sono le uniche che cambiano al massimo grado nella misura in cui il progetto cresce in grandezza e complessità.
Primo, prestate attenzione ai motivi per i quali la gente si confonde. Se vedete la stessa situazione presentarsi ancora e ancora, specialmente con i nuovi partecipanti. La possibilità che c'è è è una linea guida che necessita di di essere documentata e non lo è. Secondo, non vi stancate di dire la stessa cosa ancora e ancora, e non suonate come se siete stanchi di dirle. Voi e i veterani di altri progetti dovete ripeterlo a voi stessi; questo è un effetto inevitabile dell'arrivo di nuovi arrivati.
Ogni pagina web, ogni messaggio della mailing list, ed ogni canale IRC dovrebbe essere considerato uno spazio per i consigli, non per pubblicità, eccetto che per pubblicità delle risorse del vostro progetto. Ciò che mettete in quello spazio dipende dalla demografia di quelli che lo leggono. Un canale IRC per le domande degli utilizzatori, è, per esempio, adatto a portare gente che che non ha mai interagito col progetto prima—spesso qualcuno che ha appena installato il software e ha una domanda a cui vorrebbe venga risposto immediatamente (dopotutto, se potesse aspettare, l'avrebbe mandata alla mailing list, che probabilmente meno meno del suo tempo totale, sebbene ci vorrebbe di più perché ne venga indietrouna risposta). La gente di solito non fa un investimento permanente nel canale IRC; essi si presentano, fanno la loro domanda, e vanno via.
Quindi l'argomento del canale dovrebbe essere diretto a persone che cercano risposte tecniche sul software adesso, piuttosto che a, diciamo, a persone che potrebbero essere coinvolte nel progetto nel lungo termine e per i quali le linee guida di interazione della comunità potrebbero essere più appropriate. Qui è come un canale occupato gestisce ciò (comparate questo col precedente esempio in
in
):
State parlando su #linuxhelp
L'argomento per #linuxhelp è Prego LEGGERE
http://www.catb.org/~esr/faqs/smart-questions.html &&
http://www.tldp.org/docs.html#howto PRIMA di fare domande | Le regole del canale si trovano a http://www.nerdfest.org/lh_rules.html | Prego consultare
http://kerneltrap.org/node/view/799 prima di chiedere di aggiornare al kernel 2.6.x | lettura di memoria possibile: http://tinyurl.com/4s6mc ->
aggiornare a 2.6.8.1 o 2.4.27 | in certa misura disastro hash: http://tinyurl.com/6w8rf
| reiser4 fuori
Con le mailing list lo “spazio pubblicitario” è una piccola è un piccolo spazio in basso attaccato ad ogni messaggio. La maggior parte dei progetti vi mettono lì le istruzioni iscrizione/deiscrizione, e magari un puntatore alla homepage oppure alla pagina delle FAQ. Voi potreste pensare che chi si è iscritto alla mailing list saprebbe dove trovare queste cose ed essi probabilmente lo sanno—ma molta più gente di quelli che si sono iscritti vedono questi messaggi della mailing list. Un post archiviato può essere linkato da molti posti, alcuni post diventano cosi largamente noti che alla fine hanno molti più lettori al di fuori della mailing list che dentro.
La formattazione può fare molta differenza. Per esempio, nel progetto di Subversion, noi stavamo avendo un limitato esito favorevole nell'usare il filtro dei bug descritto in
in
. Molti rapporti di bug fasulli stavano venendo archiviati da gente inesperta, e ogni volta che ciò avveniva, l'archiviatore doveva essere educato esattamente nello stesso modo di 500 persone prima di lui. Un giorno, dopo che uno dei nostri sviluppatori era finalmente arrivato alla fine della sua cordata e aveva inveito contro qualche utilizzatore deficitario che non leggeva le linee guida del tracciatore di problemi abbastanza con cura, un altro sviluppatore decise che questo comportamento era andato avanti a lungo abbastanza. Egli suggerì che noi formattassimo la pagina frontale del tracciatore di bug in modo che la parte più importante, la ingiunzione a discutere il bug sulla mailing list o sul canale IRC prima di archiviarlo, si distinguesse per l'enormità, lettere in grassetto rosso, su uno sfondo giallo brillante, centrato in prominenza sopra ogni altra cosa nella pagina. Noi facemmo così (potete vederne i risultati a
), e il risultato fu un salto notevole nella velocità dei problemi fasulli archiviati. Ancora li prendiamo, certo, noi li prenderemo sempre ma la velocità è diminuita considerevolmente, anche se il numero degli utilizzatori cresce. La conclusione è non solo che il database contiene meno spazzatura, ma che quelli che rispondono alla archiviazione dei problemi rimangono di umore migliore e sono più propensi a restare amichevoli quando rispondono ad una archiviazione di una delle adesso rare archiviazioni fasulle. Questo migliora sia l'immagine del progetto, sia la salute mentale dei suoi volontari.
La lezione per noi fu che scrivere solamente le linee guida non era abbastanza. Noi dovevamo metterle dove sarebbero state viste da coloro che più di tutti avevano bisogno di esse, e formattarle in modo tale che il loro stato come materiale di introduzione sarebbe stato immediatamente chiaro alle persone non familiari col progetto.
Le pagine statiche non sono il solo luogo per far pubblicità ai clienti del progetto. E' anche richiesta una certa quantità di politica interattiva (nel senso di “ricordare amichevolmente” non nel senso di ammanettare e mettere in prigione). Tutta la revisione paritaria, anche le revisioni degli invii descritte in
in
, dovrebbe includere la revisione della conformità o non conformità della gente alle norme del progetto, specialmente riguardo alle convenzioni delle comunicazioni.
Un altro esempio dal progetto di Subversion: noi stabilimmo che “r12908" significasse "revisione 12908” nel deposito del controllo di versione. Il prefisso minuscolo “r” è facile da battere, e poiché è la metà dell'altezza delle cifre, esso rende un blocco di testo facilmente riconoscibile quando combinato con le cifre. Certo, quando una email di invio arriva con un messaggio di log come questo:
------------------------------------------------------------------------
r12908 | qsimon | 2005-02-02 14:15:06 -0600 (Mer, 02 Feb 2005) | 4 righe
Patch dal collaboratore J. Casuale <jrcontrib@gmail.com>
* trunk/contrib/client-side/psvn/psvn.el:
Corretti alcuni errori di stampa dalla revisione 12828.
------------------------------------------------------------------------
...parte della revisione di questo invio è per dire “Strada facendo prego usate 'r12828', non 'revisione 12828' quando vi riferite al cambiamento passato”. Questa non è pedanteria; è altrettanto importante per l'analisi sintattica automatica quanto per i lettori umani.
Seguendo il principio generale che ci dovrebbero essere dei metodi di riferimento canonico e che questi metodi di riferimento dovrebbero essere usati coerentemente ovunque, il progetto in effetti esporta certi standards. Questi standards mettono la gente in grado di scrivere strumenti che presentino le comunicazioni del progetto in modi più usabili—per esempio un revisione formattata come "r12828" potrebbe essere trasformata in un link vivo al sistema di osservazione del deposito. Ciò sarebbe piuttosto difficile se la revisione fosse scritta "revisione 12828", sia perché quella forma potrebbe essere divisa da una interruzione di linea, sia perché è meno distinta (la parola “revisione” apparirà spesso da sola, e il gruppo dei numeri apparirà spesso da solo, mentre la combinazione "r12828" può significare solo un numeri di revisione. Simili preoccupazioni si applicano ai numeri di problema, voci di FAQ (suggerimento: usate un URL con un'ancora con nome, come descritto in
), ecc.
Anche per le entità dove non c'è una ovvia breve, forma canonica, la gente tuttavia dovrebbe essere incoraggiata a fornire pezzi chiave di informazione coerentemente. Per esempio, quando ci si riferisce ad un messaggio della mailing list, non date solo il mittente e i soggetto; date anche l'URL dell'archivio e e la testata Message ID. L'ultimo permette alla gente che ha la sua copia della mailing list (le gente a volte tiene copie offline, per esempio da usare su un laptop in viaggio) per identificare senza ambiguità i messaggio giusto anche se non ha l'accesso agli archivi. Il mittente e il soggetto non sarebbero sufficienti, per che la stessa persona potrebbe fare parecchi post nello stesso trhead, anche nello stesso giorno.
Più il progetto cresce, più importante diventa questo tipo di coerenza. Coerenza significa che qualunque persona guardi, essa vede seguiti gli stessi comportamenti, così essi sanno seguire i comportamenti stessi. Questo, successivamente, riduce il numero di domande che essi hanno bisogno di di fare. Il carico di avere milioni di lettori non è più grande di quello di averne uno; i problemi di scalabilità cominciano a sorgere quando un a certe percentuale di di quei lettori fa domande. Nella misura in cui il progetto cresce, esso deve ridurre quella percentuale aumentando la densità e l'accessibilità dell'informazione, in modo che la persona in grado di trovare ciò di cui ha bisogno senza dover chiedere.
Nessuna Conversazione nel Tracciatore di Bug
In un progetto che sta facendo un uso attivo del tracciatore di bug, c'è sempre un pericolo che il tracciatore si trasformi esso stesso in un forum di discussione, anche se la mailing list sarebbe in realtà migliore. Di solito si incomincia abbastanza innocentemente: qualcuno annota un problema con una, diciamo, soluzione proposta, e fa seguire un altra annotazione che indica problemi. La prima persona risponde, ancora aggiungendosi al problema...e va così.
Il problema con questo è, primo, che il tracciatore di bug è un luogo piuttosto ingombrante per tenervi una discussione, e secondo, che altre persone possono non farvi attenzione—dopotutto essi si aspettano che che la discussione dello sviluppo avvengano sulla mailing list dello sviluppo, così è lì che guardano per essa. Essi possono non essere per nulla iscritti alla mailing list dei cambiamenti dei problemi, e anche se lo sono, possono non seguirla molto da vicino.
Ma esattamente dove nel processo è andata sbagliata qualcosa? Fu quando la persona d'origine aggiunse la sua soluzione al problema—dovrebbe aver postato nella mailing list invece? O fu quando la seconda persona rispose nel problema, invece che sulla mailing list?
Non esiste una risposta giusta, ma c'è un principio generale: se state appunto aggiungendo dati a un problema, allora fatelo nel tracciatore, ma se state incominciando una conversazione, allora fatelo nella mailing list. Potete non essere sempre in grado di dire quale è il caso, ma usate appunto il miglior giudizio. Per esempio, quando state aggiungendo una patch con una soluzione potenzialmente controversa, potreste essere in grado di anticipare che la gente sta per avere una domanda su di essa. Così anche se normalmente aggiungereste la patch al problema (ipotizzando che non volete o non potete fare l'invio del cambiamento direttamente), in questo caso potreste invece scegliere di postarla alla mailing list. In ogni caso, alla fine lì verrà il momento nello scambio in cui una parte o l'altra può dire che è sul punto di passare dalla sola aggiunta di dati a una reale conversazione—nell'esempio che incominciò questa sezione, che sarebbe la seconda persona che risponde, colui che si rendeva conto che c'erano problemi con la patch, poté predire che stava per seguire una conversazione reale, e che quindi avrebbe dovuto essere tenuta sul mezzo appropriato.
Per usare una analogia matematica, se sembra che l'informazione sarà rapidamente convergente, allora mettetela direttamente nel tracciatore di bug; se sembra che sarà divergente allora una mailing list o un canale IRC può essere un posto migliore.
Ciò non significa che non ci dovrebbe mai essere scambio nel tracciatore di bug. Chiedere maggiori dettagli per la ricetta di riproduzione da chi ha fatto il report all'origine tende ad essere un processo altamente convergente, per esempio. E' improbabile che la risposta della persona sollevi nuovi problemi; è semplicemente fornire maggiori dettagli sull'informazione già archiviata. Non c'è bisogno di distrarre la mailing list con quel procedimento. Abbiate cura con ogni mezzo di ciò con una serie di commenti nel tracciatore. Allo stesso modo, se siete abbastanza sicuri che il bug è stato riportato male (cioè, non è un bug), allora potete semplicemente dirlo così bene nel problema. Anche indicare un problema minore con una soluzione proposta è bene, nell'ipotesi che il problema non sia un pezzo di una rappresentazione che suscita applausi per la risoluzione completa.
D'altra parte, se state sollevando dei problemi filosofici sulla portata del bug o sull'appropriato comportamento del software, potete essere abbastanza sicuri che gli altri sviluppatori vorranno essere coinvolti. Sembra che la discussione diverga per un momento prima di convergere, così tenetela nella mailing list.
Linkate sempre all'argomento della mailing list dal problema, quando scegliete di postare alla mailing list. E anche importante per qualcuno che sta seguendo il problema essere capace di raggiungere la discussione. La persona che inizia il thread può trovare ciò laborioso, ma l'open source è fondamentalmente una responsabilità di chi scrive. E' molto più importante rendere facili le cose per le decine di centinaia di persone che possono leggere il bug, che per le tre o cinque persone che scrivono intorno ad esso.
E' bene trarre importanti conclusioni o sommari dalla discussione sulla mailing list e incollarle nel problema, se ciò renderà le cose convenienti per i lettori. Deve iniziare una discussione sulla mailing list un comune idioma, mettete un link al thread nel problema, e poi quando la discussione finisce, incollate il sommario finale nel problema (insieme con un link al messaggio contenente il sommario), così chi osserva il problema possa vedere quale conclusione sia stata raggiunta senza dover cliccare da qualche altra parte. Notate che di solito il problema della duplicazione dei dati da ”due capi” non esiste qui, perché ambedue gli archivi e i commenti al problema di solito sono statici, dati che non è possibile cambiare in nessun modo.
La Pubblicità
Nel software libero c'è una discreta regolare continuità tra le discussioni puramente interne e le regole delle pubbliche relazioni. Ciò avviene in parte perchè il pubblico di destinazione è mal definito. Dato che la maggioranza o tutti i post sono pubblicamente accessibili, il progetto non ha il controllo pieno sull'impressione che ne ha il mondo. Qualcuno,— diciamo, un editor
slashdot.org
—può attrarre l'attenzione dei lettori verso un post che nessuno si sarebbe mai aspettato che sarebbe stato visto dall'esterno del progetto. Questo è un fatto concreto con la quale convivono tutti i progetti open source, ma in pratica, il rischio è piccolo. In generale gli annunci che più il progetto vuole che siano pubblicizzati sono quelli che saranno più pubblicizzati, nell'ipotesi che usiate i meccanismi giusti per indicare la rilevanza di una notizia al mondo esterno.
Per gli annunci principali tendono ad esserci quattro o cinque principali canali di distribuzione, sui quali gli annunci dovrebbero essere fatti quanto più simultaneamente possibile:
La pagina principale del vostro progetto è vista probabilmente da più gente che qualsiasi altra parte del progetto. Se avete annunci veramente importanti mettete lì una breve inserzione. La breve inserzione dovrebbe essere un piccolo specchietto che linki al comunicato stampa (vedere sotto) per maggiori informazioni.
Allo stesso tempo, voi dovreste avere una area “Notizie” o ”Comunicati stampa” sul sito, dove un annuncio possa essere scritto nei dettagli. Parte del proposito di un comunicato stampa e quella di fornire un solo canonico “oggetto annuncio”a cui altri siti possano linkare, in modo da assicurarsi che esso sia strutturato di conseguenza: sia come pagina web per le release, sia come nuova entrata nel blog, sia come altro tipo di entità che possa essere linkata pur essendo tuttavia tenuta distinta da altri comunicati stampa nella stessa area.
Se il vostro progetto ha un feed RSS, assicuratevi che l'annuncio vada anche lì. Ciò può avvenire automaticamente quando create il comunicato stampa, a seconda di come le cose sono messe sul vostro sito.
(RSS è un meccanismo per distribuire sommari di meta dati ricchi agli “iscritti”, cioè gente che ha indicato un interesse nel ricevere questi sommari. Vedere per maggiori informazioni sugli RSS. Se l'annuncio riguarda una nuova release del software, allora aggiornate la voce del vostro progetto su (vedere
per maggiori informazioni sugli RSS.)
Se l'annuncio riguarda una nuova release del software, allora aggiornate la voce del vostro progetto su
(vedere su come creare la voce in primo luogo). Ogni volta che aggiornate una voce di Freshmet, quella voce va sulla change list per il giorno. La change list non è aggiornata solo sullo stesso Freshmet, ma sui vari portali (incluso
) che sono osservati ansiosamente da orde di gente. Freshmet offre gli stessi dati via feed RSS, così la gente che non è iscritta al suo feed RSS del vostro progetto può ancora vedere l'annuncio attraverso quelli di Freshmet.
Mandate una email alla mailing list degli annunci del progetto. Il nome di questa mailing list dovrebbe essere veramente “annuncia”, ciòè, annuncia@yourprojectdomain.org,
perché questa è una convenzione piuttosto standard ora e lo statuto della mailing list dovrebbe render chiaro che è a traffico molto lento riservata agli annunci principali del progetto. La maggior parte di questi annunci saranno sulle release del software, ma occasionalmente su altri eventi, come una iniziativa di raccolta fondi, la scoperta di una vulnerabilità nella sicurezza (vedere
)
più avanti in questo capitolo, o un cambiamento nel progetto può essere postato anche lì. Poiché essa è a basso traffico e usata solo per cose importanti, la mailing list annuncia ha tipicamente la più alta quantità di iscritti di ogni mailing list nel progetto (certo, ciò significa che voi non dovete abusare con essa— riflettete prima di postare). Per evitare che gente a caso faccia annunci, o peggio, spam di passaggio, la mailing list annuncia deve sempre essere moderata.
Cercate di fare gli annunci in tutti i posti in modo simultaneo quanto più è possibile. La gente potrebbe confondersi vedendo un annuncio sulla mailing list ma poi non vedendolo nella pagina principale del sito del progetto o nell'area dei comunicati stampa. Se ricevete i vari cambiamenti (emails, scrittura delle pagine web, ecc..) in un fila di attesa e le mandate tutte in un riga potete mantenere molto piccola la finestra di incoerenza.
Per un evento meno importante, potete eliminare una o tutte le uscite di cui sopra. L'evento sarà ugualmente notato dal mondo di fuori in proporzione alla susa importanza. Per esempio, se una nuova release del software è un evento importante, il fissare solamente la data della nuova release, mentre tuttavia in qualche modo fa notizia, non è quasi così impostate quanto la release stessa. Il fissare una data ha il valore di una email alle mailing list giornaliere (non alla maling list annuncia) e di un aggiornamento della linea del tempo del progetto e della pagina web dello stato, ma niente di più.
Comunque potreste vedere quella data apparire nella discussione da qualche altra parte in Internet, ovunque ci sia gente interessata al progetto. Persone che stanno in disparte sulle vostre mailing list, solo per ascoltare e mai dire qualcosa, non stanno necessariamente zitte altrove. L'orale dà una distribuzione molto ampia; dovreste contare su essa, e costruire anche annunci minori in modo da incoraggiare una trasmissione informale accurata. Nello specifico, post che vi aspettate siano quotati dovrebbero avere una parte finalizzata ad essere quotata, giusto come se steste scrivendo un comunicato stampa. Per esempio:
Giusto un aggiornamento nel progresso: state progettando di rilasciare la versione 2.0 di Scanley a metà Agosto 2005. Potete sempre controllare
http://www.scanley.org/status.html per aggiornamenti. La principale funzionalità sarà la ricerca con le espressioni regolari.
Le altre nuove funzionalità includono: ... Ci saranno anche varie correzioni di bug, incluso: ...
Il primo paragrafo è breve, dà i due più importanti pezzi di informazione (la data del rilascio e la principale nuova funzionalità), e un URL da visitare per ulteriori notizie. Se quel paragrafo è la sola notizia che attraversa lo schermo di qualcuno, state ancora facendo molto bene. Il resto della email potrebbe andar perso senza aver effetto sulla sostanza del contenuto. Certo, a volte le persone vorranno linkare all'intera email comunque, ma appunto come spesso, essi ne citeranno solo una piccola parte. Dato che l'ultima ipotesi è una possibilità, potete anche renderla facile per loro, e nel patteggiare avere qualche influenza su ciò che viene citato.
Annunciare le Vulnerabilità della Sicurezza
Gestire le vulnerabilità della sicurezza è differente dal gestire ogni altro tipo di report di bug. Nel software libero, fare le cose apertamente e con trasparenza è normale quasi come un credo religioso. Ogni passo della gestione standard dei bug è visibile a tutti quelli che hanno la cura di di guardare: l'arrivo del report iniziale, la conseguente discussione, e l'eventuale correzione.
I bug della sicurezza sono differenti. Essi possono compromettere i dati degli utenti, e magari l'intero computer dell'utente. Per discutere apertamente un tale problema si dovrebbe avvisare della sua esistenza il mondo intero—incluse tutte le parti che potrebbero fare un uso maligno del bug. Anche solo facendo l'invio della correzione in effetti dà l'annuncio dell'esistenza del bug (ci sono persone potenziali che sferrano gli attacchi che guardano i log degli invii dei progetti pubblici, sistematicamente alla ricerca di cambiamenti che indicano problemi di sicurezza nel codice di pre cambiamento). Molti progetti open source hanno fissato lo stesso gruppo di passi per gestire questo conflitto fra l'essere aperti e la segretezza, basati su queste linee guida:
Non parlate del bug pubblicamente finché non sia disponibile un correzione; quindi fornite la correzione all'esatto stesso momento in cui annunciate il bug.
Arrivate con quella correzione quando più velocemente potete—specialmente se qualcuno al di fuori del progetto riportò il bug, perché allora voi sapete che c'è almeno una persona al di fuori del progetto che è in grado di sfruttare la vulnerabilità.
In pratica questi principi portano a una serie di passi molto standardizzati che sono descritti nella sezione sotto.
Ricevere il report
Ovviamente il progetto ha bisogno di ricevere i bug nella sicurezza da ognuno. Ma gli indirizzi dei rapporti dei bug non ne hanno bisogno, perché anche essi sono visti da chiunque. Quindi, abbiate un mailing list separata per ricevere i rapporti dei bug nella sicurezza. Questa mailing list non deve avere archivi leggibili pubblicamente, e i loro iscritti devono essere strettamente controllati—solo sviluppatori di lungo periodo fidati possono stare sulla mailing list. Se avete bisogno di una definizione formale di “fidati”, dovete usare “chiunque abbia avuto l'accesso all'invio da due anni o più”, o qualcosa di simile, per evitare favoritismi. Questo è il gruppo che deve gestire i bug nella sicurezza.
Idealmente, la mailing list sulla sicurezza non dovrebbe essere protetta da spam o moderata, perché non potete volere che un importante report sia filtrato o ritardato giusto perché è avvenuto che nessun moderatore fosse online quel weekend. Se usate programmi di protezione da spm automatici, cercate di configurarli con settaggi di alta tolleranza; è meglio consentire pochi spam che perdere un report. Affinché la mailing list sia efficiente dovete pubblicizzare il suo indirizzo, certo; ma dato che non sarà moderata o, al massimo, leggermente protetta da spam, non cercate mai di postare il suo indirizzo senza una qualche sorta di trasformazione di nascondimento, come descritto in
in
.
Fortunatamente per nascondere dell'indirizzo non c'è bisogno che l'indirizzo sia illeggibile; vedere , e prendete visione del sorgente della pagina Html, per un esempio.
Sviluppate la correzione silenziosamente
E così cosa fa la mailing list quando riceve un report? Il primo compito è quello di valutare la serietà e la urgenza del problema:
Quanto seria è la vulnerabilità? Permette a chi fa l'attacco di prendere la direzione del computer si qualcuno che usa ilo vostro software? O si perdono semplicemente informazioni sulla grandezza di qualcuno dei suoi file?
Quanto facile è sfruttare la vulnerabilità? Può un attacco essere prestabilito, o richiede una conoscenza profonda, o un calcolo studiato, e fortuna?
Chi fece il report del problema a voi? Lar risposta a questa domanda non cambiate la natura della vulnerabilità, certo, ma vi dà un'idea di quante altre persone potrebbero sapere di essa. Se il report viene da una degli sviluppatori del progetto, voi potete respirare un pò più facilmente (ma solo un poco) perché potete confidare sul fatto che egli non ha parlato a nessuno di esso. D'altro canto, se il report viene con una email da anonimo14@globalhackerz.net,
allora sarebbe meglio che che voi agiate quanto più velocemente possibile. La persona vi fece un favore informandovi del problema, ma non avete idea di quante persone sono state informate da lui, o di quanto abbia aspettato prima di sfruttare la vulnerabilità sulle installazione caricate.
Notate che la differenza di cui stiamo parlando qui è fra urgente
e estremamente urgente. Anche quando il report proviene da una fonte nota e amica, ci potrebbe essere altra gente sulla rete che scoprì il bug da tempo e che non lo ha giusto riportata. La sola occasione in cui le cose non sono urgenti è quando il bug in modo innato non compromette la sicurezza in modo serio.
L'esempio "anonimo14@globalhackerz.net" non è faceto, tra parentesi. Voi potete ricevere realmente dei rapporti di bug da persone dall'identità nascosta, che con le loro parole e il loro comportamento, non chiariscono del tutto se sono dalla vostra parte o no. Non ha importanza: se hanno fatto rapporto sul buco nella sicurezza a voi essi riterranno di avervi fatto un favore, e voi potete rispondere a modo. Ringraziateli per il report, dategli una data nella o prima della quale progettate di rilasciare una correzione pubblica, e teneteli nel giro. A volte essi possono dare a voi una data—cioè, una minaccia intrinseca di pubblicizzare il bug in una certa data, siate pronti o no. Questo può essere avvertito come un minaccioso gioco di potere, ma è più probabilmente una azione preventiva risultante dalla passata delusione con produttori di software indifferenti che non presero i report di sicurezza abbastanza seriamente. D'altra parte, voi non potete permettervi di irritare questa persona. Dopotutto, se ilo bug è serio, egli ha conoscenze che potrebbero causare grossi problemi ai vostri utenti. Trattate bene queste persone che fanno i report, e sperate che trattino bene voi.
Un'altra persona che fa frequenti report di sicurezza è il professionista della sicurezza, uno che controlla il codice per campare e si mantiene con le ultime notizie sulle vulnerabilità della sicurezza. Queste persone hanno di solito esperienza su tutti e due i lati della staccionata—essi hanno ricevuto e mandato report, magari più della maggioranza degli sviluppatori nel vostro progetto. Essi anche di solito danno anche una scadenza sulla correzione di una vulnerabilità, prima che diventi pubblica. Questa scadenza può essere in un certo modo negoziabile ma questo tocca a chi manda il report; le scadenze sono diventate riconosciute fra i professionisti della sicurezza in qualche grado come l'unica via affidabile per ottenere che le organizzazioni affrontino i problemi di sicurezza tempestivamente. Così non trattate le scadenze da maleducati; è una tradizione che gode di buona reputazione, e ci sono buone ragioni per questo.
Una volta che ne conoscete la serietà e l'urgenza, potete partire col lavoro della correzione. A volte c'è un compromesso fra il fare una correzione elegantemente e il farla velocemente; questo è il perché dovete accordarvi sull'urgenza prima di partire. Mantenete la discussione ristretta ai membri della mailing list, più chi fece il report originariamente (se lui vuole essere coinvolto), a qualche sviluppatore che è necessario tirare dentro per ragioni tecniche.
Non inviate la correzione al deposito. Mantenetela in forma di patch fino alla data di andare in pubblico. Nel caso doveste inviarla, anche con un log innocente a vedersi, qualcuno potrebbe notarla e capire il cambiamento. Voi non sapete mai chi sta guardando nel deposito, e perché sarebbe interessato. Cessare le email di invio non aiuterebbe; prima di tutto l'interruzione nella sequenza dell'invio delle email potrebbe sembrare il se stessa sospetta, e comunque, i dati sarebbero tuttavia nel deposito.
Appunto fate tutto lo sviluppo in una patch e tenete la patch in qualche posto privato, magari un deposito privato separato conosciuto solo alle persone al corrente del bug. (Se usate un sistema di controllo della versione decentrato come Arch o SVK, potete fare il lavoro sotto il pieno controllo della versione, e giusto tenete quel deposito inaccessibile agli esterni.)
I numeri CAN/CVE
Potete aver visto un numero CAN o
un numero CVE associati con i problemi di sicurezza. Questi numeri di solito appaiono come "CAN-2004-0397" o "CVE-2002-0092", per esempio.
Ambedue i tipi di numeri rappresentano lo stesso tipo di entità: una voce nella lista di “Vulnerabilità comuni ed Esposizioni” curata in . Il proposito della lista è quello di fornire nomi standardizzati per tutti i problemi conosciuti di sicurezza, in modo che chiunque deve usare un unico nome canonico quando ne discute uno e un posto centralizzato dove andare per trovare maggiori informazioni. La sola differenza tra il numero “CAN” e “CVE” è che il primo rappresentata una voce candidata, non ancora approvata per l'inserimento nella lista della dal Consiglio editoriale della CVE e il secondo rappresenta una voce approvata. Comunque tutti e due i tipi di voce sono visibili al pubblico, e il numero di una voce non cambia quando è approvato—il prefisso “CAN” è solo sostituito da “CVE”
Una voce CAN/CVE non contiene di per se stessa una descrizione completa del bug non dice come proteggersi da essa. Invece, contiene un breve sommario, e un elenco di riferimenti a risorse esterne (come archivi di mailing lista) dove la gente possa andare per prende maggiori informazioni. Il vero proposito di è quello di fornire uno spazio ben organizzato in cui in cui ogni vulnerabilità possa avere un nome e una chiara rotta verso dati ulteriori. Vedere
per un esempio di voce. Notate che i riferimenti possono essere molto succinti, con le sorgenti che appaiono abbreviazioni criptate. Una chiave per queste abbreviazione si trova a
.
Se la vostra vulnerabilità soddisfa i criteri CVE, potete voler acquisire ad esso un numero CAN. Il procedimento per fare ciò e deliberatamente impedito: fondamentalmente voi dovete conoscere qualcuno, o conoscere qualcuno che conosce qualcuno. Ciò non è folle come potrebbe suonare. Affinché il Consiglio Editoriale del CVE eviti di essere travolto con candidature spurie o scritte in modo deficitario, prende candidature solo da fonti già note o fidate. Per ottenere che la vostra vulnerabilità sia elencata, quindi, avete bisogno di un percorso di conoscenze dal vostro progetto al
Consiglio Editoriale del CVE. Chiedete fra i vostri sviluppatori; uno di essi o probabilmente conosce qualcun altro che ha percorso il procedimento CAN prima, o qualcuno che lo ha, ecc.. Il vantaggio di fare ciò in questo modo è anche quello che in qualche punto lungo la catena, qualcuno può sapere abbastanza da dire a) che essa non conterebbe come vulnerabilità o come esposizione in accordo con i criteri del MITRE, per cui non è il caso di inviarla o b) la vulnerabilità
ha già un numero CAN o CVE. La seconda cosa può presentarsi se il bug è stato appena pubblicato su un'altra mailing list consultiva di sicurezza, per esempio su o sulla mailing list BugTraq a .
(Se ciò è avvenuto senza che il vostro progetto ne abbia sentito parlare, allora vi dovreste preoccupare di cos'altro potrebbe andare avanti di cui voi non avete conoscenza).
Se ottenete un numero CAN/CVE, voi volete ottenerlo nei primi stadi dell'investigazione sul bug, in modo che tutte le ulteriori comunicazioni possano far riferimento a quel numero. Le voci CAN vengono impedite fino alla data della pubblicazione; la voce consisterà in un simbolo vuoto (così voi non perdete il nome), ma ciò non rivelerà nessuna informazione sulla vulnerabilità fino alla data in cui voi annunciate il bug e la correzione.
Maggiori informazioni sul processo CAN/CVE possono essere trovate a
, e una esposizione particolarmente chiara dell'uso da parte di un progetto open source dei numeri CAN/CVE si trova a
.
Pre notifica
Una volta che il team delle risposte sulla sicurezza (cioè quegli sviluppatori che stanno sulla mailing list della sicurezza, o che sono stati tirati dentro l'affare della sicurezza con un particolare rapporto) ha una correzione pronta, dovete decidere come distribuirla.
Se inviate semplicemente la correzione al deposito, o diversamente la annunciate al mondo, voi in effetti costringete chiunque usi il vostro software ad aggiornare immediatamente o rischiare di essere bucato. Talvolta è appropriato, quindi, fare una pre notifica per certi utenti importanti. Ciò è particolarmente vero per il software client/server, dove ci possono essere ben noti server che sono degli allettanti obiettivi per chi fa gli attacchi. Gli amministratori di questi server apprezzerebbero il fatto di avere qualche giorno in più o due per fare l'aggiornamento, in modo da essere protetti nel frattempo che il metodo di attacco diventa di pubblica conoscenza.
Pre notifica significa semplicemente inviare email a quegli amministratori prima della data dell'uscita, per dire loro della vulnerabilità e come correggerla. Dovreste mandare la pre notifica solo a persone che voi confidate siano discrete con le informazioni. Cioè, la qualifica per ricevere la pre notifica è duplice: il destinatario deve far girare un grosso, importante server l'essere in pericolo sarebbe una questione seria, e e il destinatario dovrebbe essere noto per non essere uno che chiacchiera sul problema di sicurezza prima della data dell'uscita.
Mandate le email di prenotifica individualmente (una alla volta) ad ogni destinatario. Non mandate la lista intera dei destinatari subito, perché essi vedrebbero i nomi gli uni degli altri—nel senso che voi stareste avvisando ogni destinatario del fatto che ogni altro destinatario può avere una buca nella sicurezza nel suo server. Mandando a tutti loro l'email via CC non visibile (BCC) non è una buona soluzione nemmeno, perché alcuni admin proteggono la loro casella di posta con filtri antispam che o bloccano o riducono la priorità delle email BCC, dal momento che così tanto spam è inviato via BCC di questi tempi.
Qui c'è un esempio di email di pre notifica:
DA: Qui il Vostro Nome
To: admin@large-famous-server.com
Risposta a: Qui in Vosto Nome (non l'indirizzo della mailing list sulla sicurezza)
Oggetto: Notifica confidenziale della vulnerabilità di Scanley.
Questa email è una una notifica confidenziale di una allarme nel server di Scanley.
Prego *non inoltrare* nessuna parte di questa email ad alcuno. Non c'è annuncio fino al 19 Maggio e noi gradiremmo tenere questa informazione bloccata fino ad allora.
State ricevendo questa email perché (noi pensiamo) che voi facciate girare un server Scanley e vorreste averlo sistemato prima che il buco nella sicurezza venga reso pubblico il 19 Maggio.
Riferimenti:
===========
CAN-2004-1771: Sovraccarico dello stack di Scanley nelle query
Vulnerabilità:
==============
Il server può essere messo nelle condizioni di eseguire comandi arbitrari se il locale del server è mal configurato e il client invia una query mal formata.
Serietà:
=========
Molto seria. Può comportare l'arbitraria esecuzioni di codice sul server.
Soluzioni:
============
Il mettere l'opzione del 'processo del linguaggio naturale' a 'off' in scanley.conf blocca questa vulnerabilità
Patch:
======
La patch di sotto si applica a Scanley 3.0, 3.1, e 3.2.
Una nuova release (la Scanley 3.2.1) verrà creata il o appena prima del 19 Maggio, in modo che sia disponibile nello stesso momento in cui questa vulnerabilità è resa pubblica. Potete sistemare adesso, o appunto aspettare la release pubblica. L'unica differenza fra la 3.2 e la 3.2.1 sarà questa patch.
[...la patch va qui...]
Se avete un numero CAN, includetelo nella pre notifica (come mostrato sopra) anche le informazioni a sono ancora bloccate e quindi la pagina del MITRE non mostra nulla. L'inclusione del numero CAN mette il destinatario in grado di sapere con certezza che il bug del quale è stato pre notificato è lo stesso di cui ha sentito parlare attraverso i canali pubblici, così egli non ha a preoccuparsi se è necessaria qualche azione ulteriore o no, che è precisamente lo scopo dei numeri CAN/CVE.
Distribuite la correzione pubblicamente
L'ultimo passo nella gestione di un bug di sicurezza è quello di di distribuire la pubblicità della correzione. In un unico, comprensivo annuncio, dovreste descrivere il problema, dare il numero CAN/CVE, se esiste, descrivere come risolvere il problema, e come correggerlo permanentemente. Di solito “fix” significa aggiornare alla nuova versione del software, sebbene, a volte, significa applicare una patch, particolarmente se il software è fatto girare normalmente in una forma sorgente in qualche modo. Se create una nuova release, essa dovrebbe differire dalla release esistente esattamente per la patch sulla sicurezza. In questo modo gli admin prudenti possono aggiornare senza preoccuparsi su quale altra cosa essa stia avendo effetto; essi non dovrebbero nemmeno preoccuparsi dei futuri aggiornamenti perché la correzione della sicurezza ci sarà in tutte le release future come cosa naturale. (Dettagli sulle procedure della release sono discussi in
in
.)
Se o meno la correzione pubblica comporta una nuova release, fate l'annuncio con circa la stessa priorità che in una nuova release: mandate una email alle mailing list annuncia del progetto, fate un nuovo comunicato stampa, aggiornate la voce di Freshmet, ecc.. Mentre non dovreste mai minimizzare l'esistenza di un bug di sicurezza al di fuori della relazione con la reputazione del progetto, potete impostare certamente il tono e la prominenza di un annuncio di sicurezza perché sia adatto alla severità del problema. Se il buco nella sicurezza è solo una rischiosità secondaria relativa alle informazioni, non un metodo di attacco che consente all'intero computer dell'utente di essere rilevato, allora esso non può giustificare tanta agitazione. Potete anche decidere di non distrarre la mailing list annuncia con esso. Dopotutto, se il progetto guarda al lupo ogni volta, gli utenti potrebbero finire col pensare che il software sia meno sicuro di quanto in realtà lo sia, e potrebbero anche non credervi quando avete da annunciare veramente un grosso problema. Vedere
per una buona introduzione al problema del giudizio sulla severità.
In generale, se siete incerti su come trattare un problema di sicurezza, trovate qualcuno esperto e parlategli di esso. Valutare e gestire le vulnerabilità è molto una abilità acquisita, ed è facile fare dei passi falsi le prime volte.