Come sola classe formalmente distinta che si trova nei progetti open source, quelli che fanno gli invii meritano una attenzione speciale qui. Quelli che fanno gli invii sono una concessione inevitabile alla discriminazione in un sistema che diversamente è quanto meno discriminatorio possibile. Ma la “discriminazione” qui non è intesa come dispregiativo. La funzione che quelli che fanno gli invii svolgono è assolutamente necessaria, e io non penso che un progetto avrebbe successo senza di essa. Il controllo della qualità richiede, giusto, il controllo. Ci sono sempre molte persone che si ritengono competenti nel fare cambiamenti a un programma, e un qualche numero minore che effettivamente lo sono. Il progetto non può contare sul personale giudizio della gente; esso deve imporre gli standard e deve concedere l'invio solo a quelli che li soddisfano.[25]. D'altro canto, avere persone che possano inviare cambiamenti che funzionino direttamente fianco a fianco con persone che non lo possono introduce una ovvia dinamica di potere. La dinamica deve essere gestita in modo da non danneggiare il progetto.
In sezione chiamata «Chi Vota?» in Capitolo 4, L'Infrastruttura Sociale e Politica, noi già discutemmo i meccanismi del considerare i nuovi ammessi all'invio. Qui noi daremo un'occhiata agli standard con i quali i potenziali ammessi all'invio dovrebbero essere giudicati, e come questo procedimento debba essere presentato alla comunità allargata.
Nel progetto di Subversion noi sceglievamo coloro che dovevano far gli invio sulla base del principio Ippocratico: primo non fare danni. Il nostro criterio principale non è l'abilità tecnica oppure la conoscenza del codice, ma soltanto il fatto che chi fa gli invii mostri buon giudizio. Giudizio può significare semplicemente sapere cosa non intraprendere. Una persona potrebbe postare solo piccole patch, risolvendo onestamente piccoli problemi nel codice; ma se le patch si applicano un modo pulito, non contengono bug, e sono prevalentemente in accordo con i messaggi di log del progetto e col codice, con le convenzioni, e ci sono sufficienti patch a mostrare una chiara linea di comportamento, allora uno che fa già gli invii di solito propone quella persona per l'accesso all'invio. Se almeno tre persone dicono si, e nessuno obietta, allora viene fatta la proposta. Giusto, voi non potreste avere l'evidenza che è capace di risolvere problemi complessi in tutte le aree del codice base, ma questo non ha importanza: la persona ha reso chiaro che almeno è capace di giudicare le sue abilità. Le capacità tecniche possono essere imparate (e insegnate), ma il giudizio, per la maggior parte, no. Quindi, è la sola cosa che volete assicurarvi la persona abbia, prima di dargli l'accesso all'invio.
Quando la proposta di un nuovo accesso all'invio provoca discussioni, non è riguardo alle capacità tecniche, ma riguardo al comportamento della persona nella mailing list o in IRC. A volte qualcuno mostra abilità tecniche e capacità di lavorare all'interno delle linee guida formali del progetto, eppure è sostanzialmente bellicoso e non collaborativo nei forum pubblici. Questa è una faccenda seria; se la persona non sembra darsi da fare col tempo, anche in risposata ai consigli, allora noi non lo aggiungeremo come persona che fa gli invii non importa quanto capace sia. In un gruppo di volontari, capacità di socializzazione, o l'abilità di “giocare bene in un ambiente di prova”, sono importanti quanto le pure abilità tecniche. Siccome ogni cosa è sotto il controllo di versione, la penalità per l'aggiunta di uno che fa gli invii che voi non dovreste avere non è è tanto quanti problemi potrebbe causare al codice (la revisione li individuerebbe ad ogni modo), ma il fatto che potrebbe alla fine obbligare il progetto a revocare l'accesso agli invii alla persona—un atto che non è mai piacevole e che potrebbe a volte dar luogo a polemiche.
Molti progetti insistono sul fatto che la persona che potenzialmente potrebbe fare gli invii dimostri un certo livello di esperienza tecnica e sia tenace, inviando un certo numero di patch non secondarie; cioè, non solo questi progetti vogliono sapere che la persona non procurerà danni, vogliono sapere se possibilmente è brava nel codice base. Ciò è bene, ma siate attenti a che ciò non incominci a cambiare l'appartenenza a quelli che fanno gli invii in appartenenza ad un club esclusivo. La domanda da tenere a mente dovrebbe essere ”Cosa porterà i migliori risultati per il codice?” non “Dobbiamo svalutare lo stato sociale associato alla facoltà di fare gli invii ammettendo questa persona?” Il punto dell'accesso agli invii non è rafforzare l'autostima della gente, è consentire che buoni cambiamenti entrino nel codice senza un minimo di agitazione. Se voi avete 100 persone che fanno gli invii, 10 dei quali fanno cambiamenti su base regolare, e 90 dei quali correggono solo degli errori di stampa o dei piccoli bugs poche volte all'anno, questo è ancora meglio che avere solo i 10.
La prima cosa da dire sulla revoca dell'accesso all'invio è: cercate di non essere in quella situazione in primo luogo. A seconda delle persone il cui accesso all'invio sta venendo revocato, le discussioni su una tale azione possono essere molto divisive. Anche quando non fossero divisive, esse sarebbero causa di perdita di tempo ai danni del lavoro produttivo.
Comunque, se dovete farlo, la discussione dovrebbe tenersi privatamente fra le stesse persone che sarebbero nella posizione di votare per concedere a quella persona qualunque gusto dell'accesso all'invio che correntemente ha. La persona stessa non dovrebbe essere inclusa. Questo contraddice la solita ingiunzione contro la segretezza, ma in questo caso è necessario. Primo, nessuno sarebbe in grado di parlare liberamente altrimenti. Secondo, se la mozione non va a termine, voi non necessariamente volete che la persona sappia che ciò sia stato mai preso in considerazione, perché ciò potrebbe aprire domande (“Chi era dalla mia parte? Chi contro di me?) che portano al peggior tipo di faziosità. In certe rare circostanze, il gruppo può volere che qualcuno sappia che la revoca dell'acceso all'invio è stata o sta venendo considerata, come un avviso, ma questa apertura dovrebbe essere una decisione che prende il gruppo. Nessuno dovrebbe mai, di sua iniziativa, rivelare informazioni su una discussione e su un voto che gli altri presumono che siano segreti.
Once someone's access is revoked, that fact is unavoidably public (see sezione chiamata «Evitare Misteri» later in this chapter), so try to be as tactful as you can in how it is presented to the outside world.
Alcuni progetti presentano gradazioni dell'accesso all'invio. Per esempio, ci possono essere collaboratori il cui accesso all'invio dà loro libere redini nella documentazione, ma essi non possono fare gli invii per quanto riguarda il codice stesso. Aree comuni di invio parziale sono la documentazione, le traduzioni, l'adattare il codice ad altri linguaggi di programmazione, i file di specificazione per i pacchetti (per es. i file di specificazione per RedHat RPM) ed altre aree in cui un errore non dà luogo a un problema per la base del progetto.
Poiché l'accesso all'invio non è solo accesso all'invio ma significa anche far parte di un elettorato (vedere sezione chiamata «Chi Vota?» in Capitolo 4, L'Infrastruttura Sociale e Politica), nasce naturalmente la domanda: su cosa possono votare quelli che hanno l'invio parziale? Qui non c'è una singola risposta giusta; dipende da che tipo di dominio di invio parziale ha il vostro progetto. In Subversion noi abbiamo mantenuto le cose abbastanza semplici: uno che ha l'accesso all'invio parziale, può votare solo su questioni confinate al dominio di colui che fa gli invii, e non su ogni altro dominio. Importante, noi abbiamo meccanismi per dare voto consultivo (essenzialmente colui che fa gli invii scrive "+0" o "+1 (non impegnativo) invece che solo “+1” sulla scheda. Non c'è motivo di silenziare completamente la gente solo perché il loro voto non è formalmente impegnativo.
Coloro che hanno il pieno invio possono votare su ogni cosa, e solo coloro che hanno il pieno invio possono votare sull'ammissione di nuove persone con diritto di voto di ogni specie. Nella pratica, tuttavia, la competenza ad ammettere nuove persone con l'invio parziale è di solito delegata: ogni persona con invio pieno può “sponsorizzare” una nuova persona con invio parziale, e quest'ultimo in un dominio può in affetti scegliere nuove persone con diritto di invio per quello stesso dominio (questo è particolarmente utile nel far si che il lavoro di traduzione funzioni regolarmente).
Il vostro progetto può aver bisogno di piccoli differenti aggiustamenti, a seconda della natura del lavoro, ma a ogni progetto si applicano gli stessi principi generali. Ogni persona che ha l'invio dovrebbe poter votare su questioni che cadono entro la portata del suo accesso all'invio, e non su questioni all'infuori di esso, e i voti su questioni procedurali dovrebbero essere concessi solo a quelli che hanno il pieno invio, a meno che non ci sia qualche ragione (come deciso da coloro che hanno il pieno invio) di allargare l'elettorato.
Riguardo all'applicazione dell'accesso parziale all'invio: è spesso meglio non avere che il sistema di controllo di versione faccia rispettare i domini dell'invio parziale, anche se lo può. Vedere sezione chiamata «Autorizzazione» in Capitolo 3, L'Infrastruttura Tecnica le ragioni del perché.
Alcuni progetti rimuovono automaticamente le persone dall'accesso all'invio se essi per un certo tempo (diciamo, un anno) non fanno invii. Penso che questo non sia di aiuto e anche controproducente, per due ragioni.
Primo, ciò può tentare alcuni ad inviare cambiamenti accettabili ma non necessari, solo per impedire che il loro accesso all'invio si estingua. Secondo, non serve veramente a niente. Se il criterio principale per la concessione dell'accesso all'invio è il buon giudizio, allora perché presumere che il giudizio di qualcuno si deteriorerebbe solo perché egli è via dal progetto per un certo tempo? Anche se egli svanisce completamente per anni, non guardando il codice o non seguendo le discussioni dello sviluppo, quando riappare saprà quanto ha perso il contatto, ed agirà di conseguenza. Avete avuto fiducia nel suo giudizio prima, allora perché non averla sempre? Se i diplomi della scuola superiore non si estinguono, allora l'accesso all'invio certamente non lo dovrebbe.
A volte colui che ha un accesso all'invio può chiedere di essere rimosso, o di essere esplicitamente segnalato come dormiente nella liste di quelli che fanno gli invii (vedere sezione chiamata «Evitare Misteri» sotto per maggiori dettagli su questa lista). In quei casi, il progetto dovrebbe acconsentire ai desideri della persona, certamente.
Anche se la discussioni sull'ammissione di un nuova particolare persona all'invio deve essere confidenziale, i ruoli e le stesse procedure non c'è bisogno che siano segreti. Infatti, è meglio renderli pubblici, così la gente si rende conto che quelli che fanno gli invii non sono delle Camere da Star chiuse ai solo mortali, ma che chiunque può raggiungerli semplicemente postando delle buone patch e conoscendo come comportarsi nella comunità. Nel progetto di Subversion, noi mettiamo questa informazione giusto nel documento delle linee guida, dal momento la gente più adatta ad essere interessata a come l'accesso agli invii viene concesso è quella che pensa di contribuire codice al progetto.
Oltre a pubblicare le procedure, pubblicate la lista attuale di coloro che hanno accesso all'invio . Il posto tradizionale per fare questo è un file chiamato MAINTAINERS
o COMMITTERS in cima all'albero del codice sorgente del progetto. Esso dovrebbe elencare prima tutti coloro che hanno l'invio pieno, seguiti dai vari domini con accesso parziale e dai membri di ciascun dominio. Ogni persona dovrebbe essere elencata col nome e con l'indirizzo email, sebbene l'email potrebbe essere codificata per evitare spam (vedere
sezione chiamata «Nascondere gli indirizzi presenti negli archivi» in
Capitolo 3, L'Infrastruttura Tecnica
) se la persona preferisce così
Poichè la distinzione fra accesso all'invio pieno e all'invio parziale è chiara e ben definita, è proprio dell'elenco fare la distinzione anche. Oltre a ciò l'elenco non dovrebbe cercare di indicare le distinzioni non formali che inevitabilmente si presentano in un progetto, come chi è influente e come. E' una registrazione pubblica, non un file di riconoscimenti. Elencate quelli che hanno accesso all'invio in ordine alfabetico, o nell'ordine in cui sono arrivati.
[25] Notate che l'accesso all'invio significa qualcosa di differente in un sistema di versione decentralizzato, in cui ognuno può allestire un deposito che è collegato nel progetto, e dà a se stesso l'accesso all'invio a quel deposito. Nondimeno ancora si applica il concetto dell'accesso all'invio. L'”accesso all'invio” stenograficamente sta per “il diritto di fare cambiamenti al codice che saranno inoltrati alla prossima release del software del gruppo”. In un sistema di controllo di versione centralizzato, questo significa avere l'accesso diretto all'invio; in un sistema decentralizzato, significa avere che i cambiamenti di uno sono tirati dentro alla distribuzione automaticamente. E' la stessa idea in ogni caso; i meccanismi con cui son realizzati non sono terribilmente importanti.