Add/Improve Issue Triage Policies and combat growing problem of issue bloat
We have a growing problem that is only going to get worse if it continues to be ignored. As of writing (May 20, 2016), we have 3559 open issues.
Why is this a problem?
- Harder to gauge what the community really wants/needs fixed.
- Harder to find relevant issues.
- Harder to find duplicates.
- Many issues are left to rot for months, some have been untouched for over a year now.
- Difficult to find new tasks to work on.
- Infinitely growing pile of issues makes it feel like we're not making any progress.
Can we fix this within the GitLab product itself?
If we can, it'd be beneficial for all users, especially large open source project maintainers.
- Arguably part of the reason this isn't being dealt with is because GitLab.com is slow. It takes too long to load each individual issue in order to triage it. It's tiring, slow, and boring. This is being worked on extensively, and it will continue to get better, but I wanted to point this out both as something we're constantly working on improving and something contributing to the problem. (gitlab-com/operations#42 (closed), gitlab-com/operations#182 (closed))
- Reply Templates would be very helpful for quickly responding to newly created issues. (!3516 (closed))
- Mass application of labels would be helpful for dealing with uncategorized issues (currently 1900 of our 3500+ issues are entirely unlabeled). (!3917 (merged))
- Better/faster search (really great steps have been made toward speedier search recently) can improve the experience of checking for duplicates.
- Issue filters persisting when changing status (Open/Closed/All) would be helpful. (#13573 (closed))
- Suggest potential duplicates when the user is typing out an issue. (There's an issue open for this but I couldn't find it, the irony of this is not lost on me.)
- Allowing users to suggest labels could either make labelling issues easier or worse, depending on how well users understand the purpose of certain labels.
Policy changes that can improve the situation
- Be a bit more "brutal" with our issue closing. If we're definitely not going to add a feature/change, say so and close the issue. We simply can't satisfy everyone. I struggle with this myself, we need to balance pleasing users as much as possible with keeping the project maintainable.
- Outdated Issues: For issues that haven't been updated in the last 6 months (this can be updated to be a shorter period of time as the situation improves), "Awaiting Feedback" should be added to the issue. After three weeks (21 days), if no response has been made by anyone on the issue, the issue is closed. If they respond at any point in the future, the issue may be considered for reopening, but if we can't confirm an issue still exists in recent versions of GitLab, we're just adding noise to the issue tracker.
- Label issues as they come in, 1900 of the 3500 open issues are entirely unlabeled right now. This is not okay. When you create an issue, label it.
- Take ownership of issues you've opened. Sort by "Author: your username" and close any issues which you know have been fixed or become irrelevant for other reasons, and label them if they're not labelled already.
- Questions/Support Issues: If it's a question, or something vague that can't be addressed by the development team for whatever reason, close it and direct them to the relevant discussion pages we have already put together (e.g. our Discourse forum or Support).
- Duplicates: Be diligent about checking for duplicates and/or reporting duplicates when you notice them.
- New Labels: If you notice a common pattern amongst various issues (e.g. a new feature that doesn't have a dedicated label yet), suggest adding a new label in chat. @DouweM is the "Label King", make sure he approves of a label before adding it. This way we don't have a bunch of repetitive/unused/inconsistent labels.
It may also be worth setting company-wide goals with regards to issue count, e.g. "3200 issues by July 1, 2016", "2800 issues by September 1, 2016", etc.
Notes:
cc: @rspeicher @godfat @rymai