Governance for a small project: decision rights written down before they are needed

What it is

Governance is the set of rules that say who may decide what, and how a decision is recognised as made. Three shapes cover most small projects. A single maintainer decides everything and says so. A small group decides by lazy consensus, which the Apache glossary defines as a policy that assumes general consent if no responses are posted within a defined period, with an explicit vote only for contested questions. A council holds final authority: PEP 13 gives Python a five-person steering council with broad authority that the document says the council seeks to exercise as rarely as possible, preferring consensus and standard processes over rulings, voting by strict majority of non-abstaining members, and deliberating in public whenever possible.

Why it matters

Without written rules, disputes are settled by whoever is loudest or by silence, contributors cannot tell whether a proposal is approved or merely unopposed, and a hand-over has no basis to point to. The rules matter least on ordinary days and most on the day two maintainers disagree about the public API.

How to apply

• Write a GOVERNANCE file of one page: maintainers by name and area; who can merge what; the default decision rule (lazy consensus with a stated period for routine changes, explicit agreement of all maintainers for public API, licence, scope and adding a maintainer).
• Name a tie-break for the case of two maintainers: an area owner per module, or a rotating final say, decided now rather than during a dispute.
• Define how a maintainer is added (proposal, period, agreement) and how one becomes inactive or is removed, including the case of a maintainer who cannot be reached.
• Record decisions where they were made: the issue or pull request thread, and an architecture decision record for anything that shapes the codebase.
• Keep deliberation public, as PEP 13 requires of its council whenever possible; a private decision should be posted afterwards with its reasons.
• Let the file amend itself only by its own rule, and date every change.

Pitfalls

Copying a council structure for two people. Rules that are written and never applied, so the first real use is also the first test. Silence treated as consent without a stated period, which lets a proposal pass because nobody read it. Governance that names people but not areas, so every question goes to the founder.