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 “
+1” in 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 timeline on the public roadmap.
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.