Managing issues in a large-scale open source project

How the Flutter team addresses its issue backlog

We’re honored by the amount of positive feedback we get from folks using Flutter. As one of the largest active repositories on GitHub, we have a relatively unique challenge and we thought you might find it interesting to learn our philosophy and approach to how we’re dealing with issues at this scale, what changes we’re making to deal with the project growth, and some helpful tips for filing issues to maximize their value.

Sometimes developers attempt to use the total number of public logged issues as a measure of the overall quality of the project. We think this number is poorly correlated with project health, and want to explain why, counter to expectation, a larger number of issues can be a signal of a high-quality, popular project.

Lastly, we want to use this blog post to share some concrete changes we’ve made in recent months: more active scrubbing of our backlog, accomplishing (and holding to) zero-bug-bounce for unassigned issues, and a new prioritization scheme that better aligns with how we believe our customers think about priorities.

How Flutter uses GitHub

It’s common in today’s software development world for teams to keep a backlog of issues submitted both by team members and users: this backlog is the sum total of bugs, feature requests, and technical debt facing the team. Flutter is no different: we use GitHub as our backlog. If it’s a bug, an idea for a new feature, or something in between, it’s filed as an issue in our issue database on GitHub.

Each of these issues starts with you, or one of Flutter’s contributors. Contributors and users file issues about Flutter or Flutter’s API documentation in the flutter/flutter issue tracker, and issues about Flutter’s website (flutter.dev) in the flutter/website issue tracker.

There are three special considerations about how we manage issues on GitHub, which contributes to a large overall number:

1. The issue repository is completely open. The core engineering and product teams, along with the entire Flutter community, files all feature enhancements, bugs, and potential future work into the open repository.
2. We don’t aggressively close issues, even if we don’t plan to work on them in the immediate future; we want to keep the total backlog of possible…