企业官网建设流程全解析

• 嵌入式
• 物联网
• 机器人
• 自动驾驶
• 智能硬件

PX4 自动驾驶仪（PX4-Autopilot）由 Dronecode 基金会旗下的维护者团队提供技术领导。本文基于 docs/en/contribute/maintainers.md 完整解读 PX4 的维护者角色体系，结合仓库中的 MAINTAINERS.md、每周开发者会议说明 以及.github/workflows下的自动化工作流，系统说明 Code Owner 与 Reviewer 的职责差异、申请与投票流程、新增维护者的 PR 落地方式以及入职后的权限配置。读完本文，你将清楚"谁在维护 PX4""如何成为维护者""成为维护者后需要承担什么"以及"仓库中哪些文件与自动化机制支撑着这套治理体系"。

维护者角色概述：Dronecode 生态中的技术领导

PX4 的维护者由 Dronecode 基金会组织定义与监督，他们不仅为 PX4 提供技术领导，也覆盖 MAVLink、MAVSDK、QGroundControl 等生态组件。从仓库的 MAINTAINERS.md 可见，维护者名单以表格形式维护在仓库根目录，包含Code Owners（按领域划分）、Reviewers、Documentation Maintainers（文档维护者）、Release Managers（发布经理）、Security（安全处理人）以及Retired Maintainers（退休维护者）等多个分类，是整个项目治理的"活的"数据源。

所有维护者均为 GitHubDev Team团队成员，拥有仓库写权限，并参与维护者的集体决策。

两种维护者类型：Code Owner 与 Reviewer

PX4 明确区分两种维护者，二者都是维护者团队的全职成员，都通过 GitHubDev Team拥有写权限，并同等参与维护者决策。

Code Owner：某个具体领域的负责人

Code Owner 对项目的某个特定类别负责，例如状态估计（State Estimation）、多旋翼（Multirotor）或 CI。其核心特征包括：

• 对自身领域内的变更有最终发言权；
• 是该领域代码的主要评审者；
• 参与塑造该领域的路线图。

以仓库 MAINTAINERS.md 当前列出的 Code Owners 为例，可以看到领域划分粒度相当细致：

值得注意的是，同一领域可以有多个 Code Owner 共同负责（例如状态估计领域在名单中就有两位维护者），这也体现了大领域需要多维护者协作的现实。

Reviewer：跨项目协助的维护者

Reviewer 不拥有任何特定类别，而是跨项目帮助维护 PX4：在自己感兴趣的领域和时间内进行评审、分流（triage）和贡献。他们与 Code Owner 拥有相同的访问权和投票权，只是不对代码库的任何特定领域承担"随叫随到"（on-call）的职责。

Reviewer 角色非常适合那些想帮助项目但暂时不想承诺固定组件的贡献者。从源码结构看，MAINTAINERS.md 中的 Reviewers 表格独立于 Code Owners 表格单独维护，正是为了让两类角色的名单边界清晰可查。

角色演进

Reviewer 可以在与现有 Code Owner 协商一致并获得维护者团队认可后，转为某个具体领域的 Code Owner——这一转变与正式招募遵循相同的周会讨论与投票流程。

招募流程：申请与提名步骤

如果希望加入 PX4 维护者团队，或者提名他人，请按以下步骤进行（对应原文档的 Recruitment Process）：

1. 阅读角色描述：先通读下文"Dronecode 维护者角色描述"一节，确认自己理解该角色的责任；
2. 联系维护者获得赞助：自荐者需要联系 MAINTAINERS.md 名单中的任意一位现任维护者，寻求对方的赞助（sponsorship）；
3. 表明申请意向：明确说明自己是申请Code Owner（针对某个具体类别）还是Reviewer（跨项目协助，无固定类别）；
4. 周会讨论与投票：赞助维护者需要在每周开发者会议上提出该申请，维护者团队在会上投票决定是否接纳。

Reviewer 转为某领域 Code Owner 的流程同理：需要获得该领域现有 Code Owner 的同意，并在周会上经维护者团队讨论与投票通过。

新增维护者的落地方式：PR 流程

一旦维护者团队同意接纳新维护者，变更将通过一个刻意保持简单的流程落地——向 MAINTAINERS.md 提交拉取请求（PR）：

1. 由一名现任维护者发起 PR，将新维护者加入对应表格（Code Owners表填写类别，或Reviewers表）；
2. PR 必须获得至少一位其他现任维护者的批准；
3. 如果新维护者是以某具体组件的 Code Owner 或子所有者身份加入，则该组件现有 Code Owner 必须出现在审批人之中。

这个 PR 门槛与仓库的协作规范一致：根目录的 .github/PULL_REQUEST_TEMPLATE.md 要求 PR 说明解决的问题（关联 GitHub Issue）、解决方案、Changelog 条目、备选方案与测试覆盖，保障了包括治理变更在内的所有改动都有清晰的可追溯上下文。

PR 合并后，新维护者进入下面的上岗流程。

上岗流程（Onboarding Process）

每位被接纳的维护者都会经历如下三步上岗流程：

1. Discord 权限：Discord 服务器管理员会授予dev team角色，带来：
   • Discord 上的基础管理权限；
   • 进入内部维护者讨论专用的私密#maintainers频道；
2. GitHub 团队权限：获得 GitHubDev Team团队访问权，进而拥有：
   • 在 PX4 工作区任意仓库的 PR 通过审批后执行合并的权限；
   • 当新贡献者打开 PR 时触发 GitHub Actions 的权限；
   • 编辑 Issue/PR 内容的权限；
