Stella Ops Project Governance

Lazy Consensus • Maintainer Charter • Transparent Veto

Audience — contributors and maintainers of Stella Ops who need to know how decisions are made, how changes are approved, and how to escalate disputes.

Scope — applies to all repositories under https://git.stella-ops.org/stella-ops/* unless a sub-project overrides it with its own charter approved by the Core Maintainers.

1 · Decision-making workflow

Lazy consensus — silence equals approval once the timer elapses.

• A veto (-1) must include a concrete concern and a path to resolution.
• After 3 unresolved vetoes the PR escalates to a Maintainer Summit call.

2 · Maintainer approval thresholds

Approval is recorded via Git forge review or a signed commit trailer (Signed-off-by: <maintainer>).

3 · Becoming (and staying) a Maintainer

1. 3+ months of consistent, high-quality contributions.
2. Nomination by an existing Maintainer via issue.
3. 7-day vote — needs a ≥ ⅔ majority of +1.
4. Sign the Maintainer Agreement and enable 2FA.
5. Inactivity > 6 months automatically moves a Maintainer to emeritus status (re-activation is allowed).

4 · Release authority & provenance

• Every tag is co-signed by at least one Security Maintainer.
• CI emits a signed SPDX SBOM plus Cosign provenance.
• Release cadence is fixed — see the Release Engineering Playbook.
• Security fixes may create out-of-band x.y.z-hotfix tags.

5 · Escalation lanes

6 · Contribution etiquette

• Draft PRs early — CI linting and tests help you iterate.
• “There are no stupid questions” — ask in Matrix #dev.
• Keep commit messages in the imperative mood (Fix typo, Add SBOM cache).
• Run the pre-commit hook locally before pushing.

7 · Licence reminder

Stella Ops is licensed under BUSL-1.1. By contributing you agree that your patches are released under the same licence.

Appendix A — Maintainer list

The authoritative maintainer roster is generated from the maintainers YAML (scripts/gen-maintainers.sh); edit the YAML, not this section directly.