This thread is for discussing the creation of a set of guidelines for our community governance.
A comment in preface: Throughout this process, we’ll be setting standards which will be foundational for our community. I therefore encourage everyone in the core team to participate in this thread.
I’m following up on our discussion from our most recent progress call. One of the items on our to-do list is clarifying our community governance. On the call, we agreed to try to learn from Mozilla’s governance guidelines.
Instead of lumping this stuff in with the CoC, I propose that we create a page on freedombox.org at /governance which lists the members of our core team and explains how the community governs itself. Listing the core devs on a web page is fairly standard for most FOSS projects, and I think we especially need to do it now that we are getting more attention from bloggers and journalists. People will be legitimately curious about how our software is produced.
Based on my judgment and the Mozilla checklist, I think our governance page should have three sections: (1) description of our community governance, (2) Team Members (and their roles), and (3) Decision Making (which explains cycles of feedback).
1. Description of our community governance:
At the top of the page, we should write a brief description about how our community creates software. To most of the world, it is an inexplicable miracle that volunteers could create a software system. In my opinion, the description should convey to the world that (1) our team works collaboratively and (2) our production process is reliable (i.e. we’ve built a reliable ecosystem which is more than just a few people with keyboards). My proposal for this description is as follows:
The FreedomBox software project is produced by a team of contributors—some volunteers, some full-time developers—who govern the community together. In governance, we rely on mutually enforced standards, not externally enforced rules. 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.
Feedback on this description is strongly encouraged.
2. Clarifying our leadership and our respective roles:
Problem: For newcomers and existing contributors alike, it isn’t always easy to figure out who does what, and who doesn’t do what in our project. And even our contributors may feel a bit disempowered by the lack of formal recognition for their roles in the project, because it is hard to figure out the boundaries of your own authority when nobody’s role is well understood.
Proposal: We should have a section of our governance page (under the heading “Team”) which lists the names or aliases of each core team member. Here, we should list each person’s respective role. Maybe terms like Developer, Maintainer, and Designer could be used, and I think we should affix some of those titles with words like “Lead” in cases where it is relevant. I think we should also list a brief list of responsibilities beneath each person (2 or 3 bullet points). And people should also feel free to list their preferred gender pronouns if they want.
What do people think of this?
3. Clarifying our decision making and cycles of feedback:
The problem: sometimes, ideas go through endless cycles of feedback, and this results in undue delays. For example, @mray’s proposed relaunch of freedombox.org has been almost ready to publish for months. And it looks great to me. But momentum has been lost. I know we can do better—and I think a feedback cycle is a good place to start. The way we handled feedback for the reachability wizard was efficient, in my opinion. And I think we should hold ourselves to that same standard of efficiency more often.
Proposal: We should set standards for cycles of feedback that look something this:
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 parts of our decision-making process. In such cases, we use Requests for Comments. For tasks that are bigger than average and/or could plausibly be subject to disagreement, the proposer should open a Request for Comments (RFC) on our Gitlab page. The RFC written by a proposer should include (1) a sketch, mock-up, or written description of the task, (2) a brief explanation of the task’s importance, (3) a general list of action items required to execute the task, and (4) estimated timelines for both the RFC discussion period and implementation period. RFC’s should be open for no less than one week and no longer than one month. If, after one month, consensus has not yet emerged, the RFC can be extended for an additional month, but there must be concrete reasons stated for extending the RFC.
In my opinion, our RFC’s sometimes adhere to this description already—the only thing we need to do better is maintaining reasonable timelines.
Those are my three priorities for our governance page.
What do people think of these proposals?
What would you want to see on a governance page?