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升級階梯。