提升正式评审流程
在请求正式评审之前
阅读并遵循 Boost 的 提交流程。 在请求正式评审之前，库作者需要执行几个步骤。
简介
提议的库只有在经过正式评审后才能被 Boost 接受，Boost 邮件列表成员会在评审中发表他们对库的评价。
最终的“接受”或“拒绝”决定由 评审经理 根据从 Boost 邮件列表成员收到的评审意见做出。
鼓励 Boost 邮件列表成员提交正式评审意见
- 公开发布在邮件列表上。
- 私下发送给评审经理。
发送给库提交者的私下意见可能对他们有所帮助，但不会帮助评审经理做出决定，因此其他形式更受青睐。
评审期通常持续 10 天。
评审意见中应包含的内容
您的意见可以简短或冗长，但评审经理需要您对库的评估。如果您在此过程中发现了问题，请说明它们是轻微的、严重的还是阻碍性的。
Boost 库评审的目标是通过建设性批评来改进库，最后必须做出决定：库在这一点上是否足够好，可以被 Boost 接受？如果不是，我们希望已经提供了足够的建设性批评，以便在以后改进并接受。序列化库就是一个很好的例子，它说明了如何通过建设性批评导致修订，最终形成了一个优秀的库并在第二次评审中被接受。
以下是一些您可能想在评审中回答的问题
- 您对设计的评价如何？
- 您对实现的评价如何？
- 您对文档的评价如何？
- 您对库的潜在用处的评价如何？
- 您是否尝试过使用该库？使用什么编译器？您遇到过什么问题？
- 您投入了多少精力进行评估？粗略一看？快速阅读？深入研究？
- 您是否了解问题领域？
最后，每个评审都应该回答这个问题
- 您认为该库是否应该被接受为 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 天。不会有两个快速通道评审同时进行。快速通道评审可以在完整评审期间进行，尽管通常应避免这种情况。
- 评审期结束后，提交者将发布一份评审摘要，其中包含对已评审实现的拟议更改。
- 评审向导将接受或拒绝提议的库和提议的更改。
- 应用提议的更改后，组件将像任何其他库一样检入存储库。
小型评审
如果评审结果导致验收条件，评审经理可以要求进行小型评审以确定是否已满足这些条件。小型评审通常由相同的评审经理进行。
