昇腾CANN community 仓：社区治理与贡献指南

摘要： CANN开源社区的community仓是社区治理核心仓库，包含治理文档、流程模板和活动组织三大功能。社区治理分为技术委员会、维护者和贡献者三层结构。贡献流程包括找贡献点、提Issue、开发、提PR、Code Review和合入发布，需严格遵守模板和规范。Code Review标准涵盖代码规范、测试覆盖、性能数据和文档更新。成为维护者需满足贡献记录、社区声誉和技术能力要求。社区定期举办技术分

2502_94507659

11人浏览 · 2026-05-22 19:16:06

2502_94507659 · 2026-05-22 19:16:06 发布

前言

想给 CANN 开源社区做贡献，但不知道从哪入手。提 Issue、提 PR、审稿、发布 Release，这套流程有规矩。community 仓是昇腾CANN 的社区治理仓库，位于第一层——应用与加速库（边缘计算场景）。这个仓里放了所有社区治理的文档和模板。这篇文章拆开看怎么参与社区贡献。

community 仓的定位

community 仓不是代码仓库，它是社区治理仓库。位于 CANN 开源社区的顶层，跟 cann-learning-hub、samples、models 这些仓库平级。

它的核心功能是三块：

治理文档：社区章程、行为准则、决策流程、争议解决机制
流程模板：Issue 模板、PR 模板、Release 模板、Code Review 模板
活动组织：社区活动的组织文档（竞赛、Meetup、开发者大会）

换个角度看：如果你想参与 CANN 开源社区，第一个要读的就是这个仓库里的 GOVERNANCE.md 和 CONTRIBUTING.md。

社区治理结构

CANN 开源社区的治理结构分三层：

第一层是技术委员会（TSC）。由 7 位资深贡献者组成，负责技术方向的决策。比如：要不要引入一个新的算子仓库、CANN 的版本 Roadmap 怎么定、哪些 PR 可以破格合入（绕过正常审稿流程）。TSC 的会议纪要放在 meetings/tsc/ 目录下，对社区公开。

第二层是维护者（Maintainers）。每个仓库有一到多位维护者，负责日常审稿和 PR 合入。维护者有权力 approve PR、关闭 Issue、管理 Release。如果你想成为某个仓库的维护者，需要先在那个仓库里做 5+ 个高质量贡献，然后由 TSC 投票决定。

第三层是贡献者（Contributors）。任何人都可以在仓库里提 Issue 或 PR，成为贡献者。贡献者的 PR 需要维护者 approve 才能合入。

贡献流程

给 CANN 社区做贡献，标准流程是：

第一步：找贡献点。可以去这些地方找：

issues/ 目录里标记为 help wanted 的 Issue
GOVERNANCE.md 里列出的 Good First Issue 清单
自己在使用 CANN 时发现的 bug 或可以改进的地方

第二步：提 Issue。如果是 bug，先提 Issue 描述问题复现步骤。如果是新功能，先提 Issue 描述功能需求和设计思路。Issue 要用仓库提供的模板（ISSUE_TEMPLATE.md），填好所有必填项。

第三步：Fork 仓库并开发。把目标仓库 Fork 到自己的 AtomGit 账号下，然后在本地开发。开发时要遵守代码规范（CODE_STYLE.md），比如：Ascend C 代码的缩进是 2 空格、PyTorch 适配代码的命名用 snake_case。

第四步：提 PR。开发完后提 Pull Request，用 PR 模板（PR_TEMPLATE.md）填好：改了什么、为什么改、怎么测试。PR 要关联之前提的 Issue（在 PR 描述里写 Closes #123）。

第五步：Code Review。维护者会来审稿，提出修改意见。你需要根据意见修改代码，然后重新推送。这个过程可能要来回几轮。

第六步：合入和发布。审稿通过后，维护者会合入你的 PR。如果改动比较大，会等到下一个 Release 才发布。如果改动比较小（比如修了个 bug），可能会尽快发布 patch 版本。

Issue 和 PR 模板

community 仓提供了标准的 Issue 和 PR 模板，确保所有贡献都符合格式要求。

Issue 模板分三类：

Bug Report 模板：

## Bug 描述
（简明描述 bug）

## 复现步骤
1. （步骤1）
2. （步骤2）
3. （步骤3）

## 预期行为
（你期望的正确行为）

## 实际行为
（实际发生的错误行为）

## 环境信息
- CANN 版本：（比如 8.0.RC1）
- NPU 型号：（比如 Ascend 910）
- 操作系统：（比如 Ubuntu 22.04）

## 附加信息
（日志、截图、核心转储等）

Feature Request 模板：

## 功能描述
（简明描述你想要的功能）

## 使用场景
（什么场景下需要这个功能？）

## 设计方案
（如果有初步设计思路，可以在这里描述）

## 替代方案
（有没有其他实现方式？）

Question 模板：

## 问题描述
（简明描述你的问题）

## 我已经尝试过
（描述你已经做过的尝试）

## 补充信息
（补充任何有帮助的信息）

PR 模板：

## 改动描述
（简明描述这次 PR 改了什么）

## 关联 Issue
Closes #（Issue 编号）

## 改动类型
- [ ] Bug 修复
- [ ] 新功能
- [ ] 性能优化
- [ ] 文档更新
- [ ] 重构

## 测试方法
（描述怎么测试这次改动）

## 检查清单
- [ ] 代码符合规范（`CODE_STYLE.md`）
- [ ] 通过了所有单元测试
- [ ] 更新了相关文档
- [ ] 提交了测试用例