3. 官方渠道登记：
   • 将个人信息加入 Dronecode 内部维护者数据库以保持同步；
   • 以论坛帖子的形式向社区介绍新维护者，并通过日益增长的官方渠道推广。

Dronecode 维护者角色描述

本节详细描述Code Owner角色的职责与资质；Reviewer秉持同样的技术守护（stewardship）、社区引导与参会精神，只是不绑定特定类别。

职责（Code Owner）

1. 负责其类别（category）内的开发监管；
2. 为社区成员提供其类别内的指导与建议；
3. 在 GitHub 上评审社区提交的相关 PR 与 Issue；
4. 与维护者群体协调；
5. 保持对每周会议的定期出席；
6. 帮助创建并维护所代表项目的路线图；
7. 维护社区的行为准则（Code of Conduct）。

职责（Reviewer）

1. 在其专业适用的范围内评审跨项目的 PR 与 Issue；
2. 协助分流 Issue 并引导社区贡献者；
3. 与维护者群体协调；
4. 保持对每周会议的定期出席；
5. 维护社区的行为准则。

资质要求

1. 有扎实的贡献记录（proven track record of valuable contributions）；
2. 具备类别领域的领域专长（Code Owner）或对项目的广泛工作知识（Reviewer）；
3. 对申请的项目有良好的整体认知；
4. 如适用，需要获得雇主的批准。

福利

1. 官方认可：在 Dronecode/PX4 网站、文档、社区与社交媒体上获得维护者身份认证；
2. GitHub 与 Discord 特权（见上文上岗流程）；
3. 每年PX4 Developer Summit奖学金的优先名额，可用于差旅报销。

Dronecode 提供的辅助工具

Dronecode 会为维护者提供以下支持：

1. 社区调查（Community survey）：当需要了解社区意见时，通过社交媒体帖子、邮件列表、Discord 公告等方式收集反馈；
2. 工作流自动化（Workflow automation）：提供 PR/Issue 评审与打标签流程的自动化工作流。

仓库中的维护者生态：治理的工程化支撑

维护者治理并非只停留在文档层面，当前仓库从名单、会议到自动化都有对应的工程化落地，可以作为深入研究的入口。

维护者名单：MAINTAINERS.md

MAINTAINERS.md 是维护者名单的唯一事实来源（source of truth），其结构分为多个表格：Code Owners（含姓名、领域、GitHub、聊天账号、邮箱）、Reviewers、Documentation Maintainers、Release Managers、Security 与 Retired Maintainers。它还特别注明安全报告的分流与修复协调遵循 SECURITY.md 的流程——这一点与维护者体系中的 Security 角色一一对应。

每周开发者会议：dev_call

原文档多次提到的每周开发者会议（官方名称为 Weekly Community Q&A Call，曾用名 Dev Call）是维护者决策的核心场合：

• 与会者包括 Code Owners、Reviewers、测试团队负责人、Dronecode 成员以及全体社区成员；
• 会议前一周会在论坛发布议程帖，任何社区成员都可以在会前回复会议纪要来添加讨论主题；
• 会议时间为每周三 17:00（CET）。

该会议在仓库中还有自动化支撑：.github/workflows/dev_call_post.yml 通过 GitHub Actions 定时（每周一 10:00 UTC）调用 Tools/ci/dev_call_post.py，自动汇总近 7 天合并的 PR、新 Issue 与 Bug 并生成会议议程发布到论坛，同时支持dry_run与lookback_days输入参数——这正是文档所说"工作流自动化"的真实落地。

评审自动化：PR 评论与评审机器人

维护者的日常评审工作同样有工具链辅助：

• Tools/ci/pr-comment-poster.py 用于在 PR 上发布置顶式（sticky）评论；
• Tools/ci/pr-review-poster.py 则在 "Files changed" 标签页发布按行锚定的评审意见，供 clang-tidy 等工具标记具体代码行；该脚本明确规定机器人不得执行APPROVE或REQUEST_CHANGES事件，审批始终由人工维护者完成，从工程层面保障了治理规则的严肃性。

这些脚本由 .github/workflows/pr-review-poster.yml 等工作流触发，与"维护者是主要评审者"的角色定位直接呼应。

Issue 分流与标签

维护者的"协助分流 Issue"职责也有自动化配合：.github/labeler.yml 与 .github/workflows/issue_triage_label.yml 负责对 Issue/PR 自动打标签，帮助维护者快速识别领域归属，将问题分流给对应的 Code Owner。

常见问题与联系渠道

• 关于维护者角色的问题：请联系维护者团队（Point of Contact）；
• 想了解每周会议议程或加入讨论：参见每周开发者会议说明；
• 发现安全问题时如何上报：遵循 SECURITY.md 中描述的分流与协调流程；
• 想为社区做贡献但尚未达到维护者门槛：先通过常规贡献建立记录，维护者体系中的 Reviewer 角色正是为这类贡献者设计的渐进式入口。

总结

PX4 的维护者体系是一套"文档定义角色、名单作为事实源、周会承载决策、CI 自动化赋能"的完整治理闭环：Code Owner 深耕领域、Reviewer 跨界协助，招募与上岗流程清晰可操作，而 MAINTAINERS.md、每周开发者会议文档 与 .github/workflows 下的自动化脚本共同保证了这套体系在开源协作中的持续运转。对于希望深度参与 PX4 的开发者，理解这套角色与流程既是加入团队的路线图，也是理解项目决策机制的钥匙。

• 嵌入式
• 物联网
• 机器人
• 自动驾驶
• 智能硬件