审查拉取请求
本指南适用于维护人员。这些特殊人员对一个或多个 Jekyll 存储库拥有写入权限，并帮助合并他人的贡献。你可能会觉得这里的内容很有趣，但它绝对不适合所有人。
善意回应
最重要的是，请善意地审查拉取请求。只有当我们营造一个热情包容的环境时，我们的社区才能强大。为了进一步促进这一点，Jekyll 社区受所有社区成员必须遵守的行为准则约束。
自由使用表情符号 
，并随时表达你的情绪！贡献使这个项目不断向前发展，我们始终乐于收到它们，即使拉取请求最终没有合并。
Mike McQuaid 在 GitHub 博客上发表的题为 “善意地关闭拉取请求” 的文章是一个很好的起点。它描述了在哪些情况下可以出于技术完整性或准确性以外的原因关闭拉取请求。善意的一部分是对拉取请求做出快速响应和解决。
快速响应
我们应该能够在一周内审查所有拉取请求。只有当所有维护人员在同一周内都神秘地休假时，初始审查才会花费更长的时间。及时响应会鼓励社区成员和其他维护人员做出频繁、高质量的贡献。
如果你的响应需要作者做出响应，请添加 pending-feedback 标记。一旦拉取请求的作者做出响应，@jekyllbot 将自动移除该标记。
快速解决
同样地，我们应该努力快速解决拉取请求。如果一个拉取请求引入了不符合项目核心目的或目标的功能，请及时关闭它，并善意地解释为什么它不可接受。
尽可能留下详细的评论。向贡献者提供有关你请求的更改为何必要或你提出的问题为何重要解决的背景。我们能向贡献者清楚地传达的背景信息越多，贡献者就越能提供高质量的补丁。
如果作者在 30 天内没有回复，你可以关闭拉取请求。
在某些情况下，审查将涉及许多星期的反复讨论。只要交流持续进行，这很好。理想情况下，任何公关都可以在开放后的 30 天内解决。
寻找测试
如果这是一个代码更改，是否有针对更新或添加的行为的测试？发布带有错误的版本是不可避免的，但确保更改经过测试有助于将错误和回归降至最低。
CI 必须通过
要求贡献者调查 Travis 上的故障并在你开始审查之前修补它们是可以的。为贡献者留下消息，表明测试失败，并且在测试通过之前不会进行审查，这很有帮助。如果他们寻求帮助，请查看并在可能的情况下提供帮助。
两人规则
一旦两个维护人员审查了拉取请求并表示可以接受，就可以合并拉取请求。除非两个审阅者之一希望再找人审阅，否则无需等待第三个人。
考虑安全性
我们有责任向我们的用户保证，使用社区中的主题或构建他人的网站不会带来内置的安全漏洞。文件可能从何处读取和写入等内容对于保持安全非常重要。Jekyll 也是托管服务（例如 GitHub Pages）的基础，在引入安全问题时无法升级。