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 classApprovals requiredExample
Trivial0Typos, comment fixes
Non‑trivial code / docs2 maintainersFeature flags, new API endpoints
Security / breaking APILazy consensus + explicit security‑LGTMJWT validation logic, cryptography swap‑outs

3 · How to become a maintainer

  1. Consistently contribute high‑quality PRs for 3+ months.
  2. Secure a nomination from an existing maintainer.
  3. Receive ≥ ⅔ majority +1 in a 7‑day vote.
  4. Sign the MAINTAINER_AGREEMENT.md and 2FA‑enable accounts.

4 · Tagged releases & signatures

  • At least one security maintainer co‑signs every release tag.
  • CI emits a signed SPDXSoftware Package Data Exchange - another open standard format for SBOMs, widely used in open source SBOMSoftware Bill of Materials - a complete list of all packages and dependencies in your software & CosignContainer signing tool from Sigstore project for signing and verifying container images and artifacts 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.md escalation ladder.
Read technical docs