Committer 指南
这是一份不断完善的文档，旨在为 Committers 提供一些有用的技巧。其中大部分是在开发过程中吸取的教训。我们欢迎每位 Committer 为本文档做出贡献。有关 Committer 资格和一般开发流程的概述，请参阅 TVM 社区准则。
社区优先
社区的集体努力推动项目向前发展，并使项目对每个人都变得更好。当我们做出决策时，始终牢记社区会很有帮助。以下是一些我们可以提出的示例问题
我该如何鼓励新的贡献者更多地参与到项目中来？
我可以帮助我的 Committer 同事节省时间吗？
我是否让社区的其他成员能够参与设计提案？
公共存档原则
虽然面对面讨论等私有渠道对开发很有用，但它们也为更广泛的社区参与设置了障碍。Apache 的开发方式要求所有决策都在公共渠道中做出，这些渠道会被存档并对所有人开放。因此，任何贡献者都可以通过查看档案来跟上开发进度，并随时加入开发。
虽然此原则适用于每位贡献者，但对于 Committers 而言尤其重要。以下是此原则的一些示例应用
当从个人渠道收到与项目相关的问题时，鼓励对方在讨论论坛中开设公共主题，以便社区中的其他人可以从答案中受益。
在面对面讨论后，将摘要发送到公共渠道（作为 RFC 或讨论主题）。
独立项目管理
当每个人参与项目时，都应被视为戴着 Apache Committer 的帽子。也就是说，Committers 应该在项目活动的背景下，为了项目的最大利益而行动。在所有方面，区分您作为 Committer 和您可能拥有的任何其他角色的身份非常重要。
在项目参与的背景下，在可能引起混淆的情况下，说明您戴的是哪顶帽子可能会有所帮助，尤其是在您没有戴 Committer 帽子的情况下。以下是两个例子
“戴着 [foo] 帽子：[当担任 foo 角色而非 Committer 时的消息]”。
“戴着 Apache TVM 帽子：[当担任 Committer 时的消息]”。
引导 Pull Request
以下是一些引导 Pull Request 的技巧。您也可以查看代码审查。
将 PR 分配给自己，以便其他 Committers 知道该 PR 已经被处理。
使用状态标签来指示当前状态。
检查是否需要发送 RFC。
如果贡献者没有请求审阅者，请友善地要求贡献者这样做。如果 PR 来自新的贡献者，请帮助贡献者请求审阅者，并要求贡献者下次也这样做。
审核评论，要求审阅者明确批准。
将 PR 标记为已接受，并感谢贡献者/审阅者。
合并 PR :)
时间管理
Committer 可以做很多事情，例如主持讨论、Pull Request 审查和代码贡献。
参与开源项目可能很有意义，但有时也会让人感到有些不知所措。一点时间管理可能有助于缓解这个问题。例如，一些 Committers 每周有一天“社区日”，他们在这一天积极管理待处理的 PR，但在其余时间较少关注社区。
请记住，您的功劳永远不会消失，因此在为项目做贡献时，请放慢节奏，慢慢来 :)
广泛协作
有时，我们倾向于只与我们认识的人互动。然而，广泛的协作对于项目的成功是必要的。请记住这一点，为那些您不经常接触的社区成员引导 PR 并请求代码审查。