Stella Ops Governance Model
Decisions are made in the open, using lazy‑consensus and clear escalation rules—no hidden back‑channels, no surprise rewrites.
1 · Lazy‑consensus workflow
- Pull‑request open → default
+1. - Timers:
- Docs / non‑code: 48 h
- Code & tests: 7 × 24 h
- Veto (
-1) must include a concrete concern and a path to resolution. - Silence = approval once the timer elapses.
2 · Maintainer approval thresholds
| Change class | Approvals required | Example |
|---|---|---|
| Trivial | 0 | Typos, comment fixes |
| Non‑trivial code / docs | 2 maintainers | Feature flags, new API endpoints |
| Security / breaking API | Lazy consensus + explicit security‑LGTM | JWT validation logic, cryptography swap‑outs |
3 · How to become a maintainer
- Consistently contribute high‑quality PRs for 3+ months.
- Secure a nomination from an existing maintainer.
- Receive ≥ ⅔ majority
+1in a 7‑day vote. - Sign the
MAINTAINER_AGREEMENT.mdand 2FA‑enable accounts.
4 · Tagged releases & signatures
- At least one security maintainer co‑signs every release tag.
- CI emits a signed SPDX SBOM & Cosign provenance.
- Release candidates follow the announced schedule.
5 · Dispute & security escalation
- Technical deadlocks: escalate to a Maintainer Summit call, minutes posted publicly.
- Security bugs: handled under the responsible‑disclosure policy.
- Code‑of‑Conduct violations: follow
docs/12_CODE_OF_CONDUCT.mdescalation ladder.