FreedomBox Community Governance
A proposito della nostra comunità
Il progetto FreedomBox è governato da una comunità che include volontari part-time e contributori a tempo pieno. Per la governance ci affidiamo al nostro codice di condotta scritto e agli standard applicati reciprocamente. La comunità mira a prendere decisioni tramite discussione aperta e consenso; in caso di disaccordo, si discute fino a trovare una soluzione o si concorda di rinviare la discussione. Sebbene solo un numero limitato di sviluppatori possano approvare le richieste di merge, tutti sono invitati ad unirsi alla comunità dei contributori e proporre codice o altri tipi di contributi.
Core team
Incontra i membri del nostro core team! Sebbene diversi membri della comunità contribuiscano, il core team è composto da coloro che sono più coinvolti nello sviluppo di FreedomBox.
-
Sunil Mohan AdapaLead Developer & Code ReviewerEmail -
Joseph NuthalapatiDevOps Engineer, Developer, & Code ReviewerEmail | Sociale | Sito Web -
James ValleroyRelease Manager, Developer, & Code ReviewerEmail | Sociale
Collaboratori
Sebbene il core team sia piccolo, centinaia di volontari hanno contribuito a FreedomBox nel corso degli anni. Molti di questi contributori sono elencati qui. Li ringraziamo per il loro impegno!
Come vengono prese le decisioni
In genere, le decisioni su sviluppo e design del software vengono discusse dai membri del core team ed implementate tramite la nostra piattaforma di sviluppo software (GitLab). Molte di queste decisioni non creano controversie e non richiedono dibattiti prolungati.
Ma talvolta sono necessarie discussioni prolungate. Per le proposte che potrebbero plausibilmente generare disaccordi, adottiamo la procedura di “Request for Comments” (richiesta di commenti o RFC). Le RFC devono essere pubblicate su una delle nostre piattaforme di sviluppo (GitLab o il forum) ed includere: (1) un riassunto scritto o uno schizzo della proposta, (2) una breve spiegazione del perché la proposta è necessaria, (3) un elenco degli elementi d’azione richiesti per implementarla. Opzionalmente, si può includere un quarto punto: una tempistica suggerita per il processo di discussione, allo scopo di evitare ritardi inutili. Talvolta, i disaccordi rendono difficile rispettare le scadenze prefissate; in questi casi, i partecipanti devono sforzarsi, in buona fede, per trovare un compromesso e, in mancanza di esso, possono prorogare la discussione.
Miglioramento tramite revisione
In generale, quando le proposte su sviluppo o design del software vengono accettate, sono considerate perfezionabili, non definitive. Questo approccio, permette di approvare proposte generalmente solide senza soffermarsi su dettagli minori. Piccole modifiche alle proposte accettate possono sempre essere fatte successivamente, anziché subito. Come la proposta originale, anche le revisioni sono soggette a discussione e non possono essere fatte unilateralmente. Nello spirito della sperimentazione, accogliamo le revisioni per favorire miglioramenti incrementali al nostro software.