Project Governance

---
name: project-governance
description: Define who decides what in a project, how that changes, and how disputes end, before a disagreement forces the question. Use when a project grows past one maintainer or a conflict has no clear resolution path.
---

# Project governance

Governance is the answer to who decides. Every project has it,
explicitly or by accident, and the accidental version fails exactly when
it is needed: during a real disagreement between people who both care.

## Method

1. **Write down the current reality first.** Even benevolent dictator is
   a governance model, and stating it honestly is more useful than
   describing an aspirational committee that does not meet.
2. **Define roles by permission and expectation.** What a contributor,
   reviewer, and maintainer may each do, and what is expected of them.
   Vague roles produce both overstepping and paralysis.
3. **Say how people gain and lose roles.** A path in that is achievable
   and a path out that is not personal, including inactivity, so the
   list of maintainers stays real.
4. **Choose a decision rule and a tiebreak.** Lazy consensus for most
   things, with a named person or vote for deadlock. Most disputes are
   settled by having any rule agreed in advance.
5. **Separate technical from community decisions.** Code direction and
   conduct enforcement need different processes and often different
   people (see code-of-conduct-enforcement).
6. **Keep an amendment process.** Governance that cannot change becomes
   fiction, and the process for changing it should be harder than an
   ordinary decision but not impossible.

## Boundaries

- Governance sets process; it does not supply judgement, and a good
  document cannot rescue a project whose maintainers will not talk.
- Foundation membership brings structure and obligations that may not
  suit a small project.
- Trademark and asset ownership are legal matters separate from
  governance and often overlooked until a fork.