Guida alle Politiche per le Relazioni tra Sviluppatori

Guida alle Politiche per le Relazioni tra Sviluppatori Relazioni tra Sviluppatori Davide Cendron Guida alle Politiche per le Relazioni tra Sviluppatori 1.1.2 2006-08-27 Politica di risoluzione dei conflitti

Introduzione

Sebbene i conflitti abbastanza seri da richiedere il coinvolgimento dei responsabili delle "Relazioni tra Sviluppatori" (il termine originale inglese è "Developer Relations", d'ora in poi verrà utilizzata la traduzione italiana, ndt) siano rari, è inevitabile che gli sviluppatori abbiano degli scontri di varie entità. È essenziale che il team Relazioni tra Sviluppatori trovi delle risoluzioni eque ed imparziali ai problemi tra sviluppatori. Sebbene tutte le situazioni differiscano e sia necessario esercitare una buona capacità di giudizio, queste linee guida sono pensate per definire una via d'azione il più soddisfacente possibile.

Quando bisognerebbe coinvolgere i membri del gruppo Relazioni tra Sviluppatori?

I membri del gruppo Relazioni tra Sviluppatori dovrebbero essere coinvolti solamente in un conflitto quando sono falliti altri tentativi per risolverlo. Gli sviluppatori dovrebbero cercare di discutere in modo educato relativamente alla controversia per risolvere il conflitto tra loro. Gli sviluppatori all'interno di un singolo progetto di alto livello (Top Level Project - TLP , ndt) coinvolti in un conflitto dovrebbero consultarsi con il responsabile TLP. Sebbene i responsabili TLP non siano necessariamente qualificati per risolvere dispute personali, problemi tecnici che sfociano in conflitto possono essere spesso risolti all'intero del progetto senza il coinvolgimento dei membri di Relazioni tra Sviluppatori. Quest'ultimi dovrebbero essere coinvolti quando i precedenti metodi non hanno avuto successo. Qualsiasi membro del Sottoprogetto Risoluzione Conflitti di Relazioni tra Sviluppatori può lavorare con le parti in causa per risolvere il conflitto; il membro di Relazioni tra Sviluppatori che prende in carico questo ruolo dovrebbe chiarire che sta prendendo il controllo del conflitto per prevenire problemi di comunicazione. Questo non significa che il membro di Relazioni tra Sviluppatori in controllo non possa chiedere assistenza ad altri.

Questioni non necessariamente collegate a conflitti personali, come violazioni intenzionali o ripetute delle regole, comportamente malizioso o caustico nei confronti di sviluppatori o utenti, o simili problemi di comportamento specifici di uno sviluppatore dovrebbero essere inviati direttamente al team Relazioni tra Sviluppatori tramite devrel@gentoo.org. Esse verranno affrontate di volta in volta singolarmente e potrebbero richiedere azioni disciplinari.

Qualsiasi reclamo che le parti non riusciranno a risolvere da sè usando le risorse descritte in precedenza è assegnato al sottoprogetto Risoluzione Conflitti per una sua risoluzione. Questo processo è descritto in "Azione Disciplinaria e Risoluzione"

Azione Disciplinaria e Risoluzione

Introduzione

Un'Azione Disciplinare deve essere decisa in base ad ogni singolo caso dal Responsabile(i) di Relazioni tra Sviluppatori. Per la maggior parte delle situazioni che richiedono un'azione disciplinare, è sufficiente un avviso per correggere la condotta futura. Se la condotta non migliora, è appropriato imporre un periodo probatorio, da due settimane ad un mese, in cui l'accesso alle infrastrutture di Gentoo sarà revocato. Se dopo il ripristino dell'accesso si verifica ancora una condotta negativa, sarà necessario effettuare una rimozione dal progetto. In casi estremi, la sospensione o la rimozione potrebbe essere necessaria a seguito di un singolo reato. Tranne che in situazioni critiche dove l'azione immediata è necessaria, questo tipo di azione disciplinare è determinata dai membri del sottoprogetto Risoluzione Conflitti.

A seguito della rimozione di uno sviluppatore, la mailing list gentoo-core dovrebbe essere avvisata. Inoltre, il team Relazioni tra Sviluppatori dev'essere informato dei fatti che hanno portato alla rimozione o alla sospensione di uno sviluppatore, e questa informazione va archiviata in un bug. Gli sviluppatori rimossi dal progetto non possono tornare ad esserlo senza l'approvazione del (dei) responsabile(i) di Relazioni tra Sviluppatori.

Sottoprogetto Risoluzione Conflitti

Il gruppo Relazioni tra Sviluppatori ha instaurato un sottoprogetto Risoluzione Conflitti per risolvere le dispute coperte da questo regolamento. Questo gruppo è composto da un membro di Relazioni tra Sviluppatori come coordinatore strategico, quattro sviluppatori Gentoo attivi che servono da consiglio di risoluzione conflitti, e da eventuali sostituti stabiliti dal coordinatore. Il coordinatore è scelto dai membri attivi di Relazioni tra Sviluppatori, ed è responsabile della scelta dei membri del consiglio e di qualsiasi eventuale sostituto. I membri di Relazioni tra Sviluppatori approvano o rifiutano le scelte del coordinatore.

Il coordinatore del sottoprogetto Risoluzione Conflitti è innanzitutto un contatto strategico tra il consiglio e il (i) capo(i) di Relazioni tra Sviluppatori, e per tale motivo non ha il diritto di voto nel determinare la risoluzione di qualsiasi conflitto a meno che non sia necessario per effettuare uno spareggio. Tuttavia, il capo dovrebbe essere coinvolto in qualsiasi conflitto indirizzato a questo sottoprogetto, e deve essere disponibile per offrire una guida, consigli, o assistenza in caso di necessità. Il capo ha anche l'incarico di far sì che tutti i membri del sottoprogetto siano di fatto dei partecipanti attivi, che tutti i membri siano idonei al loro compito, che il sottoprogetto lavori per instaurare qualsiasi procedura interna necessaria, e per azioni amministrative simili necessarie per il corretto funzionamento del consiglio.

Regolamento Risoluzione Conflitti

Una volta che un reclamo viene inviato al sottoprogetto Risoluzione Conflitti, il consiglio si assume la responsabilità di coordinare tutti gli aspetti del reclamo. Il consiglio deve agire in accordo con le seguenti linee guida:

Le dispute tra sviluppatori devono prima essere assegnate ad un membro del sottoprogetto Risoluzione Conflitti di Relazioni tra Sviluppatori perchè agisca come mediatore. Questo passaggio potrebbe essere omesso solo in caso di un accordo unanime tra i membri del consiglio, e solo se nessun membro del sottoprogetto ha già provato ad effettuare una mediazione come descritto in precedenza.

Reclami che non richiedono di per sè una mediazione (come ripetuti problemi di QA -- Garanzia di Qualità, ndt) sono trattati esclusivamente dal consiglio. Anche i problemi per i quali la mediazione non ha avuto successo vengono reindirizzati al consiglio per una risoluzione.

In un caso o nell'altro, una volta che il reclamo raggiunge il consiglio per la risoluzione definitiva, il consiglio dovrebbe agire nei confronti di esso in modo tempestivo. Sebbene sia impossibile stabilire in modo assoluto dei limiti temporali, non si accettano ritardi non necessari. È a carico dei membri del consiglio istituire le comunicazioni tra loro stessi. IRC è il mezzo di comunicazione preferito, ma l'e-mail è un'alternativa accettabile nel caso in cui IRC si dimostri impossibile da utilizzare.

Non ha importanza come il consiglio scelga di adempiere ai propri compiti, tutte le procedure pubbliche inclusi gli incontri del consiglio e le sessioni di voto devono essere rese pubbliche. Tuttavia, le discussioni con le parti coinvolte nel reclamo tenute con lo scopo di mediazione dovrebbero essere mantenute private su richiesta o delle parti o dei membri del consiglio in riunione con le parti. Il capo del sottoprogetto è responsabile del rilascio (al pubblico) dei log o delle e-mail all'alias mail devrel e di mantenere un archivio di tutti di documenti pubblici. Nel caso di discussioni private, deve essere fornito un sommario di tutte la parti non sensibili della discussione.

Risoluzione e Appello

Una volta che i membri del consiglio hanno informazioni sufficienti per trarre una conclusione, s'incontreranno per prendere una decisione finale riguardo alla risoluzione appropriata del reclamo. Il capo del sottoprogetto non voterà per determinare questa risoluzione finale a meno che non sia necessario effettuare uno spareggio.

Qualsiasi parte di una disputa risolta da il consiglio può appellarsi alla risoluzione al(i) capo(i) di Relazioni tra Sviluppatori. Nessun'altro sviluppatore può appellarsi.

Nel caso di un appello, il(i) capo(i) di Relazioni tra Sviluppatori deve intraprendere una delle due azione. Possono rifiutare l'appello e riferirlo al Consiglio per una risoluzione finale.

Oppure, possono accettare l'appello. Se lo fanno, il(i) capo(i) devono immediatamente pubblicare l'appello all'alias mail devrel per effettuare una votazione sull'appello da parte di Relazioni tra Sviluppatori. I membri di quest'ultimo gruppo hanno tre giorni per votare l'accettazione o il rifiuto dell'appello.

Se l'appello viene votato dalla maggioranza dei votanti, esso ha avuto successo. In questo caso, la decisione del consiglio viene modificata come richiesto nell'appello.

Se Relazioni tra Sviluppatori vota per rifiutare l'appello, allora la decisione del consiglio viene accettata senza modifiche. L'esito dei voti potrebbe venire impugnato per fare nuovamente appello al Consiglio per una risoluzione, ma, nuovamente, è permesso appellarsi solo alle parti coinvolte dalla risoluzione.

Considerazioni Etiche

Nessun membro di Relazioni tra Sviluppatori può partecipare a più di un tentativo di risoluzione di un conflitto. Più precisamente, chiunque provi a mediare o altrimenti a risolvere un conflitto nella prima parte del processo viene escluso dal prendere parte agli stadi successivi (come il servire qualsiasi consiglio di risoluzione di una disputa).

In particolare, se una parte di una disputa è anche un membro di Relazioni tra Sviluppatori, questa persona non dovrebbe avere nessun ruolo nel processo di risoluzione della disputa se non come parte in causa. Se quel membro di Relazioni tra Sviluppatori ha anche uno specifico ruolo nel processo di risoluzione (come capo Relazioni tra Sviluppatori o vicecapo Risoluzione Conflitti), allora questa persona deve immediatamente informare Relazioni tra Sviluppatori del conflitto e chiedere loro di scegliere un sostituto per farlo agire un sua vece per questa disputa.

Per qualsiasi reclamo inviato al sottoprogetto Risoluzione Conflitti, il(i) capo(i) di Relazioni tra Sviluppatori e il capo del sottoprogetto dovrebbero discutere con ciascun altro membro del consiglio per determinare potenziali conflitti d'interesse. I membri del consiglio aventi un conflitto d'interessi in qualsiasi disputa particolare non dovrebbero partecipare alla risoluzione di essa. Dovrebbero essere rimpiazzati da un sostituto scelto dal capo del sottoprogetto. Sia che il sostituto diventi un membro permanente del consiglio sia che il membro sostituito venga reintegrato alla fine della disputa viene lasciato a discrezione del capo del sottoprogetto.

Reclami sollevati riguardo ad un qualsiasi membro del sottoprogetto Risoluzione Conflitti dovrebbero essere indirizzati in ogni momento al(i) capo(i) di Relazioni tra Sviluppatori o ad un incontro del team Relazioni tra Sviluppatori per essere discussi. In estreme circostanze, l'intero gruppo Relazioni tra Sviluppatori potrebbe votare la rimozione dei membri dal sottoprogetto risoluzione conflitti. Inoltre, i membri del consiglio possono essere sostituiti a discrezione del capo del sottoprogetto con una spiegazione a Relazioni tra Sviluppatori.

Varie

Assenze giustificate

Spesso gli sviluppatori Gentoo vanno in vacanza, devono prendersi un breve periodo di pausa per esami universitari, o vanno perfino in luna di miele. Anche se fa piacere che gli sviluppatori abbiano una vita al di fuori di Gentoo, sarebbe utile far sapere quando si va via e quando si prevede di tornare. Quando si parte, avvisare i gruppi di sviluppo più vicini come anche creare una voce devaway.

Bisogna creare un file chiamato .away nella propria directory /home/proprionomeutente. Questo file conterrà i dettagli della propria assenza e si rifletteranno nel sito devaway . Tale pagine è aggiornata una volta ogni ora. Nel momento in cui si è tornati, basta semplicemente cancellare il file .away dalla propria directory home.

Un'assenza giustificata estesa viene definita come inattività per qualsiasi periodo di tempo maggiore di 60 giorni. L'accesso all'infrastruttura Gentoo probabilmente verrà disabilitata durante questo periodo per ragioni di sicurezza. Ciò significa che l'accesso al CVS e l'accesso alla shell a dev verranno influenzate -- l'email probabilmente no. Se il team Relazioni tra Sviluppatori non viene avvisato in anticipo in previsione di un periodo di inattività esteso, dopo 60 giorni lo sviluppatore verrà considerato ritirato ed ogni rientro sarà a discrezione del(i) responsabile(i) di Relazioni tra Sviluppatori e il rispettivo capo progetto, se applicabile.

Post-ritiro

Le e-mail gentoo.org degli sviluppatori ritirati verranno rimosse dalle mailing list di Gentoo per prevenire l'invio di notifiche di mancato recapito. Gli sviluppatori ritirato hanno la responsabilità di reiscriversi alle liste pubbliche utilizzando un indirizzo email non-Gentoo.

Agli sviluppatori ritirari verrà inoltrata la propria mail @gentoo.org per un numero di mesi uguale al numero di anni approssimato per eccesso nei quali sono stati sviluppatori ufficiali.
Le mail verranno inoltrate per un massimo di 6 mesi.

Questo regolamento assicura che tutti gli sviluppatori abbiano minimo 1 mese di inoltro in base alla politica esistente. E uno sviluppatore che è stato attivo per circa 3 anni avrà 3-4 mesi per poter spostare le proprie mail personali ad un account diverso da gentoo.org.