Development of Public Code needs governance in various ways. As part of our stewardship we help the communities develop the governance models that suit their specific situations as good as possible. We recognize that governance is not a “one size fits all” but rather something that are best adjusted to the culture, maturity, composition and size of a community.
The Foundation for Public Code does not do governance of codebases, instead we support, consult on, and help communities execute governance.
Finding out what needs for governance a community has
Whatever methods are used to figure this out, there are a few basic questions that need to be answered:
- How do you want to make decisions, large and small, around the codebase and the community?
- Can certain issues only be decided by certain community members and can others be distributed and/or delegated to the wider community or specialist parts of the community?
- If so, how is it decided who to gets to take part in the different decision processes
Designing a governance model
After the needs of the community have been established, a suitable governance model can be designed. As a help to get started this template can be used as inspiration.
These are usual sections that could be included when designing the governance model:
- Maintainership (teams, members and meetings)
- Changes in codebase governance
- Decision making process
- Conflict Resolution
- Intellectual property
- Code of Conduct
Whatever model is chosen it is best documented in a
GOVERNANCE file that is placed in the root catalog of the codebase repository and linked to from the
The Standard for Public Code has some criteria related to governance.
This criteria have several requirements that are somehow related to the governance of a codebase. Firstly it makes clear that a lot of things need to be publicly accessible and that things need to be documented in the open way. It then touches upon on how people can interact and what expectations they can have on the codebase. Lastly it states that the governance itself should be documented in a GOVERNANCE file.
Require review of contributions
This is the other criteria that implies governance of a codebase. It does so by mandating that contributions need to be approved by other parties in the community and specifies how this could be done.
Some common anti-patterns that we have noticed are:
- The governance model is setup to require reviewer from another organization.
- If one organization is making 90% of the pull requests, perhaps the other organizations cannot keep up with that pace. If the model is too rigid, merging them timely might become a problem.
- If one organization has the majority, or all of the reviewers, but has not dedicated time for them to review code from contributors from other organizations, the back log of pull request to review will grow. If the model is too rigid, merging them timely might become a problem.
- A model requiring perfect consensus or even unanimous votes might get caught in decision paralysis if the voting members usually have different opinions.
The governance game is useful early in the process to get people to reflect on what governance can mean for a codebase, the complexity around it and some things worth considering when setting it up. It is also useful as a tool for visualizing how a current governance model is setup or could be changed.