企业官网建设流程全解析

• 编译器
• 深度学习
• 模型优化

本篇技术指南围绕 Apache TVM 开源项目（tvm）的 Committer 职责展开，系统讲解社区优先、公开归档、独立项目管理三大治理原则，并逐步拆解引导（Shepherd）一个 Pull Request 的完整流程、时间管理与广泛协作的实践经验。读者将掌握 TVM 社区中 Committer 的标准工作流：从认领 PR、指派审查者、主持评审到达成共识后合入代码，并理解背后的 Apache 治理模型与仓库中的 CI 自动化工具是如何支撑这一流程的。

文档定位与背景

Committer Guide 是 Apache TVM 贡献指南体系中的一份"演进中"（evolving）的文档，其定位是面向已拥有仓库写权限的 Committer 提供实战建议。文档开篇即说明：其中大部分内容来自项目开发过程中的经验教训（lessons learned），并欢迎每位 Committer 共同补充。

整个贡献指南体系还包括：

• 社区指南：阐述 TVM 采用的 Apache 治理模型、committership 与总体开发流程；
• 代码审查指南：代码评审的 F0–F4 质量因素与共识构建方法；
• 代码规范与技巧：C++/Python 代码风格与常见实现技巧；
• 提交 Pull Request：面向贡献者的提交流程与检查清单。

本指南可以视为上述文档中"角色职责"层面的具体操作手册：社区指南定义"谁是 Committer"，而本文档回答"Committer 应该怎么做"。

Community First：以社区利益为先

文档提出的第一原则是Community First（社区优先）。TVM 依靠集体的力量推进项目，因此在做任何决策时都应把社区放在心中。文档给出了三个可以随时自省的问题：

• 如何鼓励新贡献者更多地参与项目？
• 能否帮助其他 Committer 节省时间？
• 是否让社区其他成员能够参与设计提案（design proposals）？

这一原则在仓库中有直接体现。CONTRIBUTORS.md 开篇即声明"TVM adopts the Apache way and governs by merit"，并主动邀请"earned the merit"的贡献者加入开发社区。更具体地说，社区指南 将"community involvement"列为识别潜在 Committer 的三大特质之一：活跃参与讨论论坛、通过教程/演讲/外展推广项目，并鼓励 Committer 与没有物理接触过的社区成员广泛协作（do code reviews and discuss designs with community members that they do not interact physically）。

Public Archive Principle：公开归档原则

文档强调，虽然私下讨论（如面对面交流）对开发有用，但它会为更广泛社区的参与制造壁垒。Apache 的开发方式要求所有决策在公开渠道进行，并且这些渠道需要可归档、人人可访问。这样任何贡献者都能通过查看归档跟上开发进度，随时加入讨论。

这一原则对 Committer 尤为重要，文档给出了两个具体应用场景：

• 当有人在私人渠道询问项目相关问题，鼓励对方在讨论论坛（discuss forum）中开一个公开帖，让其他社区成员也能从答案中受益；
• 在面对面讨论之后，向公开渠道发送一份总结（可以以 RFC 或讨论帖的形式）。

TVM 的治理体系正是围绕"公开可归档渠道"构建的：社区指南 明确指出，社区鼓励使用 issues、discuss forum 和 mailing-list 等公开、可归档的渠道进行讨论，"so that everyone in the community can participate and review the process later"。重大变更提案（RFC）也必须在公开渠道发布以供社区讨论。

Independent Project Management：独立项目管理

Apache 治理模型有一条关键假设：每个人在参与项目活动时都被视为戴着"Apache Committer 帽子"。即 Committer 在项目语境下应代表项目的最佳利益行事，并严格区分 Committer 身份与其他任何角色。

文档特别建议：在可能引起混淆的场合，主动声明自己戴的是哪顶帽子（hat），尤其是当自己并未戴着 Committer 帽子时。文档给出了两个示例格式：

