审核 Pull Request

本指南面向维护者。 这些特殊成员拥有一个或多个 Jekyll 仓库的 写入权限，并负责帮助合并其他人的贡献。你可能会觉得这里的内容很有意思，但它并不适合所有人阅读。

Respond Kindly

最重要的一点：请始终以友善的态度审核 Pull Request。 只有营造一个欢迎且包容的社区环境，我们的社区才能持续发展壮大。为了进一步推动这一点，Jekyll 社区制定了行为准则，所有社区成员都必须遵守。

请大胆使用 emoji ❤️ 🎉 ✨ 🎊，也欢迎适当表达情绪！！ 正是因为大家不断贡献，这个项目才能持续前进。即使某个 Pull Request 最终没有被合并，我们也始终感谢每一位贡献者。

Mike McQuaid 在 GitHub 博客上的文章 “Kindly Closing Pull Requests” 是一个很好的参考起点。

文章介绍了很多适合关闭 Pull Request 的场景，而不仅仅是因为技术实现不正确或代码质量不足。 友善的一部分，也包括及时回复和处理 Pull Request。

Respond Quickly

我们应该能够在一周内完成所有 Pull Request 的审核。 唯一可能导致首次审核超过一周的情况，大概只有所有维护者刚好同一周集体休假了。

及时响应能够鼓励社区成员和其他维护者持续提交高质量贡献。

如果你的回复需要作者进一步反馈，请添加 pending-feedback 标签。 @jekyllbot 会在 Pull Request 作者回复后自动移除该标签。

Resolve Quickly

同样地，我们也应该尽快完成 Pull Request 的处理。 如果某个 Pull Request 引入的功能不符合项目核心目标或定位，请尽快关闭，并友善说明不被接受的原因。

尽量留下详细评论。 向贡献者说明你为什么要求进行某项修改，或者为什么某个问题必须解决。

我们能够提供的上下文越清晰，贡献者就越容易提交高质量补丁。

如果超过 30 天作者仍未回复，你可以关闭该 Pull Request。

有些情况下，审核过程可能会持续数周、来回沟通很多次。只要沟通仍在继续，这都是正常的。 理想情况下，任何 PR 都应该能在创建后的 30 天内完成处理。

Look for Tests

如果这是代码改动，请确认是否为新增或修改的行为添加了测试。

发布带有 Bug 的版本几乎无法完全避免，但确保改动经过测试，可以最大程度减少 Bug 和功能回退问题。

CI Must Pass

在开始审核之前，让贡献者先排查 Travis 的失败项并修复问题，是完全合理的。

最好给贡献者留言说明：当前测试未通过，因此在测试通过之前不会开始代码审核。 如果对方请求帮助，并且你有时间，也可以协助一起排查问题。

Rule of Two

当两个维护者完成审核并确认 Pull Request 可以接受后，就可以合并。

除非其中一位审核者希望再增加一次审核，否则无需等待第三位维护者。

Think Security

我们有责任确保用户在使用社区主题，或者构建他人网站时，不会自带安全漏洞。

例如文件允许从哪里读取、写入到哪里，这类问题都必须重点关注安全性。

Jekyll 同时也是诸如 GitHub Pages 这类托管服务的基础，而这些平台在引入安全问题后，往往无法立即升级修复。