CANN社区组织管理全指南：SIG创建、成员变更与PMC/TSC治理实操

CANN社区组织管理全指南：SIG创建、成员变更与PMC/TSC治理实操

【免费下载链接】community本项目是CANN开源社区的核心管理仓库，包含社区的治理章程、治理组织、通用操作指引及流程规范等基础信息项目地址: https://gitcode.com/cann/community

CANN社区基于CANN/community仓库实现了项目、SIG、仓库、成员及其权限的统一管理，任何组织层面的变更都通过"修改组织信息文件 + 提交 PR + 获得三重标签自动合入"的流程落地。本文以社区组织管理操作手册（contributor/organization.md）为主线，系统讲解新建 SIG、SIG 组变更（maintainer/committer 任免）、SIG 组终止、PMC 成员变更与 TSC 成员变更的完整流程，并结合仓库内的org-info.yaml、sig-info.yaml、pmc.yaml、tsc.yaml等真实配置文件进行纵深解读。读者按本文操作，即可掌握向 TSC 申报议题、配置 SIG 权限、完成组织架构变更的全套实战技能。

一、社区治理组织架构与权限管理模型

CANN 社区的组织管理采用"章程规范 + 配置文件驱动"的双层架构：

• 治理章程：定义各类组织实体的职责边界与决策机制，包括 SIG 治理章程、PMC 治理章程、TSC 治理章程、角色定义与晋升机制。
• 配置文件：以 YAML 文件承载组织成员信息，是权限系统的事实来源（source of truth），主要包括：

配置文件	路径	管理对象
组织信息文件	CANN/org-info.yaml	各 SIG 的 maintainer 名单
SIG 信息文件	CANN/sigs/<sig_name>/sig-info.yaml	各 SIG 的 committer、repositories、branch、目录级权限
PMC 成员文件	CANN/PMC/pmc.yaml	PMC 成员（pmc_members）及 PMC 管辖仓库
TSC 成员文件	CANN/TSC/tsc.yaml	TSC 成员（tsc_members）
SIG 引导页	CANN/sigs/README.md	全量 SIG 列表及简介

从 CANN/sigs/shared_config.yaml 可以看到，社区甚至为公共配置（如版本分支、.gitcode目录、.gitmodules文件）也定义了独立的 committer 名单，体现了"权限细化到文件/目录级别"的管理粒度。

所有组织变更遵循同一套 PR 审查机制：PR 需同时获得cann-cla/yes、lgtm、approved三个标签后方可自动合入。变更生效后，权限每隔 1 小时刷新一次，配置完成后需要耐心等待。

二、创建 SIG 组：从议题申报到权限配置

2.1 向技术委员会提交新建 SIG 申请

确认 SIG 符合申请条件

申请之前，请确保该 SIG 符合 SIG 治理章程 中的要求。章程明确指出，申请新 SIG 前需要：

• 深入理解 SIG 治理框架、角色职责和生命周期；
• 确认技术方向的唯一性和可行性——查阅 CANN/sigs/README.md 中已有 SIG 列表和邮件列表，确保所申请的技术方向在社区中尚不存在；
• 确认所申请的技术项目能够最终转化为 CANN 的新增部件或子项目；
• 准备 SIG 章程与目标（可参考 SIG组申报模板）。

提交申请

新建 SIG 需要向技术委员会（TSC）提交申请，具体方式是在技术委员会例会申报议题，有两种申报途径：

1. 订阅技术委员会邮箱（[e-mail]邮件列表），收到例会通知后，直接回复会议邮件申报会议议题，例如：1. XXX SIG新建申请 -- 申请人：XXX。
2. 直接在技术委员会会议纪要模板（TSC 会议白板）中进行申报，将相关议题和申报人员信息刷新到对应例会议题中，例如：1. XXX SIG新建申请 -- 申请人：XXX。

申请模板详见 SIG组申报模板。

议题经技术指导委员会例会审批通过（评审形成会议纪要，该纪要是后续创建 SIG 的必要凭证）后，SIG 发起人需要完成 SIG 各类权限配置。

2.2 第一步：修改组织架构（注册 maintainer）

（1）Fork 并修改：ForkCANN/community仓库，修改 org-info.yaml（编写指南见 org-info.yaml编写指南），新增该 SIG 组的定义。

org-info.yaml位于仓库CANN/目录下，用于记录 CANN 组织中各 SIG 的 Maintainer 信息。其顶层字段包括：

