我应该在向比特币核心回购（Bitcoin Core repo）开放的拉取请求（pull request，PR）的描述中包括什么，以帮助审阅者快速高效地审阅和测试PR？
比特币核心开发
比特币核心评论
分享
改进这个问题
跟随
24分钟前编辑
一小时前问的
迈克尔·福克森
593277银牌2222铜牌
添加评论
1个答案
0
目前在contribution.md中有一些（有限的）指导。
拉请求的标题应以拉请求影响的组件或区域作为前缀
e、 g.共识：为BIP-XXXX OP\U CHECKAWESOMESIG添加新的操作码
pull请求的主体应该包含对补丁做了什么的充分描述，更重要的是，为什么要这样做，以及理由和推理。您应该包括对任何讨论的引用（例如，其他问题或邮件列表讨论）。
很难准确地解释PR描述中应该包含什么，因为这在很大程度上取决于它是什么类型的pull请求(新请求的描述不应该包含任何@提及。）一个小文档PR只需要一两句话来解释更改和进行更改的理由。在另一个极端，一个共识的改变将需要一个长的，详细的描述，解释历史背景，链接到以前的讨论（例如BIPs，邮件列表），并说服评论者，社区对这个改变有共识。
然而，公关作者应该想使公关审查尽可能容易。理想情况下，评审人员应该能够从PR描述中了解PR试图做什么以及为什么，而不必探索PR链以获得所需的上下文。另外，关于审阅者应该注意什么的指针（特别是如果有特定的安全考虑）或者关于审阅者如何测试PR的指导也可能被证明是有用的。如果它很容易被审查，那么它更有可能被审查。
fanquake在这个公关评论中提供了一些额外的指导：
PR描述（和commit消息）可能包括：正在更改什么，为什么它等同于以前的检查？什么时候变的？e、 qt5.12并不是我们构建Qt的唯一版本，我们支持的最低版本仍然是5.9.x。如果所构建的Qt版本与此更改无关，为什么会这样？链接到相关的上游变更（如适用）。
您如何验证/评审员应如何验证这是一个无操作？e、 g.“如果这是对配置检查的更改，那么在更改之前和之后生成的二进制文件应该是相同的。你可以用build for compare.py来证明这一点。”
添加更多的信息不仅意味着更多的贡献者可以，或者将更有可能进行审查，而且任何与安全相关的更改都应该比“依赖项头中发生的某些更改”更好地进行总结。
公关作者还应该考虑让公关易于测试的新/经验不足的审查，尤其是如果它不是一个复杂的公关，需要大量的上下文理解。
一个很好的例子，公关的描述，为经验较少的评论家是这一个从乔恩阿塔克。它明确地列出了审阅者需要做什么来验证功能是否按描述工作，包括审阅者可以运行的确切命令。
欢迎测试和审核！如何测试：
要运行full-live仪表板（在Linux上）：$`watch–interval 1
要运行完整的仪表板：$./src/bitcoin cli-netinfo 4
要查看帮助：$./src/bitcoin cli-netinfo help
查看帮助摘要：$./src/bitcoin cli-help | grep-a4netinfo
这里有Jon Atack关于向比特币核心提交拉取请求的额外指导。
分享
改进这个答案
跟随
36分钟前编辑
1小时前回答
迈克尔·福克森
593277银牌2222铜牌
添加评论
