跳到主要内容

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

时间管理

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

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

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

广泛合作

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