一个开源项目能走多远，取决于社区怎么组织。CANN 社区的治理模型借鉴了 Linux 和 OpenStack 的成熟实践：TSC（技术指导委员会）+ WG（工作组）+ SIG（特别兴趣组）+ PMC（项目管理委员会）四层结构。每个层级的权责不一样——了解这个结构，就知道遇到问题时该找谁，该走哪条路。
四层治理结构
| 层级 | 职责 | 成员 | 决策方式 |
|---|---|---|---|
| TSC | 技术方向、架构演进、重大变更审批 | 华为 + 外部Maintainer | RFC提案 + TSC投票 |
| WG | 某个领域的具体工作（算子/通信/工具） | 社区贡献者 | 工作组内部共识 |
| SIG | 跨仓库的长期专题（性能优化/安全/文档） | 活跃开发者 | 异步讨论 + 周会 |
| PMC | 发行版、质量、发布计划、安全响应 | 华为核心团队 | 定期会议 |
一个新算子入库的完整流程
假设要给 ops-math 贡献一个新的 sincos 算子（在信号处理里高频使用）。走完整个流程需要经过 SIG 提案 → 代码评审 → CI → PMC 审批：
第一步：SIG 提案
# SIG-Math 提案：新增 sincos 向量算子 ## 背景 信号处理场景（LFM 雷达波形生成、音频合成）需要 sin+cos 同时计算。 当前 ops-math 没有 sincos 融合算子，用户只能用两条指令， sincos 融合可以省掉中间结果的 HBM 读写。 ## 设计方案 - 算子名：sincos - 输入：shape [N] 的 float32/float16 tensor - 输出：两个 tensor（sin_result, cos_result），shape 同输入 - 实现：Vector 单元流水线，计算 cos 和 sin 的指邻结果， 只读一次输入，写两次输出 - 性能目标：比两条独立 sin/cos 指令快 40%（减少 HBM 读次数） ## 验收标准 - [ ] UT 覆盖率 > 90% - [ ] 精度：相对误差 < 1e-6（float32） - [ ] 性能：单次调用延迟 < 同等条件下的 sin+cos 两条指令提案发到 SIG-Math 的邮件列表，等待 5 个工作日的异步评审。如果没有人反对，进入代码实现阶段。
第二步：代码实现 + PR
gitclone https://atomgit.com/cann/ops-mathcdops-math# 创建分支gitcheckout-bfeature/sincos-vector# 实现文件结构ops-math/ ops/ math/ sincos/ sincos.cpp# Ascend C kernelsincos_tiling.cpp# Tiling 策略sincos_test.cpp# 单元测试BUILD# bazel 构建文件PR 需要包含：
- 完整的代码实现和注释
- 单元测试（覆盖率 > 90%）
- 性能基准测试（对比两条独立指令）
- 更新
METADATA.json（算子元数据注册） - 更新 README（新增算子说明）
第三步：CI 流水线
每个 PR 触发自动 CI，包含四道检查：
# .github/workflows/ci.yml 简化版stages:-lint:script:-clang-format-style=file src/*.cpp-cpplint--filter=-legal/copyright .-build:script:-bazel build //ops/math/sincos:sincos_test-matrix:[ascend-910,ascend-950pr]-unit_test:script:-bazel test //ops/math/sincos:sincos_test-coverage:90%-performance:script:-python benchmark_sincos.py-threshold:latency < sin+cos * 0.6# 40% 加速四道全部绿了才能合入。任何一道红了，Maintainer 不会 review 代码。
第四步：Maintainer Review
ops-math 的 Maintainer 至少需要两人 approve：
## Maintainer Review Checklist 功能正确性： [✓] 边界条件处理（NaN/Inf/0 输入） [✓] dtype 支持（float16/float32） [✓] tiling 策略在不同 N 下的正确性 性能： [✓] sincos 融合确实只读一次输入 [✓] Vector pipeline 没有 stall [✓] benchmark 证明 40% 加速达标 代码质量： [✓] 注释完整，解释关键设计决策 [ ] 版权头缺失（需要补）第五步：PMC 合入审批
Maintainer approve 后，PR 自动转到 PMC 审批。PMC 审批主要关注：
- 算子是否属于 ops-math 的合理范围（不是领域越界）
- 性能和精度是否满足社区标准（不是贡献一个慢的替代方案）
- 是否有潜在的 License 或专利问题
踩坑一：SIG 提案的先例问题
如果提案的功能在 SIG 历史讨论里被否决过（比如之前有人提过 sigmoid fusion 被拒绝），新的 sincos fusion 提案需要额外说明和之前否决的差异。
错误做法：不看历史讨论，直接开 PR。被 Maintainer 打回说「之前有类似提案被 TSC 否了」。
正确做法：先在 SIG 邮件列表搜历史记录。
# 搜索 SIG-Math 的历史提案curl"https://community.cann.com/sigs/sig-math/proposals?status=rejected"|grepsincos# 如果有相关提案，看否决理由再决定是否继续提# 如果没有，再发新提案，说明：# - sincos 和之前否决的 sigmoid fusion 的区别（输入独立 vs 强依赖）# - 性能数据（sigmoid fusion 收益不高，sincos 收益明确）踩坑二：CI 的测试矩阵覆盖不全
CI 配置里只测了 Ascend 910，但 sincos 在 Ascend 950PR 上的行为可能不一样（比如 Vector 单元的流水线深度不同）。上线后 950PR 用户报 bug。
错误配置：
# .github/workflows/ci.ymlmatrix:platform:[ascend-910]# 只测 910正确配置：
# .github/workflows/ci.ymlmatrix:platform:[ascend-910,ascend-950pr]dtype:[float16,float32]# 穷举所有组合：# ascend-910 × float16# ascend-910 × float32# ascend-950pr × float16# ascend-950pr × float32踩坑三：Contributor License Agreement 签名
CANN 是开源协议，贡献者需要签 CLA（Contributor License Agreement）。不签 CLA 的 PR 会被 PMC 直接关闭——不管代码多好。
# 首次贡献前必须在 CANN 社区系统完成 CLA 签名# 地址：https://community.cann.com/cla# 签名后，你的 GitHub 账号和 CLA 绑定# 之后的每个 PR 系统自动识别，无需再签# 注意：CLA 对每个账号只签一次签名流程：个人账号登录 → 填写个人信息 → 电子签名 → 等待 1-2 个工作日审核 → 审核通过后账号标记为 CLA-signed → PR 自动通过 CLA 检查。
community 仓库里的文档质量差异大——有些仓库的 CONTRIBUTING.md 写得很详细，有些几乎是空的。参与社区的第一步不是写代码，是把一个仓库的 CONTRIBUTING.md、CODEOWNERS、METADATA.json 完整读一遍——这三个文件决定了你的 PR 能不能被接受。