• Wearing [foo] hat: [message when serving as foo's role and not as committer]（戴着 [foo] 角色的帽子，而非 Committer 身份发言）
• Wearing Apache TVM hat: [messages when serving as committer]（戴着 Apache TVM 的帽子，以 Committer 身份发言）

Shepherd a Pull Request：引导一个 PR 的完整流程

文档用一组清单式的操作步骤给出了引导（shepherd）PR 的标准流程，这是 Committer 日常工作中最高频的职责。完整的步骤链如下：

1. 将 PR 指派给自己（Assign the PR to yourself），让其他 Committer 知道该 PR 已经有人照看，避免重复认领；
2. 使用状态标签（status label）标明当前状态；
3. 检查是否需要发送 RFC；
4. 确认贡献者是否已请求审查者：若未请求，礼貌地请贡献者自行请求；对于新贡献者，帮其请求审查者，并提醒其下次自行操作；
5. 主持评审过程（Moderate the reviews），请审查者明确地 approve；
6. 将 PR 标记为 accepted，并致谢贡献者与审查者；
7. 合入 PR（Merge the PR）。

关于第 4 步与第 5 步，文档进一步指向代码审查指南，该指南详细规定了评审过程中的具体做法。

引导 PR 背后的自动化支撑

仓库中的 CI 工具链为上述流程提供了自动化支撑，可以从源码层面印证"认领—请求审查—等待—合入"的闭环是如何实现的：

• 审查者自动识别：github_cc_reviewers.py 中的find_reviewers()函数用正则r"(cc( @[-A-Za-z0-9]+)+)"解析 PR 描述中的cc @username语法，将 @ 提及的社区成员自动添加为 PR 的 Reviewers（脚本注释写明 "Add @cc'ed people in a PR body as reviewers"）。这正对应文档中"帮助贡献者请求审查者"的环节——贡献者只需在 PR 描述中写cc @reviewer即可完成请求。
• 自动催办机制：ping_reviewers.py 通过 GitHub GraphQL API 查询所有处于 OPEN 状态的 PR，check_pr()函数逐一比较 PR、review、comment 的最新活动时间（createdAt/updatedAt/lastEditedAt/publishedAt），当time_since_last_action > wait_time（超过设定的等待时间）时，会构造一条 ping 消息提醒对应审查者。这对应代码审查指南中"Reviewers 应努力对请求了审查的 PR 及时反馈"的要求——代码审查指南明确指出："Automated tooling helps out in this regard, as PRs with no activity for a set amount of time will get a bot comment pinging the relevant parties."
• 欢迎与引导机器人：github_tvmbot.py 中定义了一条对每个新 PR 自动发布的感谢与引导消息（THANKS_MESSAGE），提示贡献者参考贡献指南并在 PR 线程中请求 [Reviewers] 的代码审查。这正体现了文档第 4 步"对于新贡献者，帮其请求审查者"的社区自动化实践。

审查者角色与"显式审批"

社区指南 定义了两类相关角色：

• Committers：被授予项目写权限的个人，通常负责一个或多个代码领域，并监管该领域的代码审查流程；
• Reviewers：积极贡献并愿意参与新贡献代码审查的个人，由活跃贡献者中识别产生。一个 PR 必须经过至少一位 reviewer 审查才能合入。

代码审查指南 进一步明确了"显式审批"的操作方式：当你的评论得到回应后，请记住在 PR 的 changes 标签页中点击approve（或在代码上评论并选择request changes）。若部分 reviewer 在一段时间内（如一周）未响应，且已有审查足够充分，代码所有者（code owner）可以按个案判断是否合入。

Time Management：Committer 的时间管理

Committer 能做的事情很多：主持讨论、PR 审查、代码贡献等。做开源项目既有回报也容易让人应接不暇，因此文档建议适当的时间管理策略。文档给出的示例做法是：一些 Committer 每周设定一个"社区日"（community day），在这一天集中处理积压的 PR，而其余时间则降低社区关注频率。

文档特别强调了一句暖心的提醒：你的 merit（贡献积累）永远不会消失，所以在为项目做贡献时请放慢节奏、找到自己的步调。

Broad Collaboration：广泛协作

一个值得注意的倾向是：人们往往只与自己认识的人互动。但文档指出，广泛的协作是项目成功所必需的。具体到实践层面，Committer 应当：

• 为平时没有物理接触的社区成员引导 PR（shepherd PRs for...community members who you do not interact physically）；
• 向这些成员请求代码审查（request code reviews from...）。

社区指南 同样强调"鼓励 Committer 广泛协作"，并进一步规定PMC（Project Management Committee）在提名新成员时应力求提名自己组织之外的候选人（"PMCs should strive to only nominate new candidates outside of their own organization"），这是避免项目被单一组织主导的制度性保障。

与代码审查及代码规范体系的衔接

Committer 引导 PR 时，其评审标准由配套文档约束。这三份文档共同构成 TVM 的质量保障体系：

代码审查的 F0–F4 质量因素

代码审查指南 定义了审查代码质量时应考虑的五个因素（F0–F4），其中架构相关因素被认为最重要，因为架构决策最容易积累长期技术债：

测试覆盖与 API 文档是代码贡献的硬性期望；代码可读性相对主观，审查者应给出建设性、可执行的评论，而不是要求别人完全按自己的方式写代码。

共识构建与换位思考

代码审查指南 还提出了与 Committer 引导流程直接相关的"共识构建"（Consensus Building）原则：

• 通过建设性的、基于技术事实的对话保持文明并构建共识；
• 拥有该领域所有权的 Committer 可以充当 shepherd，综合所有讨论并建议一个可推进的解决方案；
• 由于合入（merge）涉及大量信任，shepherd 应在签字前仔细阅读 PR，并在合入引发问题时负责跟进；
• 合入涉及重大架构变更的 PR 前，应等待一段时间（例如三天），给社区成员表达意见和参与审查的机会。

此外还有"一致性"提醒：我们都是人，很难做到完美一致。如果贡献者认为准则应用得不一致，Committer 应当倾听并坦诚面对——流程与准则需要随社区演进不断迭代。

代码规范与合入门槛

代码规范与技巧 规定 TVM 采用 Google C/C++ 风格，公共函数用 doxygen 格式文档化，Python 代码用 numpydoc 格式并使用python 3.7语言特性。风格由clang-format强制执行，可通过 Docker 运行：

# 用 clang-format 检查某个文件 docker/bash.sh ci_lint clang-format-10 [path-to-file] # 运行全部 lint（含 clang-format） python tests/scripts/ci.py lint

提交 Pull Request 则规定了贡献者侧的要求：提交前基于最新main分支 rebase（git fetch upstream && git rebase upstream/main）、通过 lint 检查等。Committer 在合入前应确认这些门槛均已满足——这些要求与代码审查指南中"架构一致性、测试覆盖、API 文档"的期望一脉相承。

治理层级与角色晋升（补充上下文）

为完整理解 Committer 的职责边界，社区指南 补充了治理层级的关键规则：

• 战略决策需要 binding votes 的lazy 2/3 多数（至少 3 票 +1，且 +1 票数两倍于 -1 票数），适用于：采用指导级社区战略、建立新模块、采用新代码库（或创建新的子项目）等重大决策；
• PMC 由活跃 Committer 组成，负责主持讨论、管理发布、提名新 Committer/PMC 成员。候选人通常先经 PMC 内部讨论，再经共识批准（至少 3 个 +1 且无否决；任何否决必须附带理由）。

新贡献者成长为 Committer 的路径（社区指南 列出的识别特质）包括：对 RFC、代码审查、新特性提案的持续贡献；高质量的、无需大量返工即可合入的代码与良好测试；以及论坛等渠道的社区参与。

实践清单：从零开始担任 Shepherd

综合本文档与配套文档，一次完整的 PR 引导（shepherding）会话可以归纳为以下可执行清单：

1. 认领：将 PR assign 给自己，打上状态标签；
2. 审视范围：确认 PR 是否聚焦（避免多个无关改动合入一个 PR），是否需要 RFC，是否涉及重大架构变更（如是，考虑等待约三天再合入）；
3. 确保审查者：确认 PR 是否已有 reviewer；若是新贡献者，帮助其在 PR 描述中以cc @username或直接请求 Reviewers 的方式添加审查者；
4. 主持评审：鼓励审查者显式 approve 或 request changes，综合各方意见推动共识；关注 F0–F4 质量因素，确认 lint（python tests/scripts/ci.py lint）、测试覆盖与 API 文档达标；
5. 收尾：将 PR 标记为 accepted，向贡献者与审查者致谢，然后合入；
6. 复盘：若合并后发现回归，合入者负责跟进；若在评审中总结出可复用的经验，可补充到代码规范与技巧中供社区共享。

结语

Apache TVM 的 Committer 指南虽然篇幅精炼，却浓缩了 Apache 开源治理的核心理念：公开决策、社区优先、角色分明、广泛协作。而仓库中的 github_cc_reviewers.py、ping_reviewers.py、github_tvmbot.py 等自动化脚本，以及 CONTRIBUTORS.md 中按领域标注的 Committer 名录，为这套治理原则提供了可运行的工程化支撑——文档描述"应该怎么做"，CI 工具链则让"自动做到"成为可能。对于任何想深入了解或参与 Apache TVM 社区的开发者，从阅读社区指南与代码审查指南开始，是进入这一协作体系的最佳起点。

• 编译器
• 深度学习
• 模型优化