Gemeinschaftliche Freedombox-Leitung

Über unsere Gemeinschaft

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.


Treffen Sie die Mitglieder unseres Kernteams! Obwohl mehrere Community-Mitglieder Beiträge leisten, besteht das Kernteam aus denjenigen, die am meisten an der Entwicklung von FreedomBox beteiligt sind.


Obwohl unser Kernteam klein ist, haben Hunderte von Freiwilligen im Laufe der Jahre Beiträge zu FreedomBox geleistet. Viele dieser Mitwirkenden sind hier aufgeführt. Wir danken ihnen für ihre Arbeit!

Wie Entscheidungen getroffen werden

Im Allgemeinen werden Entscheidungen über Softwareentwicklung und -design von Mitgliedern des Kernteams mithilfe unserer offenen Softwareentwicklungsplattform (d.h. GitLab) diskutiert und implementiert. Viele der von unserem Team getroffenen Entscheidungen sind unumstritten und erfordern keine längeren Diskussionen.

But sometimes, extended periods of discussion are necessary. For proposals that could plausibly be subject to disagreement, we use a “Request for Comments” (RFC) procedure. RFC’s should be posted to one of our open development platforms (i.e. Gitlab or the forum) and should include (1) a written summary, sketch, or mock-up of the proposal, (2) a brief explanation of why the proposal is needed, and (3) a list of action items required to implement the proposal. Optionally, one may also include in the RFC a fourth item: a suggested timeline for the discussion process in order to prevent unnecessary delays. Sometimes, disagreements make it difficult to follow prescribed timelines; in such cases, participants should make efforts in good faith to compromise and, failing that, can extend the discussion.

Improvement by Revision

In general, when proposals regarding software development or design are accepted, these proposals are treated as revisable, not permanent. This improvement-by-revision approach to proposals enables us to accept generally solid proposals without dwelling on minor details. Minor tweaks to accepted proposals can always be made later instead of upfront. Like the original proposal, revisions are subject to discussion and can’t be made unilaterally. In the spirit of experimentation, we embrace revisability in order to foster incremental improvements to our software.