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.