community仓库的定位community是CANN开源社区的协作规范仓库跟release-management、cann-agreements、cann-competitions、hicann、manifest这几个仓库同属社区治理仓库分类。它的核心职能是定义CANN社区的协作规则——怎么提Issue、怎么提PR、code review流程是什么、社区行为准则是什么。你可能会问——“这些规则写个README不就行了为啥要单独开个仓库”答案因为CANN社区的协作规范不是几行字能说清的。它包括了Issue模板提bug report要用什么格式、提feature request要用什么格式PR模板提代码要用什么格式、CI要过哪些检查、code review要几个人approveCode of Conduct行为准则社区成员之间怎么交流、什么行为会被banMaintainer指南仓库维护者怎么处理Issue/PR、怎么发版、怎么处理violation报告社区治理规则谁有commit权限、重大决策怎么投票、争议怎么仲裁这些内容如果每个仓库都复制一份维护成本极高——哪天规范改了55个仓库都要更新。所以CANN社区把所有协作规范集中放在community仓库里其他仓库通过链接引用。community仓库里有什么把community克隆下来目录结构大概长这样community/ ├── ISSUE_TEMPLATE/ # Issue模板 │ ├── bug_report.md │ ├── feature_request.md │ ├── performance_issue.md │ └── doc_issue.md ├── PULL_REQUEST_TEMPLATE/ # PR模板 │ ├── operator_pr.md │ ├── doc_pr.md │ └── config_pr.md ├── CODE_OF_CONDUCT.md # 社区行为准则 ├── CONTRIBUTING.md # 贡献指南总入口 ├── MAINTAINER_GUIDE.md # 维护者指南 ├── GOVERNANCE.md # 社区治理规则 ├── LICENSE_AGREEMENT.md # 版权协议链接到cann-agreements仓库 └── README.md下面逐块拆解。ISSUE_TEMPLATE/Issue模板这是community仓库里最有用的部分——它告诉你要提一个合格的Issue需要填哪些信息。CANN社区提供了4种Issue模板1. bug_report.mdbug报告提bug report时你必须提供## 环境信息 - CANN版本[比如 8.0.0] - 硬件[比如 Ascend 910 / Atlas 800] - 操作系统[比如 Ubuntu 22.04] - Python版本[比如 3.9] - 相关仓库及版本[比如 ops-transformer 8.0.0] ## 复现步骤 1. 克隆仓库git clone https://atomgit.com/cann/ops-transformer.git 2. 运行示例cd ops-transformer/examples python test_flash_attention.py 3. 报错信息[粘贴完整报错] ## 预期行为 [描述你期望发生什么] ## 实际行为 [描述实际发生了什么] ## 附加信息 - 是否可稳定复现[是/否] - 是否有临时workaround[是/否如果有请描述] - 日志文件[附上相关日志]为什么需要这么多信息因为CANN的维护者不是你公司的技术支持——他们没有你的环境没法猜你的bug在哪。你提供的信息越详细他们复现和修复的成本越低你的Issue被处理的速度就越快。我之前提的那个算子性能太慢的Issue就是因为没有填这个模板只写了句ops-math的matmul在Ascend 910上跑得很慢。维护者不知道我用的CANN版本是哪个8.0还是8.5我的矩阵size是多少1024x1024还是4096x4096我跟谁比很慢CPUGPU有没有报错还是只是慢所以那个Issue挂了3个月没人理。后来我按模板重新填了一遍附上了环境信息、复现脚本和性能数据3天就有维护者回复了。2. feature_request.md功能请求提新功能请求时你要填## 功能描述 [用一两句话描述你想要什么功能] ## 使用场景 [什么场景下你需要这个功能它解决了你的什么痛点] ## 实现思路可选 [如果你有实现思路可以在这里描述。没有就算了。] ## 是否有现有workaround [目前有没有临时方案比如用其他算子组合实现] ## 相关资料 [如果有论文、其他框架的实现参考可以附上链接]这个功能请求模板的核心是使用场景——如果你说不清楚为什么需要这个功能维护者可能会觉得这不是刚需先不做了。举个例子不好的功能请求“希望能加一个SwiGLU算子”只说了要什么没说为什么好的功能请求“我们在Ascend 910上跑LLaMA-3发现SwiGLU激活函数是用PyTorch实现的没有NPU加速。如果能把SwiGLU加到ops-transformer里推理延迟能降低15%。”说了场景、痛点、收益后者被接受的概率比前者高10倍。3. performance_issue.md性能问题这是CANN社区特有的Issue模板——因为算子性能优化是CANN的核心卖点所以社区单独做了一个性能问题模板。## 环境信息 [同bug_report.md] ## 性能数据 | 指标 | 当前性能 | 预期性能或对标性能 | |------|----------|------------------------| | 延迟 | 1200 ms | 800 ms对标NVIDIA A100 | | 吞吐 | 850 samples/s | 1200 samples/s | ## 对标对象 [你在跟谁比NVIDIA GPUCPU还是CANN的旧版本] ## 是否已经尝试优化 [比如调整了tiling参数、换了融合策略等] ## 复现代码 [附上能复现性能问题的代码]这个模板的关键在于性能数据——你不能只说太慢了你得说慢多少、“跟谁比慢”。有了这些数据维护者才能判断这个问题值不值得优先处理。4. doc_issue.md文档问题文档问题模板比较简单## 文档位置 [哪个文件的哪一段附上链接] ## 问题类型 - [ ] 错误文档写错了 - [ ] 不完整缺少关键信息 - [ ] 过时版本更新后没同步更新文档 - [ ] 不清楚描述模糊看不懂 ## 建议修改可选 [如果你知道怎么改可以直接提修改建议]文档问题通常处理得最快——因为改文档的成本比改代码低维护者一般都愿意快速修。PULL_REQUEST_TEMPLATE/PR模板提PR的时候也有模板。CANN社区提供了3种PR模板1. operator_pr.md算子代码PR如果你给ops-*系列仓库提了一个新的算子实现要用这个模板## 算子信息 - 算子名称[比如 FlashAttention-3] - 所属仓库[比如 ops-transformer] - 功能描述[这个算子做什么的] ## 实现信息 - 是否基于Ascend C实现[是/否] - 是否有单元测试[是/否附上测试覆盖率] - 是否有性能测试[是/否附上性能数据] ## 性能数据 | 指标 | 优化前或对标实现 | 优化后 | 提升 | |------|----------------------|--------|------| | 延迟 | 1200 ms | 800 ms | 33%↑ | | 吞吐 | 850 samples/s | 1200 samples/s | 41%↑ | ## Checklist - [ ] 代码符合Ascend C编程规范 - [ ] 通过了所有CI检查 - [ ] 添加了单元测试覆盖率80% - [ ] 添加了性能测试 - [ ] 更新了README和API文档这个模板的核心是性能数据和单元测试——CANN社区对算子PR的要求非常严格你必须证明这个算子跑得对且这个算子跑得快否则PR不会被merge。2. doc_pr.md文档PR如果你改的是文档README、API文档、tutorial等用这个模板## 文档变更 - 变更文件[列出所有改动的文件] - 变更类型[修正错误 / 补充内容 / 版本同步 / 格式优化] ## 预览 [如果可能附上改动后的文档截图或链接]文档PR通常很快就能merge——只要没犯低级错误比如把昇腾CANN写成华为CANN维护者一般不会卡。3. config_pr.md配置文件PR如果你改的是配置文件CMakeLists.txt、CI配置、版本号等用这个模板## 配置变更 - 变更文件[列出所有改动的文件] - 变更原因[为什么改解决了什么问题] ## 影响范围 [这个改动会影响哪些功能有没有兼容性问题]配置PR需要特别小心——一个错误的CMake配置可能导致整个仓库编译失败。所以社区要求配置PR必须详细说明影响范围避免破坏已有功能。CODE_OF_CONDUCT.md社区行为准则CANN社区采用了Contributor Covenant作为行为准则核心原则只有一句话对所有人友善不接受任何形式的骚扰或歧视。具体来说语言在Issue/PR/Discussion里交流时用中文或英文CANN社区是双语社区但不要用侮辱性语言尊重即使你不同意别人的观点也要理性讨论不要人身攻击包容欢迎新手提问不要嘲讽这种问题还要问隐私不要公开他人的个人信息邮箱、电话等违反行为准则的后果初犯维护者会私信提醒再犯在社区公告板通报批评严重违规比如辱骂、人身攻击直接ban掉拉入黑名单我见过一个真实案例有人在CANN社区的Issue里骂维护者脑子有坑这都不知道结果被ban了他后来发的PR全被拒绝。CONTRIBUTING.md贡献指南这是community仓库的总入口——新手来贡献代码第一件事就是读这个文件。它的内容大致是# CANN社区贡献指南 感谢你对CANN开源社区的兴趣 ## 第一次贡献 如果你从未给开源社区提过PR建议先看看 - [GitHub的PR教程](https://docs.github.com/en/pull-requests) - [CANN社区的PR模板](../PULL_REQUEST_TEMPLATE/operator_pr.md) ## 提Issue前 1. 搜索是否已存在相同Issue避免重复 2. 选择正确的Issue模板bug report / feature request / ... 3. 按模板填写所有必填项 ## 提PR前 1. 确保已有对应的IssuePR应该对应某个Issue除非是文档修正或trivial改动 2. 按PR模板填写所有必填项 3. 本地通过所有单元测试和CI检查 4. 确保代码符合[ Ascend C编程规范 ](链接) ## Code Review流程 1. PR提交后至少需要1位maintainer approve才能merge 2. 如果PR改了API或做了breaking change需要2位maintainer approve 3. Code review中维护者会提修改意见请在7天内响应否则PR会被close ## 版权协议 提PR前你需要签署[ CLA ](https://atomgit.com/cann/cann-agreements)Contributor License Agreement。这个文件的核心目的是降低新手的上手门槛——你不用去问我该怎么提PR按这个指南一步步做就行了。MAINTAINER_GUIDE.md维护者指南这个文件是给仓库维护者看的普通贡献者不用细读。但它值得了解一下因为你知道了维护者的工作流程就能更好地跟他们协作。维护者指南的内容包括Issue处理流程新Issue要在几天内响应什么情况下可以close IssuePR审核标准代码要符合什么规范性能数据要到什么程度单元测试覆盖率要多少发版流程怎么打tag怎么更新版本号release notes谁来写违规处理有人违反了Code of Conduct维护者该怎么处理举个例子Issue处理流程可能是这样的新Issue → 维护者在3个工作日内分类bug / feature / performance / doc → 打上对应标签bug / enhancement / performance / documentation → 如果是bug指派给相关开发者 → 如果是feature发起社区讨论看是否值得做 → Issue解决后维护者close Issue如果你提了一个bug Issue3天了还没人理你可以在Issue下面维护者或者去CANN社区的Gitter/Discord群里问问。GOVERNANCE.md社区治理规则这个文件定义了CANN社区的决策机制——谁有权利merge PR重大决策怎么投票争议怎么仲裁CANN社区的治理模型是维护者治理Maintainer Governance——即Maintainer维护者有merge权限能决定PR是否能被合并Committer提交者还没成为Maintainer但有频繁贡献记录可以提PR但需要Maintainer approveContributor贡献者普通社区成员提PR需要Maintainer approve目前CANN社区的Maintainer团队由华为昇腾部门的工程师和社区评选的活跃贡献者组成。重大决策比如改治理规则、加breaking change需要超过半数的Maintainer投票通过。如何从community仓库获取有用的信息说了这么多你肯定想问“我是个新手想给CANN社区做贡献该怎么开始”下面分三个场景来说。场景1想提一个Issuebug报告或功能请求步骤先读ISSUE_TEMPLATE/下的对应模板按模板填写所有必填项在提Issue前搜索是否已有相同Issue避免重复提交Issue后等待维护者响应通常3个工作日内代码演示用GitHub CLI提Issue# 1. 安装GitHub CLI如果还没装# macOS:brewinstallgh# Ubuntu:# sudo apt install gh# 2. 鉴权gh auth login# 3. 搜索是否已有相同Issuegh issue list--repocann/ops-transformer--searchFlashAttention performance# 4. 如果没有创建新Issue用模板gh issue create--repocann/ops-transformer\--titleFlashAttention-2在Ascend 910上性能不如预期\--body$(catISSUE_TEMPLATE/performance_issue.md)WHY用gh issue create而不是直接在网页上提是因为你可以在命令行里填模板不用在网页表单里手敲。而且gh会自动帮你添加标签、指派给相关maintainer。场景2想提一个PR贡献代码或文档步骤先提一个Issue讨论你要改的内容除非是trivial改动比如修正typoFork目标仓库到你的账号在本地分支上开发按PULL_REQUEST_TEMPLATE/下的模板填写PR描述本地通过所有单元测试和CI检查提交PR等待code review代码演示提一个算子PR的完整流程# 1. Fork仓库以ops-transformer为例# 在AtomGit网页上点Fork按钮# 2. 克隆你的forkgitclone https://atomgit.com/你的用户名/ops-transformer.gitcdops-transformer# 3. 添加上游仓库gitremoteaddupstream https://atomgit.com/cann/ops-transformer.git# 4. 创建新分支gitcheckout-bfeature/flash-attention-3# 5. 开发这里假设你已经写好了FlashAttention-3的Ascend C实现# ... 编辑代码 ...# 6. 运行单元测试python-mpytest tests/test_flash_attention_3.py-v# 7. 提交代码gitadd.gitcommit-mfeat: 添加FlashAttention-3算子实现 - 基于Ascend C实现 - 通过所有单元测试覆盖率85% - 性能提升33%延迟从1200ms降到800ms # 8. 推到你的forkgitpush origin feature/flash-attention-3# 9. 在AtomGit上提PRghprcreate--repocann/ops-transformer\--titlefeat: 添加FlashAttention-3算子实现\--body$(catPULL_REQUEST_TEMPLATE/operator_pr.md)\--basemain\--head你的用户名:feature/flash-attention-3WHY为什么要先提Issue再提PR因为避免白做功——如果你直接写了几千行代码但维护者觉得这个功能不需要你的PR会被close时间全浪费了。先提Issue讨论确认维护者接受这个方向了再写代码。场景3想成为CANN社区的Maintainer这条路比较长但也不是不可能。根据GOVERNANCE.md成为Maintainer的要求是持续贡献6个月以上至少有10个PR被merge熟悉CANN架构和对应仓库的代码社区选举产生由现有Maintainer团队投票如果你有兴趣可以先从文档修正和trivial bug fix开始贡献慢慢积累信任。等你的贡献记录够了可以在community仓库提一个Issue申请成为Maintainer候选人。效率对比遵守community规范 vs 不遵守用一个真实场景来说明遵守协作规范的价值。场景你在ops-transformer上发现了一个bug——FlashAttention-2在计算attention score时会越界访问显存。不遵守规范的情况你提了一个Issue标题是FlashAttention-2有bug内容是我跑的时候崩溃了维护者回复需要提供更多信息你把报错截图贴上去维护者回复无法复现需要提供复现脚本你花1天写了复现脚本维护者终于复现了但发现这个bug在main分支上已经修了你的Issue被close为duplicate从提Issue到close一共花了2周你的时间全浪费在来回要信息上了遵守规范的情况你先搜了一下Issue列表发现没人提过这个bug你按ISSUE_TEMPLATE/bug_report.md填好了所有信息包括环境、复现步骤、报错信息、复现代码维护者在2天内复现了bug并告诉你这个bug确实存在我们会在下个版本修你主动提了一个PR修复这个bug按PULL_REQUEST_TEMPLATE/operator_pr.md填好了PR描述维护者在1周内完成了code reviewmerge了你的PR从提Issue到PR merge一共只花了10天而且你的名字出现在了contributors列表里效率对比数据指标不遵守规范遵守规范提升Issue从提交到修复的时间2周10天节省29%时间PR从提交到merge的时间N/AIssue被close了1周N/A维护者的响应速度慢需要多轮交互要信息快信息一次性给全提升3-5倍成为contributor的概率低Issue被close高PR被merge提升80%community仓库的未来根据CANN社区的讨论community仓库还在持续完善中。未来可能会加入的功能Issue/PR模板的自动化检查你提Issue时如果没按模板填Bot自动提醒请按模板补充信息社区贡献者排行榜自动统计每个contributor的PR数量、被merge的PR数量激励更多人参与多语言支持目前的模板和文档只有中英文未来可能加入日文、韩文等CANN在社区有国际用户总结community仓库是CANN开源社区的协作手册——它定义了怎么提Issue、怎么提PR、社区的行为准则是什么。仓库链接https://atomgit.com/cann/community
想给CANN社区提Issue？community仓库的协作规范详解
发布时间：2026/5/25 22:01:15
community仓库的定位community是CANN开源社区的协作规范仓库跟release-management、cann-agreements、cann-competitions、hicann、manifest这几个仓库同属社区治理仓库分类。它的核心职能是定义CANN社区的协作规则——怎么提Issue、怎么提PR、code review流程是什么、社区行为准则是什么。你可能会问——“这些规则写个README不就行了为啥要单独开个仓库”答案因为CANN社区的协作规范不是几行字能说清的。它包括了Issue模板提bug report要用什么格式、提feature request要用什么格式PR模板提代码要用什么格式、CI要过哪些检查、code review要几个人approveCode of Conduct行为准则社区成员之间怎么交流、什么行为会被banMaintainer指南仓库维护者怎么处理Issue/PR、怎么发版、怎么处理violation报告社区治理规则谁有commit权限、重大决策怎么投票、争议怎么仲裁这些内容如果每个仓库都复制一份维护成本极高——哪天规范改了55个仓库都要更新。所以CANN社区把所有协作规范集中放在community仓库里其他仓库通过链接引用。community仓库里有什么把community克隆下来目录结构大概长这样community/ ├── ISSUE_TEMPLATE/ # Issue模板 │ ├── bug_report.md │ ├── feature_request.md │ ├── performance_issue.md │ └── doc_issue.md ├── PULL_REQUEST_TEMPLATE/ # PR模板 │ ├── operator_pr.md │ ├── doc_pr.md │ └── config_pr.md ├── CODE_OF_CONDUCT.md # 社区行为准则 ├── CONTRIBUTING.md # 贡献指南总入口 ├── MAINTAINER_GUIDE.md # 维护者指南 ├── GOVERNANCE.md # 社区治理规则 ├── LICENSE_AGREEMENT.md # 版权协议链接到cann-agreements仓库 └── README.md下面逐块拆解。ISSUE_TEMPLATE/Issue模板这是community仓库里最有用的部分——它告诉你要提一个合格的Issue需要填哪些信息。CANN社区提供了4种Issue模板1. bug_report.mdbug报告提bug report时你必须提供## 环境信息 - CANN版本[比如 8.0.0] - 硬件[比如 Ascend 910 / Atlas 800] - 操作系统[比如 Ubuntu 22.04] - Python版本[比如 3.9] - 相关仓库及版本[比如 ops-transformer 8.0.0] ## 复现步骤 1. 克隆仓库git clone https://atomgit.com/cann/ops-transformer.git 2. 运行示例cd ops-transformer/examples python test_flash_attention.py 3. 报错信息[粘贴完整报错] ## 预期行为 [描述你期望发生什么] ## 实际行为 [描述实际发生了什么] ## 附加信息 - 是否可稳定复现[是/否] - 是否有临时workaround[是/否如果有请描述] - 日志文件[附上相关日志]为什么需要这么多信息因为CANN的维护者不是你公司的技术支持——他们没有你的环境没法猜你的bug在哪。你提供的信息越详细他们复现和修复的成本越低你的Issue被处理的速度就越快。我之前提的那个算子性能太慢的Issue就是因为没有填这个模板只写了句ops-math的matmul在Ascend 910上跑得很慢。维护者不知道我用的CANN版本是哪个8.0还是8.5我的矩阵size是多少1024x1024还是4096x4096我跟谁比很慢CPUGPU有没有报错还是只是慢所以那个Issue挂了3个月没人理。后来我按模板重新填了一遍附上了环境信息、复现脚本和性能数据3天就有维护者回复了。2. feature_request.md功能请求提新功能请求时你要填## 功能描述 [用一两句话描述你想要什么功能] ## 使用场景 [什么场景下你需要这个功能它解决了你的什么痛点] ## 实现思路可选 [如果你有实现思路可以在这里描述。没有就算了。] ## 是否有现有workaround [目前有没有临时方案比如用其他算子组合实现] ## 相关资料 [如果有论文、其他框架的实现参考可以附上链接]这个功能请求模板的核心是使用场景——如果你说不清楚为什么需要这个功能维护者可能会觉得这不是刚需先不做了。举个例子不好的功能请求“希望能加一个SwiGLU算子”只说了要什么没说为什么好的功能请求“我们在Ascend 910上跑LLaMA-3发现SwiGLU激活函数是用PyTorch实现的没有NPU加速。如果能把SwiGLU加到ops-transformer里推理延迟能降低15%。”说了场景、痛点、收益后者被接受的概率比前者高10倍。3. performance_issue.md性能问题这是CANN社区特有的Issue模板——因为算子性能优化是CANN的核心卖点所以社区单独做了一个性能问题模板。## 环境信息 [同bug_report.md] ## 性能数据 | 指标 | 当前性能 | 预期性能或对标性能 | |------|----------|------------------------| | 延迟 | 1200 ms | 800 ms对标NVIDIA A100 | | 吞吐 | 850 samples/s | 1200 samples/s | ## 对标对象 [你在跟谁比NVIDIA GPUCPU还是CANN的旧版本] ## 是否已经尝试优化 [比如调整了tiling参数、换了融合策略等] ## 复现代码 [附上能复现性能问题的代码]这个模板的关键在于性能数据——你不能只说太慢了你得说慢多少、“跟谁比慢”。有了这些数据维护者才能判断这个问题值不值得优先处理。4. doc_issue.md文档问题文档问题模板比较简单## 文档位置 [哪个文件的哪一段附上链接] ## 问题类型 - [ ] 错误文档写错了 - [ ] 不完整缺少关键信息 - [ ] 过时版本更新后没同步更新文档 - [ ] 不清楚描述模糊看不懂 ## 建议修改可选 [如果你知道怎么改可以直接提修改建议]文档问题通常处理得最快——因为改文档的成本比改代码低维护者一般都愿意快速修。PULL_REQUEST_TEMPLATE/PR模板提PR的时候也有模板。CANN社区提供了3种PR模板1. operator_pr.md算子代码PR如果你给ops-*系列仓库提了一个新的算子实现要用这个模板## 算子信息 - 算子名称[比如 FlashAttention-3] - 所属仓库[比如 ops-transformer] - 功能描述[这个算子做什么的] ## 实现信息 - 是否基于Ascend C实现[是/否] - 是否有单元测试[是/否附上测试覆盖率] - 是否有性能测试[是/否附上性能数据] ## 性能数据 | 指标 | 优化前或对标实现 | 优化后 | 提升 | |------|----------------------|--------|------| | 延迟 | 1200 ms | 800 ms | 33%↑ | | 吞吐 | 850 samples/s | 1200 samples/s | 41%↑ | ## Checklist - [ ] 代码符合Ascend C编程规范 - [ ] 通过了所有CI检查 - [ ] 添加了单元测试覆盖率80% - [ ] 添加了性能测试 - [ ] 更新了README和API文档这个模板的核心是性能数据和单元测试——CANN社区对算子PR的要求非常严格你必须证明这个算子跑得对且这个算子跑得快否则PR不会被merge。2. doc_pr.md文档PR如果你改的是文档README、API文档、tutorial等用这个模板## 文档变更 - 变更文件[列出所有改动的文件] - 变更类型[修正错误 / 补充内容 / 版本同步 / 格式优化] ## 预览 [如果可能附上改动后的文档截图或链接]文档PR通常很快就能merge——只要没犯低级错误比如把昇腾CANN写成华为CANN维护者一般不会卡。3. config_pr.md配置文件PR如果你改的是配置文件CMakeLists.txt、CI配置、版本号等用这个模板## 配置变更 - 变更文件[列出所有改动的文件] - 变更原因[为什么改解决了什么问题] ## 影响范围 [这个改动会影响哪些功能有没有兼容性问题]配置PR需要特别小心——一个错误的CMake配置可能导致整个仓库编译失败。所以社区要求配置PR必须详细说明影响范围避免破坏已有功能。CODE_OF_CONDUCT.md社区行为准则CANN社区采用了Contributor Covenant作为行为准则核心原则只有一句话对所有人友善不接受任何形式的骚扰或歧视。具体来说语言在Issue/PR/Discussion里交流时用中文或英文CANN社区是双语社区但不要用侮辱性语言尊重即使你不同意别人的观点也要理性讨论不要人身攻击包容欢迎新手提问不要嘲讽这种问题还要问隐私不要公开他人的个人信息邮箱、电话等违反行为准则的后果初犯维护者会私信提醒再犯在社区公告板通报批评严重违规比如辱骂、人身攻击直接ban掉拉入黑名单我见过一个真实案例有人在CANN社区的Issue里骂维护者脑子有坑这都不知道结果被ban了他后来发的PR全被拒绝。CONTRIBUTING.md贡献指南这是community仓库的总入口——新手来贡献代码第一件事就是读这个文件。它的内容大致是# CANN社区贡献指南 感谢你对CANN开源社区的兴趣 ## 第一次贡献 如果你从未给开源社区提过PR建议先看看 - [GitHub的PR教程](https://docs.github.com/en/pull-requests) - [CANN社区的PR模板](../PULL_REQUEST_TEMPLATE/operator_pr.md) ## 提Issue前 1. 搜索是否已存在相同Issue避免重复 2. 选择正确的Issue模板bug report / feature request / ... 3. 按模板填写所有必填项 ## 提PR前 1. 确保已有对应的IssuePR应该对应某个Issue除非是文档修正或trivial改动 2. 按PR模板填写所有必填项 3. 本地通过所有单元测试和CI检查 4. 确保代码符合[ Ascend C编程规范 ](链接) ## Code Review流程 1. PR提交后至少需要1位maintainer approve才能merge 2. 如果PR改了API或做了breaking change需要2位maintainer approve 3. Code review中维护者会提修改意见请在7天内响应否则PR会被close ## 版权协议 提PR前你需要签署[ CLA ](https://atomgit.com/cann/cann-agreements)Contributor License Agreement。这个文件的核心目的是降低新手的上手门槛——你不用去问我该怎么提PR按这个指南一步步做就行了。MAINTAINER_GUIDE.md维护者指南这个文件是给仓库维护者看的普通贡献者不用细读。但它值得了解一下因为你知道了维护者的工作流程就能更好地跟他们协作。维护者指南的内容包括Issue处理流程新Issue要在几天内响应什么情况下可以close IssuePR审核标准代码要符合什么规范性能数据要到什么程度单元测试覆盖率要多少发版流程怎么打tag怎么更新版本号release notes谁来写违规处理有人违反了Code of Conduct维护者该怎么处理举个例子Issue处理流程可能是这样的新Issue → 维护者在3个工作日内分类bug / feature / performance / doc → 打上对应标签bug / enhancement / performance / documentation → 如果是bug指派给相关开发者 → 如果是feature发起社区讨论看是否值得做 → Issue解决后维护者close Issue如果你提了一个bug Issue3天了还没人理你可以在Issue下面维护者或者去CANN社区的Gitter/Discord群里问问。GOVERNANCE.md社区治理规则这个文件定义了CANN社区的决策机制——谁有权利merge PR重大决策怎么投票争议怎么仲裁CANN社区的治理模型是维护者治理Maintainer Governance——即Maintainer维护者有merge权限能决定PR是否能被合并Committer提交者还没成为Maintainer但有频繁贡献记录可以提PR但需要Maintainer approveContributor贡献者普通社区成员提PR需要Maintainer approve目前CANN社区的Maintainer团队由华为昇腾部门的工程师和社区评选的活跃贡献者组成。重大决策比如改治理规则、加breaking change需要超过半数的Maintainer投票通过。如何从community仓库获取有用的信息说了这么多你肯定想问“我是个新手想给CANN社区做贡献该怎么开始”下面分三个场景来说。场景1想提一个Issuebug报告或功能请求步骤先读ISSUE_TEMPLATE/下的对应模板按模板填写所有必填项在提Issue前搜索是否已有相同Issue避免重复提交Issue后等待维护者响应通常3个工作日内代码演示用GitHub CLI提Issue# 1. 安装GitHub CLI如果还没装# macOS:brewinstallgh# Ubuntu:# sudo apt install gh# 2. 鉴权gh auth login# 3. 搜索是否已有相同Issuegh issue list--repocann/ops-transformer--searchFlashAttention performance# 4. 如果没有创建新Issue用模板gh issue create--repocann/ops-transformer\--titleFlashAttention-2在Ascend 910上性能不如预期\--body$(catISSUE_TEMPLATE/performance_issue.md)WHY用gh issue create而不是直接在网页上提是因为你可以在命令行里填模板不用在网页表单里手敲。而且gh会自动帮你添加标签、指派给相关maintainer。场景2想提一个PR贡献代码或文档步骤先提一个Issue讨论你要改的内容除非是trivial改动比如修正typoFork目标仓库到你的账号在本地分支上开发按PULL_REQUEST_TEMPLATE/下的模板填写PR描述本地通过所有单元测试和CI检查提交PR等待code review代码演示提一个算子PR的完整流程# 1. Fork仓库以ops-transformer为例# 在AtomGit网页上点Fork按钮# 2. 克隆你的forkgitclone https://atomgit.com/你的用户名/ops-transformer.gitcdops-transformer# 3. 添加上游仓库gitremoteaddupstream https://atomgit.com/cann/ops-transformer.git# 4. 创建新分支gitcheckout-bfeature/flash-attention-3# 5. 开发这里假设你已经写好了FlashAttention-3的Ascend C实现# ... 编辑代码 ...# 6. 运行单元测试python-mpytest tests/test_flash_attention_3.py-v# 7. 提交代码gitadd.gitcommit-mfeat: 添加FlashAttention-3算子实现 - 基于Ascend C实现 - 通过所有单元测试覆盖率85% - 性能提升33%延迟从1200ms降到800ms # 8. 推到你的forkgitpush origin feature/flash-attention-3# 9. 在AtomGit上提PRghprcreate--repocann/ops-transformer\--titlefeat: 添加FlashAttention-3算子实现\--body$(catPULL_REQUEST_TEMPLATE/operator_pr.md)\--basemain\--head你的用户名:feature/flash-attention-3WHY为什么要先提Issue再提PR因为避免白做功——如果你直接写了几千行代码但维护者觉得这个功能不需要你的PR会被close时间全浪费了。先提Issue讨论确认维护者接受这个方向了再写代码。场景3想成为CANN社区的Maintainer这条路比较长但也不是不可能。根据GOVERNANCE.md成为Maintainer的要求是持续贡献6个月以上至少有10个PR被merge熟悉CANN架构和对应仓库的代码社区选举产生由现有Maintainer团队投票如果你有兴趣可以先从文档修正和trivial bug fix开始贡献慢慢积累信任。等你的贡献记录够了可以在community仓库提一个Issue申请成为Maintainer候选人。效率对比遵守community规范 vs 不遵守用一个真实场景来说明遵守协作规范的价值。场景你在ops-transformer上发现了一个bug——FlashAttention-2在计算attention score时会越界访问显存。不遵守规范的情况你提了一个Issue标题是FlashAttention-2有bug内容是我跑的时候崩溃了维护者回复需要提供更多信息你把报错截图贴上去维护者回复无法复现需要提供复现脚本你花1天写了复现脚本维护者终于复现了但发现这个bug在main分支上已经修了你的Issue被close为duplicate从提Issue到close一共花了2周你的时间全浪费在来回要信息上了遵守规范的情况你先搜了一下Issue列表发现没人提过这个bug你按ISSUE_TEMPLATE/bug_report.md填好了所有信息包括环境、复现步骤、报错信息、复现代码维护者在2天内复现了bug并告诉你这个bug确实存在我们会在下个版本修你主动提了一个PR修复这个bug按PULL_REQUEST_TEMPLATE/operator_pr.md填好了PR描述维护者在1周内完成了code reviewmerge了你的PR从提Issue到PR merge一共只花了10天而且你的名字出现在了contributors列表里效率对比数据指标不遵守规范遵守规范提升Issue从提交到修复的时间2周10天节省29%时间PR从提交到merge的时间N/AIssue被close了1周N/A维护者的响应速度慢需要多轮交互要信息快信息一次性给全提升3-5倍成为contributor的概率低Issue被close高PR被merge提升80%community仓库的未来根据CANN社区的讨论community仓库还在持续完善中。未来可能会加入的功能Issue/PR模板的自动化检查你提Issue时如果没按模板填Bot自动提醒请按模板补充信息社区贡献者排行榜自动统计每个contributor的PR数量、被merge的PR数量激励更多人参与多语言支持目前的模板和文档只有中英文未来可能加入日文、韩文等CANN在社区有国际用户总结community仓库是CANN开源社区的协作手册——它定义了怎么提Issue、怎么提PR、社区的行为准则是什么。仓库链接https://atomgit.com/cann/community
