Compatibility/WebCompat Priority Flags: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(removing duplicate content.)
m (Karlcow moved page Compatibility/WebCompat Tracking And Triage to Compatibility/WebCompat Priority Flags: Better title for what people are really searching.)
 
(3 intermediate revisions by the same user not shown)
Line 1: Line 1:
This page explains Webcompat Priority flags on Bugzilla. There is a specific [[Compatibility/Webcompat Reports|process for Triaging and processing webcompat.com reports]].
== WebCompat Priority project flag ==
== WebCompat Priority project flag ==


A Bugzilla "Webcompat Priority" project flag exists, and people can set its value to "?" to put a bug on the radar of this triage program. You may want to discover the [[Compatibility/CommonIssues|most common Webcompat issues]].
A Bugzilla "Webcompat Priority" project flag exists, and people can set its value to "?" to put a bug on the radar of this triage program.  


[[File:Webcompat-priority-flag.png|frame|left]]
[[File:Webcompat-priority-flag.png|frame|left]]
Line 7: Line 9:
<br clear=all>
<br clear=all>


The basic idea is as follows:
* [[Compatibility/Core Bugs|Core Bugs with an assigned Webcompat Priority]]
* [[Compatibility/Core Bugs Triage|Core bugs in need to be triaged]]
 
== Webcompat Priority Meaning on Bugzilla ==
 
