• 简介
• 评审意见中应包含的内容
• 结果
• 评审经理须知
• 库提交者须知
• 库维护者的权利和责任
• 评审向导
• 快速通道评审

简介

提议的库只有在经过正式评审后才能被 Boost 接受，Boost 邮件列表成员会在评审中评论他们对库的评估。

最终的“接受”或“拒绝”决定由评审经理根据从 Boost 邮件列表成员收到的评审意见做出。

鼓励 Boost 邮件列表成员提交正式评审意见

• 公开在邮件列表上。
• 私下发给评审经理。

给库提交者的私人评论可能对他们有所帮助，但无助于评审经理做出决定，因此首选其他形式。

评审期通常持续 10 天。

评审意见中应包含的内容

您的评论可以是简短的或冗长的，但评审经理需要您对库的评估。如果您在过程中发现问题，请注明它们是次要的、严重的还是阻碍性的。

Boost 库评审的目标是通过建设性的批评来改进库，最终必须做出决定：该库目前是否足够好以被 Boost 接受？ 如果不是，我们希望提供足够的建设性批评，以便在稍后进行改进并被接受。 Serialization 库就是一个很好的例子，说明建设性批评如何促成修订，从而产生一个优秀的库，并在第二次评审中被接受。

以下是您可能希望在评审中回答的一些问题

• 您对设计的评估是什么？
• 您对实现的评估是什么？
• 您对文档的评估是什么？
• 您对库的潜在实用性的评估是什么？
• 您是否尝试使用该库？ 使用什么编译器？ 您遇到任何问题吗？
• 您在评估中投入了多少精力？ 匆匆一瞥？ 快速阅读？ 深入研究？
• 您是否熟悉问题领域？

最后，每个评审都应回答这个问题

• 您认为该库应该被接受为 Boost 库吗？ 请务必明确说明这一点，以便您的其他评论不会掩盖您的总体意见。

许多评审都包含针对库作者的问题。 作者有兴趣为他们的库辩护，反驳您的批评； 否则，他们就不会将他们的库提交评审。 如果您没有很快收到对您问题的回复，请耐心等待； 如果时间太长或者您没有得到您认为足够的答案，请再次询问或尝试改写问题。 请记住，英语不是许多 Boost 用户的母语，这可能会导致误解。

电子邮件是一种糟糕的沟通媒介，即使邮件很少在传输过程中丢失，它们也经常淹没在其他邮件的洪流中。 不要认为未回复的邮件意味着您被忽略了。 建设性地提出批评会更容易被接受并产生更积极的影响，您也会得到您想要的答案。

结果

在评论期结束后的一段合理时间内，评审经理将向邮件列表发布消息，说明该库是被接受还是被拒绝。 理由也很有帮助，但其程度取决于评审经理。 如果有建议或在最终包含之前必须满足的条件，则应说明。 关于评审报告的及时性或质量的担忧应私下向评审向导提出。

评审经理须知

在可以安排库进行正式评审之前，必须有一位与库提交无关的活跃 Boost 成员自愿担任该库的“评审经理”。 成员可以联系库作者（在邮件列表上或私下）表达对管理评审的兴趣。 库作者必须接受某人作为评审经理。

评审经理

• 检查提交内容，以确保它真的足够完整，值得进行正式评审。 请参阅 Boost 库要求和指南。 如有必要，与提交者合作以验证代码在多个编译器和平台上可以正确编译和运行。
• 与 评审向导和提交者确定最终时间表。
• 在常规 boost 邮件列表 和 boost-announce 邮件列表 上发布评审时间表通知。
  • 通知应包括库的简要说明及其功能，以便读者了解该库是否是他们有兴趣评审的库。
  • 如果已知该库在某些编译器上会失败，请在评审通知中提及它们，以便使用这些编译器的评审员不会浪费时间诊断已知问题。
  • 建议在单独的电子邮件中将通知发送到每个邮件列表，否则在线电子邮件到新闻网关可能会感到困惑。
• 检查 Boost 库目录，查找可能与新提交内容交互的库。 这些潜在的交互应在评审公告中指出，并且应私下通知这些库的作者并敦促他们参与评审。
• 如果人们不积极参与评审，则敦促他们进行评审。
• 关注关于库的评审讨论，根据需要进行主持或回答问题。
• 如果评审期间提交的评审太少，则请求 评审向导 允许延长评审时间表。
• 确定是否就接受该库达成共识以及是否有任何附加条件。 共识与投票不同。 评审经理有权根据权威性或周全性来权衡意见。
• 在常规 boost 邮件列表、boost-users 邮件列表和 boost-announce 邮件列表上发布 评审结果 通知。

