立即开放：Gradle 的 GitHub 问题
简介
Gradle 自成立以来一直是一个开源项目，但作为一个团队，我们并没有完全践行现代开源协作的精神。例如，我们没有让人们容易了解我们正在做的事情，并且我们没有为用户提交功能请求或针对正确的问题跟踪器提交错误提供清晰简单的流程。
我们非常高兴地宣布，这一切都在今天发生改变。我们已经在 Gradle 仓库上开放了 GitHub Issues，接下来我们将立即、中期和长期进行更改，以将 Gradle 社区的需求置于首位并保持下去！
立即生效 #
✔︎ 您现在可以通过 GitHub Issues 提交功能请求和错误。我们整理了一套简单的指南，以 问题模板 的形式呈现，以便您每次提交新问题时都会看到它们。我们将不符合这些指南的问题标记为 not-actionable，并添加评论询问缺少的内容。为了保持整洁，我们将在这些问题一周不活动后关闭它们。
✔︎ 您提交的可操作问题将与其他 Gradle 改进一起被优先考虑。对大量用户有利的低成本变更最容易被证明是合理的，因此请为您关心的 👍 问题 添加反应。像许多其他 GitHub 项目一样，我们将使用这些反应作为一种简单的投票系统。
✔︎ 我们将使用 ZenHub 管理问题优先级和工作流程。如果您还不熟悉 ZenHub，ZenHub 通过其巧妙的浏览器扩展为 GitHub Issues 添加了许多功能。它允许我们将相关问题分组到 史诗 中，并通过看板视图可视化所有内容。安装和使用 ZenHub 绝不是必需的，但如果您想更深入地了解我们正在做的事情，请查看一下。
✔︎ 拉取请求将在一周内得到确认，并且对它们的审查将通过 GitHub 内置的 拉取请求审查 完成。请继续遵守 贡献指南——在一个像 Gradle 这样庞大且广泛使用的项目中，严格并确保事情正确至关重要。
中期过渡 #
开放的 JIRA 问题将被迁移到 GitHub，并且在 Gradle 3.2 发布后，将不再有新问题放入 JIRA。我们将要求对不可操作的 JIRA 问题提供示例和/或澄清，以便可以优先处理它们。
为了绘制更清晰的路线图，我们将添加和维护高层次功能 史诗，并用代表未来 Gradle 版本的里程碑标记它们。
我们的 错误论坛 将不再必要，并将设置为只读。对于一般使用问题和无法提供可重现的测试用例或 构建扫描 的潜在错误，请继续使用 帮助/讨论论坛。
长期统一 #
一旦我们完成了上面详述的更改，我们将继续寻找方法，使 Gradle 生态系统能够接受更大的社区贡献。我们对此感到非常兴奋，并且我们希望您也会如此。
我们很乐意听取您的反馈——请在这篇文章的评论中告诉我们您的想法，或在 Twitter 上 @Gradle 与我们交流。我们非常欢迎您的建议、问题，当然还有 问题。