As discussed on the progress call on August 10, I am posting draft material for the community page here as a wiki. Once it has been approved, it can be posted to freedombox.org.
Title: FreedomBox Community
Body:
The FreedomBox software project is produced by a team of contributors—some volunteers, some full-time contributors—who govern the community together. In governance, we rely on mutually enforced standards and our code of conduct. The community aims to make decisions using consensus that emerges from open discussion. 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.
Core Team (listed side-by-side in a horizontal bar):
Meet the members of our core team! Though several community members make contributions to the FreedomBox project, the core team consists of those who are most involved in the development of FreedomBox.
Sunil Mohan Adapa
Lead Developer & Code Reviewer
Connect: Email
Joseph Nuthalapati
DevOps Engineer, Developer, & Code Reviewer
Connect: Email | Social | Website
James Valleroy
Release Manager, Developer, & Code Reviewer
Connect: Email | Social
Danny Haidar
Vice President of FreedomBox Foundation
Connect: Email | Website
Contributors
Hundreds of volunteers have made contributions to FreedomBox throughout the years. Many of those contributors are listed here. We thank them for their work!
==How Decisions are Made==
Generally, decisions about software development and design are discussed by members of the core team and implemented using our open development platform. Many of the decisions made by our team are uncontroversial and don’t require extended periods of discussion and feedback.
But sometimes, extended periods of discussion and feedback 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. If desired, one may also include in the RFC a timeline on the discussion process in order to prevent unnecessary delays. But 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.
==Accepted Proposals are Revisable==
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.