Stella Ops 治理模型
所有决策均在公开环境中进行，采用惰性共识和明确的升级规则——没有隐藏的后台渠道，没有意外的改写。
1 · 惰性共识工作流
- 拉取请求已打开 → 默认「
+1」。 - 计时器：
- 文档 / 非代码：48 小时
- 代码与测试：7 × 24 小时
- 否决（
-1）必须包含具体的关切和解决路径。 - 计时器到期后，沉默 = 批准。
2 · 维护者批准阈值
| 变更类别 | 所需批准数 | 示例 |
|---|---|---|
| 琐碎更改 | 0 | 错别字、注释修复 |
| 非琐碎代码 / 文档 | 2 名维护者 | 功能标志、新 API 端点 |
| 安全 / 破坏性 API 更改 | 惰性共识 + 明确的 security-LGTM | JWT 验证逻辑、加密组件替换 |
3 · 如何成为维护者
- 持续贡献高质量 PR 达 3 个月以上。
- 获得现有维护者的提名。
- 在 7 天投票中获得 ≥ ⅔ 多数「
+1」票。 - 签署
MAINTAINER_AGREEMENT.md并启用账户 2FA。
4 · 标签发布与签名
- 每个发布标签至少需要一名安全维护者联合签名。
- CI 输出签名的 SPDX SBOM 和 Cosign 来源证明。
- 候选版本遵循公布的时间表。
5 · 争议与安全升级
- 技术僵局：升级至维护者峰会电话会议，会议记录公开发布。
- 安全漏洞：按照负责任披露政策处理。
- 行为准则违规：遵循
docs/12_CODE_OF_CONDUCT.md升级阶梯。