字段	类型	层级	说明
name	字符串	一层	项目名称，此处是 CANN
description	字符串	一层	项目描述信息
sigs	列表	一层	项目组内所有 SIG 的信息清单

sigs中每条记录的元素：

字段	类型	层级	说明
sig_name	字符串	二层	SIG 组的名称，必填
maintainers	列表	二层	项目看护者成员清单

maintainers中每条个人信息记录的元素：

字段	类型	层级	说明
gitcode_id	字符串	三层	GitCode ID，必填
name	字符串	三层	姓名（或者网名），可选
email	字符串	三层	个人邮箱地址，可选

参照 CANN/org-info.yaml 中真实配置，新增一个 SIG 的 YAML 写法如下：

# 组织/项目基本信息 name: CANN # 组织/项目名称 description: 项目描述 # SIG 列表 sigs: - sig_name: ops-basic # SIG 名称 (必填) maintainers: # 该 SIG 的 Maintainers - gitcode_id: zhou-qilong name: 周奇龙 email: [e-mail] - gitcode_id: gubaocheng name: 顾宝成 email: [e-mail]

需要注意：同一人可以在不同 SIG 担任 Maintainer（例如loov1同时出现在 aal、ops-basic、shmem 等多个 SIG 的 maintainers 列表中，可参见 CANN/org-info.yaml）。SIG Maintainer 拥有该 SIG 名下所有仓库的一级（直接）Committer 权限，并负责管理其所属 SIG 的 sig-info.yaml 文件。

（2）提交 PR：提交 PR 至master分支，PR 描述中需要附加评审纪要。

（3）通过审查并合入 PR：此 PR 需获得cann-cla/yes、lgtm、approved三个标签，由 tsc_members 评论/lgtm和/approve后自动合入：

• cann-cla/yes：CLA 协议检查。机器人会自动检查 commits 中的邮箱是否已签署 CLA 协议。若已签署，将添加此标签；若未签署，会添加cann-cla/no标签并留言提示；
• lgtm：请联系org-info.yaml中 tsc_members 进行评审。评审通过后，由 maintainer 评论/lgtm；
• approved：联系 tsc_members 进行批准。批准后，由 tsc_members 评论/approve。

2.3 第二步：创建 SIG 目录和 committer 信息文件

（1）创建目录与信息文件：在第一个 PR 合并后，在相应项目的sigs目录下创建新的 SIG 组目录（例如 CANN/sigs/ops-basic/）；在该目录中创建sig-info.yaml文件（编写指南见 sig-info.yaml编写指南），并配置 maintainers、committers 等信息，同时补充README.md介绍文件以及 CANN/sigs/README.md 中的 SIG 入口。

（2）提交 PR：提交第二个 PR 至master分支，PR 描述中需要附加评审纪要。

（3）通过审查并合入 PR：此 PR 需获得cann-cla/yes、lgtm、approved三个标签后自动合入：

• cann-cla/yes：CLA 协议检查，规则同上；
• lgtm：请联系org-info.yaml中该 SIG 组的 maintainers 进行评审。评审通过后，由 maintainer 评论/lgtm；
• approved：联系该 SIG 组的 maintainers 进行批准。批准后，由 maintainer 评论/approve。

（4）绑定会议账号：PR 合入后，需要登录社区会议平台（meeting.osinfra.cn）的个人中心，将 GitCode 账号与华为账号绑定。绑定 GitCode ID 后，CANN 社区 SIG maintainer、committer 自动拥有创建会议权限（具体会议指导可参见 CANN 社区会议指南）。

注意：权限每隔 1 小时刷新一次，配置后请耐心等待。

（5）申请邮件列表：PR 合入后，如果该 SIG 组需要新建邮件列表，需要 maintainer 在新建 sig 的 community 仓库的 GitCode PR 中 @ 社区基础设施负责人（gitcode 账号weixin_43493709），并描述：你好，需要新建邮件列表，邮件列表名为[e-mail]（其中 xxx 代表 sig 名）。

三、SIG 组变更：任免 maintainer 与 committer

3.1 变更流程

任免 maintainer/committer 的流程详见 SIG 治理章程。章程规定：Maintainer 变更需及时知会技术指导委员会并更新 SIG 组织信息和相关权限；若 Maintainer 发生变动，需及时通知技术指导委员会并更新相关信息。

3.2 情况一：maintainer 任免

