Boost 正式审查流程
请求正式审查之前
阅读并遵循 Boost 提交流程。 在请求正式审查之前，库作者必须采取几个步骤。
简介
只有经过正式审查，Boost 才会接受提议的库，在审查期间，Boost 邮件列表成员会对其评估发表评论。
最终的“接受”或“拒绝”决定由审查管理员根据 boost 邮件列表成员的审查意见做出。
鼓励 Boost 邮件列表成员提交正式审查意见
- 公开发布到邮件列表。
- 私下发送给审查管理员。
私下评论对库提交者可能会有所帮助，但不会帮助审查管理员做出决定，因此首选其他形式。
审查期通常持续 10 天。
审查意见中应包含的内容
您的评论可以简短或冗长，但审查管理员需要您对库的评估。如果您在此过程中发现了问题，请注明它们是轻微的、严重的还是致命的。
Boost 库审查的目标是通过建设性批评来改进库，最终必须做出决定：该库目前是否足够好以被 Boost 接受？如果没有，我们希望提供足够的建设性批评，以便在以后改进并被接受。序列化库就是一个很好的例子，它说明了建设性批评如何导致修改，最终形成了一个在第二次审查中被接受的优秀库。
以下是在审查中您可能想要回答的一些问题
- 您对设计的评价是什么？
- 您对实现的评价是什么？
- 您对文档的评价是什么？
- 您对库潜在用途的评价是什么？
- 您是否尝试过使用该库？使用的是什么编译器？您遇到过任何问题吗？
- 您在评估中投入了多少精力？粗略一看？快速阅读？深入研究？
- 您是否了解问题领域？
最后，每次审查都应该回答这个问题
- 您认为该库应该被接受为 Boost 库吗？请明确说明这一点，以便您的其他评论不会掩盖您的总体意见。
许多审查都包含针对库作者的问题。作者有兴趣为他们的库辩护，否则他们就不会提交库进行审查。如果您没有快速得到问题的答案，请耐心等待；如果时间过长或者您没有得到您认为满意的答案，请再次提问或尝试重新措辞。请记住，英语不是许多 Boost 用户的母语，这可能会导致误解。
电子邮件是一种糟糕的沟通媒介，即使消息很少在传输过程中丢失，它们也常常淹没在其他消息的洪流中。不要认为未回复的消息意味着您被忽略了。建设性的批评更容易被接受，并产生更积极的影响，您也会得到想要的答案。
结果
在评论期结束后的一段时间内，审查管理员将在邮件列表中发布一条消息，说明库是否已被接受或拒绝。解释说明也很有帮助，但其范围由审查管理员决定。如果有建议或最终包含之前必须满足的条件，则应说明。有关审查报告的及时性或质量的担忧应私下提交给审查向导。
审查管理员须知
在库可以安排正式审查之前，必须有一名与库提交无关的活跃 boost 成员自愿担任该库的“审查管理员”。成员可以通过列表或私下联系库作者，表达管理审查的兴趣。库作者必须接受某人作为审查管理员。
审查管理员
- 检查提交内容，确保其确实足够完整，值得进行正式审查。请参阅Boost 库要求和指南。如有必要，与提交者合作验证代码是否可以在多个编译器和平台上正确编译和运行。
- 与审查向导和提交者最终确定时间表。
- 在常规boost 邮件列表和boost-announce 邮件列表上发布审查时间表的通知。
- 通知应包含库的简要说明及其功能，以便读者了解该库是否是他们有兴趣审查的库。
- 如果已知库在某些编译器上无法运行，请在审查通知中提及它们，以便使用这些编译器的审查员不会浪费时间诊断已知问题。
- 建议将通知分别发送到每个邮件列表，否则在线电子邮件到新闻网关可能会混淆。
- 检查 Boost 库目录，查找可能与新提交内容交互的库。应在审查公告中指出这些潜在的交互，并应私下通知这些库的作者并敦促他们参与审查。
- 如果没有人主动进行审查，则敦促人们进行审查。
- 关注有关库的审查讨论，根据需要进行主持或回答问题。
- 如果在审查期间提交的审查数量似乎太少，则请求审查向导允许延长审查时间表。
- 决定是否达成共识接受该库以及是否有任何附加条件。共识与投票不同。审查管理员可以根据权威或周到程度来权衡意见。
- 在常规boost邮件列表、boost-users邮件列表和boost-announce邮件列表上发布审查结果的通知。
换句话说，审查管理员有责任确保审查过程顺利进行。
尽管审查管理员也可以审查库，但他们应该为 Boost 用户的利益服务。由于审查管理员可能对库有（强烈）意见，原则上建议他们在审查结束之前不要分享他们的意见。可能直到审查总结出来之前。审查管理员将做出最终选择，提前宣布意见可能会对审查过程产生负面影响。
⚠ 为避免任何利益冲突，潜在的审查管理员应向 Boost 社区披露他们是否与库的作者或库本身有任何关系。
库提交者须知
有关库开发人员为使库被 Boost 接受而采取的步骤的说明，请参阅提交流程。
首先，库作者应该接受一位审查管理员。如果他们觉得，无论出于何种原因，审查管理员候选人不够胜任或公正，他们不应该接受这样的候选人。z
提议的库在审查期间应保持稳定；如果有很多更改，只会让审查员感到困惑和恼火。但是，立即上传严重错误的修复程序非常有用，尤其是那些阻止审查员充分评估库的错误。在邮件列表上发布此类修复程序的通知。
审查员建议的库改进通常应在审查期结束后进行。如果建议的更改可能会影响审查员的判断，请在邮件列表上发布待定更改的通知。
库维护者的权利和责任
通过向 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 天。不会有两个快速通道评审并行运行。快速通道评审可以在全面评审期间进行，但通常应避免这种情况。
- 评审期结束后，提交者将发布包含对已评审实现的拟议更改的评审摘要。
- 评审专家将接受或拒绝提议的库和拟议的更改。
- 应用拟议的更改后，该组件将像任何其他库一样检入存储库。
小型评审
如果评审结果附带接受条件，则评审管理员可以请求进行小型评审，以确定是否满足这些条件。小型评审通常由同一位评审管理员进行。
