Modèle de gouvernance de Stella Ops
Les décisions sont prises au grand jour, en utilisant le consensus paresseux et des règles d'escalade claires — pas de canaux cachés, pas de réécritures surprises.
1 · Flux de travail du consensus paresseux
- Pull‑request ouverte →
+1par défaut. - Délais :
- Documentation / non‑code : 48 h
- Code et tests : 7 × 24 h
- Véto (
-1) doit inclure une préoccupation concrète et une voie vers la résolution. - Silence = approbation une fois le délai écoulé.
2 · Seuils d'approbation des mainteneurs
| Classe de changement | Approbations requises | Exemple |
|---|---|---|
| Trivial | 0 | Fautes de frappe, corrections de commentaires |
| Code / documentation non‑trivial | 2 mainteneurs | Feature flags, nouveaux endpoints API |
| Sécurité / API avec rupture | Consensus paresseux + security‑LGTM explicite | Logique de validation JWT, remplacement de cryptographie |
3 · Comment devenir mainteneur
- Contribuer régulièrement des PR de haute qualité pendant 3+ mois.
- Obtenir une nomination d'un mainteneur existant.
- Recevoir ≥ ⅔ de majorité
+1lors d'un vote de 7 jours. - Signer le
MAINTAINER_AGREEMENT.mdet activer le 2FA sur les comptes.
4 · Versions taguées et signatures
- Au moins un mainteneur sécurité co‑signe chaque tag de version.
- La CI génère un SBOM SPDX signé et une provenance Cosign.
- Candidates aux versions suivez le calendrier annoncé.
5 · Escalade des litiges et de la sécurité
- Impasses techniques : escalader vers un appel Sommet des Mainteneurs, procès‑verbal publié publiquement.
- Bugs de sécurité : traités selon la politique de divulgation responsable.
- Violations du Code de Conduite : suivre l'échelle d'escalade de
docs/12_CODE_OF_CONDUCT.md.