1. Fork 并修改：ForkCANN/community仓库到个人账号，修改 org-info.yaml（org-info.yaml编写指南）和 SIGREADME.md里面的人员信息。
2. 提交 PR：向CANN/community仓库的master分支提交 PR。
3. 通过审查并合入 PR：PR 需要获得以下三个标签才能被合并：
   • cann-cla/yes：CLA 协议检查。机器人会自动检查 commits 中的邮箱是否已签署 CLA 协议。若已签署，将添加此标签；若未签署，会添加cann-cla/no标签并留言提示；
   • lgtm：请联系org-info.yaml文件中列出的tsc_members进行评审。评审通过后，由 tsc_member 评论/lgtm，机器人会自动添加标签；
   • approved：同样联系tsc_members进行批准。批准后，由 tsc_member 评论/approve，机器人会自动添加标签。

3.3 情况二：committer 任免

1. Fork 并修改：ForkCANN/community仓库，修改目标 SIG 的 sig-info.yaml（sig-info.yaml编写指南）和 SIGREADME.md里面的人员信息。
2. 提交 PR：向CANN/community仓库的master分支提交 PR。
3. 通过审查并合入 PR：PR 需要获得以下三个标签才能被合并：
   • cann-cla/yes：CLA 协议检查，规则同上；
   • lgtm：请联系sig-info.yaml中该 SIG 组的maintainers进行评审。评审通过后，由 maintainer 评论/lgtm；
   • approved：同样联系该 SIG 组的maintainers进行批准。批准后，由 maintainer 评论/approve。

关键差异：maintainer 任免的评审方是tsc_members，而 committer 任免的评审方是该 SIG 组的 maintainers。这是因为 maintainer 的变更影响面覆盖整个 SIG 的组织结构，需要上升到 TSC 层面审批；而 committer 属于 SIG 内部权限，由 SIG 负责人自行管理。

四、SIG 组终止：目录移除与组织信息清理

4.1 变更流程

终止 SIG 的流程详见 SIG 治理章程。章程规定 SIG 终止的场景包括：完成历史使命、长期不活跃或技术方向不再符合社区发展需求。Maintainer 可主动向技术指导委员会提交终止申请并说明理由，技术指导委员会也有权根据活跃度和贡献度决定是否终止某个 SIG。

4.2 第一步：移除 SIG 目录

（1）删除目录：在相应项目的sigs目录下删除对应 SIG 组目录。

（2）提交 PR：提交 PR 至master分支（PR 描述中需要附加评审纪要）。

（3）通过审查并合入 PR：此 PR 需获得cann-cla/yes、lgtm、approved三个标签后自动合入：

• cann-cla/yes：CLA 协议检查，规则同上；
• lgtm：请联系org-info.yaml中该 SIG 组的 maintainers 进行评审。评审通过后，由 maintainer 评论/lgtm；
• approved：联系该 SIG 组的 maintainers 进行批准。批准后，由 maintainer 评论/approve。

（4）权限回收：PR 合入后，SIG 组成员在 SIG 组对应的会议预定权限、代码合入权限等会被取消。

4.3 第二步：修改组织架构

（1）Fork 并修改：ForkCANN/community仓库，修改 org-info.yaml（org-info.yaml编写指南），删除该 SIG 组的定义。

（2）提交 PR：提交 PR 至master分支（PR 描述中需要附加评审纪要）。

（3）通过审查并合入 PR：此 PR 需获得cann-cla/yes、lgtm、approved三个标签，需由 tsc_members 评论/lgtm和/approve后自动合入：

• cann-cla/yes：CLA 协议检查，规则同上；
• lgtm：请联系org-info.yaml中 tsc_members 进行评审。评审通过后，由 maintainer 评论/lgtm；
• approved：联系 tsc_members 进行批准。批准后，由 tsc_members 评论/approve。

注意终止流程与创建流程的顺序相反：创建时先改组织架构（第一个 PR）、再建 SIG 目录（第二个 PR）；终止时先删 SIG 目录（第一个 PR）、再改组织架构（第二个 PR），以此保证权限回收与信息清理的先后一致性。

五、PMC 成员变更

5.1 变更流程

PMC 变更流程详见 PMC 治理章程。

5.2 权限配置