换句话说，评审经理有责任确保评审过程顺利进行。

尽管评审经理也被允许评审库，但他们应服务于 Boost 用户的利益。 由于评审经理可能对库有（强烈的）意见，因此建议作为原则问题，他们在评审结束之前，可能在评审摘要之前，不要分享他们的意见。 评审经理将做出最终选择，并且在流程早期宣布意见可能会对评审过程产生负面影响。

⚠ 为了避免任何利益冲突，潜在的评审经理应向 Boost 社区披露他们是否与库的作者或库本身有任何关系。

库提交者须知

有关库开发人员为使库被 Boost 接受而经历的步骤的说明，请参阅 提交流程。

首先，库作者应接受评审经理。 如果他们觉得，无论出于何种原因，评审经理候选人不称职或不公正，他们不应接受此类候选人。

提议的库在评审期间应保持稳定； 如果有大量更改，只会让评审员感到困惑和恼火。 然而，立即上传严重错误的修复程序非常有用，特别是那些阻止评审员充分评估库的错误。 在邮件列表上发布此类修复程序的通知。

评审员建议的库改进通常应在评审期结束后进行。 如果建议的更改可能会影响评审员的判断，请在邮件列表上发布有关待定更改的通知。

库维护者的权利和责任

通过将库提交给 Boost，您接受维护您的库或寻找合格的志愿者担任维护者的责任。 您必须愿意将您的库和文档置于 Boost 兼容许可之下。

您将被期望及时回复合理的错误报告和问题，并根据需要在 boost 邮件列表上参与有关您的库的讨论。

您可以自由地以任何您希望的方式更改您的库，并且鼓励您积极进行改进。 然而，同行评审是 Boost 流程的重要组成部分，因此也鼓励您在对已接受的库的接口进行重大更改之前，从 boost 社区获得反馈。

如果在某个时候您不再希望担任库的维护者，您有责任向 boost 社区公开此情况，并找到另一个人来代替您。

已被放弃的库将由 社区维护团队 负责。

评审向导

评审向导协调正式评审时间表

• 当请求对库进行正式评审时
  • 根据库提交者的初步接受、他们参与 Boost 社区（包括邮件列表、以前的评审和其他论坛）的情况，批准评审经理。
  • 在（通过私人电子邮件）检查评审经理和库作者的可用性后，建议一个时间表。
  • 一旦评审经理验证库已准备好进行评审，就确定最终时间表。
  • 解决评审经理和提交者的进度延迟或其他问题。
• 以 评审时间表 网页的形式维护过去和待审评审的时间表。
• 解决评审经理和库提交者的问题，他们有时希望就诸如“我们是否应该延长评审期，因为...？”等问题获得第三方的意见。
• 监控总体评审过程，并根据需要进行细微调整，或就可能的重大调整向列表提出询问。

Boost 评审向导的角色目前由以下人员担任

• Mateusz Loskot (mateusz at loskot dot net)
• John Phillips (johnphillipsithaca at gmail dot com)

过去的评审向导（我们感谢您的服务）

• Ronald Garcia
• Tom Brinkman
• Thomas Witt

快速通道评审

要获得快速通道评审资格

• 组件必须很小。
• 该技术必须已在 Boost 库中使用，并且新组件提供了一个通用实现。
• 沙箱中提供了完整的 Boost 兼容实现。
• 评审向导确定提案符合快速通道评审的条件。

程序

• Boost 评审向导在主要的 Boost 开发人员列表上发布评审公告。 快速通道评审期通常持续 5 天。 不会同时运行两个快速通道评审。 快速通道评审可以在完整评审期间运行，尽管通常应避免这种情况。
• 评审期结束后，提交者将发布一份评审摘要，其中包含对已评审实现的拟议更改。
• 评审向导将接受或拒绝提议的库和拟议的更改。
• 在应用拟议的更改后，该组件将像任何其他库一样签入存储库。

迷你评审

如果评审导致接受条件，则评审经理可以请求迷你评审，以确定是否已满足条件。 迷你评审通常由同一评审经理进行。