Wiki: Community page

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.

2 Likes

A few things to note:

Contact info: I thought it’d be good to include contact info beneath each person’s name. If anyone wants to withhold that info for themselves, no problem. Simply remove it from your section in the wiki post.

Photos or avatars? I imagine that we would want to put an avatar beneath/above each person’s name, just to keep the page professional. How would people feel about uppercase initials for each of us, like this:

Bios It would be nice to have a few sentences that describe what each person does. Please feel free to add one for yourself.

Titles I added titles based on the information that people volunteered on the progress call and my own knowledge of the project. Please feel free to revise your title as you please.

tagging @njoseph @sunil @jvalleroy

Update: I read through the comments on RFC: Community Governance Page and wrote a RFC procedure that is based on the comments. Since we agreed to adopt an RFC procedure on a previous progress call, I think it’s important that we put this in our community page.

I tried to make the RFC process incorporate everyone’s feedback and, most of all, fit with our unique community. I look forward to discussing on our upcoming progress call.

Any objections to this proposal?

Looks good to me including the sections on RFC. I have updated the wiki page containing the list of contributors to the project. I will also be providing a photograph for the final page.

1 Like

I just posted a WIP merge request to gitlab for the community page: GitLab merge request here. But before doing so, I made many minor revisions (phrasing, sentence structure, headings). For the sake of transparency, here is the new version of the community page’s text, which can be compared to the previous versions above.


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.

Core Team

Meet the members of our core team! Though several community members make contributions, 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

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!

How Decisions are Made

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.

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.