Refining the Gradle issue backlog
Table of Contents
Introduction
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 closed our whole backlog of 2000 issues…after her first week. Every. Single. Issue. I was shocked. I was raging. Looking back at it today, it was the best thing she could have done for that team back then to help focus on the important parts again. Over the following years, the team was able to focus again on the most important things and keep the backlog of tasks within the limits defined by the team. But don’t worry, our plan with the Gradle backlog will be less aggressive :)
Keeping this backlog in a state that we can derive our prioritization from is extremely important for the success of the Gradle project. You, as our community, play a vital part by helping us identify the important pieces and closing outdated issues. Not only that, we want to ensure that you know what the team is up to, what our priorities are and which features/defects simply fall out of scope given the bandwidth we have available. In order to help us with this, we’ve decided to introduce “Probot: Stale”, a bot that looks at the activity (labels, comments, …) of issues to determine if they’re still active. If they’re inactive for a period of time (e.g. 2 years), it marks them with a stale, giving committers and members a chance to intervene. Once tagged with the stale label, the issues have a grace period of 21 days before they’re automatically closed.
What does this mean for you? #
We understand that it can be hard to see older issues being closed automatically, especially if you opened the issue and care about it. But closing stale issues does not mean we don’t care. In fact it is the opposite. This will help us to (re)discover the most important issues to prioritise them and you can help with this. So instead of just having your issues laying around unnoticed in the sheer mass of 2000+ unaddressed issues, you can now use the opportunity to get back to us about your concern.
It’s important to realize that these issues are marked and closed as stale. It’s not “this is invalid” or “we disagree that this is a cool feature”, it really is just “stale”. It means nobody in a long time had the bandwidth to look at it.
Going forward #
If an issue you care about is marked as stale or closed but it is still a concern for you: Please let us know and update the issue so we can reopen it for consideration. You will help us a lot and increase chances of progress, if you validate the issue against the latest Gradle release and if you make sure that you have a sample project attached that reproduces the bug or demonstrates the use case for the feature you miss. We will be more open by saying “We don’t have the bandwidth”. Hopefully that will trigger a new conversation about the importance of the issue at hand - instead of letting it sit on the backlog, ignoring it for years to come.
Does this mean you should stop opening issues and PRs? No way! Please keep reporting issues you find, send your ideas/feature requests along and keep opening those PRs. We’re more than happy to review those and schedule them accordingly. This change enables us, the Gradle team, to regain focus on the aspects that provide the highest value for you, our community.