Many community issues are being left in this project unanswered

As our team has gotten piled down in work, it has become harder for us to prioritise looking at issues that don't directly mention us. As a result we have issues coming into Omnibus that go unanswered.

While we may not necessarily be able to come up with a perfect solution, I think we do need to do better than we are doing now.

Maybe:

• Get more triage help from the rails project?
• Have each of us spend Xmin a day or week on triaging new issues?
• Assign and rotate a weekly/monthly role to one of us similar to support's fix4all?

In my opinion, what this triaging usually entails is:

1. Labelling issues appropriately
2. Closing-non issues
3. Engaging with the community and asking for more feedback
4. The three above steps will sometimes require you to attempt to reproduce the problem
5. Finding blockers that the community have found and we have missed, and alerting the team
6. When finding a regression, assign a milestone and an owner. (or at least ping a potential owner/the whole build team)

I want our team to be aware of the blocker/regressions so we all have a good handle on the state of our project

cc\ @gitlab-build-team

I agree, we need to find a way to handle this better. Few notes:

Get more triage help from the rails project?

I don't expect this to happen, they have dedicated people to handle the tracker and they still cannot keep up. We are on our own.

Have each of us spend Xmin a day or week on triaging new issues?

This would be great if we could discipline ourselves individually to do it. If everyone pitched in daily during their coffee break, we would be able to keep the issue tracker under control.

Assign and rotate a weekly/monthly role to one of us similar to support's fix4all?

In principle, I am against rotations like these. For me personally, this decreases work happiness. However, if the rest of the team thinks they would prefer something like this, I am ok with it.

For now I cannot think of a better suggestion, so I prefer having everyone grab 20 minutes of their day and respond to some issues. We could even make this into a team effort and have a coffee-issue break together on one day of a week.

I like the idea of working on this over a coffee call with a teammate(s). At the very least triaging and assigning issues with each other.

I like the idea of team effort more. It may result in faster actions/replies.

Doing it together at the same time increases the chance that we will be looking at the same issues, and not getting through as many. Though on the other hand, as long as we don't have two people reproducing the same issue at the the same time this could still work well.

@rymai do you have any advice for us on how to do this most efficiently? Is there anything that worked for other issue trackers?

For now I cannot think of a better suggestion, so I prefer having everyone grab 20 minutes of their day and respond to some issues.

@marin I think that's a good solution. Ideally, developers would do the same for CE/EE (I'm sure some developers are already doing that, but everyone should help). This is documented:

Any GitLab team member can triage issues. Keeping the number of untriaged issues low is essential for maintainability, and is our collective responsibility. Consider triaging a few issues around your other responsibilities, or scheduling some time for it on a regular basis.

– https://about.gitlab.com/handbook/engineering/issues/issue-triage-policies/

do you have any advice for us on how to do this most efficiently? Is there anything that worked for other issue trackers?

We have an issue triage policies page: https://about.gitlab.com/handbook/engineering/issues/issue-triage-policies/ Maybe that can help?

I will /cc @markglenfletcher here since he's definitely GitLab's triage specialist!

I think it definitely helps to pipe new issues into a channel in slack. It makes people aware of the number of issues that are coming in and people can take a look in to help when they have time, without all issues ending up in their inbox or having to remember to look at the issue list. It also means team members just need to subscribe to the labels that they are interested/are domain experts in. I doubt that anyone receives emails for all new issues in any of our trackers, they'd never be able to get through them all.

I think we should:

• Start with a new slack channel for omnibus issues and also the runner.
• Add issue templates that (aim to) ensure that the correct info is provided at the time the issue is raised
• I can also enforce this if I move an issue over from CE or EE
• Add a default issue template that outlines the rules for using the tracker
• We do this for CE to cut down on the number of support requests raised and encourage users to use the community channels such as the Community Forum and Stack Overflow
• We suggest that only Feature Proposals and reproducible bugs be raised and our issue triage policies also reflect this so we can link to those when we close off a support request. (This feels bad to do as GitLab is an open source product, and the team is full of friendly people who are super keen to help, but there are too many support requests to field them all successfully and do everything else we need to do)
• Have all domain experts subscribe to their relevant labels
• That way other people that are triaging need only add a label and know that the correct people will receive an email about it
• This requires that the project's labels be fairly comprehensive

Start with a new slack channel for omnibus issues and also the runner.

I am against this, the noise ratio is already insane so introducing another channel (that will ultimately be ignored) won't help in my view.

Add issue templates that (aim to) ensure that the correct info is provided at the time the issue is raised.

We should definitely do better on this. We have an issue template but it is to long and to vague. Improving it should be our first task. @gitlab-build-team can someone propose a draft of a better issue template given the experience we have gathered? We can ask @markglenfletcher to help us with refining it.

Have all domain experts subscribe to their relevant labels

All Build team member should be subscribed to Build label in CE/EE issue tracker and should also be subscribed to the omnibus-gitlab issue tracker. I've mentioned this multiple times to everyone. If someone hasn't done it yet, they should be doing it now.

mentioned in merge request gitlab-com/www-gitlab-com!6027 (merged)

mentioned in merge request !1553 (merged)

closed via merge request !1553 (merged)

mentioned in commit fe01fd93

mentioned in commit gitlab-com/www-gitlab-com@b85be855