Confirmed users
1,567
edits
(removing duplicate content.) |
(Gardening the Webcompat Priority triage) |
||
| Line 1: | Line 1: | ||
== 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 | 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 7: | ||
<br clear=all> | <br clear=all> | ||
The | * [[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. | |||
* '''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 == | |||
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 ==== | ||