Meta: How to keep our issue tracker in good shape
There's a recent blog post by @aday on managing issue trackers for GNOME maintainers. It's quite a good summary (thanks!).
@felipeborges initiated a small discussion on Matrix, but to maybe continue the discussion or at least not to lose it, I am posting this here with some quotes from the discussion.
Quotes
Some things can be improved for sure. We have around 900 open issues atm. I go through them sometimes to close issues that are definitely fixed or irrelevant now.
The hardest part here is the closing of issues imo. When do you do that? Often the bug is clear, but we need more input and the issuer isn't responding. And for real bugs, I think closing is not very productive perhaps? It's still a bug...
The problem with Settings issues is that maybe even more than 50% of the time, the issue is in the backend, but users report it to us because that's what they see. To redirect them to the correct issue tracker sometimes requires deep knowledge that I also don't really have. And newcomers can and do indeed help (thanks!) with labelling etc, but that is not where the time goes. Figuring out what's going on and leaving a useful comment is what takes the most time.
Those are all good practices especially with handling old issues. But what's the reasoning behind 'Close issues that have been labelled “need info” for 6 weeks'? That's the only one that stood out to me.
I'm thinking more along the way of letting newcomers try to reproduce issues with missing information. Would be a nice way to boost engagement and allow even non coders to contribute something
So these guidelines are mainly from the old bug squad, which used to do a lot of triage on incoming bugzilla tickets. I think that rule translates to - "someone reported an incomplete bug and didn't provide the requested information for 6 weeks". If the rules don't make sense we can change them. I already have a few changes in mind.
People can always reopen need-info issues if they come back after closure. We should inform them that they can reopen while closing it.
Raised questions
- When is an issue "inactive"?
- What kind of issues can be closed and what kind should stay open even if inactive?
- Do we allow feature requests at all? Or should those be closed and pointed to Discourse?
- What to do with issues that appear related to Settings, but are actually backend problems? Closing them without redirecting somewhere can appear rude, but often it takes time to figure out where to redirect reporters.
- Can we improve the use of issue labels? ("Scoped" labels perhaps?)
- Can we try and engage more newcomers to help with issues? Triaging/reproducing/anything?
Since this discussion is about Gitlab issues, I thought it was more natural to have this here than on Discourse. Feel free to add comments or change the description with more questions/anything else.