Stella Ops治理模型
決策是公開做出的，使用惰性共識和明確的升級規則——沒有隱藏的反向渠道，沒有意外的重寫。
1 · 惰性共識工作流程
- 拉取請求打開 → 默認
+1。 - 定時器：
- 文檔/非代碼：48 小時
- 代碼和測試：7 × 24 小時
- 否決（
-1）必須包括具體的關注點和實現目標的路徑 - 沉默=計時器到期後批准。
2 · 維護者批准閾值
| 更改類 | 需要批准 | 示例 |
|---|---|---|
| 簡單 | 0 | 拼寫錯誤、註釋修復 |
| 非平凡的代碼/文檔 | 2 維護者 | 功能標誌、新 API 端點 |
| 安全/破壞API | 惰性共識 + 顯式security-LGTM | JWT 驗證邏輯、密碼學交換 |
3 · 如何成為維護者
- 在3個月以上中持續貢獻高質量的 PR。
- 從現有維護者那裡獲得提名。
- 在 7 天投票中獲得 ≥ ⅔ 多數
+1。 - 簽署
MAINTAINER_AGREEMENT.md和啟用 2FA 的帳戶。
4 · 標記版本和簽名
- 至少一個安全維護人員共同簽署每個發布標籤。
- CI 發出簽名的
SPDX軟體套件資料交換 - 另一種廣泛用於開源的SBOM開放標準格式SBOM軟體物料清單 - 軟體中所有套件和相依性的完整列表和CosignSigstore專案的容器簽章工具，用於簽署和驗證容器映像和製品出處。 - 候選版本遵循公佈的時間表。
5 · 爭議和安全升級
- 技術僵局：升級為維護者峰會電話會議，會議記錄已發布公開。
- 安全錯誤：根據負責任的披露策略處理。
- 違反行為準則：遵循
docs/12_CODE_OF_CONDUCT.md升級階梯。