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