This fits into the more general webcompat Guide and addresses only the Diagnosis process. Webcompat tooling is addressed in Diagnosis tooling.

Some techniques to handle needsdiagnosis workload.

Webcompat issues are distributed in two places. The story to prioritize work is slightly different at both places.

Where are the bugs?

• GitHub
• Mozilla bugzilla (only Mozilla products)
• Blink bug tracker (only Blink derivatives products)
• Webkit BrowserCompat (only WebKit issues, but probably slightly different and not everything is tracked under this keyword).

Webcompat Bugs on GitHub

We will focus first on GitHub. Every issues which are required to be diagnosed are located in the needsdiagnosis milestone. As of 2019-05-16, there is a backlog of ~150 issues. Our goal is to maintain this at the lowest number possible. We had a pick at the end of 2017 which was around 1200 bugs. This should not happen again. Not all issues are equal with regards to the work we do and our priorities. Each browser vendor will probably focus on their own bugs. Mozilla issues represent the lion share, because of the direct reporting system available on Firefox Nightly and Firefox developer Edition.

Understand the priorities

It is possible to discriminate a bit more the issues when doing needsdiagnosis work. The system has a set of labels helping to create an additional layer of filtering. This is helpful for defining priorities when attacking the needsdiagnosis.

• priority-(normal|important|critical): This label is set depending on the ranking of the website domain name where the issue is happening. A bug on a well-known website will probably affect a lot more people than an issue on a personal blog.
• severity-(minor|important|critical): This defines how bad the issue is for the usability of the website. A rounded corner issue doesn't have the same impact than a website totally blank.

Use your own judgement to make the right call with the help of these flags.

• browser-*: these are set to identified in which browser the issue is happening. Sometimes it can be multiple browsers. This would be useful to discriminate the issue if you are interested in the issues of a specific browser. For example, browser-firefox-mobile.
• engine-*: It defines the family of rendering engines the issue belongs to. Right now, only engine-gecko is available, but other vendors are welcome to add their own label.

Document your diagnosis

When starting a diagnosis, document all your findings. You may not be able to finish the diagnosis. And all the comments you made will give hints and clues for the next person in line trying to crack the issue or for the website developer to understand why/where this is failing. It will help them to track down faster the issue in their own internal systems.

What type of failures?

When diagnosing you may want to keep in mind the Web Compatibility Taxonomy, which basically describe a broad category of scenarii. It answers why the site might be failing.

Diagnosis Done?

Move the issue to the next step, be needscontact or contactready. Even sitewait, if in the process of diagnosing you already contacted someone.

For Mozilla contributors and employees

Workload Rotation System

The core needsdiagnosis team at Mozilla is composed of Dennis (denschub), Karl (karlcow), Ksenia (ksy36) and Thomas (wisniewskit), but anyone is welcome to join. We have a system of work rotation for incoming bugs.

This system doesn't prevent you to work on diagnosis when you are not on the rotation shift. See the Not So Fresh Bugs section below.

Fresh bugs

List of fresh bugs

When on rotation shift day, your job is to go through the pile of issues to diagnose for the full day (except emergencies, you may swap with someone else). A fresh bug is a bug which has not been diagnosed yet. It may include bugs which are a couple of weeks old. The date of creation or the date it landed in needsdiagnosis is meaningless. The criteria for freshness is:

Did anyone have started a diagnosis on this issue?

If the answer is no, then this is a fresh bug. You may not be able to go through all the bugs pile; It's normal. The important is to be able to do as much as possible so we don't build a backlog. Someone else will take care of the rest on the next day.

Think also about the priorities.

Not so fresh bugs

List of all needsdiagnosis issues.

During the rotation shift, and in the unlikely event, you have tackled the list of all fresh bugs, you may want to jump to the rest of the issues. These bugs need to be handled. The diagnosis has probably been started and/or the diagnoser met a dead end. Feel free to take over if you know how to solve it.

When Blocked With Diagnosis

Don't stay too long on a tough diagnosis, move to the next one. Some diagnosis may take longer. Just move to the next one, and you might have an idea in the next hour or the next couple of days on how to solve it and you can come back to it.

If your knowledge in a specific area is limited to not hesitate to ping someone else from the Mozilla Core Team and/or someone else from the Webcompat team. After years, we developed some skills in certain areas.

@@should we list here the name with the expertise for some of the domains@@