Indice
Riuscire a far si che le persone aderiscano a ciò di cui ha bisogno il progetto, e lavorare insieme per raggiungerlo, richiede più che la sola atmosfera cordiale e una mancanza della ovvie disfunzioni. Richiede qualcuno o più di qualcuno, che sappiano gestire tutte le persone coinvolte. Gestire i volontari può non essere un'arte tecnica nello stesso senso della programmazione di un computer, ma può essere un'arte che può essere migliorata con studio e pratica.
Questo capitolo è un afferrare e mettere in borsa tecniche specifiche per la gestione dei volontari. Esso afferra, forse più fortemente che i precedenti capitoli, con Subversion come caso di studio, perché io ho lavorato a quel progetto per scrivere questo ed ho avuto tutte le fonti primarie a portata di mano, e in parte perché è più accettabile lanciale pietre di critica nelle propria serra di vetro piuttosto che in quella di altri. Ma ho visto anche in molti altri progetti i benefici dell'applicare e le conseguenze del non applicare le raccomandazioni che seguono; quando sarà politicamente fattibile dare esempi provenienti da alcuni altri progetti, io lo farò.
Parlando di politiche, questo è un buon momento come nessuno per dilungarsi con quella molto malfamata parola per uno sguardo più da vicino. A molti ingegneri piace pensare alla politica come a qualcosa in cui la gente si imbarca. "Io sto solo sostenendo la causa di un miglior corso per il progetto ma quello sta sollevando obiezioni per ragioni politiche". Io credo che questa antipatia per la politica (o per quello che si immagina sia la politica) sia particolarmente forte negli ingegneri perché gli ingegneri sono acquisiti all'idea che alcune soluzioni siano oggettivamente superiori ad altre. Cosi, quando qualcuno agisce in modo da sembrare motivato da considerazioni esterne per esempio il mantenimento della sua posizione di influenza, la riduzione dell'influenza di qualche altro, il commercio aperto dei voti, o l'evitare di ferire la sensibilità di qualcuno gli altri partecipanti al progetto possono annoiarsi. Certamente, questo raramente impedisce loro di comportarsi nello stesso modo quando i loro interessi vitali sono in gioco.
Se ritenete “politica” una parola sporca, e sperate di mantenere il vostro progetto libero da essa, arrendetevi proprio ora. La politica è inevitabile ogni volta che la gente deve gestire collettivamente un risorsa condivisa. E' assolutamente razionale che una delle considerazioni che entra nel processo del prendere decisioni da parte di ognuno è la domanda su come una data azione può incidere sulla propria futura influenza nel progetto. Dopotutto, se avete fiducia nel vostro giudizio e nelle vostre capacità, come molti programmatori fanno, allora la possibile perdita di influenza di futura influenza deve essere considerato un risultato tecnico, in un certo senso. Simili ragionamenti si applicano ad altri comportamenti che potrebbero sembrare, nel loro aspetto, come “pura” politica. In effetti non c'è cosa pura politica come questa: è precisamente perché le azioni hanno conseguenze sul mondo reale che la gente diventa politicamente consapevole in primo luogo. La politica, in fin dei conti, è semplicemente una presa di coscienza che devono essere tenute in conto tutte le conseguenze delle decisioni. Se una particolare decisione porta al risultato che molti partecipanti trovano tecnicamente soddisfacente, ma comporta un cambiamento nei rapporti di potere che lascia che persone chiave si sentano isolate, il secondo un risultato importante proprio come il primo. Ignorarlo sarebbe di nobili sentimenti, ma miope.
Così, quando leggete il consiglio che segue, e quando lavorate con il vostro progetto personale, ricordate che non c'è nessuno al di sopra della politica. Apparire al di sopra della politica, è solamente una particolare strategia politica, e a volte è molto utile, ma non è mai la realtà. Politico è semplicemente ciò che avviene quando la gente è in disaccordo, e i progetti di successo sono quelli che sviluppano meccanismi politici per gestire costruttivamente i disaccordi.
Perché lavorano dei volontari in progetti di software libero?[22]
Quando viene chiesto loro, molti dichiarano che lo fanno perché vogliono produrre buon software, o vogliono essere coinvolti personalmente nel correggere i bugs che a loro interessano. Ma queste ragioni, di solito, non sono tutta la storia. Dopotutto, sapreste immaginarvi un volontario che sta in un progetto, anche se nessuno ha detto una parola di apprezzamento sul suo lavoro, o lo ha ascoltato nelle discussioni? Certo no. Chiaramente le persone spendono tempo sul software libero per ragioni che appunto vanno oltre il desiderio astratto di produrre buon codice. Il capire le vere motivazioni dei volontari vi aiuterà a mettere le cose in modo da attirarli e a mantenerli. Il desiderio di produrre buon codice può esserci fra queste motivazioni, insieme con la sfida e il valore educativo del lavorare su problemi difficili. Ma gli uomini hanno un innato desiderio di lavorare con altri uomini, e di guadagnasi rispetto attraverso attività di collaborazione. I gruppi impegnati in attività di collaborazione devono elaborare norme di comportamento in modo che quello stato sia acquisito e mantenuto attraverso azioni che giovano agli obiettivi del gruppo.
Queste norme non nasceranno da se stesse. Per esempio, in qualche progetto—alcuni sviluppatori esperti sanno probabilmente farne il nome su due piedi —le persone a quanto pare ritengono che lo status si acquisti postando frequentemente e con ricchezza di parole. Essi non sono pervenuti a questa conclusione per caso. Ci sono arrivati perché sono gratificati dal dal fare intricate, lunghe trattazioni, indipendentemente dal fatto che ciò aiuti o meno il progetto. Poi ci sono alcune tecniche per creare un'atmosfera in cui le azioni per acquisire uno status sono azioni costruttive.
DLa delega non è solo un modo per suddividere il carico di lavoro; esso è anche uno strumento politico e sociale. Considerate tutte le conseguenze di quando chiedete a qualcuno di fare qualcosa. Il più ovvio effetto è che, se accetta, lui fa il lavoro e voi no. Ma un'altra conseguenza è che egli fa sapere che voi avete avuto fiducia in lui nell'affidargli il compito. Inoltre, se avete fatto la richiesta in un forum pubblico, allora egli sa che gli altri nel gruppo sono anche al corrente di quella fiducia. Egli può aver la sensazione di una certa pressione ad accettare, il che significa che dovete chiedere in un modo che gli permetta di declinare gentilmente se non vuole realmente il lavoro. Se il compito richiede coordinazione con gli altri nel progetto, voi in realtà state chiedendo che egli diventi più coinvolto, obblighi di forma che non avrebbero potuto esserci in altre circostanze, e che forse diventano una forma di autorità in qualche sotto dominio del progetto. Il coinvolgimento aggiuntivo potrebbe spaventarlo, o potrebbe portarlo anche ad impegnarsi in altri modi, per un aumentato senso di impegno complessivo.
A causa di tutte queste conseguenze, spesso ha un senso chiedere a qualche altro di fare qualcosa anche quando sapete che potreste farlo più facilmente e velocemente voi stessi. Certo, c'è talvolta uno stringente argomento di efficienza economica relativamente a questa cosa comunque: forse il costo economico di farlo voi stessi sarebbe troppo alto ci potrebbe essere qualcosa di più importante che potreste fare in quel lasso di tempo. Ma anche quando non si applica l'argomento del costo economico, voi potete ancora voler chiedere a qualche altro di intraprendere il lavoro perché a lungo andare voi volete tirarlo più in profondità nel progetto, anche se ciò significhi spendere un tempo extra per aver cura di lui all'inizio. Si applica anche le tecnica inversa: se voi occasionalmente vi offrite volontari per fare qualcosa che qualche altro non vuole o non ha il tempo di fare, vi guadagnerete la sua buona volontà e il rispetto. La delega e la sostituzione non esistono solo per ottenere che un compito individuale sia portato a termine; esse esistono anche per coinvolgere più strettamente la gente nel progetto.
A volte è giusto aspettarsi che una persona accetterà un particolare compito. Per esempio, se qualcuno scrive un bug nel codice, o invia codice che non si conforma alle linee guida del progetto in qualche modo evidente, allora è sufficiente richiamare l'attenzione sul problema e quindi comportarsi come se diate per scontato che la persona vi farà attenzione. Ma ci sono altre situazioni in cui non è in nessun modo chiaro che che voi avete il diritto di aspettarvi l'effetto. La persona potrebbe fare come chiedete, oppure no. Poiché non c'è nessuno a cui piace essere preso senza argomenti, c'è bisogno che stiate attenti a questi due tipi di situazioni e fare su misura le vostre richieste di conseguenza.
Una cosa che quasi tutte le volte provoca una istantanea irritazione nella gente è il fatto che gli venga richiesto di fare qualcosa in un modo che presuppone che voi pensate che è chiaramente sua responsabilità farlo, quando essi la pensano diversamente. Per esempio l'assegnazione di un problema in arrivo è un terreno particolarmente fertile per questo tipo di irritazione. I partecipanti a un progetto di solito sanno chi è esperto in quei campi, così quando arriva un rapporto di bug, ci saranno spesso una o due persone di cui ognuno sa che sono capaci di correggerli. In ogni caso se voi assegnate il problema a una di queste due persone senza il loro previo assenso, egli potrà pensare di essere stato messo in una condizione scomoda. Egli sente la pressione di una aspettativa, ma può anche pensare che è stato punito per la sua esperienza. Dopotutto il modo in cui uno acquisisce esperienza è correggendo i bugs, così qualche altro porrebbe prendersi questo compito! (Notate che il tracciatore di bugs che assegna automaticamente i problemi a persone particolari basandosi sull'informazione esistente nel rapporto di bugs è meno probabile che faccia male, perché ognuno sa che le assegnazioni furono fatte da un processo automatico, e non è indice di aspettative umane.)
Mentre sarebbe simpatico suddividere il carico quanto più possibile in modo regolare, ci sono certe occasioni in cui voi volete giusto incoraggiare le persone che possono correggere un bug nella maniera più veloce possibile. Dato che non potete affrontare una ristrutturazione delle comunicazioni per ogni tale assegnazione (“Vorresti dare un'occhiata questo bug?” “Si” “Okay, ti sto per assegnare questo problema” “Okay”), dovreste fare l'assegnazione nella forma di una richiesta, non comunicando nessuna pressione. Virtualmente ogni tracciatore di problemi permette che un commento sia associato con l'assegnazione di un problema. In quel commento potete dire qualcosa del genere:
Sto assegnando questo a te, perché tu hai la massima familiarità con questo codice. Sentiti libero di respingerlo se non hai il tempo di dargli un'occhiata, tuttavia. (E fammi sapere se non vorresti ricevere tali richieste in futuro.)
Ciò fa distinzione fra richiesta di assegnazione e accettazione da parte di chi la riceve, di quella assegnazione. Il pubblico qui non è solo chi fa l'assegnazione, è ognuno: l'intero gruppo assiste a una pubblica conferma dell'esperienza di chi riceve l'assegnazione, ma il messaggio rende anche chiaro che chi riceve l'assegnazione è libero di accettare o declinare la responsabilità.
Quando chiedete a qualcuno di fare qualcosa, ricordatevi di averlo fatto e seguitelo, non importa in cosa. La maggior parte delle richieste vengono fatte in forums pubblici, e sono all'incirca della forma “Puoi prenderti cura di X?” Facci sapere in ogni caso; non c'è problema se non puoi, solo abbiamo bisogno di saperlo. Potete o non potete ricevere risposta. Se la ricevete e la risposta è negativa, il cerchio è chiuso non avete bisogno di altra strategia per trattare con X. Se c'è una risposta positiva controllate i progressi nel problema e commentate sul progresso che vedete o no (chiunque lavora meglio se sa che qualcuno sta apprezzando il suo lavoro). Se non c'è una risposta dopo pochi giorni, chiedete ancora, o postate dicendo che non avete ricevuto nessuna risposta e siete alla ricerca di qualcun altro che lo faccia. O fatelo proprio voi stessi, ma tuttavia assicuratevi di dire che non avete avuto risposta alla vostra richiesta.
Lo scopo del rendere noto il ritardo nella risposta non è quello di mortificare la persona, e la vostra osservazione dovrebbe essere messa nella forma tale da non avere quell'effetto. Lo scopo è semplicemente quello di far sapere che voi tenete traccia di quello che avete chiesto, e che rendete note le reazioni che ricevete. Questo fa si che le persone più probabilmente dicano si la prossima volta, perché essi osserveranno (anche se solo inconsciamente) che voi state probabilmente rendendo noto ogni lavoro che fanno, dato che avete reso noto il molto meno visibile evento che qualcuno ha mancato di rispondere.
Un'altra cosa che rende felice la gente è il fatto che vengano resi noti i loro interessi—in generale, più renderete noti e ricorderete gli aspetti della personalità di qualcuno, più egli si sentirà a suo agio, è più vorrà lavorare con un gruppo di cui voi fate parte.
Per esempio, c'era una accentuata differenza nel progetto Subversion, fra quelli che volevano raggiungere una release definitiva 1.0 (cosa che alla fine fecero), e chi voleva principalmente aggiungervi nuove funzionalità su interessanti problemi ma che non aveva cura di quando la 1.0 sarebbe uscita. Nessuna di queste posizioni è migliore o peggiore dell'altra; essi sono solo due differenti tipi di sviluppatori, e tutti e due fanno una gran quantità di lavori nel progetto. Ma noi imparammo velocemente il fatto di non dare per scontato che la loro eccitazione per quanto riguarda la guida della 1.0 fosse condivisa da tutti. I media elettronici possono essere molto ingannevoli: potete avere la sensazione di una finalità condivisa, quando, in effetti, essa è condivisa solo dalle persone con cui è vi successo di dover parlare, mentre altri hanno priorità completamente differenti.
Più siete al corrente di che tipo di persone vuole uscire dal progetto, tanto più efficacemente potete far richiesta di loro. Perfino solo il dimostrare una comprensione di cosa vogliono, senza fare nessuna richiesta associata, è utile, per il fatto che conferma a una persona che non è solo una particella in una massa indifferenziata.
Lode e critica non sono opposti; sotto molti aspetti essi sono simili. Sono sia una forma primaria cdi attenzione, e sono tantissimo efficaci quando sono specifici piuttosto che generici. Sia dovrebbero essere espressi con obiettivi concreti in mente. Sia possono essere sminuiti per inflazione: lodate troppo o troppo spesso, e svaluterete la vostra lode; lo stesso vale per la critica, sebbene in pratica, la critica provochi una reazione e quindi è un po' più resistente alla svalutazione.
Una importante caratteristica della cultura tecnica è che la critica dettagliata spassionata è spesso presa come una specie di lode (come discusso in sezione chiamata «Riconoscere la maleducazione» in Capitolo 6, Comunicazione), a causa della conseguenza che il lavoro di chi la riceve è apprezzato per il tempo richiesto per analizzarlo. Comunque ambedue le condizioni—dettagliato e spassionato—devono per questa persona risultare veri. Per esempio, se qualcuno fa un cambiamento trasandato al codice è inutile (e in realtà dannoso) fargli seguire una semplice frase del tipo “Questo era trasandato”. La trascuratezza è in fin dei conti una caratteristica della persona, non del suo lavoro, ed è importante mantenere le vostre reazioni focalizzate sul lavoro. E' molto più efficace descrivere tutte le cose sbagliate in quel cambiamento, tatticamente e senza malizia. Se questo è il terzo o il quarto cambio trasandato in una riga da parte delle stessa persona, è opportuno dirlo—di nuovo senza rabbia—alla fine della vostra critica, per rendere chiaro che il comportamento è stato notato.
Se qualcuno non si migliora in risposta alla critica, la soluzione non è più critica o più forte critica. La soluzione per il gruppo è rimuovere quella persona dalla posizione di non competenza, in un modo tale da le sensazioni di risentimento quanto più è possibile; vedere sezione chiamata «Gli avvicendamenti» più avanti in questo capitolo per gli esempi. Questa è una occorrenza rara comunque. La maggior parte della gente risponde molto bene alla critica che sia specifica, e che contenga una chiara (anche se non detta) aspettativa di miglioramento.
La lode non dovrebbe offendere i sentimenti di nessuno, certo, ma questo non significa che dovrebbe essere usata per nulla meno con attenzione della critica. La lode è uno strumento: prima di usarla, chiedetevi perché volete usarla. Come regola, non è una buona idea lodare la gente per cose che usualmente fa, o per azioni che sono una parte normale e prevista della partecipazione al gruppo. Se voi doveste farlo, sarebbe difficile sapere quando smettere dovreste lodare ognuno perché fa le cose normali? Dopotutto, se lasciate fuori qualcuno, egli si chiederà perché. E' molto meglio esprimere lode e gratitudine con parsimonia, in risposta a inattesi e insoliti sforzi, con l'intento di incoraggiare più sforzi di questi. Quando un partecipante sembra essesi mosso permanentemente in uno stato di alta produttività, adattate la vostra soglia di lode per quella persona in modo consono. Lodi ripetute per comportamenti normali diventano senza senso comunque. Invece, quella persona dovrebbe avvertire che il suo alto livello di produttività è ora considerato come normale e naturale, e solo il lavoro che vada oltre quel livello dovrebbe essere notato particolarmente.
Con questo non voglio dire che i contributi della persona non dovrebbero essere riconosciuti, certo. Ma ricordate che se il progetto è messo su bene, ogni cosa che quello persona fa è già visibile comunque, e così il gruppo saprà (e la persona saprà che che il resto del gruppo sa) ogni cosa che fa. Ci sono anche modi per dare un riconoscimento al lavoro che uno fa per mezzo di altro al posto di lodi dirette. Potete menzionare di passaggio, mentre discutete un argomento correlato, che egli ha fatto un sacco di lavoro in un dato campo ed è l'esperto locale lì; potete pubblicamente consultarlo circa qualche questione sul codice; o magari, più efficacemente, potete fare un massiccio uso ulteriore del lavoro che ha fatto, in modo che veda che gli altri sono a proprio agio nel contare sul risultato del suo lavoro. Probabilmente non è necessario fare queste cose in modo calcolato. Qualcuno che regolarmente dà ampi contributi in un progetto lo saprà, e occuperà una funzione influente senza che faccia nulla di proposito. Di solito non c'è bisogno di fare passi espliciti per assicurare ciò, a meno che voi non abbiate la sensazione, per una qualsiasi ragione, che un collaboratore è sottostimato.
Fate attenzione a che i partecipanti non cerchino di esercitare una proprietà esclusiva su certe aree del progetto, e a coloro che sembrano voler fare tutto il lavoro in quelle aree, fino al punto di assumere la direzione del lavoro che altri incominciano. Tale comportamento può sembrare anche sano all'inizio. Dopotutto in superficie egli sembra una persona che si prede più responsabilità, e mostra una attività maggiore un una data area. Ma a lungo andare, ciò è distruttivo. Quando la gente ha la percezione di un segnale di “non sconfinamento” si astiene. Il risultato è una ridotta revisione in quell'area, e di una maggiore fragilità, perché lo sviluppatore solitario diventa un punto di fallimento che provoca il fallimento dell'intero progetto. Peggio, ciò infrange la collaborazione, lo spirito egualitario del progetto. La teoria dovrebbe essere sempre quella che ogni sviluppatore deve essere il benvenuto nell'essere di aiuto in ogni operazione in ogni momento. Certo, in pratica le cose vanno un po' diversamente: le persona hanno aree in cui sono più o meno influenti, e i non esperti rinviano agli esperti in certi domini del progetto. Ma la chiave è che ciò sia tutto volontario: l'autorità informale è data per scontata se basata sulla competenza e sul giudizio dimostrato, ma non dovrebbe mai essere acquisita volontariamente. Anche se la persona che desidera l'autorità e effettivamente competente, è cruciale che eserciti quell'autorità informalmente, attraverso il consenso del gruppo, e che non sia la causa dell'escussione di altri dal lavoro in quel gruppo.
Respingere o modificare il lavoro di qualcuno, è una roba completamente differente. Lì, il fattore decisivo è il contenuto del lavoro, non chi è sembrato agire come custode. Può avvenire che una stessa persona sembra fare la maggior parte del lavoro di revisione per una data area, ma fino a quando egli non cerca di impedire a qualcun altro di fare anche lo stesso lavoro, le cose stanno probabilmente a posto.
Per combattere un incipiente territorialismo, o anche l'apparenza di esso, molto progetti hanno fatto il passo di bandire l'introduzione nei file sorgenti dei nomi degli autori e quelli dei manutentori designati. Io sono francamente d'accordo con questa pratica: noi la seguiamo nel progetto Subversion, ed è più o meno la politica ufficiale nella Apache Software Foundation. Il membro della ASF la presenta in questo modo:
All'Apache Software Foundation noi scoraggiavamo l'uso dei tag author nel codice sorgente. C'erano molte ragioni per questo, oltre alle conseguenze legali. Lo sviluppo collettivo consiste nel lavorare sui progetti come gruppo e aver cura del progetto come gruppo. Dare riconoscimenti è giusto, e dovrebbe essere fatto, ma in un modo che non permetta false attribuzioni, anche per sottinteso. Non c'è una linea chiara su quando aggiungere o rimuovere un tag author. Aggiungete il vostro nome quando cambiate un commento? Quando inserite una correzione in linea. Rimuovete il tag di un altro autore quando cambiate un codice senza cambiare il risultato ed esso sembra al 95% differente? Che fate con persone che vanno in giro a toccare ogni file, a cambiare quanto basta per creare una quantità effettiva di tag, in modo che il loro nome appaia dappertutto?
Ci sono modo migliori di dare riconoscimenti, e la nostra preferenza è di usare questi. Da un punto di vista tecnico i tag author non sono necessari; se volete trovare chi ha scritto un pezzo particolare di codice, può essere consultato il sistema del controllo di versione per capirlo. I tags author tendono anche ad essere antiquati. Volete veramente essere contattati in privato su un pezzo di codice che avete scritto cinque anni fa ed essere felici di averlo dimenticato?
I files sorgente di codice di un progetto sono il cuore della sua identità. Essi dovrebbero rispecchiare il fatto che la comunità degli sviluppatori è nel complesso responsabile per essi, e non è divisa in piccoli feudi.
La gente talvolta parla in favore dei tags author o mantainer nei files sorgente sulla base del fatto che essi danno un riconoscimento visibile a quelli che hanno fatto la maggior parte del lavoro lì. Ci sono due problemi su questo argomento. Primo, i tags inevitabilmente sollevano la imbarazzante questione di quanto lavoro uno debba fare per vedere il suo nome elencato lì pure. Secondo, essi aggiungono il problema del riconoscimento a quello della paternità: aver fatto il lavoro in passato, non implica la paternità dell'aerea in cui il lavoro fu fatto, ma è difficile se non impossibile una tale conclusione quando i nomi individuali sono elencati in cima ai files sorgenti. In ogni caso l'informazione dei riconoscimenti può essere ottenuta dai logs del controllo di versione e per mezzo di altri meccanismi messi al-di-fuori-della-banda, come gli archivi delle mailing lists, in modo tale che non si perda nessuna informazione bandendola dai files sorgente stessi.
Se il vostro progetto decide di bandire i nomi individuali dai file sorgenti, cercate di non debordare. Per esempio, molti progetti hanno un'area contrib/ in cui sono tenuti piccoli strumenti e scripts di aiuto, spesso scritti da gente che non è per altra via associata al progetto. E' bene che quei files contengano i i nomi degli autori, perché essi non sono effettivamente in manutenzione al progetto nel suo intero. D'altra parte, se uno strumento dato come contributo incomincia ad essere modificato da altre persone nel progetto, alla fine voi potete volerlo spostare in un una locazione meno isolata, e facendo il caso che l'autore originale approvi, rimuovere il nome dell'autore, di modo che il codice appaia come ogni altra risorsa in manutenzione da parte dalla comunità. Se l'autore è permaloso su questo, sono accettabili soluzioni di compromesso, per esempio:
# indexclean.py: Rimuoveere i vecchi dati da un indice Scanley. # # Autore originale: K. Maru <kobayashi@yetanotheremailservice.com> # Ora mantenuto da: The Scanley Project <http://www.scanley.org/> # and K. Maru. # # ...
Ma è meglio evitare tali compromessi, se possibile, e molti autori si stanno persuadendo, perché sono felici del fatto che si sta facendo del loro contributo una parte più integrale del progetto.
La cosa importante è ricordare che c'è una continuità fra il cuore e la periferia di ogni progetto. I principali files di codice sorgente del software sono chiaramente parte del cuore, e dovrebbero essere essere considerati in manutenzione da parte della comunità. D'altra parte, strumenti di accompagnamento o pezzi di documentazione possono essere il lavoro di singoli individui, che li hanno in manutenzione essenzialmente da soli, anche se i lavori possono essere associati, o anche distribuiti, dal progetto. Non c'è bisogno di applicare una regola di taglia unica a ogni file, finché vale il principio che non è permesso che le risorse in manutenzione alla comunità diventino territori personali.
Cercare di non consentire agli uomini ciò che invece potrebbero fare le macchine. Come regola pratica, automatizzare una operazione comune vale dieci volte almeno lo sforzo che uno sviluppatore dovrebbe impiegare a fare manualmente quella operazione una volta. Per operazioni molto frequenti o molto complesse, il rapporto potrebbe arrivare facilmente a venti o anche di più.
Il pensare a voi stessi come “gestori di progetto”, piuttosto che solo come ad un altro sviluppatore, potrebbe essere un utile atteggiamento qui. A volte gli sviluppatori individuali sono tropo infagottati in lavori di basso livello per vedere il quadro grande e rendersi conto che ognuno sta sprecando un sacco di energie ad eseguire manualmente operazioni automatizzabili. Anche quelli che se ne rendono conto possono non avere il tempo di risolvere il problema: perché ogni esecuzione individuale dell'operazione non è percepita come un enorme carico, nessuno si secca abbastanza di fare qualcosa che la riguarda. Ciò che rende convincente l'automazione è che quel piccolo carico è moltiplicato per il numero di volte che ogni sviluppatore incorre in essa, e quindi quel numero è moltiplicato per il numero degli sviluppatori.
Qui sto usando il termine “automazione” in senso largo, per indicare non solo le ripetute azioni nelle quali una o due variabili cambiano ogni volta, ma ogni tipo di infrastruttura tecnica che assiste gli uomini. Il minimo standard di automazione richiesta per far girare un progetto in questi giorni è descritto in Capitolo 3, L'Infrastruttura Tecnica , ma ogni progetto può avere i suoi particolari problemi anche. Per esempio un gruppo che sta lavorando sulla documentazione, potrebbe volere un sito che mostri le più aggiornate versioni dei documenti in ogni momento. Siccome la documentazione è scritta in un linguaggio di markup come l'XML, ci può essere un passo della compilazione, spesso piuttosto intricato, relativo alla creazione di documenti che si possano esporre e che si possano scaricare. Adattare un sito in modo che tale compilazione avvenga automaticamente ad ogni invio può essere complicato e dispendioso come tempo impiegato ma ne vale la pena, anche se vi costa un giorno o più ad allestirlo. Il beneficio complessivo di avere pagine aggiornate in ogni momento è enorme, anche se il costo di non non averlo potrebbe sembrare solo un piccolo incomodo in ogni singolo momento, ad ogni singolo sviluppatore.
Fare tali passi non solo elimina tempo sprecato, ma l'oppressione e la frustrazione che ne deriva quando gli uomini fanno dei passi sbagliati (come li faranno inevitabilmente) nel cercare di portare a termine complicate procedure manualmente. Le operazioni dai molteplici passi, deterministiche sono ciò per cui i computers sono stati inventati; riservate agli uomini cose più interessanti.
L'esecuzione di tests automatizzati sono utili per ogni progetto di software, perché il testing automatizzato (specialmente il testing di regressione) permette agli sviluppatori di sentirsi a proprio agio quando cambiano codice in aree con cui non hanno familiarizzato, e così incoraggiano lo sviluppo d'esplorazione. Poiché la ricerca dei guasti è difficile da fare a mano uno essenzialmente deve azzeccare dove potrebbe aver sbagliato qualcosa, e tentare vari esperimenti per provare il contrario—l'avere modi automatizzati per individuare tali guasti risparmia al progetto un sacco di tempo. Ciò anche fa si che la gente sia più rilassata nel migliorare la leggibilità di larghe falciate di codice , e quindi contribuisce alla capacità di tenere in manutenzione il software nel lungo periodo.
Il testing di regressione non è una panacea. Tanto per dirne una, esso funziona molto bene con programmi con una interfaccia con comandi eseguiti in serie. Il software che è fatto funzionare con una interfaccia utente grafica è molto più difficile da far funzionare da programma. Un altro problema è che la struttura della swite per il test di regressione può spesso essere piuttosto complessa, con una curva di apprendimento e un carico di manutenzione che le sono peculiari. Ridurre questa complessità è una della cose più utili che possiate fare, anche se può richiedere un considerevole ammontare di tempo. La cosa più facile è aggiungere nuovi tests alla suite, più gli sviluppatori faranno così, più pochi bugs sopravviveranno nella release. Ogni sforzo fatto per rendere i tests più facili sarà ripagato molte volte durante vita del progetto.
Molti progetti hanno una regola “Non sfasciate l'allestimento!” ,che significa: non fare un invio che renda difficile la compilazione o l'esecuzione del software. Essere la persona che sfascia la costruzione è di solito causa di leggero imbarazzo e di burla. I progetti con una swite per i tests di regressione spesso hanno una regola corollario: non inviare cambiamenti che fanno fallire i tests. E' molto facile osservare questi fallimenti se ci sono esecuzioni automatiche notturne dell'intera suite di tests, con i risultati inviati alle mailing lists dello sviluppo, o a una mailing list dedicata di risultai del testing; questo è un altro esempio di automazione utile.
La maggior parte degli sviluppatori volontari sono disposti a spendere un tempo extra per scrivere tests di regressione, quando il sistema di test è comprensibile ed è facile lavorare con esso. Accompagnare i cambiamenti con tests è intesa come cosa responsabile da fare, ed è una facile opportunità di collaborazione: spesso due sviluppatori si divideranno il lavoro per la correzione di un bug, con uno che scrive la correzione stessa e uno che scrive il test. Il secondo sviluppatore può spesso beccarsi il maggior lavoro, e poiché scrivere un test è già meno soddisfacente che correggere realmente il bug, è imperativo che la suite di test non renda l'esperienza più stressante di quanto debba essere.
Alcuni progetti vanno anche oltre, richiedendo che un test accompagni ogni correzione di bug o ogni nuova funzionalità. Se questa sia una buona idea o no dipende da molti fattori: la natura del software, la composizione del team di sviluppo, e la difficoltà di scrivere nuovi tests. Il progetto CVS (http://www.cvshome.org/)
ha a lungo avuto questa regola. E' una buona politica in teoria, poiché CVS è un sistema di controllo di versione e quindi molto avverso al rischio di rovinare o maltrattare i dati dell'utilizzatore. Il problema in pratica è che la suite di test di regressione di CVS è un enorme script di shell (in modo divertente chiamato sanity.sh),
difficile da leggere e difficile da modificare o estendere. La difficoltà di aggiungere nuovi tests, combinata col requisito che le patches siano accompagnate da nuovi tests, significa che CVS in effetti scoraggia le patches. Quando ebbi modo di lavorare a CVS, talvolta vidi la gente iniziare e anche completare le loro patches al proprio codice di CVS, ma arrendersi quando quando si diceva loro del requisito dell'aggiunta di un nuovo test a sanity.sh.
E' normale impiegare più tempo a scrivere un nuovo test di regressione che a correggere il bug originale. Ma CVS portò questo fenomeno all'estremo: uno poteva impiegare ore nel cercare di scrivere il suo test in modo appropriato, e ancora trovarsi in errore, perché ci sono appunto troppo imprevedibili complessità relative al cambiamento di uno script della shell di Bourne di 35.000 linee. Anche gli sviluppatori anziani di CVS si lamentavano quando dovevano aggiungere un nuovo test.
Questa situazione era dovuta a un nostro fallimento su tutta la linea nel considerare il rapporto di automazione. Sebbene il passare a una struttura di test reale—sia costruita personalmente sia dal di fuori, avrebbe richiesto uno sforzo maggiore.[23] Ma il non fare così è costato al progetto molto più, nel corso degli anni. Quante correzioni di bugs non ci sono in CVS oggi, a causa dell'ostacolo di una cattiva suite di test? Non non ne possiamo sapere l'esatto numero, ma è sicuramente molte volte più grande del numero di correzioni o di nuove funzionalità a cui gli sviluppatori potrebbero dover rinunciare per sviluppare un nuovo sistema di test (o integrare un sistema esterno). Quella operazione richiederebbe solo un finito ammontare di tempo, mentre la penalizzazione dell'uso della suite di test corrente continuerà per sempre se non si fa niente.
Il punto non è quello che avere avere requisiti stringenti per scrivere tests è male, né che scrivere il vostro sistema di test come lo script della shell di Bourne è necessariamente male. Il punto è semplicemente che quando il sistema di test diventa una significativo impedimento per lo sviluppo, qualcosa deve essere fatto. Lo stesso vale per ogni processo di routine che diventa una strettoia o una barriera.
Ogni interazione con un utilizzatore è un'opportunità per procurarsi un nuovo volontario. Quando un utilizzatore si concede il tempo di scrivere ad una delle mailing lists del progetto o di mettere un archivio un rapporto di bug, ha già indicato se stesso come possessore di un maggiore potenziale per un coinvolgimento rispetto alla maggior parte degli utilizzatori (dai quali il progetto non avrà mai notizie). Seguite questo potenziale: se egli ha descritto un bug, ringraziatelo per il report e chiedetegli de vuole correggerlo. Se egli ha scritto per dire che che una domanda importante manca nelle FAQ, o che la documentazione del programma è insufficiente in qualche modo, allora ammettete apertamente l'esistenza del problema (ammesso che esso esista realmente), e chiedetegli se è interessato a scrivere il materiale mancante. Naturalmente molte volte l'utilizzatore farà obiezione. Ma non costa molto chiedere, e ogni volta che lo fate, ciò ricorda agli altri ascoltatori in quel forum che essere coinvolti nel progetto è qualcosa che ognuno può fare.
Non limitate i vostri obiettivi ad acquisire nuovi sviluppatori e gente che scriva la documentazione. Per esempio, anche l'addestramento della gente a scrivere buoni rapporti di bugs dà buoni risultati a lungo andare, se non impiegate troppo tempo per persona, e se essi procedono ad inviare più report di bugs in futuro—cosa a cui sono molto propensi se ottengono una costruttiva reazione al loro primo rapporto. Una costruttiva reazione non è necessario che sia una correzione del bug, sebbene questo sia sempre l'ideale; essa può essere anche un sollecitazione per maggiori informazioni, o solamente la conferma che quel comportamento è un bug. La gente vuole essere ascoltata. Secondariamente essi vogliono che il loro bug sia corretto. Voi potrete non essere in grado di dare loro la seconda cosa in modo opportuno, ma (o il progetto intero) potete dare loro la prima cosa.
Un corollario di questo è che gli sviluppatori non dovrebbero esprimere collera a persone che archiviano ben comprensibili ma vaghi report di bug. Questo è uno dei miei fastidi ricorrenti; vedo farlo su varie mailing lists open source, è il male che fa è palpabile. Alcuni sventurati principianti scriveranno un inuutile report:
non mi riesce di prendere una Scanley da far girare. Ogni volta che parte, mi dà errore. Sta qualcun altro riscontrando lo stesso problema?
che hanno visto questo tipo di report centinaia di volte, e che non si sono trattenuti dal pensare che il principiante non li hanno visti centinaia di volte risponderanno all'incirca così:
Cosa avete supposto di fare con così poca informazione? E' frustrante. Dateci almeno qualche dettaglio, come la versione di Scanley, il vostro sistema operativo e l'errore.
Lo sviluppatore ha mancato di vedere le cose dal punto di vista dell'utilizzatore, ed ha mancato anche di considerare l'effetto che una tale reazione potrebbe avere sul tutte le altre altre persone che stanno osservando lo scambio. Naturalmente un utilizzatore che non ha una esperienza di report di bugs, non saprà come scrivere un report di bug. Quale è il modo giusto di trattare questa persona? Educatelo! E fatelo in modo che egli ritorni per maggiori ragguagli:
Mi dispiace che state avendo problemi. Abbiamo bisogno di maggiori informazioni per renderci conto di ciò che sta succedendo qui. Prego diteci la versione di Scanley, il vostro sistema operativo, e il testo esatto dell'errore. La miglior cosa che possiate fare è quella di inviare uno scritto che mostri gli esatti comandi che avete dato, e l'uscita che hanno prodotto. Vedere http://www.scanley.org/how_to_report_a_bug.html per maggiori ragguagli.
Questo modo di rispondere è molto più efficace per ottenere le necessarie informazione dagli utilizzatori, perché sono scritte dal punto di vista dell'utilizzatore. Primo, esso esprime simpatia: Voi avevate un problema; non sentivamo il vostro disappunto.. (Ciò non è necessario in ogni risposta a ogni rapporto di bug; dipende dalla serietà del problema e da quanto è sembrato sconvolto l'utilizzatore. Secondo, invece di disprezzarlo perché no sa come riportare un bug, gli dice come, e abbastanza in dettaglio per essere veramente utile per esempio molti utilizzatori non si rendono conto che “mostraci l'errore” significa “mostraci l'esatto testo dell'errore, senza omissioni o riassunti.” La prima volta che lavorate con tale utilizzatore, bisogna che siate precisi su questo. Alla fine ciò offre un puntatore a molte più dettagliate e complete istruzioni per l'invio dei rapporti sui bugs. Se avete stabilito con successo un contatto con l'utilizzatore, egli si prenderà spesso il tempo di leggere quel documento e fare ciò che dice. Ciò vuol dire che voi, certamente, dovete aver preparato quel documento in anticipo. Esso dovrebbe dare chiare istruzioni su che tipo di informazioni vuole vedere in ogni rapporto il vostro team di sviluppo. Idealmente, esso dovrebbe evolversi nel tempo in risposta a ai tipi pericolari di omissioni e di cattivi report che l'utilizzatore tende a a fare per il vostro progetto.
Le istruzioni sui report di Subversion sono un esempio standard alla lettera della forma (vedere Appendice D, Istruzioni di Esempio per Segnalare un Bug). Notate come essi rispondono ad un invito a fornire una patch per correggere il bug. Ciò non avviene perché un tale invito porterà a un rapporto patch/report più grande la maggior parte degli utilizzatori sono in grado di correggere bugs di cui già sanno che una patch sarebbe la benvenuta, e non hanno bisogno che gli venga detto. Il reale proposito di un invito è quello di porre l'accento per tutti gli utilizzatori, specialmente quelli nuovi nel progetto, o nuovi al software libero in generale, sul fatto che che il progetto va avanti con contributi di volontari. In un certo senso, gli attuali sviluppatori del progetto non sono più responsabili della correzione dei bugs di quanto non lo siano quelli che li hanno segnalati nei report. Questo è un punto importante con il quale molti nuovi utilizzatori non avranno familiarità. Una volta che se ne rendono conto essi probabilmente contribuiranno a fa si che la correzione al bug avvenga, se non contribuendo col codice allora fornendo un più completa ricetta per la riproduzione, o offrendosi per tests di bugs che le altre persone postano. L'obiettivo è far si che ogni utilizzatore si renda conto che non c'è una innata differenza fra se stessi e la gente che lavora al progetto è una questione di quanto tempo uno ci mette dentro, non di chi uno sia.
L'ammonizione a non rispondere in modo irritato non vale per gli utilizzatori sgarbati. Occasionalmente gli utilizzatori postano reports o rimostranze che, indipendentemente dal loro contenuto di informazione, mostrano un disprezzo con derisione nei confronti di alcune manchevolezze del progetto. Spesso tali persone alternativamente insultano e fanno complimenti, come la persona che postò alla mailing list di Subversion:
Com'è che sono quasi 6 giorni che non ci sono ancora binari postati per la piattaforma di windows?!? E' la stessa storia ogni volta, ed è molto frustrante. Perché queste cose non sono automatizzate in modo che possano essere disponibili immediatamente?!?. Quando voi postate un allestimento “RC”, io penso che l'idea sia quella ch volete che gli utilizzatori testino l'allestimento, ma tuttavia non provvedete in nessun modo a fare così. Perché anche avete un lungo periodo testing se non fornite i mezzi per testare??
La risposta iniziale a questa infiammatorio post fu sorprendentemente contenuta: la gente fece notare che il progetto aveva un politica esplicita di non fornire binari, e disse, con vari gradi di irritazione, che sarebbe stato compito dei volontari di produrli essi stessi se erano tanto importanti per loro. Ci credete o no, il suo post successivo partiva con queste righe:
Prima di tutto, lasciatemi dire che Subversion è fantastico, e io apprezzo veramente l'impegno di chiunque vi sia coinvolto. [...]
...e quindi ritornò a redarguire il progetto di nuovo perché non forniva i binari, mentre non ancora si offriva volontario per fare qualcosa a proposito. Dopodiché, circa 50 persone gli saltarono addosso, e non so dire se veramente ci feci caso. La politica di “zero tolleranza” verso la maleducazione sostenuta in sezione chiamata «Stroncate sul Nascere la Scortesia» in Capitolo 2, Partenza si applica a persone con cui il progetto ha una prolungata interazione (o vorrebbe averla). Ma quando qualcuno rende chiaro dall'inizio che sta diventando una fontana di bile, non vale la pena di farlo sentire il benvenuto.
Tali situazioni sono fortunatamente piuttosto rare, e sono notevolmente rare in progetti e che fanno uno sforzo per ingaggiare utilizzatori con cortesia e costruttivamente sin dalla loro prima interazione.
[22] Questa questione fu studiata in dettaglio, con interessanti risultati, in uno scritto di Karim Lakhani e Robert G. Wolf, dal titolo Perché gli Hackers Fanno Ciò che Fanno: Comprendere Lo Sforzo e le Motivazioni nei Progetti Liberi/Open Source. Vedere http://freesoftware.mit.edu/papers/lakhaniwolf.pdf.
[23] Notare che lì non ci sarebbe bisogno di convertire tutti i tests esistenti alla nuova struttura; le due cose potevano esistere felicemente una a fianco a l'altra, con i vecchi tests convertiti solo se c'era bisogno che fossero cambiati.