1. Fork 并修改：ForkCANN/community仓库到个人账号，修改 CANN/PMC/pmc.yaml。
2. 提交 PR：向CANN/community仓库的master分支提交 PR。
3. 通过审查并合入 PR：PR 需要获得以下三个标签才能被合并：
   • cann-cla/yes：CLA 协议检查。机器人会自动检查 commits 中的邮箱是否已签署 CLA 协议。若已签署，将添加此标签；若未签署，会添加cann-cla/no标签并留言提示；
   • lgtm：请联系pmc.yaml文件中列出的pmc_members进行评审。评审通过后，pmc_member 评论/lgtm，机器人会自动添加标签；
   • approved：同样联系pmc_members进行批准。批准后，由 pmc_members 评论/approve，机器人会自动添加标签。

从仓库中的 CANN/PMC/pmc.yaml 可以看到 PMC 文件的实际结构：顶层包含name、description、mailing_list（[e-mail]）、meeting_whiteboard_url、pmc_members以及repositories字段。其中repositories段声明了 PMC 管辖的仓库（如 cann/release-management、cann/community），并为每个仓库配置了 committer 名单；在cann/community仓库下还通过entry_configs将CANN、cla、contributor、docs、events、governance、security、templates、QA等目录的权限细化到具体成员。

六、TSC 成员变更

6.1 变更流程

TSC 变更流程详见 TSC 治理章程。

6.2 权限配置

1. Fork 并修改：ForkCANN/community仓库到个人账号，修改 CANN/TSC/tsc.yaml。
2. 提交 PR：向CANN/community仓库的master分支提交 PR。
3. 通过审查并合入 PR：PR 需要获得以下三个标签才能被合并：
   • cann-cla/yes：CLA 协议检查。机器人会自动检查 commits 中的邮箱是否已签署 CLA 协议。若已签署，将添加此标签；若未签署，会添加cann-cla/no标签并留言提示；
   • lgtm：请联系tsc.yaml文件中列出的tsc_members进行评审。评审通过后，tsc_member 评论/lgtm，机器人会自动添加标签；
   • approved：同样联系tsc_members进行批准。批准后，由 tsc_members 评论/approve，机器人会自动添加标签。

仓库中的 CANN/TSC/tsc.yaml 展示了 TSC 成员文件的真实形态：除name、description、mailing_list（[e-mail]）、meeting_whiteboard_url外，核心字段是tsc_members成员列表。TSC 负责定义 CANN 社区的技术方向、决策重大技术事项、管理项目及人员架构，因此其成员列表的变更同样遵循三重标签自动合入机制，且评审与批准权都在 TSC 成员内部闭环。

七、sig-info.yaml 权限模型深度解读

sig-info.yaml是整个社区权限体系中最精细的一层，它实现了"SIG → 仓库 → 分支 → 目录/文件"四级权限下发。下面结合 sig-info.yaml编写指南 与 CANN/sigs/ops-basic/sig-info.yaml 的真实配置展开。

7.1 文件格式与角色

每个 SIG 在 community 仓库的CANN/sigs目录下配置一个sig-info.yaml，主要包含如下一层基本元素：

字段	类型	层级	说明
name	字符串	一层	SIG 组名称
description	字符串	一层	SIG 组描述信息
mailing_list	字符串	一层	SIG 组讨论邮件列表地址
meeting_whiteboard_url	字符串	一层	SIG 例会纪要 URL
committers	列表	一层	SIG 组对应的 committer 名单
repositories	列表	一层	SIG 组所管辖的代码仓库信息

权限体系中的两个关键角色：

角色	字段	权限范围
审批者（Committer）	committers	代码合并权限（可覆盖到文件级）
分支守护者	branch_keeper	特定分支版本管理（打 keeper_approved 标签）

注意：maintainer 自动拥有 SIG 层的 committer 权限，无需重复配置。

repositories列表中的每一条记录可包含如下元素：

字段	类型	层级	说明
repo	列表	二层	仓库组，可以是一个仓库，也可以是一组仓库，可选
committers	列表	二层	仓库组对应的 committer 名单，可选
contributors	列表	二层	仓库组对应的 contributor 名单，可选
branch_configs	列表	二层	分支列表，可选
entry_configs	列表	二层	仓库下的目录或文件配置，可选

branch_configs列表中的每一条记录：

字段	类型	层级	说明
branch	列表	三层	分支列表，可选
committers	列表	三层	仓库对应分支下的 committer 名单，可选
branch_keeper	列表	三层	仓库对应分支下的 branch_keeper 名单，可选
entry_configs	列表	三层	仓库对应分支下的目录或文件配置，可选

