TSC 项目角色
项目角色
您可以以 贡献者 、 协作者 或 维护者 的身份参与 Zephyr 项目。
贡献者 ：向项目贡献代码、文档或其他资源的任何社区成员。
协作者 ：参与项目一个或多个领域的活跃贡献者。
维护者 ：负责项目中特定领域或子系统的牵头协作者。维护者还会根据需要，在技术指导委员会（TSC）中担任其所负责领域的代表。
此处的领域是指 Zephyr 项目代码库中的特定子系统、组件或模块。例如，网络、文件系统、设备驱动程序、架构支持以及开发板支持包（开发板和 SoC 定义）等。
项目中的每个领域应至少有一名维护者，也可以有多名协作者。根据领域的规模和复杂程度，也可以有多名维护者，但维护者人数应保持在实际所需的最低限度，以确保有效管理和决策。
Contributor
贡献者 是希望在任何层面为项目作出贡献的开发者。
贡献者拥有以下权利并承担以下责任：
有权贡献代码、文档、翻译、美术作品等。
有权报告缺陷（bug）并提出改进建议。
有权参与评审他人的贡献。
有权参与功能开发过程。
有责任遵守已作出的决定。欢迎提供新的相关信息，以便重新讨论这些决定。
有责任处理自身贡献引入的问题和 bug。
有责任遵守社区规则。
有责任在参与讨论和贡献评审时提供建设性意见。
有责任遵守项目的行为准则（https://github.com/zephyrproject-rtos/zephyr/blob/main/CODE_OF_CONDUCT.md）
Zephyr 贡献者徽章
当您对 Zephyr 项目的首次贡献被合并后，您便有资格申领 Zephyr 贡献者徽章。此数字徽章可展示在您的网站、博客、社交媒体个人资料等位置，用于展示您对 Zephyr 项目的参与，并帮助提升项目的知名度。
您可以填写 Zephyr Contributor Badge form 来申请贡献者徽章。
Collaborator
协作者 是同时参与 Zephyr 源代码维护的贡献者。决策完全以实际贡献为依据，因此协作者的意见在决策时具有更高的权重。
持续参与项目即可成为协作者，包括在一段时间内为项目作出重要贡献，以及参与至少一个领域的开发和评审。
如需申请成为协作者，请提交一个拉取请求，将自己添加到 MAINTAINERS 文件 中某个领域的 collaborators 部分，并通知该领域的维护者。此项添加需要获得该领域维护者的批准。
除贡献者的权利和责任外，协作者还拥有以下权利并承担以下责任：
有权与所维护领域的维护者一起，参与制定该领域的短期和中期目标。
有责任参与功能开发过程。
有责任在合理时间内审查相关代码变更。
有责任确保代码质量达到预期水平。
有责任参与社区讨论。
有责任在适当时指导新贡献者
有责任在开展质量验证和发布工作时参与其中。
协作者在拉取请求中提出的修改要求应由原提交者处理。如果修改要求不符合 预期要求 和项目指南，或存在分歧，则由受指派人负责推进审查流程并解决分歧。
协作者对拉取请求的批准计入合并 PR 所需的最低批准数。合并时可能还需满足其他条件。
Maintainer
维护者 是一种协作者，还负责了解、引导和预判 Zephyr 源代码特定领域的需求。
个人可以通过长期持续作出有意义的贡献，成为某个领域的维护者。这包括：
为该领域作出重要的技术贡献。
积极参与开发流程，包括代码审查和设计讨论。
熟悉该领域的架构、约束和演进。
当原作者向项目引入新的领域或子系统，并展现出公认的专业能力以及对该领域的长期投入时，也可以被授予维护者身份。
无论何种情况，维护者身份都意味着承担技术责任，并持续参与支持该领域的社区活动。
要申请成为维护者，请提交一个拉取请求，将自己添加到 MAINTAINERS 文件 中相应领域的 maintainers 部分，并通知该领域的现有维护者。此项添加需要获得该领域维护者的批准。
通常只有一名维护者，但根据领域的具体情况，也可能由多名维护者共同承担责任。
除了贡献者和协作者所享有的权利及承担的责任外，维护者还具有以下权利和责任：
有权确定相关子系统或所参与领域的总体架构。
有权与协作者和提交者共同就相关子系统或所参与领域作出决策。参见 PR 技术升级 。
有责任向 TSC 传达相关子系统或领域的发展方向
有责任确保项目的所有贡献都在合理时间内得到审查。
有责任落实行为准则。作为社区的领导者，维护者应以身作则，遵守项目的行为准则，并为所有人营造友好、包容的环境。
有责任对其代码领域中的静态分析问题进行分类和优先级评估。参见 静态代码分析 。
维护者对拉取请求的批准计入合并 PR 所需的最低批准数。合并时可能还需满足其他条件。
团队与支持活动
受指派人
受指派人 是拉取请求所修改领域的维护者之一。
系统会根据所修改的代码自动设置受指派人。如果无法自动设置，或另有更合适的受指派人，其他维护者或发布工程团队可以设置受指派人。在后一种情况下，需要在评论中说明更换原因。
静态分析审计团队
静态分析审计团队与发布工程团队密切合作，确保在发布周期内报告的静态分析缺陷得到妥善处理。该团队具有以下权利和职责：
有权撤销静态分析工具（例如 Coverity）中任何不符合项目预期要求的问题分诊结果。
有责任将不当分类告知代码负责人。
如果任何问题未得到相应代码负责人的妥善处理，有责任向 TSC 报告。
加入静态分析审计团队
深入参与项目并具备一定静态分析专业知识的贡献者。
发布工程团队
由参与多个领域的活跃维护者组成的团队。
发布工程团队成员应按照既定的轮换周期和遴选流程担任发布经理。
轮换周期和遴选流程由发布工程团队制定，并由 TSC 批准。
该团队直接向 TSC 汇报。
发布工程团队具有以下权利和职责：
有权按照项目规则将代码变更合并到 zephyr 代码树。
有权回退任何导致代码库无法正常工作的变更
有权关闭任何连续 <N> 个月无活动的搁置变更
有责任接受并遵循 TSC 的指示。
有责任与维护者协调代码合并。
有责任合并所有已获相应维护者批准且符合变更合并标准的贡献，无论其来源和所属领域。
有责任确保 Zephyr 代码库保持可正常工作且通过 CI 检查的状态
加入发布工程团队
深入参与项目的维护者可由一名具有投票权的 TSC 成员提名加入发布工程团队。被提名者经现有具有投票权的 TSC 成员批准后，即可成为该团队成员。
为确保发布工程团队正常运作，TSC 应定期审查团队所遵循的流程、团队规模是否适当以及成员构成（例如，确保团队成员分布在多个地理位置和时区）。
发布经理
负责按照项目为某个特定版本制定的里程碑和路线图，推动该版本发布工作直至完成的 维护者 。
发布经理必须获得 TSC 批准。
发布经理是发布工程团队的成员，除以下权利和职责外，还拥有该团队的权利并承担相应职责：
有权管理和协调代码冻结里程碑（M3，参见 项目管理概述 ）之后的所有代码合并。
负责推动和协调本次发布的问题分诊流程
负责编写本次发布的发行说明
负责及时向项目的所有利益相关方（包括整个社区）通报发布状态。
负责与质量保证（QA）和验证团队协调，并在重大变更和重要里程碑之前，直接或通过 QA 验证变更。
角色 / 权限
Admin |
Merge Rights |
成员 |
所有者 |
协作者 |
||
主要角色 |
贡献者 |
x |
||||
协作者 |
x |
|||||
维护者 |
x |
|||||
支持角色 |
质量保证/验证 |
x |
x |
|||
DevOps |
x |
|||||
系统管理员 |
x |
x |
||||
发布工程 |
x |
x |
角色卸任
经 TSC 或 TSC 代表批准担任项目角色的人员，如果不再积极行使该角色的权利并履行相应职责，TSC 可以要求其卸任。
不再活跃的维护者或协作者卸任时，应从 Zephyr 仓库的 MAINTAINERS 文件 相关部分中移除其 GitHub 用户名。卸任可由 TSC、TSC 代表或本人发起。维护者也可以发起移除其负责领域内不再活跃的协作者。
维护者可以对卸任要求提出异议，并请求 TSC 作出决定。
MAINTAINERS 文件
以下准则适用于 MAINTAINERS 文件的结构、范围和维护。
根据《Zephyr 项目章程》，MAINTAINERS 文件应有指定人员负责其准确性、结构和日常维护。这些人员应由 TSC 任命。
维护职责的划分粒度应保持合理，便于管理。
TSC 应与现有维护者和贡献者合作，积极发掘并鼓励贡献者担任代码库中无人维护领域的维护者，并推动为这些组件指派维护者。
无人维护的领域必须在 MAINTAINERS 文件中明确标记为无人维护。
对 MAINTAINERS 文件的更新应遵循以下要求：
引入新文件或目录时，通常应将此类更新作为独立提交。
重大变更（包括新增领域和维护者）应通过单独的拉取请求提交，并须经 MAINTAINERS 文件的维护者批准。此类变更可能源于将现有的大型领域拆分为较小领域，或将较小领域合并。
为代码库的不同领域分配维护者的指南：
- 架构、核心组件、子系统、示例和测试：
每个领域都必须明确指定维护者。
- 开发板（包括相关示例和测试）和 SoC（包括 DTS 定义）
每个开发板和 SoC 都应通过涵盖开发板、SoC 及其相关组件和驱动的平台领域，明确指定维护者。
- 驱动 / 后端
API 层面的领域必须有维护者，具体的驱动实现或后端也必须纳入涵盖相应驱动实现的平台领域。驱动实例或后端发生变更时，应指派驱动领域或子系统的维护者负责。