Figuring out how to handle diagnosis more efficiently

[denschub]

Our current diagnosis backlog is a bit too large for my personal comfort. And unfortunately, some of the issues are quite old already. This is the distribution of our current diagnosis backlog:

Having issues that are 3-6 months old is usually no issue, but after that, issues frequently become impossible to diagnose because the site changed. It's quite possible that we're missing out on a few Gecko issues, just because we didn't get around looking at them.

I'm not creating this OKR to set up a specific goal, like "have no diagnosis issue older than 3 months without someone looking at it" or something. Instead, I think we should get together and ask ourselves if there is anything we can do to avoid this situation:

• Maybe we decide to spend less time on simple visual issues that don't break the usage of a site?
• Maybe different workflows during diagnosis might help? Maybe different tooling? For example, I recently realized that I pretty much never look at the Compatibility panel in the devtools, even though they can be a source of useful hints (and we can even extend that panel ourselves to add more "warning triggers")
• Maybe we should get better at asking other Mozilla engineers to help out if we don't see the source of a problem? Maybe we could even establish a communication channel that we can use to get someone elses help without pinging people directly and depending on them respond?

There's a lot of different ideas, and others have other ideas. Let's spend some good time on figuring that out.

No time estimate for this card. The initial discussions can be done async, and don't take too much time. Depending on the nature of ideas coming up, we might have to spend additional time. And the whole Diagnosis task is one of our Background Noise tasks anyway, so a good time estimate for the whole Diagnosis story would probably be "as much time as we have left". :)