We’re very happy to announce that all of that is changing today. We’ve opened up GitHub Issues on the Gradle repository, and what follows are the immediate, medium-, and long-term changes we’re making to put — and keep! — the needs of the Gradle community front and center.
︎ You can now submit feature requests and bugs through GitHub Issues. We’ve put together a simple set of guidelines in the form of an issue template so you’ll be presented with them each time you submit a new issue. We’ll label issues that don’t follow these guidelines as
not-actionable and we’ll add a comment asking for what’s missing. To keep things clean, we’ll close these issues after a week of inactivity.
︎ Actionable issues you submit will be prioritized alongside other Gradle improvements. Low-cost changes that benefit a large number of users are the easiest to justify, so please add a reaction to issues that matter to you. Like many other GitHub projects, we’ll use these reactions as a simple kind of voting system.
︎ We’ll manage issue priority and workflow using ZenHub. If you’re not already familiar, ZenHub adds a number of features to GitHub Issues through its clever browser extension. It allows us to group related issues into epics and to visualize everything via a kanban board. Installing and using ZenHub is by no means a requirement, but do check it out if you’d like to get an additional level of insight about what we’re working on.
︎ Issues that are well-suited for community contribution will be labeled
help-wanted. Take a look— you’ll see there are already a few there.
Pull requests will be acknowledged within a week and reviews of them will be done through GitHub’s built-in pull request reviews. Please continue to follow the contribution guidelines — in a project as large and widely-used as Gradle, it’s crucial to be rigorous and get things right.
Open JIRA issues will be migrated to GitHub, and no new issues will be put into JIRA after the release of Gradle 3.2. We’ll ask for examples and/or clarification on JIRA issues that are not actionable so that they can be prioritized.
To draw a clearer roadmap, we’ll add and maintain high-level feature epics and mark them with milestones representing future Gradle releases.
Our bugs forum will no longer be necessary and will be made read-only. For general usage questions and potential bugs for which no reproducible test case or build scan can be provided, please continue to use the help/discuss forum.
Once we’ve made the changes detailed above, we’ll continue looking for ways we can open up Gradle ecosystem to even greater community contribution. We’re really excited about this, and we hope you will be too.