entry_configs列表中的每一条记录：

字段	类型	层级	说明
path	列表	-	目录、文件列表或者通配符路径，可选
committers	列表	-	目录或者文件列表下的 committer 名单，可选

committers、branch_keeper、contributors的每一条个人信息记录：

字段	类型	层级	说明
gitcode_id	字符串	-	GitCode ID，必填
name	字符串	-	姓名（或者网名），可选
email	字符串	-	个人邮箱地址，可选

7.2 五种典型配置场景

以 ops-basic 为例（完整样例见 sig-info.yaml编写指南 附录），五种配置场景如下：

场景 1：只有 SIG 组级 committers，各仓库不单独设置。此时 SIG 组级committers自动拥有该 SIG 下所有仓库的 committer 权限，branch_keeper按仓库可选配置：

name: ops-basic # SIG组名称 description: This is a sample sig. # SIG组描述信息 mailing_list: [e-mail] # SIG组讨论邮件列表地址 meeting_whiteboard_url: https://etherpad-cann.meeting.osinfra.cn/p/sig-ops-basic # SIG例会纪要URL committers: # SIG组所有committer名单（ccc和ddd拥有ops-basic下所有仓库的committer权限） - gitcode_id: ccc - gitcode_id: ddd repositories: # repositories 字段说明SIG组所管理的仓库组信息 - repo: # 仓库组，可以是一个仓库，也可以是一组仓库，可选 - CANN/ops-basic-AAA branch_configs: - branch: - master branch_keeper: # 某个分支的版本经理，有权限评论/merge，打keeper_approved标签 - gitcode_id: eee - repo: - CANN/ops-basic-BBB branch_configs: - branch: - master branch_keeper: - gitcode_id: fff

场景 2：针对 SIG 组各仓库单独设置 committers。仓库组的committers只对组内列出的仓库生效：

name: ops-basic description: This is a sample sig. mailing_list: [e-mail] meeting_whiteboard_url: https://etherpad-cann.meeting.osinfra.cn/p/sig-ops-basic committers: - gitcode_id: ccc - gitcode_id: ddd repositories: - repo: # 仓库组 - CANN/ops-basic-AAA - CANN/ops-basic-BBB committers: # ggg和hhh拥有AAA、BBB仓库的committer权限 - gitcode_id: ggg - gitcode_id: hhh - repo: - CANN/ops-basic-CCC - CANN/ops-basic-DDD committers: # kkk和lll拥有CCC、DDD仓库的committer权限 - gitcode_id: kkk - gitcode_id: lll

场景 3：仓库级 committers + 目录/文件级（entry）committers。entry_configs中的path可以是目录、完整文件路径或通配符路径。注意通配符路径只支持*，且使用通配符时必须加双引号，否则会导致解析 sig-info 失败：

name: ops-basic description: This is a sample sig. mailing_list: [e-mail] meeting_whiteboard_url: https://etherpad-cann.meeting.osinfra.cn/p/sig-ops-basic committers: - gitcode_id: ccc - gitcode_id: ddd repositories: - repo: - CANN/ops-basic-AAA - CANN/ops-basic-BBB committers: # ggg和hhh拥有AAA、BBB仓库下除entry声明的路径外的committer权限 - gitcode_id: ggg - gitcode_id: hhh entry_configs: - path: - cmake/figures - siginfo.yaml - "*/*/op_graph/*_proto.h" # 通配符路径必须使用双引号 - "*/*/op_api/*.h" committers: # yyy和zzz拥有上述路径的committer权限 - gitcode_id: yyy - gitcode_id: zzz - path: - debug/validate - setup.py committers: # uio和asd拥有debug/validate目录和setup.py文件的committer权限 - gitcode_id: uio - gitcode_id: asd

场景 4：仓库级 committers + 分支级（branch）committers 与 branch_keeper。branch_configs将权限精确作用到指定分支：

name: ops-basic description: This is a sample sig. mailing_list: [e-mail] meeting_whiteboard_url: https://etherpad-cann.meeting.osinfra.cn/p/sig-ops-basic committers: - gitcode_id: ccc - gitcode_id: ddd repositories: - repo: - CANN/ops-basic-AAA - CANN/ops-basic-BBB committers: - gitcode_id: ggg - gitcode_id: hhh branch_configs: - branch: # 分支组，可以是一个分支，也可以是一组分支 - master - br_release committers: # kkk和lll拥有master、br_release分支的committer权限 - gitcode_id: kkk - gitcode_id: lll branch_keeper: - gitcode_id: ooo - branch: - develop - feature committers: - gitcode_id: zzz - gitcode_id: xxx branch_keeper: - gitcode_id: qqq

