一个开源项目能走多远取决于社区怎么组织。CANN 社区的治理模型借鉴了 Linux 和 OpenStack 的成熟实践TSC技术指导委员会 WG工作组 SIG特别兴趣组 PMC项目管理委员会四层结构。每个层级的权责不一样——了解这个结构就知道遇到问题时该找谁该走哪条路。四层治理结构层级职责成员决策方式TSC技术方向、架构演进、重大变更审批华为 外部MaintainerRFC提案 TSC投票WG某个领域的具体工作算子/通信/工具社区贡献者工作组内部共识SIG跨仓库的长期专题性能优化/安全/文档活跃开发者异步讨论 周会PMC发行版、质量、发布计划、安全响应华为核心团队定期会议一个新算子入库的完整流程假设要给 ops-math 贡献一个新的 sincos 算子在信号处理里高频使用。走完整个流程需要经过 SIG 提案 → 代码评审 → CI → PMC 审批第一步SIG 提案# SIG-Math 提案新增 sincos 向量算子 ## 背景 信号处理场景LFM 雷达波形生成、音频合成需要 sincos 同时计算。 当前 ops-math 没有 sincos 融合算子用户只能用两条指令 sincos 融合可以省掉中间结果的 HBM 读写。 ## 设计方案 - 算子名sincos - 输入shape [N] 的 float32/float16 tensor - 输出两个 tensorsin_result, cos_resultshape 同输入 - 实现Vector 单元流水线计算 cos 和 sin 的指邻结果 只读一次输入写两次输出 - 性能目标比两条独立 sin/cos 指令快 40%减少 HBM 读次数 ## 验收标准 - [ ] UT 覆盖率 90% - [ ] 精度相对误差 1e-6float32 - [ ] 性能单次调用延迟 同等条件下的 sincos 两条指令提案发到 SIG-Math 的邮件列表等待 5 个工作日的异步评审。如果没有人反对进入代码实现阶段。第二步代码实现 PRgitclone 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-stylefile 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 sincos * 0.6# 40% 加速四道全部绿了才能合入。任何一道红了Maintainer 不会 review 代码。第四步Maintainer Reviewops-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 的历史提案curlhttps://community.cann.com/sigs/sig-math/proposals?statusrejected|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 是开源协议贡献者需要签 CLAContributor 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 能不能被接受。
