Contribute on GitHub

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:

Principles

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 README file.

Standard compliance

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.

Anti-patterns

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.

Workshop

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.

Further reading

Open Governance - a collection of governance models of open source projects (no public code examples there yet).