Committer 手册

本文档长期更新中，旨在为 committer 提供一些实用技巧。其中大部分是在开发过程中总结的经验教训。我们欢迎每一位 committer 为本文档做出贡献。有关提交和一般开发过程的概述，请参阅 TVM 社区指南。

社区优先

社区成员努力推动了项目的发展，使得这个项目看起来相当完美。当我们在做决定的时候，要时刻把社区放在第一位。以下是我们可以提出的一些示例问题：

• 我该如何鼓励新的贡献者更多地参与项目？
• 我可以帮其他 committer 节省时间吗？
• 我是否让社区的其他人参与设计提案？

公共档案原则

尽管类似面对面讨论这样的私人渠道有益于发展，但它们也限制了更广的社区参与。 Apache 的开发方式要求所有决策都要在公共渠道中实施，因为这些渠道被归档并可供所有人访问。因此，任何贡献者都可以通过浏览档案来跟上开发的步伐，并随时加入开发。

这一原则适用于所有贡献者，对 committer 来说尤其重要。下面是该原则的一些示例应用：

• 当从个人渠道获得与项目相关的问题时，鼓励新开一个论坛来讨论，这样的话社区中的其他人也可以受益。
• 在面对面讨论之后，将摘要发送到公共渠道（例如 RFC 或线程讨论）。

认领 pull request

下面是一些认领 pull request 的技巧。也可以查看 代码 Reviews。

• 将 PR 分配给自己，以便其他 committer 知道 PR 已被处理。
• 使用状态标签来标注当前状态。
• 检查是否需要发送 RFC。
• 如果贡献者没有请求 reviewer 去 review 自己的代码，请提示一下他。如果 PR 来自一个新的贡献者，提示他去请求 reviewer，并让他下次也这样做。
• 审核 review，要求 reviewer 明确批准。
• 将 PR 标记为已接受状态，并感谢贡献者/reviewer。
• merge PR

独立项目管理

在参与项目时，每个人都被假定戴上他们的 Apache committer 角色。也就是说，committers 应在项目活动中为项目的最佳利益而行事。从 committers 和您可能担任的其他角色中区分你的角色在是很重要的。

在项目参与的过程中，明确显示您所担任的角色对可能混淆的情况非常有帮助，特别是在您没有表明 committers 身份的情况下。有两个例子：

"[foo] 角色：[担任 foo 且不担任 commiter 时发消息]"。 "pache TVM 角色：[在担任 committer 时发消息]".

时间管理

committer 可以做很多事情，例如主持讨论、review pull request 和贡献代码。

在开源项目上工作会收获很多，但有时也会有点不知所措。一点时间管理可能有助于缓解这个问题。例如，一些 committer 一周内有一天是“社区日”，他们积极管理优秀的 PR，但在其余时间较少关注社区。

记住，只要能提供有价值的贡献就是有意义的，因此在为项目做贡献时可以慢慢来。

广泛合作

我们倾向于只与认识的人互动。然而，广泛的合作对于项目的成功是必要的。鼓励多为社区中不认识的人认领 PR，或请求他们 review 代码。