现已开放：Gradle 的 GitHub Issues
引言
Gradle 自成立以来一直是开源项目，但作为一个团队，我们并不总是能跟上现代开源协作的精神。例如，我们并没有让大家轻松了解我们的工作进展，也没有一个清晰简单的流程供用户提交功能请求或 Bug 到一个合适的 Issue 跟踪器。
我们非常高兴地宣布，所有这些从今天开始都将改变。我们已在 Gradle 仓库上开放了 GitHub Issues，接下来是我们为将 Gradle 社区的需求放在首位（并将一直保持！）而进行的一系列即时、中期和长期的变革。
立即生效 #
✔︎ 您现在可以通过 GitHub Issues 提交功能请求和 Bug。我们已经以 Issue 模板 的形式制定了一套简单的指南，这样您每次提交新 Issue 时都会看到它们。我们会将不符合这些指南的 Issue 标记为 not-actionable，并添加评论要求补充缺失的信息。为了保持整洁，我们将在一周无活动后关闭这些 Issue。
✔︎ 您提交的可操作 Issue 将与其他 Gradle 改进一起被优先处理。容易论证的是低成本但惠及大量用户的更改，因此请为对您重要的 Issue 添加 👍 反应。与其他许多 GitHub 项目一样，我们将使用这些反应作为一种简单的投票系统。
✔︎ 我们将使用 ZenHub 来管理 Issue 的优先级和工作流程。如果您还不熟悉，ZenHub 通过其巧妙的浏览器扩展为 GitHub Issues 增加了一些功能。它允许我们将相关的 Issue 分组到 Epics 中，并通过看板可视化所有内容。安装和使用 ZenHub 绝非强制要求，但如果您想更深入地了解我们正在进行的工作，不妨查看一下。
✔︎ Pull Request 将在一周内得到确认，并通过 GitHub 内置的 Pull Request 评论 进行审查。请继续遵循 贡献指南——在一个像 Gradle 这样庞大且被广泛使用的项目中，严谨并确保万无一失至关重要。
中期过渡 #
将迁移开放的 JIRA Issue 到 GitHub，并且在 Gradle 3.2 发布后将不再向 JIRA 提交新 Issue。我们将要求对 JIRA Issue 提供示例和/或澄清，以使其更具可操作性并能被优先处理。
为了绘制更清晰的路线图，我们将添加和维护高级功能 Epics，并用代表未来 Gradle 发行版的里程碑标记它们。
我们将不再需要我们的 Bug 论坛，并将其设为只读。对于一般使用问题以及没有可重现的测试用例或 Build Scan 的潜在 Bug，请继续使用 帮助/讨论论坛。
长期统一 #
一旦我们完成了上述详细的更改，我们将继续寻找方法来进一步开放 Gradle 生态系统，以获得更大的社区贡献。我们对此感到非常兴奋，并希望您也会如此。
我们很乐意听取您的反馈——请在本文的评论区告诉我们您的想法，或在 Twitter 上联系我们 @Gradle。您的建议、问题以及当然还有 Issue 都非常欢迎。