问题分类

本指南面向维护者。 这些特别的人拥有一个或多个 Jekyll 仓库的 写入权限（write access），并负责帮助合并其他人的贡献。你可能会觉得这里的内容很有趣，但它显然并不适合所有人。

在评估 Issue 之前，首先要判断它属于功能请求（feature request）还是 Bug。

在 Jekyll 项目中，我们使用以下定义来区分：

功能（Feature） - 功能是指为 Jekyll 当前能力之外新增功能的请求。 Bug - Bug 是指用户在使用当前 Jekyll 功能时遇到的错误问题。

功能请求？

如果该 Issue 描述的是功能请求，请先思考以下问题：

这是一个配置项（setting）吗？Settings are a crutch 这篇文章提到，配置项通常只是为了“让某件事能正常工作”的权宜之计。很多配置项其实意味着默认行为设计得不好，或者只是一个适合通过插件解决的边缘场景。我们希望尽可能保持设置项这棵 “圣诞树” 简洁，以避免降低产品易用性。我们更偏向“做决定，而不是提供无数选项”的设计理念。
至少有 80% 的用户会觉得这个功能有用吗？如果连四分之一的用户都不会使用它，那么这个请求很可能并不符合产品核心目标。
是否已经有其它方式能够实现用户的最终目标？很多功能请求，其实源于文档不清晰或用户不了解已有功能。尝试弄清楚用户真正想做什么。他们是否已经可以通过现有功能完成这个目标？
即使 80% 的用户都会使用，它是否符合项目核心目标？我们正在开发的是一个用于构建静态网站的工具，而不是一个什么都想做的“瑞士军刀”。

你可以随时征求其他维护者意见，或者向 Issue 作者进一步提问。但根据上述问题的答案，该请求可能并不属于项目范围之内。

如果这个请求属于项目范围，那么请与其他维护者一起在产品路线图中确定优先级。

同时：

如果你想成为 最棒的维护者，甚至可以直接自己提交一个实现该功能的 PR。

如果 Bug 已经提供了明确的复现步骤，请花一点时间亲自尝试。

如果有帮助，也可以直接为该场景编写测试用例，并加入测试套件中。

你是否能够稳定复现这个问题？

如果无法复现，请把你的复现步骤贴出来，并向 Issue 作者请求进一步说明。

Issue 作者是否正在使用受支持的平台？

我们当前支持：

如果作者无法在受支持平台上复现该问题，你可以直接关闭该 Issue。

对于 Windows 相关问题：

请留言告知用户：

另外，也可以引导用户前往 Jekyll Talk（https://talk.jekyllrb.com）寻求社区帮助。

如果用户的问题发生在 GitHub Pages 或其它托管平台上，并且我们无法复现，请引导他们联系对应平台的支持渠道，然后关闭 Issue。

如果一个 Issue 没有清楚说明：

那么我们很难准确处理该问题。

如果用户没有提供这些信息，请主动要求补充说明，并添加 pending-feedback 标签。

这些信息对于编写测试用例非常重要，可以帮助我们避免未来再次引入相同问题。

当 Issue 作者回复后，pending-feedback 标签会自动移除。

另外还要判断：

用户期望的行为，真的是我们想支持的吗？

有时候，看似是 Bug 报告，实际上只是伪装成 Bug 的功能请求。

关于如何处理功能请求，请参考上面的说明。

如果一个 Issue 至少一个月没有任何活动，@jekyllbot 会自动将其标记为 stale。

同时，@jekyllbot 会自动留言，询问该问题是否仍能在当前版本中复现。

如果接下来一个月依然无人回复，该 Issue 会被自动关闭。

如果需要阻止自动关闭，可以添加 pinned 标签。