FreedomBox Community Governance

About Our Community

The FreedomBox software project is governed by a community that includes part-time volunteers and full-time contributors. In governance, we rely on our written code of conduct and mutually enforced standards. The community aims to make decisions through open discussion and consensus. In cases of disagreement, the community discusses until a resolution has been found or agrees to postpone the discussion. Though a select number of our developers have the power to accept merge requests, anyone is welcome to join our contributor community and submit code or non-code contributions.

Kerngroep

Maak kennis met de leden van onze kerngroep! Hoewel heel wat gemeenschapsleden bijdragen aan het project, bestaat de kerngroep uit diegenen, die het meest betrokken zijn bij de ontwikkeling van FreedomBox.

Contributors

Though our core team is small, hundreds of volunteers have made contributions to FreedomBox throughout the years. Many of those contributors are listed here. We thank them for their work!

Besluitvorming

Generally, decisions about software development and design are discussed by members of the core team and implemented using our open software development platform (i.e. GitLab). Many of the decisions made by our team are uncontroversial and don’t require extended periods of discussion.

Maar soms is een langere periode van discussie nodig. Voor voorstellen waarbij het aannemelijk is dat er onenigheid over is, gebruiken we een "Verzoek om Commentaar" (RFC) procedure. RFC's moeten worden gepubliceerd op een van onze open ontwikkel platforms (d.w.z. Gitlab of het forum) en bevatten (1) een geschreven samenvatting of ruwe schets van het voorstel, (2) een korte uitleg waarom het voorstel nodig is, en (3) een lijst met acties die nodig zijn om het voorstel te implementeren. Optioneel kan er een vierde punt aan de RFC worden toegevoegd: een suggestie voor een planning van het discussieproces om nodeloos tijdverlies te voorkomen. Soms maken onenigheden het moeilijk om zo voorgeschreven planning te halen; in die gevallen moeten de deelnemers proberen om in goed vertrouwen een compromis te bereiken en als dat niet lukt de discussieperiode te verlengen.

Verbetering door Herziening

In het algemeen wordt een geaccepteerd voorstel met betrekking to de ontwikkeling van de software of het ontwerp gezien als iets dat kan worden teruggedraaid, als niet permanent. Deze verbetering-door-herziening benadering maakt het voor ons mogelijk om voorstellen die in de basis goed zijn te accepteren zonder lang te discussieren over kleine details. Kleine aanpassingen aan geaccepteerde voorstellen kunnen later altijd nog gemaakt worden in plaats van meteen. Net als het oorspronkelijke voorstel zijn herzieningen onderwerp van discussie en kunnen ze niet eenzijdig gemaakt worden. Om in de geest van experimenteren te blijven, moedigen we het kunnen herzien van voorstellen aan om stapsgewijze verbeteringen aan onze software mogelijk te maken.