Project governance¶
This policy explains how maintainers manage the CapOps community proposal. Project governance is separate from the organizational capacity governance described by the framework.
Status and authority¶
The project is independent. No contributor speaks for a provider, the FinOps Foundation, or an industry standards body by contributing here. The repository owner initially maintains the project; additional maintainers can be appointed through a recorded public proposal as participation develops.
Maintainers manage repository access, editorial consistency, releases, and community conduct. Contributors propose changes; reviewers assess evidence and applicability. Participation does not confer certification, accreditation, or a provider commitment.
How decisions are made¶
| Change | Evidence expected | Decision |
|---|---|---|
| Typo or broken link | Reproducible location and correction | Maintainer may merge a focused fix |
| Provider claim | Current authoritative source, supported scope, review date | Maintainer checks the claim and restrictions |
| Capability or scenario | User decision, proposed outcome, practical example, overlap analysis | Maintainer records accept, revise, defer, or decline |
| Canonical definition or structure | Rationale, affected pages, migration of terminology, objections | Public discussion before maintainer decision |
| Sensitive material | Private report and minimum necessary evidence | Contain first; publish only a sanitized outcome |
Ordinary changes go through pull requests with passing documentation checks. An initial publication or urgent correction may be made directly by a maintainer, with its rationale and checks recorded. No vote count overrides factual accuracy or confidentiality requirements.
Resolving disagreement¶
Reviewers should distinguish an incorrect claim from a preference or an organizational variation. Propose alternatives and describe their consequences. If consensus is not reached, the maintainer records the chosen approach and unresolved concerns. New public evidence can reopen a decision; repeated disagreement without new evidence need not block unrelated improvements.
Contributors should disclose relevant commercial interests when recommending product-specific mechanisms. Provider names identify facts, not sponsorship.
Releases and maintenance¶
The roadmap gives review goals, not dates. A release review checks terminology, references, template compatibility, navigation, diagrams, and confidentiality. Record material changes in WHATS_NEW.md and keep the README current.
Provider guidance is time-sensitive. Its review date describes the last source check, not a continuing warranty. Accuracy corrections take priority over expanding the catalog. If a page cannot be maintained, mark its limitation explicitly rather than silently presenting stale mechanisms as current.