Governance: Who Decides, and How to Write It Down

Governance is the answer to “who can merge this?” and “what happens when two of us disagree?”. For a solo project the answer is you, and writing it down still helps. For anything bigger, the projects that last are the ones that answered before the fight.

Every project has a model, written or not#

A project without a governance document still has one: the person with the merge button decides. That works until they’re gone or two people with merge rights disagree. The models that open-source projects use, each with the document that describes it (as of September 2026):

Projects move between models. Python went from one person to a council in 2018. React, run by Meta since it was open-sourced, announced in October 2025 that it would move to a React Foundation with independent technical governance. None of these is the right one. The wrong one is the one nobody wrote down.

A GOVERNANCE.md answers five questions#

Who are the roles, how do you get one, how are decisions made, how do conflicts end, and how do people leave. Node.js’s and Astro’s documents answer all five; they’re worth reading before you write yours. For a small project, a template:

# Governance

## Roles

- **Maintainers**, listed in MAINTAINERS.md, can merge pull requests and publish releases.
- **Contributors** are everyone who opens an issue or a pull request.

## Becoming a maintainer

A maintainer can nominate a contributor who has reviewed or contributed regularly for (three) months. The other maintainers have one week to object.

## Decisions

Most decisions happen in pull requests, by lazy consensus: if no maintainer objects within 72 hours, it goes ahead. Breaking changes need an issue labeled `rfc` and the approval of (a majority of) maintainers.

## Conflicts

When maintainers disagree and can't converge, (the lead maintainer / a majority vote of maintainers) decides.

## Leaving

A maintainer who steps down, or is inactive for (six) months, becomes emeritus: listed and thanked, without merge or publish rights.

For a project you maintain alone, one paragraph is enough, and better than nothing:

This project is maintained by (name), who makes the final decisions. Contributions are welcome: see CONTRIBUTING.md. If (name) stops maintaining it, (the plan: a named successor, an archive, a pointer to a fork).

A contributor ladder turns “how do I become a maintainer?” into a list#

People who contribute often want to know what comes next, and maintainers need a fair way to say yes. A ladder lists the roles, what each one does, and what it takes to get there. Kubernetes’ community membership is the reference:

Each role is defined somewhere a machine can read, like an OWNERS file, so tools know who can approve what. The top of the ladder matters as much: Kubernetes keeps emeritus_approvers in its OWNERS files, Node.js has emeritus collaborators, and Astro has alumni. Stepping back should be a status, not a disappearance. Burnout, Succession and the End of a Project covers why.

Decide big changes in writing#

A pull request is enough for a bug fix. It’s not enough for a new language feature, a breaking change or a new release policy: the discussion needs to happen before the code, where everyone affected can see it. Projects use two kinds of document for that:

• RFCs (requests for comments), for proposals that change the project for everyone: Rust, React and Ember keep them in a repository, one pull request per proposal.
• ADRs (architecture decision records), a page per technical decision, with its context and consequences, so that the next maintainer knows why.

Rust’s process shows the parts that matter. On rust-lang/rfcs#3958, a proposal to support LaTeX math in Rustdoc, a bot tracked each team member’s review, and the concerns they raised until each was resolved (1). A majority of approvals opened a final comment period (2):

The final comment period opened on August 26, 2026, closed ten days later with a decision to merge, and the RFC was merged the next day. A deadline for objections is what turns a discussion into a decision.

Votes, vetoes and lazy consensus#

Most decisions don’t need a vote, and a project that votes on everything stops moving. Apache’s voting rules give the vocabulary most projects borrow:

• Lazy consensus: announce what you’ll do, and do it if nobody objects in time. Silence is consent.
• +1, 0, -1: yes, no opinion, no. A vote on a release needs three binding +1 and runs for at least 72 hours, “regardless of their geographic location”.
• The veto: on code changes, a -1 is a veto that can’t be overridden, and it must come with a technical justification. A veto without one isn’t valid.

Write down which decisions need a vote, and which rely on lazy consensus. Everything else is a pull request.

Join a foundation when others depend on you#

A foundation holds what a project shouldn’t leave with one person or one company: the trademark, the domain, the money, and sometimes the legal risk. In exchange, the project gives up some control, and follows the foundation’s rules.

It’s worth it when several organizations depend on the project and none of them should own it: that’s when neutrality has a value. Before that, it’s paperwork for a project that still needs contributors.

When the founder leaves, governance is the plan#

On July 12, 2018, Guido van Rossum, who had decided everything in Python for nearly three decades, posted “Transfer of power” to the core developers: he was stepping down, and wouldn’t appoint a successor. The core developers wrote proposals, voted in December 2018 for a steering council (PEP 8016), and elected the first one in early 2019. Python didn’t stop, because the people and the process to decide were already there.

Most projects are smaller, and their founder’s exit is quieter. The question is the same: who decides the day you stop? Burnout, Succession and the End of a Project covers the handover itself.

Do this now#

• Write down who decides in your project today, in a GOVERNANCE.md, even one paragraph.
• List the maintainers in the repository, with what each one can do.
• Decide what needs more than a pull request, and write how those decisions are made.
• Add an emeritus section, and thank the people who stepped back.

Go further#

• Node.js’ GOVERNANCE.md: a complete governance document for a large project, readable in fifteen minutes.
• Kubernetes community membership: the contributor ladder most projects copy.
• Apache voting process: lazy consensus, +1s and vetoes, precisely defined.
• PEP 13: how Python decides, since its founder stepped down.