Gouvernance du projet FreedomBox par la communauté

À propos de notre communauté

Le projet logiciel FreedomBox est régi par une communauté comprenant à la fois des volontaires contribuant sur leur temps libre et des contributeurs à plein temps. En termes de gouvernance nous nous fions à notre code de conduite écrit et à des standards appliqués par souci mutuel des contributeurs de les faire respecter. La communauté se donne pour but de prendre des décisions basées sur des discussions ouvertes et la recherche du consensus. En cas de désaccord, la communauté poursuit la discussion jusqu’à ce qu’une résolution soit trouvée, ou accepte de reporter la discussion. Même si un nombre défini de développeurs a le pouvoir d’accepter les demandes de fusion de code, chacun est bienvenu pour rejoindre notre communauté de contributeurs et proposer des contributions de code ou autre que du code.

Équipe principale

Voici les membres de notre équipe principale ! Il y a certes plusieurs membres de la communauté qui contribuent régulièrement, mais l’équipe principale est constituée de ceux qui sont les plus investis dans le développement de FreedomBox.

Contributeurs·ices

Bien que notre équipe principale soit restreinte, des centaines de volontaires ont proposé leurs contributions au fil des années. Un grand nombre de ces contributeurs sont listés ici. Nous les remercions pour leur travail !

Comment les décisions sont prises

D’une manière générale, les décisions de conception et de développement logiciels sont discutées entre les membres de l’équipe principale et réalisées en utilisant notre plateforme de développement ouverte (i.e. GitLab). Beaucoup des décisions prises par notre équipe principale ne prêtent pas à controverse et ne nécessitent pas de périodes de discussion étendues.

Mais parfois des périodes de discussions étendues sont nécessaires. Pour les propositions vraisemblablement sujettes à différends, nous utilisons la procédure de demande de commentaires, « Request For Comments » (RFC) en anglais. Les RFC doivent être publiée sur une plateforme de développement ouverte (i.e. GitLab ou le forum) et doivent inclure (1) un résumé écrit, un schéma, ou une maquette de la proposition, (2) une explication succincte de pourquoi la proposition est nécessaire, et (3) une liste des éléments actionnables à mettre en œuvre pour réaliser la proposition. De manière facultative, il est possible d’inclure un quatrième élément à la RFC : un planning suggéré pour le processus de discussion, afin d’éviter les délais inutiles. Parfois les désaccords rendent difficiles le suivi du planning proposé ; dans ce cas les participant doivent de bonne foi faire les efforts nécessaires pour aboutir un compromis, ou à défaut étendre la période de discussion.

Amélioration par révision

En général, lorsque des propositions concernant la conception ou le développement logiciels sont acceptées, ces propositions sont considérées comme révisables et non permanentes. L’approche d’amélioration des propositions par révision nous permet d’accepter les propositions globalement solides sans avoir à se perdre dans des détails. Des ajustements mineurs à des propositions déjà acceptées peuvent toujours être fait par la suite plutôt qu’au préalable. De même que la proposition initiale, les révisions sont sujettes à discussion et ne peuvent être mises en œuvre de manière unilatérale. Dans l’idée de favoriser l’expérimentation, nous acceptons et accueillons le principe des révisions afin d’encourager les améliorations incrémentales de nos logiciels.