场景 5：仓库级 + 分支级 committers + 分支下目录/文件级（branch entry）committers。这是最细粒度的组合场景，branch_configs内嵌套entry_configs，将权限作用到"特定分支下的特定目录/文件"，完整 YAML 可参见 sig-info.yaml编写指南 中的第 5 个示例。

7.3 真实配置印证：ops-basic SIG 的权限下发

以 CANN/sigs/ops-basic/sig-info.yaml 为例，可以看到四级权限模型在真实场景中的落地：

• SIG 层：name: ops-basic、mailing_list: [e-mail]、meeting_whiteboard_url指向 sig-ops-basic 白板，committers: []（该 SIG 未配置 SIG 级 committers，权限全部下沉到仓库层）；
• 仓库层：repositories覆盖 cann/opbase、cann/ops-cv、cann/ops-math、cann/atvoss、cann/cann-samples、cann/ops-rand、cann/ops-test-kit、cann/ops-multimodal-fusion、cann/ops-ras 等仓库，每个仓库组都配置了独立的 committers 名单；
• 目录/文件层：通过entry_configs将权限细分到具体模块，例如ops-cv下image/crop_and_resize、image/grid_sample系列、objdetect/roi_align系列、experimental等路径，以及ops-math下conversion/*、math/*（add、mul、reduce 系列、sort 等数十个算子目录）分别由不同成员组负责；path中还大量使用了"*/*/op_host/op_api/*.h"、"*/*/op_graph/*_proto.h"、"*/*/docs/acl*.md"等双引号通配符路径来批量授权接口头文件与文档目录。

这套模型的直接收益是：一个仓库内不同目录/算子可以由不同的 committer 独立审批，实现代码合入权限的"文件级"精细化管控，同时通过仓库组（repo 列表）与分支组（branch 列表）的批量配置降低维护成本。

八、总结：组织变更操作速查

CANN 社区的所有组织变更（新建 SIG、maintainer/committer 任免、SIG 终止、PMC/TSC 成员变更）都收敛为同一条标准化路径：

1. Fork 并修改对应配置文件：新增/删除 SIG 改 CANN/org-info.yaml 与 CANN/sigs/<sig_name>/sig-info.yaml；maintainer 任免改 org-info.yaml + SIG README；committer 任免改 sig-info.yaml + SIG README；PMC 成员改 CANN/PMC/pmc.yaml；TSC 成员改 CANN/TSC/tsc.yaml。
2. 提交 PR 至 master 分支，PR 描述中附加评审纪要。
3. 等待三重标签：cann-cla/yes（CLA 检查，机器人自动处理）+lgtm（对应评审方评论/lgtm）+approved（对应评审方评论/approve），标签齐全后自动合入。
4. 等待权限刷新：权限每隔 1 小时刷新一次，配置后耐心等待；必要时在社区会议平台绑定 GitCode 账号获取会议创建权限。

各变更类型的评审方对照如下：

变更类型	修改文件	评审/批准方
新建 SIG（组织架构）	CANN/org-info.yaml	tsc_members
新建 SIG（目录与 committer）	CANN/sigs/<sig_name>/sig-info.yaml	该 SIG 组 maintainers
maintainer 任免	CANN/org-info.yaml + SIG README	tsc_members
committer 任免	CANN/sigs/<sig_name>/sig-info.yaml + SIG README	该 SIG 组 maintainers
SIG 终止	删除 SIG 目录 + 修改 CANN/org-info.yaml	该 SIG 组 maintainers / tsc_members
PMC 成员变更	CANN/PMC/pmc.yaml	pmc_members
TSC 成员变更	CANN/TSC/tsc.yaml	tsc_members

本文全部流程均以 contributor/organization.md 为基准，配套的章程性文件（SIG 治理章程、PMC 治理章程、TSC 治理章程）与配置文件编写指南（org-info.yaml编写指南、sig-info.yaml编写指南）均可在仓库内查阅，开发者可据此完整落地社区组织管理操作。

【免费下载链接】community本项目是CANN开源社区的核心管理仓库，包含社区的治理章程、治理组织、通用操作指引及流程规范等基础信息项目地址: https://gitcode.com/cann/community