'''Webcompat Priority''' is an intended signal for the Core Teams to help them decide along Severity, Performance, Business objectives, if the work should be prioritized for a team. A core team may decide it's not worth working on this right now based on the Webcompat Priority. The '''Webcompat Priority''' will change depending on the circumstances. It can start as a P3 and evolves with time toward a P1, because the issue is acute across the Web.
 
Webcompat Priority have 3 essential values: from P1 to P3. P1 is the highest priority.


1. The WebCompat team triages and diagnoses site compat bugs (generally reported by our users to webcompat.com).
* '''P1''': The Webcompat team sets P1 when usually the Core bug creates issues for a lot sites (spread widely) OR if the site has a high ranking internationally or in a specific locale (it affects a lot of users). A good indicator is to look at the seeAlso list of bugs and/or duplicates on this bug. We try as much as possible to have real live websites, more than just test cases illustrating the issues. A known implementation difference (aka interoperability issues) between Blink, WebKit and Gecko doesn't necessary create a higher priority for Webcompat.
* '''P2''': @@better definition here@@
* '''P3''': When a Webcompat issue affects a live site with a low ranking, we will usually start the priority at P3.
* '''revisit''': When we are not sure yet what we should do with this bug. It's not entirely clear that it breaks real websites in a significant way that would make it a priority. Some interop issues might fall in this category where we know that there are implementation differences, but these do not create breakages online.
* '''-''': Ideally this is never set because it seems rude. Clearing the flag for non-priorities seems like a better outcome.
* '''---''': This clears the flag. Perhaps this is a performance or a UI issue, or something else entirely. Not really an interop bug.


2. When they discover core interop bugs (as opposed to site bugs), they file a bug on Bugzilla, or identify an existing bug.


3. The WebCompat Priority flag is set to "?" to nominate it for triage. Historically this has been done by Mike Taylor, with other Engineering Managers and Product Managers.


4. The "?" bugs are triaged and given one of N values:
== From Webcompat issues to Core Bugs ==
* P1: This bug breaks either a lot of sites, or a top site. It should be fixed first.
* P2: This bug breaks either a lot of sites, or a top site. It should be fixed next.
* P3: This bugs breaks some sites, and should eventually get next. These bugs probably end up as P2s and P1s at some point.
* revisit: This bug breaks a site, but it's either very long-tail or an edge case. Come back in case we discover this breaks more sites to get a higher priority.
* -: Ideally this is never set because it seems rude. Clearing the flag for non-priorities seems like a better outcome.
* ---: This clears the flag. Perhaps this is a performance or a UI issue, or something else entirely. Not really an interop bug.


5. Somebody works with Engineering Managers to ensure these bugs are prioritized and fixed.
=== Triage Process ===
6. Great success, promotions for everyone. 👑


How do we decide between P1, P2, and P3? Mike tried to balance the notion of "[[Compatibility/Severity_Triage|severity]]" with a sites impact (measured by popularity). The Trexa list is a good list to use to determine that: trexa.webcompat.com/lists
The basic idea is as follows:


# The WebCompat team triages and diagnoses site compat bugs (generally reported by our users to webcompat.com).
# When they discover core interop bugs (as opposed to site bugs), they file a bug on Bugzilla, or identify an existing bug and they set `Webcompat Priority: ?` if it has not been set yet.
# During the Core Triage Meeting every other week of the Webcompat team Meeting, the Webcompat team (mostly people diagnosing webcompat issues) is looking at assessing a '''Webcompat Priority''' flag by checking the '''?''' bugs. (see above for the definition of values).


==== Untracked queries ====  
==== Untracked queries ====  

Latest revision as of 08:21, 2 April 2022

This page explains Webcompat Priority flags on Bugzilla. There is a specific process for Triaging and processing webcompat.com reports.

WebCompat Priority project flag

A Bugzilla "Webcompat Priority" project flag exists, and people can set its value to "?" to put a bug on the radar of this triage program.

Webcompat-priority-flag.png


Webcompat Priority Meaning on Bugzilla

Webcompat Priority is an intended signal for the Core Teams to help them decide along Severity, Performance, Business objectives, if the work should be prioritized for a team. A core team may decide it's not worth working on this right now based on the Webcompat Priority. The Webcompat Priority will change depending on the circumstances. It can start as a P3 and evolves with time toward a P1, because the issue is acute across the Web.

Webcompat Priority have 3 essential values: from P1 to P3. P1 is the highest priority.

  • P1: The Webcompat team sets P1 when usually the Core bug creates issues for a lot sites (spread widely) OR if the site has a high ranking internationally or in a specific locale (it affects a lot of users). A good indicator is to look at the seeAlso list of bugs and/or duplicates on this bug. We try as much as possible to have real live websites, more than just test cases illustrating the issues. A known implementation difference (aka interoperability issues) between Blink, WebKit and Gecko doesn't necessary create a higher priority for Webcompat.
  • P2: @@better definition here@@
  • P3: When a Webcompat issue affects a live site with a low ranking, we will usually start the priority at P3.
  • revisit: When we are not sure yet what we should do with this bug. It's not entirely clear that it breaks real websites in a significant way that would make it a priority. Some interop issues might fall in this category where we know that there are implementation differences, but these do not create breakages online.
  • -: Ideally this is never set because it seems rude. Clearing the flag for non-priorities seems like a better outcome.
  • ---: This clears the flag. Perhaps this is a performance or a UI issue, or something else entirely. Not really an interop bug.


From Webcompat issues to Core Bugs

Triage Process

The basic idea is as follows:

  1. The WebCompat team triages and diagnoses site compat bugs (generally reported by our users to webcompat.com).
  2. When they discover core interop bugs (as opposed to site bugs), they file a bug on Bugzilla, or identify an existing bug and they set `Webcompat Priority: ?` if it has not been set yet.
  3. During the Core Triage Meeting every other week of the Webcompat team Meeting, the Webcompat team (mostly people diagnosing webcompat issues) is looking at assessing a Webcompat Priority flag by checking the ? bugs. (see above for the definition of values).

Untracked queries

All bugs

Category Untracked Untracked to Revisit
DOM webcompat? webcompat-revisit
Layout webcompat? webcompat-revisit
All webcompat-revisit
Non-Core webcompat?

Recently Fixed Bugs

Priority set, fixed in the last 2 months

Priority unset, fixed in the last 2 months