CANN社区组织管理全指南SIG创建、成员变更与PMC/TSC治理实操【免费下载链接】community本项目是CANN开源社区的核心管理仓库包含社区的治理章程、治理组织、通用操作指引及流程规范等基础信息项目地址: https://gitcode.com/cann/communityCANN社区基于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.yamlPMC 成员pmc_members及 PMC 管辖仓库TSC 成员文件CANN/TSC/tsc.yamlTSC 成员tsc_membersSIG 引导页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提交申请具体方式是在技术委员会例会申报议题有两种申报途径订阅技术委员会邮箱tsccann.osinfra.cn邮件列表收到例会通知后直接回复会议邮件申报会议议题例如1. XXX SIG新建申请 -- 申请人XXX。直接在技术委员会会议纪要模板TSC 会议白板中进行申报将相关议题和申报人员信息刷新到对应例会议题中例如1. XXX SIG新建申请 -- 申请人XXX。申请模板详见 SIG组申报模板。议题经技术指导委员会例会审批通过评审形成会议纪要该纪要是后续创建 SIG 的必要凭证后SIG 发起人需要完成 SIG 各类权限配置。2.2 第一步修改组织架构注册 maintainer1Fork 并修改ForkCANN/community仓库修改 org-info.yaml编写指南见 org-info.yaml编写指南新增该 SIG 组的定义。org-info.yaml位于仓库CANN/目录下用于记录 CANN 组织中各 SIG 的 Maintainer 信息。其顶层字段包括字段类型层级说明name字符串一层项目名称此处是 CANNdescription字符串一层项目描述信息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: zhouqilong2huawei.com - gitcode_id: gubaocheng name: 顾宝成 email: gubaochenghuawei.com需要注意同一人可以在不同 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/yesCLA 协议检查。机器人会自动检查 commits 中的邮箱是否已签署 CLA 协议。若已签署将添加此标签若未签署会添加cann-cla/no标签并留言提示lgtm请联系org-info.yaml中 tsc_members 进行评审。评审通过后由 maintainer 评论/lgtmapproved联系 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/yesCLA 协议检查规则同上lgtm请联系org-info.yaml中该 SIG 组的 maintainers 进行评审。评审通过后由 maintainer 评论/lgtmapproved联系该 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并描述你好需要新建邮件列表邮件列表名为xxxcann.osinfra.cn其中 xxx 代表 sig 名。三、SIG 组变更任免 maintainer 与 committer3.1 变更流程任免 maintainer/committer 的流程详见 SIG 治理章程。章程规定Maintainer 变更需及时知会技术指导委员会并更新 SIG 组织信息和相关权限若 Maintainer 发生变动需及时通知技术指导委员会并更新相关信息。3.2 情况一maintainer 任免Fork 并修改ForkCANN/community仓库到个人账号修改 org-info.yamlorg-info.yaml编写指南和 SIGREADME.md里面的人员信息。提交 PR向CANN/community仓库的master分支提交 PR。通过审查并合入 PRPR 需要获得以下三个标签才能被合并cann-cla/yesCLA 协议检查。机器人会自动检查 commits 中的邮箱是否已签署 CLA 协议。若已签署将添加此标签若未签署会添加cann-cla/no标签并留言提示lgtm请联系org-info.yaml文件中列出的tsc_members进行评审。评审通过后由 tsc_member 评论/lgtm机器人会自动添加标签approved同样联系tsc_members进行批准。批准后由 tsc_member 评论/approve机器人会自动添加标签。3.3 情况二committer 任免Fork 并修改ForkCANN/community仓库修改目标 SIG 的 sig-info.yamlsig-info.yaml编写指南和 SIGREADME.md里面的人员信息。提交 PR向CANN/community仓库的master分支提交 PR。通过审查并合入 PRPR 需要获得以下三个标签才能被合并cann-cla/yesCLA 协议检查规则同上lgtm请联系sig-info.yaml中该 SIG 组的maintainers进行评审。评审通过后由 maintainer 评论/lgtmapproved同样联系该 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/yesCLA 协议检查规则同上lgtm请联系org-info.yaml中该 SIG 组的 maintainers 进行评审。评审通过后由 maintainer 评论/lgtmapproved联系该 SIG 组的 maintainers 进行批准。批准后由 maintainer 评论/approve。4权限回收PR 合入后SIG 组成员在 SIG 组对应的会议预定权限、代码合入权限等会被取消。4.3 第二步修改组织架构1Fork 并修改ForkCANN/community仓库修改 org-info.yamlorg-info.yaml编写指南删除该 SIG 组的定义。2提交 PR提交 PR 至master分支PR 描述中需要附加评审纪要。3通过审查并合入 PR此 PR 需获得cann-cla/yes、lgtm、approved三个标签需由 tsc_members 评论/lgtm和/approve后自动合入cann-cla/yesCLA 协议检查规则同上lgtm请联系org-info.yaml中 tsc_members 进行评审。评审通过后由 maintainer 评论/lgtmapproved联系 tsc_members 进行批准。批准后由 tsc_members 评论/approve。注意终止流程与创建流程的顺序相反创建时先改组织架构第一个 PR、再建 SIG 目录第二个 PR终止时先删 SIG 目录第一个 PR、再改组织架构第二个 PR以此保证权限回收与信息清理的先后一致性。五、PMC 成员变更5.1 变更流程PMC 变更流程详见 PMC 治理章程。5.2 权限配置Fork 并修改ForkCANN/community仓库到个人账号修改 CANN/PMC/pmc.yaml。提交 PR向CANN/community仓库的master分支提交 PR。通过审查并合入 PRPR 需要获得以下三个标签才能被合并cann-cla/yesCLA 协议检查。机器人会自动检查 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_listpmccann.osinfra.cn、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 权限配置Fork 并修改ForkCANN/community仓库到个人账号修改 CANN/TSC/tsc.yaml。提交 PR向CANN/community仓库的master分支提交 PR。通过审查并合入 PRPR 需要获得以下三个标签才能被合并cann-cla/yesCLA 协议检查。机器人会自动检查 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_listtsccann.osinfra.cn、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 例会纪要 URLcommitters列表一层SIG 组对应的 committer 名单repositories列表一层SIG 组所管辖的代码仓库信息权限体系中的两个关键角色角色字段权限范围审批者Committercommitters代码合并权限可覆盖到文件级分支守护者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: ops-basiccann.osinfra.cn # 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: ops-basiccann.osinfra.cn 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 目录/文件级entrycommitters。entry_configs中的path可以是目录、完整文件路径或通配符路径。注意通配符路径只支持*且使用通配符时必须加双引号否则会导致解析 sig-info 失败name: ops-basic description: This is a sample sig. mailing_list: ops-basiccann.osinfra.cn 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 分支级branchcommitters 与 branch_keeper。branch_configs将权限精确作用到指定分支name: ops-basic description: This is a sample sig. mailing_list: ops-basiccann.osinfra.cn 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 entrycommitters。这是最细粒度的组合场景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: ops-basiccann.osinfra.cn、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 成员变更都收敛为同一条标准化路径Fork 并修改对应配置文件新增/删除 SIG 改 CANN/org-info.yaml 与 CANN/sigs/sig_name/sig-info.yamlmaintainer 任免改 org-info.yaml SIG READMEcommitter 任免改 sig-info.yaml SIG READMEPMC 成员改 CANN/PMC/pmc.yamlTSC 成员改 CANN/TSC/tsc.yaml。提交 PR 至 master 分支PR 描述中附加评审纪要。等待三重标签cann-cla/yesCLA 检查机器人自动处理lgtm对应评审方评论/lgtmapproved对应评审方评论/approve标签齐全后自动合入。等待权限刷新权限每隔 1 小时刷新一次配置后耐心等待必要时在社区会议平台绑定 GitCode 账号获取会议创建权限。各变更类型的评审方对照如下变更类型修改文件评审/批准方新建 SIG组织架构CANN/org-info.yamltsc_members新建 SIG目录与 committerCANN/sigs/sig_name/sig-info.yaml该 SIG 组 maintainersmaintainer 任免CANN/org-info.yaml SIG READMEtsc_memberscommitter 任免CANN/sigs/sig_name/sig-info.yaml SIG README该 SIG 组 maintainersSIG 终止删除 SIG 目录 修改 CANN/org-info.yaml该 SIG 组 maintainers / tsc_membersPMC 成员变更CANN/PMC/pmc.yamlpmc_membersTSC 成员变更CANN/TSC/tsc.yamltsc_members本文全部流程均以 contributor/organization.md 为基准配套的章程性文件SIG 治理章程、PMC 治理章程、TSC 治理章程与配置文件编写指南org-info.yaml编写指南、sig-info.yaml编写指南均可在仓库内查阅开发者可据此完整落地社区组织管理操作。【免费下载链接】community本项目是CANN开源社区的核心管理仓库包含社区的治理章程、治理组织、通用操作指引及流程规范等基础信息项目地址: https://gitcode.com/cann/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 CANN社区组织管理全指南：SIG创建、成员变更与PMC/TSC治理实操
CANN社区组织管理全指南SIG创建、成员变更与PMC/TSC治理实操【免费下载链接】community本项目是CANN开源社区的核心管理仓库包含社区的治理章程、治理组织、通用操作指引及流程规范等基础信息项目地址: https://gitcode.com/cann/communityCANN社区基于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.yamlPMC 成员pmc_members及 PMC 管辖仓库TSC 成员文件CANN/TSC/tsc.yamlTSC 成员tsc_membersSIG 引导页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提交申请具体方式是在技术委员会例会申报议题有两种申报途径订阅技术委员会邮箱tsccann.osinfra.cn邮件列表收到例会通知后直接回复会议邮件申报会议议题例如1. XXX SIG新建申请 -- 申请人XXX。直接在技术委员会会议纪要模板TSC 会议白板中进行申报将相关议题和申报人员信息刷新到对应例会议题中例如1. XXX SIG新建申请 -- 申请人XXX。申请模板详见 SIG组申报模板。议题经技术指导委员会例会审批通过评审形成会议纪要该纪要是后续创建 SIG 的必要凭证后SIG 发起人需要完成 SIG 各类权限配置。2.2 第一步修改组织架构注册 maintainer1Fork 并修改ForkCANN/community仓库修改 org-info.yaml编写指南见 org-info.yaml编写指南新增该 SIG 组的定义。org-info.yaml位于仓库CANN/目录下用于记录 CANN 组织中各 SIG 的 Maintainer 信息。其顶层字段包括字段类型层级说明name字符串一层项目名称此处是 CANNdescription字符串一层项目描述信息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: zhouqilong2huawei.com - gitcode_id: gubaocheng name: 顾宝成 email: gubaochenghuawei.com需要注意同一人可以在不同 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/yesCLA 协议检查。机器人会自动检查 commits 中的邮箱是否已签署 CLA 协议。若已签署将添加此标签若未签署会添加cann-cla/no标签并留言提示lgtm请联系org-info.yaml中 tsc_members 进行评审。评审通过后由 maintainer 评论/lgtmapproved联系 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/yesCLA 协议检查规则同上lgtm请联系org-info.yaml中该 SIG 组的 maintainers 进行评审。评审通过后由 maintainer 评论/lgtmapproved联系该 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并描述你好需要新建邮件列表邮件列表名为xxxcann.osinfra.cn其中 xxx 代表 sig 名。三、SIG 组变更任免 maintainer 与 committer3.1 变更流程任免 maintainer/committer 的流程详见 SIG 治理章程。章程规定Maintainer 变更需及时知会技术指导委员会并更新 SIG 组织信息和相关权限若 Maintainer 发生变动需及时通知技术指导委员会并更新相关信息。3.2 情况一maintainer 任免Fork 并修改ForkCANN/community仓库到个人账号修改 org-info.yamlorg-info.yaml编写指南和 SIGREADME.md里面的人员信息。提交 PR向CANN/community仓库的master分支提交 PR。通过审查并合入 PRPR 需要获得以下三个标签才能被合并cann-cla/yesCLA 协议检查。机器人会自动检查 commits 中的邮箱是否已签署 CLA 协议。若已签署将添加此标签若未签署会添加cann-cla/no标签并留言提示lgtm请联系org-info.yaml文件中列出的tsc_members进行评审。评审通过后由 tsc_member 评论/lgtm机器人会自动添加标签approved同样联系tsc_members进行批准。批准后由 tsc_member 评论/approve机器人会自动添加标签。3.3 情况二committer 任免Fork 并修改ForkCANN/community仓库修改目标 SIG 的 sig-info.yamlsig-info.yaml编写指南和 SIGREADME.md里面的人员信息。提交 PR向CANN/community仓库的master分支提交 PR。通过审查并合入 PRPR 需要获得以下三个标签才能被合并cann-cla/yesCLA 协议检查规则同上lgtm请联系sig-info.yaml中该 SIG 组的maintainers进行评审。评审通过后由 maintainer 评论/lgtmapproved同样联系该 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/yesCLA 协议检查规则同上lgtm请联系org-info.yaml中该 SIG 组的 maintainers 进行评审。评审通过后由 maintainer 评论/lgtmapproved联系该 SIG 组的 maintainers 进行批准。批准后由 maintainer 评论/approve。4权限回收PR 合入后SIG 组成员在 SIG 组对应的会议预定权限、代码合入权限等会被取消。4.3 第二步修改组织架构1Fork 并修改ForkCANN/community仓库修改 org-info.yamlorg-info.yaml编写指南删除该 SIG 组的定义。2提交 PR提交 PR 至master分支PR 描述中需要附加评审纪要。3通过审查并合入 PR此 PR 需获得cann-cla/yes、lgtm、approved三个标签需由 tsc_members 评论/lgtm和/approve后自动合入cann-cla/yesCLA 协议检查规则同上lgtm请联系org-info.yaml中 tsc_members 进行评审。评审通过后由 maintainer 评论/lgtmapproved联系 tsc_members 进行批准。批准后由 tsc_members 评论/approve。注意终止流程与创建流程的顺序相反创建时先改组织架构第一个 PR、再建 SIG 目录第二个 PR终止时先删 SIG 目录第一个 PR、再改组织架构第二个 PR以此保证权限回收与信息清理的先后一致性。五、PMC 成员变更5.1 变更流程PMC 变更流程详见 PMC 治理章程。5.2 权限配置Fork 并修改ForkCANN/community仓库到个人账号修改 CANN/PMC/pmc.yaml。提交 PR向CANN/community仓库的master分支提交 PR。通过审查并合入 PRPR 需要获得以下三个标签才能被合并cann-cla/yesCLA 协议检查。机器人会自动检查 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_listpmccann.osinfra.cn、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 权限配置Fork 并修改ForkCANN/community仓库到个人账号修改 CANN/TSC/tsc.yaml。提交 PR向CANN/community仓库的master分支提交 PR。通过审查并合入 PRPR 需要获得以下三个标签才能被合并cann-cla/yesCLA 协议检查。机器人会自动检查 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_listtsccann.osinfra.cn、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 例会纪要 URLcommitters列表一层SIG 组对应的 committer 名单repositories列表一层SIG 组所管辖的代码仓库信息权限体系中的两个关键角色角色字段权限范围审批者Committercommitters代码合并权限可覆盖到文件级分支守护者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: ops-basiccann.osinfra.cn # 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: ops-basiccann.osinfra.cn 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 目录/文件级entrycommitters。entry_configs中的path可以是目录、完整文件路径或通配符路径。注意通配符路径只支持*且使用通配符时必须加双引号否则会导致解析 sig-info 失败name: ops-basic description: This is a sample sig. mailing_list: ops-basiccann.osinfra.cn 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 分支级branchcommitters 与 branch_keeper。branch_configs将权限精确作用到指定分支name: ops-basic description: This is a sample sig. mailing_list: ops-basiccann.osinfra.cn 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 entrycommitters。这是最细粒度的组合场景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: ops-basiccann.osinfra.cn、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 成员变更都收敛为同一条标准化路径Fork 并修改对应配置文件新增/删除 SIG 改 CANN/org-info.yaml 与 CANN/sigs/sig_name/sig-info.yamlmaintainer 任免改 org-info.yaml SIG READMEcommitter 任免改 sig-info.yaml SIG READMEPMC 成员改 CANN/PMC/pmc.yamlTSC 成员改 CANN/TSC/tsc.yaml。提交 PR 至 master 分支PR 描述中附加评审纪要。等待三重标签cann-cla/yesCLA 检查机器人自动处理lgtm对应评审方评论/lgtmapproved对应评审方评论/approve标签齐全后自动合入。等待权限刷新权限每隔 1 小时刷新一次配置后耐心等待必要时在社区会议平台绑定 GitCode 账号获取会议创建权限。各变更类型的评审方对照如下变更类型修改文件评审/批准方新建 SIG组织架构CANN/org-info.yamltsc_members新建 SIG目录与 committerCANN/sigs/sig_name/sig-info.yaml该 SIG 组 maintainersmaintainer 任免CANN/org-info.yaml SIG READMEtsc_memberscommitter 任免CANN/sigs/sig_name/sig-info.yaml SIG README该 SIG 组 maintainersSIG 终止删除 SIG 目录 修改 CANN/org-info.yaml该 SIG 组 maintainers / tsc_membersPMC 成员变更CANN/PMC/pmc.yamlpmc_membersTSC 成员变更CANN/TSC/tsc.yamltsc_members本文全部流程均以 contributor/organization.md 为基准配套的章程性文件SIG 治理章程、PMC 治理章程、TSC 治理章程与配置文件编写指南org-info.yaml编写指南、sig-info.yaml编写指南均可在仓库内查阅开发者可据此完整落地社区组织管理操作。【免费下载链接】community本项目是CANN开源社区的核心管理仓库包含社区的治理章程、治理组织、通用操作指引及流程规范等基础信息项目地址: https://gitcode.com/cann/community创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考