Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

评审策略

团队成员有权合并来自其他贡献者在 https://github.com/rust-lang/reference 仓库中的更改。根据所做更改的类型,有不同的评审指南:

评审原则

评审者和作者在评审过程中应关注以下若干关键原则:

  • 可理解性:参考手册中的散文应该能被项目的大多数成员理解。贡献应假定读者熟悉参考手册的其余内容,但在可能的情况下,各章节应通过链接到相关内容来促进这种理解。
  • 可辩护性:当 lang-docs 团队合并对参考手册的更改时,他们同意为此后的内容负责。团队成员需要对辩护和解释参考手册内容的正确性感到有信心。在可能的情况下,对参考手册的更改应通过简明的示例来支持任何主张以验证其正确性。
  • 风格:不期望作者在起草对参考手册的新贡献时具备规范编写者的能力。只要主张是可理解和可辩护的,PR 可以以随意基调或作者的个人风格而不是参考手册的风格来撰写。团队成员将在评审中带来编辑经验,并在必要时在合并前修改措辞、组织结构、风格等以符合参考手册。

策略更改

对团队运作方式的重大更改(如对本文档的更改)应得到团队的一致同意,不得有阻止性反对意见。

对诸如风格强制执行之类的小修改,可以由一位团队成员评审后完成,只要有很高的信心认为任何团队成员不太可能反对(例如,将已在实践中使用的指南正式化)且更改可以轻松回滚。

有意义的内容添加或更改

在添加或更改参考手册中的内容时,评审者应与适当的专家协商以验证更改。如果评审者对更改的正确性有高度信心、评审者对该主题非常熟悉或相关专家已经是 PR 的作者或积极参与了 PR,则可能不需要这样做。何时进行协商由评审者自行做出良好判断。

内容应始终遵循本贡献者指南中的指南。

小内容更改

对于小内容更改 — 如小的清理、措辞修正或格式更正 — 维护者可以直接将修正推送到 PR 分支并合并,无需咨询作者或其他评审者。

工具更改

工具的小更改可以在一个团队成员的评审下进行。这包括 bug 修复、不太可能有反对意见的小添加以及已经讨论过的添加。

重大更改,如内容编写方式的更改或工具工作方式的重大更改,应由团队批准,不得有阻止性反对意见。

评审流程流程图

在评审 pull request 时,问自己以下问题:

提出的更改是否正确?

如果我们不确定且无法自己轻松验证,我们会询问知道答案的人。

这是否对语言做出了新的保证?

如果这将对语言做出新的保证,这需要经过 lang 团队的接受(除非 lang 团队已经在其他地方明确接受了此保证)。如果对这些有任何不确定,请咨询 @traviscross。

我们会自己将此添加到参考手册吗?

有很多 PR 可能是正确的,但当我们看到它们时,我们内心深处觉得这实在不是我们会费心自己去写的内容。我们不想仅仅因为一个 PR 摆在我们面前且不是明显错误就接受它。它应该明显增加价值。

这在编辑上是否合理?

有些 PR 试图过度“推销“语言,或试图解释得比需要的更多(或更少),或给出过多(或过少)的示例等。PR 应该与参考手册的整体风格相匹配。

这写得好吗?

有些 PR 是正确的但措辞生硬或有排版问题。如果更改很小,我们会直接在分支上添加提交来清理然后合并。

本策略尚未涵盖从相关团队获得最终批准的流程。