Compatibility/WebCompat Priority Flags: Difference between revisions
m (→WebCompat Priority project flag: add another note) |
(add link to most common issues) |
||
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. You may want to discover the [[Compatibility/CommonIssues|most common Webcompat issues]]. | ||
[[File:Webcompat-priority-flag.png|frame|left]] | [[File:Webcompat-priority-flag.png|frame|left]] |
Revision as of 01:32, 20 October 2020
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 most common Webcompat issues.
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.
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:
- 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. 6. Great success, promotions for everyone. 👑
How do we decide between P1, P2, and P3? Mike tried to balance the notion of "severity" with a sites impact (measured by popularity). The Trexa list is a good list to use to determine that: trexa.webcompat.com/lists
Webcompat Priority? bugs
Webcompat Priority? bugs are regularly triaged with the following outcomes:
1. webcompat+ is set and a priority is assigned to one of the following whiteboard tags, depending on the number of affected sites (or dupes), or how the issue affects top sites or other strategic initiatives.
- [Webcompat Priority:P1]: highest impact bugs or features for web compatibility
- [Webcompat Priority:P2]: medium impact bugs of features for web compatibility
- [Webcompat Priority:P3]: low impact bugs or features for web compatibility (but still considered important).
2. The tracking flag is left alone. The intention is to keep potentially important issues on our radar by not removing the flag — as we become aware of more site breakage it will be re-triaged and prioritized accordingly.
3. The tracking flag is cleared. This probably means the issue is not considered a compatibility issue.
Untracked queries
All bugs
Category | Untracked | Untracked to Revisit |
DOM | webcompat? | webcompat-revisit |
Layout | webcompat? | webcompat-revisit |
All | webcompat-revisit | |
Non-Core | webcompat? |