Suddividete i Compiti di Management e i Compiti Tecnici. Suddividere il carico del management cos� come il carico tecnico del mandare avanti il progetto. Nella misura in cui il progetto diventa pi� complesso, sempre pi� il lavoro � quello di amministrare la gente e il flusso delle informazioni. Non c'� motivo per non suddividere quel carico, e la suddivisione non richiede una gerarchia dall'alto in basso —ci� che avviene in pratica tende ad essere pi� tipico della topologia di una rete peer to peer che della struttura di un comando stile militare.
A volte i ruoli del management sono formalizzati, e a volte si verificano spontaneamente. Nel progetto di Subversion, noi avevamo un manager delle patch, un manager delle traduzioni, un manager della documentazione, un manager dei problemi (sebbene non ufficiale) e un manager di release. Per dare avvio ad alcuni di questi ruoli non prendemmo una decisione consapevole, per altri avvenne che i ruoli avessero inizio da s�; nella misura in cui il progetto cresce, mi aspetto che si aggiungeranno altri ruoli. Qui di seguito esamineremo alcuni questi ruoli, e una coppia di altri, in dettaglio (eccetto il manager di release che � stato trattato gi� in sezione chiamata �Il manager di release� e sezione chiamata �Dittatura Da Parte del Proprietario Della Release� precedentemente in questo capitolo).
Quando leggete la descrizione del ruolo, notate che nessuno di essi richiede il controllo esclusivo sul dominio in questione. Il manager dei problemi non impedisce ad altre persone di fare cambiamenti nel database dei problemi, il manager delle FAQ non insiste sul fatto di essere la sola persona che redige le FAQ, e cos� via. Questi ruoli consistono tutti nella responsabilit� senza il monopolio. Una parte importante del lavoro del manager di ciascun dominio � quella di prender nota quando altre persone stanno lavorando in quel dominio, e trascinare loro a fare le cose nel modo in cui le fa il manager, in modo che gli sforzi multipli si rafforzino piuttosto che andare in conflitto. I managers di dominio dovrebbero anche documentare i processi con i quali essi fanno il loro lavoro, cos� che quando uno lascia qualcun altro possa colmare la mancanza subito.
A volte c'� un conflitto: due o pi� persone vogliono lo stesso ruolo. Non c'� una via giusta per gestire questa cosa. Potreste suggerire ad ogni volontario di postare una proposta (una “applicazione”) e ottenere che ogni persona che fa l'invio voti su chi � il migliore. Ma ci� � scomodo e potenzialmente pericoloso. Io trovo che una tecnica migliore sia quella di chiedere ai vari candidati di sistemare la cosa fra loro stessi. Essi, di solito, saranno pi� soddisfatti del risultato, che se la decisione fosse stata imposta dal di fuori.
In un progetto si software libero che riceve un sacco di patch, tener traccia di quali patch sono arrivate, e cosa si � deciso su esse pu� essere un incubo, specialmente se lo si fa un modo decentralizzato. La maggior parte delle patch arrivano come posts alla mailing list di sviluppo (sebbene alcune possano apparire nel tracciatore di bug, o su siti esterni), e quindi ci sono un numero di differenti itinerari che la patch pu� percorrere dopo l'arrivo.
A volte qualcuno revisiona le patch, trova i problemi, e li rimanda all'autore originario per la ripulita. Ci�, di solito, porta a un processo iterativo tutto visibile sulla mailing list in cui l'autore originario posta le versioni revisionate della patch fino a quando il revisore non ha nient'altro da criticare. Non � sempre facile dire quando il processo � terminato: se il revisore fa l'invio della patch, allora chiaramente il ciclo � completo. Ma se non lo fa, potrebbe essere semplicemente perch� non ha tempo, o perch� non ha l'accesso all'invio e non potrebbe unirsi alla cordata degli altri sviluppatori nel farlo.
Un'altra frequente risposta a una patch � una discussione a ruota libera, non necessariamente sulla patch stessa, ma sul fatto se il concetto che sta dietro la patch � buono. Per esempio, la patch pu� correggere un bug, ma il progetto preferisce correggere quel bug in un altro modo, come parte della risoluzione di una classe pi� generale di problemi. Spesso questa non � nota in anticipo, ed � la patch che ne stimola la scoperta.
Occasionalmente, una patch postata � accolta con assoluto silenzio. Ci�, di solito, � dovuto al fatto che al momento nessuno sviluppatore ha il tempo di revisionare la patch. Poich� non c'� un limite particolare per quanto riguarda il tempo che ogni persona aspetta che qualcun altro raccolga la palla, e nel frattempo altre priorit� stanno arrivando, � molto facile che una patch sfugga tra le crepe senza che una singola persona abbia intenzione che avvenga. Il progetto potrebbe perdere una utile patch in questo modo, e ci sono anche altri dannosi effetti collaterali anche: ci� � scoraggiante per l'autore, che ha impiegato lavoro per la patch, e fa apparire il progetto nell'insieme come se abbia perso i contatti, specialmente agli altri che stanno prendendo in considerazione la scrittura di patch.
Il lavoro del manager di patch � quello di assicurare che le patch non “scivolino fra le crepe”. Ci� si ottiene seguendo ogni patch attraverso una sorta di stato stabile. Il manager di patch esamina ogni discussione della mailing list che consegua ad un post di patch. Se essa finisce con un invio, egli non fa niente. Se essa va in un' iterazione revisione/correzione, che termina con una versione finale della patch senza che ci sia l'invio, egli archivia un problema che punti alla versione finale, e alla mailing lista che tratta di esso, di modo che ci sia una registrazione permanente che gli sviluppatori possono seguire in seguito. Se la patch si indirizza ad un problema esistente, egli annota il problema con ricche informazioni, invece di aprire un nuovo problema.
Quando una patch non riscuote per niente una reazione, il manager di patch aspetta pochi giorni, quindi d� seguito alla cosa chiedendo se qualcuno sta per revisionarla. Questo, di solito, riceve una reazione: uno sviluppatore pu� spiegare che non pensa che la patch debba essere applicata, e ne d� le ragioni, o pu� revisionarla, nel qual caso viene fatto uno dei precedenti percorsi. Se non c'� ancora risposta, il manager di patch pu� o non pu� archiviare un problema per la patch, a sua discrezione, ma almeno chi originariamente ha fatto l'invio ha ricevuto qualche reaction.
L'avere un manager di patch ha salvato il team di sviluppo di Subversion un sacco di volte, ed fatto risparmiare energie mentali. Senza una persona designata che si prenda la responsabilit�, ogni sviluppatore avrebbe da preoccuparsi continuamente “Se non ho il tempo di rispondere a questa patch subito, posso contare sul fatto che qualche altro lo faccia? Dovrei cercare di dargli un'occhiata. Ma se altre persone stanno anche tenendola d'occhio, per le stesse ragioni, noi avremmo inutilmente duplicato lo sforzo.” Il manager di patch rimuove la seconda congettura dalla situazione. Ciascuno sviluppatore pu� prendere la decisione giusta per lui dal primo momento che vede la patch. Se vuole dargli seguito con una revisione, pu� farlo il manager di patch adatter� il suo comportamento di conseguenza. Se vuole ignorare la patch completamente, andr� anche bene; il manager di patch dovr� assicurarsi che essa non sia dimenticata.
Siccome il sistema funziona solo se la gente pu� far conto sul fatto che il manager di patch sia l� senza errore, il ruolo dovrebbe essere detenuto formalmente. In Subversion noi facemmo richiesta per esso mediate annuncio pubblicitario sulla mailing list dello sviluppo e degli utilizzatori, raccogliemmo molti volontari, e prendemmo il primo che ci rispose. Quando quella persona dovette ritirarsi (vedere sezione chiamata �Gli avvicendamenti� pi� avanti in questo capitolo), facemmo di nuovo la stessa cosa. Non cercammo mai di avere pi� persone ad detenere in comune il ruolo a causa delle informazioni addizionali che sarebbero state richiesta fra loro, ma forse a un volume molto alto di invii di patch, potrebbe aver senso un manager di patch a pi� teste.
Nei progetti di software “traduzione” pu� riferirsi a due cose molto differenti. Pu� significare tradurre la documentazione del software in altre lingue, o pu� significare tradurre il software stesso cio� ottenere le segnalazioni dei errore o dei messaggi di aiuto in altre lingue preferite dall'utente. Ambedue sono complesse operazioni, ma una volta che la giusta infrastruttura � allestita, esse sono largamente separabili dall'altro sviluppo. Poich� le operazioni sono simili in qualche modo, ha senso (a seconda del vostro progetto), avere un solo manager delle traduzioni che le gestisca ambedue, o pu� essere meglio avere due differenti manager.
Nel progetto di Subversion noi avevamo un manager di traduzione che gestiva ambedue le cose. Egli non deve scrivere le traduzioni egli stesso, certo, egli pu� dare una mano a uno o due, ma mentre questo scrive, egli dovrebbe aver bisogno di parlare dieci lingue (venti contando i dialetti) per lavorare a tutte le traduzioni. Invece, egli gestisce dei team di traduttori volontari: egli li aiuta a coordinarsi fra loro, e coordina i team fra loro e il resto del progetto.
Una parte delle ragioni per cui il manager delle traduzioni � necessario � che i traduttori sono una entit� demografica differente da quella degli sviluppatori. Essi a volte hanno qualche o nessuna esperienza nel lavorare con deposito del controllo di versione, o certamente proprio nel lavorare come parte del team di volontari distribuito. Ma sotto altri aspetti essi sono spesso la miglior specie di volontari: persone proprio con una specifica conoscenza del dominio che videro una necessit� e scelsero di essere coinvolti. Essi di solito sono desiderosi di imparare, ed entusiasti di mettersi al lavoro. Tutto ci� di cui hanno bisogno � uno che gli dica come. Il manager delle traduzioni assicura che la traduzione avvenga in modo da non interferire senza necessit� col regolare sviluppo. Egli anche funziona come come sorta di rappresentanza dei traduttori come corpo unificato, ogni volta che gli sviluppatori devono essere informati di cambiamenti tecnici richiesti per supportare lo sforzo di traduzione.
Cos�, le abilit� pi� importanti della posizione sono diplomatiche, non tecniche. Per esempio, in Subversion noi avevamo la politica che tutte le traduzioni dovevano avere almeno due persone a lavorarvi, perch� altrimenti non c'� modo di revisionare il testo. Quando un nuovo volontario si offre per tradurre Subversion in, diciamo, Malgascio, il manager delle traduzioni deve agganciargli qualcuno che post� sei mesi prima esprimendo interesse a tradurre in Malgascio, o anche politicamente chiedere al volontario di andare a trovare un altro traduttore in Malgascio per lavorare come suo partner. Una volta che abbastanza persone sono disponibili, il manager li sistema per un proprio tipo di accesso all'invio, li informa delle convenzioni del progetto (come per esempio scrivere i messaggi di log), e quindi tiene un occhio ad assicurarsi che essi aderiscano a queste convenzioni.
Le conversazioni fra il manager delle traduzioni e gli sviluppatori, o fra il manager delle traduzioni e i team delle traduzioni, sono di solito tenute nel linguaggio originale del progetto cio� la lingua da cui tutte le traduzioni sono fatte. Per molti progetti di software libero, questa � l'inglese, ma non importa quale sia fino a quando il progetto � d'accordo su ci�. (L'inglese comunque � probabilmente il meglio per progetti che vogliono attrarre una larga comunit� internazionale di sviluppatori).
Le conversazioni all'interno di un particolare team di traduzione avvengono nella loro lingua comune, comunque, � uno dei compiti del manager delle traduzioni quello di mettere su una mailing list dedicata per ogni team. In questo modo i traduttori possono discutere il loro lavoro liberamente, senza distrarre la gente su altre liste principali, la maggior parte delle quali non sarebbero in grado di capire il linguaggio di traduzione, comunque.
Il tenere aggiornata la documentazione � un compito senza fine. Anche nuove funzionalit� o miglioramenti che entrano nel codice hanno la possibilit� di causare un cambiamento nella documentazione. Anche, una volta che la documentazione del progetto raggiunge un certo livello di completezza, voi troverete che un sacco di patch che la gente manda sono per la documentazione, non per il codice. Questo perch� ci sono molte pi� persone competenti a correggere i bug nella prosa pi� che nel codice: tutti gli utilizzatori sono lettori, ma solo pochi sono programmatori.
Le patch sulla documentazione sono di solito molto pi� facili da revisionare e da applicare che le patch sul codice. C'� poco testing o nessun testing da fare, e la qualit� dal cambiamento pu� essere valutata rapidamente giusto con una revisione. Poich� la quantit� � alta, ma il carico di revisione abbastanza basso il rapporto informazioni addizionali amministrative-lavoro produttivo � pi� grande per le patch di documentazione di quello delle patch di codice. Inoltre, la maggior parte delle patch avranno probabilmente la necessit� di qualche ritocco per mantenere una coerenza di voce d'autore nella documentazione. In molti casi le patch si sovrapporranno o intaccheranno altre patch, e necessiteranno di essere ritoccate una rispetto all'altra prima di essere inviate alla mailing list a e al deposito.
Date le esigenze di gestire le patch sulla documentazione, e il fatto che il codice base ha bisogno di essere monitorato, in modo che la documentazione sia aggiornata, ha senso avere una persona, o un piccolo team, dedicato al compito. Essi possono tenere una registrazione di come e dove esattamente la documentazione resta indietro al software, ed possono avere delle procedure collaudate per gestire grandi quantit� di patch in un modo integrato.
Certo, questo non preclude ad altra gente nel progetto di applicare patch di documentazione al volo, specialmente quelle piccole, quando il tempo lo permette. E lo stesso manager di patch (vedere sezione chiamata �Il Manager delle Patch� prima in questo capitolo) pu� tener traccia sia di patch del codice si di patch di documentazione, archiviandole dove i team della documentazione e il team di sviluppo rispettivamente vogliono. (Se la quantit� totale di patch supera la capacit� di una persona di tenerne traccia, tuttavia, passare a separati manager di codice e documentazione, � probabilmente un buon primo passo. Il punto del team della documentazione � avere persone che si ritengano responsabili del mantenere la documentazione organizzata, aggiornata, e coerente. In pratica, ci� significa conoscere la documentazione profondamente con l'osservare in codice base, osservare i cambiamenti che gli altri inviano alla documentazione, osservare le patch di documentazione che arrivano, e usare tutte queste sorgenti di informazioni per mantenere in salute la documentazione.
Il numero dei problemi nel tracciatore di bug del progetto cresce in proporzione al numero di persone che usano il software. Quindi, anche se correggete i bug e sistemate un programma sempre pi� robusto, vi dovreste aspettare che tuttavia che il numero di problemi aperti cresca essenzialmente senza limiti. La frequenza di problemi duplicati anche cresce, come crescer� la frequenza di problemi descritti in modo incompleto e con pochi particolari.
I manager dei problemi sono di aiuto nell'alleviare questi problemi con l'osservazione di ci� che va nel database, facendovi periodicamente la rivista per vedere se ci sono problemi specifici. Il loro atto pi� comune probabilmente � correggere i problemi che arrivano, o perch� chi ha fatto il report non riemp� correttamente alcuni campi del form, o perch� il problema � un duplicato di uno esistente nel database. Ovviamente, pi� un manager di problemi � familiare con il database dei bug del progetto, con pi� efficienza sar� capace di trovare i problemi duplicati. Questo � uno dei principali vantaggi di avere poche persone che si specializzino nel database dei bug, invece che chiunque cerchi di farlo ad hoc. Quando il gruppo cerca di farlo in maniera decentralizzata, nessun singolo acquisisce una profonda esperienza nel contenuto del database.
I manager di problemi possono servire da mappa fra i problemi e i singoli sviluppatori. Quando ci sono un sacco di reports di bug che arrivano, non tutti gli sviluppatori possono leggere le mailing lists di notifica dei problemi con uguale attenzione. Comunque, se qualcuno che conosce il team degli sviluppatori sta tenendo d'occhio tutti i problemi che arrivano, allora pu� con discrezione dirigere l'attenzione di certi sviluppatori verso specifici bugs quando � opportuno. Certo, questo deve essere fatto con sensibilit� verso chiunque altro vada avanti nello sviluppo, e ai desideri e al temperamento del destinatario. Quindi, � spesso la miglior cosa che il manager di problemi sia uno sviluppatore egli stesso.
A seconda di come il vostro progetto usa il tracciatore di bug, il manager di problemi pu� anche modellare il database in modo da riflettere le priorit� del progetto. Per esempio, in Subversion, noi programmavamo i problemi in relaeses future specifiche, in modo che quando qualcuno chiedeva “Quando sar� corretto il bug X?, noi eravamo in grado si rispondere “Fra due releases”, anche se non gli potevamo dare la data esatta. Le releases sono rappresentate nel tracciatore di problemi come pietre miliari obiettivo, un campo disponibile in IssueZilla[24] As a rule, every Subversion release has one major new feature and a list of specific bug fixes. We assign the appropriate target milestone to all the issues planned for that release (including the new feature—it gets an issue too), so that people can view the bug database through the lens of release scheduling. These targets rarely remain static, however. As new bugs come in, priorities sometimes get shifted around, and issues must be moved from one milestone to another so that each release remains manageable. This, again, is best done by people who have an overall sense of what's in the database, and how various issues relate to each other.
Un'altra cosa che i manager di problemi fanno � segnalare quando i problemi diventano obsoleti. A volte un bug � corretto accidentalmente come parte di in cambiamento al software non correlato, o a volte il progetto cambia la sua mentalit� su fatto che un certo comportamento sia un errore. Trovare i problemi obsoleti non � facile: il solo modo di farlo sistematicamente � di fare una spazzata a tutti i problemi nel database. Intere spazzate diventano sempre meno fattibili col tempo, nella misura in cui cresce il numero dei problemi. Dopo un certo limite, il solo modo di mantenere in salute il database � quello di usare un approccio dividi-e-conquista: classificare immediatamente i problemi all'arrivo e dirigerli all'attenzione dello sviluppatore o del team. Il destinatario allora si prende carico del problema per il resto della sua vita, custodendolo verso la risoluzione o verso l'oblio se necessario. Quando il database � cos� grande, il manager dei problemi diventa pi� che un coordinatore complessivo, spedendo meno tempo a guardare ad ogni problema da s�, e pi� tempo a metterlo nelle mani della persona giusta.
La manutenzione delle FAQ � sorprendentemente un problema difficile. Diversamente dalla maggior parte dei documenti in un progetto, il cui contenuto � pianificato in anticipo dagli autori, una FAQ � un documento del tutto reattivo (vedere Manutenzione di una sezione FAQ). Non importa quanto grosso diventi, voi tuttavia non sapete quale sar� la nuova aggiunta. E poich� esso e costruito pezzo per pezzo, � molto facile che il documento nella sua interezza diventi incoerente e disorganizzato, e contenente anche voci duplicate o semi duplicate. Anche quando non ha nessun ovvio problema come questi, ci sono spesso interdipendenze non notate fra le voci link che dovrebbero essere creati e non lo sono perch� la relativa voce fu inserita un anno lontano.
Il ruolo del manager delle FAQ � duplice. Primo, egli mantiene la qualit� complessiva delle FAQ in quanto rimanere familiare con almeno gli argomenti di tutte le domande in esse, in modo che quando la gente aggiunge nuove voci che sono un duplicato o sono correlate alle voci esistenti, possa essere fatto l'appropriato adattamento. Secondo, egli osserva la mailing list del progetto e gli altri forum per altri problemi o domande e per scrivere nuove voci delle FAQ basate su queste informazioni. Questo secondo compito pu� essere piuttosto complesso: uno deve essere capace di seguire un argomento, riconoscere le domande base sollevate in esso, postare una voce nuova nelle FAQ, incorporarvi i commenti da parte di altri (poich� � impossibile che il manager delle FAQ essere un esperto in ogni argomento trattato nelle FAQ), e avvertire quando il processo � finito in modo che la voce sia alla fine aggiunta.
Il manager delle FAQ diventa anche l'esperto naturale nel formattare le FAQ. Ci sono un sacco di piccoli dettagli coinvolti nel tenere una FAQ nella forma giusta (vedere sezione chiamata �Trattate Tutte le Risorse Come un Archivio� in Capitolo�6, Comunicazione); quando gente a caso modifica le FAQ, a volte dimentica alcuni di questi dettagli. Questo va bene finch� il manager delle FAQ � li a pulire dopo di loro.
Sono disponibili vari software per essere di aiuto nella manutenzione delle FAQ. E' bene fare uso di essi, finch� non compromettono la qualit� delle FAQ, ma guardatevi dal sovra-automazione. Alcuni progetti cercano di automatizzare completamente il processo di manutenzione delle FAQ, permettendo a chiunque di contribuire e modificare le voci delle FAQ in modo simile alle wiki (vedere sezione chiamata �Wiki� in Capitolo�3, L'Infrastruttura Tecnica ). Ho visto che questo accade particolarmente con le Faq-O-Matic (http://faqomatic.sourceforge.net/), sebbene pu� essere che che i casi che ho visto fossero semplici abusi che andavano oltre ci� per cui le Faq-O-Matic erano state concepite. In ogni caso, mentre la decentralizzazione completa della manutenzione delle FAQ riduce il carico di lavoro per il progetto, ha come risultato delle FAQ pi� trasandate. Non c'� una persona con una larga vedute di tutte le FAQ, nessuno che avvisa quando certe voci necessitano di aggiornamento o diventano obsolete completamente, e nessuno che osservi le interdipendenze tra le voci. Il risultato sono delle FAQ che spesso non riescono a fornire agli utilizzatori quello che stanno cercando, e nei casi peggiori li ingannano. Usate qualunque strumento di cui avete bisogno per fare la manutenzione alle vostre FAQ, ma non permettete mai alla convenienza degli strumenti di sedurvi a compromettere la qualit� delle FAQ.
Vedere l'articolo di Sean Michael Kerner, Le FAQ sule FAQ, a http://osdir.com/Article1722.phtml, per la descrizione e la valutazione degli strumenti di manutenzione delle FAQ.