# Refining the Gradle issue backlog

DevFeed: [Refining the Gradle issue backlog](<https://devfeed.tech/articles/refining-the-gradle-issue-backlog-24693.md>)

Original publisher: [Read original article](<https://blog.gradle.org/stale-issue-backlog>)

Author: Benjamin Muskalla

Published: 2020-06-09T04:00:00Z

Content type: article

Language: en

Sources: [The Gradle Blog](<https://devfeed.tech/sources/the-gradle-blog.md>)

Topics: [Gradle](<https://devfeed.tech/topics/gradle.md>), [Pull Request](<https://devfeed.tech/topics/pull-request.md>)

Tags: [bugs](<https://devfeed.tech/tags/bugs.md>), [community](<https://devfeed.tech/tags/community.md>), [contribution](<https://devfeed.tech/tags/contribution.md>), [features](<https://devfeed.tech/tags/features.md>), [gradle](<https://devfeed.tech/tags/gradle.md>), [issue](<https://devfeed.tech/tags/issue.md>)

## AI overview

This article explains that Gradle's influx of community issues, feature requests, defects, and contributions has outgrown the team's capacity to manage the backlog regularly. It discusses the need to focus triage and engineering work on the issues and features that provide the most value to users.

## Source excerpt

One of the biggest success factors of Gradle is its community. There is no day that goes by without users suggesting new features, finding and reproducing defects or opening a pull request with a contribution. We appreciate every single issue that users create. Thank you! Working on a successful project like Gradle comes with challenges, be it the number of questions and contributions or deciding which aspect has the highest priority for the team. Even though we don't like to accept it, we don't have infinite capacity. We want our teams to be able to focus on producing the most value for our users. That means fixing the right bugs and implementing the best features. Given the diversity of our community, this is not an easy task to do. We want to find the right features/defects to do together with our users and not be paralyzed by the sheer volume of things we could potentially do. Rationale As part of our daily work, we triage new issues that you create, decide which ones should go into the next release, and check which issues are the most voted by the community. All while actually fixing existing issues and implementing new features. We're quite happy and feel productive with our current workflow. One aspect we're not very good at right now is managing the rest of our backlog. The sheer volume of ideas and contributions coming from the outside outweighs the number of tasks we can tackle within a reasonable timeframe. Given how many issues there are on our backlog, be it features, bugs or questions, it is really tough to find the time to go through all of them regularly. We need to determine which bugs are still reproducible in more recent versions of Gradle and which use cases have been implemented (maybe by just using one of the new features). Approach As engineers, we sometimes struggle to close a defect even though it is not fixed. Several years ago, exactly that happened to myself. In a former life, my company had just hired our first product manager. She close