Amey-Thakur 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
- 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.
- 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.
- 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.
- 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.
- Separate technical from community decisions. Code direction and conduct enforcement need different processes and often different people (see code-of-conduct-enforcement).
- 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.