(First draft of triage page) |
(Merging triage page with backlog page) |
||
| (8 intermediate revisions by 2 users not shown) | |||
| Line 3: | Line 3: | ||
This page contains information related to bug triage processes and procedures for Gecko layout and CSS bugs. | This page contains information related to bug triage processes and procedures for Gecko layout and CSS bugs. | ||
= Components | = Components = | ||
The following are the Bugzilla components in the | The following are the Bugzilla components in the <code>Core</code> product that the Platform Layout team is responsible for: | ||
* [https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=CSS+Parsing+and+Computation CSS Parsing and Computation] | * [https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=CSS+Parsing+and+Computation CSS Parsing and Computation] | ||
| Line 14: | Line 14: | ||
* [https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Layout:+Flexbox Layout: Flexbox] | * [https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Layout:+Flexbox Layout: Flexbox] | ||
* [https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Layout:+Floats Layout: Floats] | * [https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Layout:+Floats Layout: Floats] | ||
* [https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Layout:+Form | * [https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Layout:+Form Layout: Form] | ||
* [https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Layout:+Generated+Content,+Lists,+and+Counters Layout: Generated Content, Lists, and Counters] | * [https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Layout:+Generated+Content,+Lists,+and+Counters Layout: Generated Content, Lists, and Counters] | ||
* [https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Layout:+Grid Layout: Grid] | * [https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=Layout:+Grid Layout: Grid] | ||
| Line 29: | Line 29: | ||
= Triage Guidelines = | = Triage Guidelines = | ||
The definition of Triaged is bugs of type <code>defect</code> where the component is not <code>UNTRIAGED</code>, and a Severity value not equal to <code>--</code> or <code>N/A</code>. | |||
<br/>Bugs of type Task or Enhancement may have a Severity of <code>N/A</code>, but defects must have a Severity that is neither <code>--</code> nor <code>N/A</code>. | |||
For an overview of Bugzilla triage see the documentation [https://firefox-source-docs.mozilla.org/bug-mgmt/policies/triage-bugzilla.html Triage for Bugzilla] | |||
== How To Triage == | == How To Triage == | ||
Ensure that the bug is in the proper component. Is it a | Ensure that the bug is in the proper component. Is it a Layout bug? If not, move it to a more appropriate component and allow the triage owners of that component to take over from there. | ||
Otherwise, if you can reproduce the bug: | Otherwise, if you can reproduce the bug: | ||
# Change its status from | # Change its status from <code>UNCONFIRMED</code> to <code>NEW</code>. | ||
# Set the severity of the bug using the guidance on severity listed below. | # Set the severity of the bug using the guidance on severity listed below. | ||
# Preferably, provide a brief comment as to why you believe the bug meets the criteria of the severity you are setting. | # Preferably, provide a brief comment as to why you believe the bug meets the criteria of the severity you are setting. | ||
If you cannot reproduce the bug: | If you cannot reproduce the bug: | ||
* Do not set the severity until the bug can be reproduced. Leave it in | * Do not set the severity until the bug can be reproduced. Leave it in <code>UNCONFIRMED</code> status. | ||
* Consider asking the reporter for more information or a reduced test case if possible. (Make sure you need-info the reporter as part of your comment.) | * Consider asking the reporter for more information or a reduced test case if possible. (Make sure you need-info the reporter as part of your comment.) | ||
* Consider asking others more familiar with the affected component to try and reproduce. | * Consider asking others more familiar with the affected component to try and reproduce. | ||
* Consider asking for QA support (MoCo employees only). | * Consider asking for QA support (MoCo employees only). | ||
== Severity | == Severity == | ||
Severity levels in Bugzilla are designated S1 - S4, in decreasing order. | Severity levels in Bugzilla are designated S1 - S4, in decreasing order. For a bug to be considered triaged, the severity level on the bug ''must'' be set. Generally, only Mozilla Layout team members or other designated contributors should be setting severity levels on bugs in layout or CSS-related components. Bugzilla users without edit bug access do not have the ability to set severity. | ||
=== S1 | === S1 - Catastrophic === | ||
Blocks development/testing, may impact more than 25% of users, causes data loss, potential chemspill, and no workaround available. | Blocks development/testing, may impact more than 25% of users, causes data loss, potential chemspill, and no workaround available. Encountering an S1 layout bug should be '''very rare'''! | ||
Examples of S1 layout bugs: | Examples of S1 layout bugs: | ||
* Any security bug with the sec-critical keyword | * Any security bug with the <code>sec-critical</code> keyword | ||
* Bugs that cause severe layout breakage on high-traffic sites, particularly breakage that results in missing or unintentionally hidden content | * Bugs that cause severe layout breakage on high-traffic sites, particularly breakage that results in missing or unintentionally hidden content | ||
* Layout bugs that break the browser user interface in significant ways | * Layout bugs that break the browser user interface in significant ways | ||
* | * Most startup crashes, unless very, very low-volume | ||
* Crashes on frequently-visited sites, or printing crashes that affect many users | * Crashes on frequently-visited sites, or printing crashes that affect many users | ||
=== S2 - Serious === | |||
Major functionality/product severely impaired and a satisfactory workaround doesn't exist. | |||
Examples of S2 layout bugs: | |||
* Any security bugs with the <code>sec-high</code> keyword | |||
* Very, very low-volume startup crashes | |||
* Most other crashes unless they are very, very low volume | |||
* Severe performance issues, such as very long restyle times or very long reflows, particularly if affecting frequently-visited sites | |||
* Bugs that cause obviously visible broken layout or unintentionally hidden content | |||
* Print output bugs that cause data loss (such as missing pages, missing content) | |||
* Webcompat issues that cause more than minor cosmetic site breakage, particularly those for which a work around is cumbersome, tedious or difficult for authors to deploy | |||
=== S3 - Normal === | |||
Blocks non-critical functionality and a work around exists | |||
Examples of S3 layout bugs: | |||
* Most <code>sec-moderate</code> and <code>sec-low</code> security bugs | |||
* Very, very low-volume crashes | |||
* Small webcompat issues that authors can work around in a relatively easy way | |||
* Smaller cosmetic issues on frequently-visited sites | |||
* Layout breakages that do not cause issues accessing/viewing content on any site | |||
* Most smaller to medium-sized performance issues, where performance is not a severe impediment to accessing a site for either desktop or mobile users | |||
=== S4 - Small/Trivial === | |||
Minor significance, cosmetic issues, low or no impact to users | |||
Examples of S4 layout bugs: | |||
* Code cleanliness issues — cleanups — that don’t directly impact users | |||
* Minor cosmetic issues that are not noticeable to most users (e.g. 1px “off”, small alignment bugs, minor rendering differences from competing browsers, unexpected scrollbars, unwanted table borders) | |||
* Minor cosmetic issues related to printing | |||
* Minor line breaking, hyphenation or ligature issues | |||
* Other edge case layout issues — even webcompat issues — that are rarely encountered "in the wild" | |||
* Minor spec conformance issues that are rarely encountered | |||
* Most WPT failure bugs from upstream changes | |||
= Common Triage Queries = | |||
A list of commonly-used Bugzilla queries for untriaged and recently-triaged bugs: | |||
* '''[https://mzl.la/49Zfvj7 Recent Untriaged Layout Bugs]''': Bugs for all layout components that were created in the last 30 days and do not yet have a set severity. | |||
* '''[https://mzl.la/3IqoE8w Recently Triaged to S1 or S2]''': Bugs that were triaged at S1 or S2 in the last 30 days, are not stalled, and not resolved. | |||
* '''[https://github.com/mozilla/wg-decisions/issues/ CSS Working Group Resolutions]''': Resolutions from the CSSWG for which we should decide whether or not to file a bug. | |||
= How We Track Our Backlog = | |||
All tracking of backlog and work-in-progress items happens in [https://bugzilla.mozilla.org/ Bugzilla]. | |||
<br/> | |||
===== Flags ===== | |||
There are several flag used to track work in Bugzilla including: | |||
* [https://wiki.mozilla.org/BMO/UserGuide#Tracking_Flags Tracking Flags] | |||
* [https://wiki.mozilla.org/BMO/UserGuide#Status_Flags Status Flags] | |||
* [https://wiki.mozilla.org/BMO/UserGuide#Project_Flags Project Flags] | |||
* [https://wiki.mozilla.org/BMO/UserGuide#Needinfo_Flag Need Info Flags] | |||
===== Assigned ===== | |||
A bug is considered "assigned" if it has both a valid assignee AND its status is set to <code>ASSIGNED</code>. Having only one of these fields set is not sufficient for it to be tracked as an assigned bug. <code>nobody[at]mozilla.org</code> is not a valid assignee for a bug to be considered assigned. | |||
= Common Backlog Queries = | |||
* [https://mzl.la/3SYnmGO Untriaged Defects] | |||
* [https://mzl.la/4c13viY Unassigned S1 and S2 Defects] | |||
* [https://mzl.la/48LwO6a Triaged S1 and S2 Defects] | |||
* '''[https://bugzilla.mozilla.org/buglist.cgi?resolution=---&classification=Client%20Software&classification=Developer%20Infrastructure&classification=Components&classification=Server%20Software&classification=Other&status_whiteboard_type=casesubstring&query_format=advanced&status_whiteboard=layout%3Abacklog Entire Layout Backlog]''': All bugs that have been tagged as backlog candidates or are on the official backlog. For more detailed backlog tracking see our [https://wiki.mozilla.org/Platform/Layout/Backlog backlog page]. | |||
* '''[https://bugzilla.mozilla.org/buglist.cgi?resolution=---&classification=Client%20Software&classification=Developer%20Infrastructure&classification=Components&classification=Server%20Software&classification=Other&status_whiteboard_type=casesubstring&query_format=advanced&status_whiteboard=%5Blayout%3Abacklog%3Aquality%5D High-Priority Quality Bugs]''': Backlog items specifically related to improving product quality (not new features/enhancements) that will improve Firefox for many sites or users. Bugs in this list ''should meet at least one of the following criteria'': | |||
** Known webcompat bug of some significance (P1 or P2 webcompat priority, or otherwise has known webcompat challenges for multiple sites or users) | |||
** Performance-related bug the fixing of which will likely improve layout performance for multiple sites | |||
** Bug tracking spec changes that could result in future webcompat issues if left unaddressed | |||
** Bugs that have been highly-upvoted by users | |||
* '''[https://bugzilla.mozilla.org/buglist.cgi?resolution=---&classification=Client%20Software&classification=Developer%20Infrastructure&classification=Components&classification=Server%20Software&classification=Other&status_whiteboard_type=casesubstring&query_format=advanced&status_whiteboard=%5Blayout%3Abacklog%3Acode-quality%5D Code Quality Bugs]''': Backlog items related to improving code quality and reducing tech debt. Fixing these bugs should be primarily motivated by improving code cleanliness and developer productivity. | |||
Latest revision as of 18:54, 14 March 2024
Summary
This page contains information related to bug triage processes and procedures for Gecko layout and CSS bugs.
Components
The following are the Bugzilla components in the Core product that the Platform Layout team is responsible for:
- CSS Parsing and Computation
- CSS Transitions and Animations
- DOM: CSS Object Model
- Layout
- Layout: Block and Inline
- Layout: Columns
- Layout: Flexbox
- Layout: Floats
- Layout: Form
- Layout: Generated Content, Lists, and Counters
- Layout: Grid
- Layout: Images, Video, and HTML Frames
- Layout: Positioned
- Layout: Ruby
- Layout: Scrolling and Overflow
- Layout: Tables
- Layout: Text and Fonts
- Print Preview
- Printing: Output
- Printing: Setup
- SVG
Triage Guidelines
The definition of Triaged is bugs of type defect where the component is not UNTRIAGED, and a Severity value not equal to -- or N/A.
Bugs of type Task or Enhancement may have a Severity of N/A, but defects must have a Severity that is neither -- nor N/A.
For an overview of Bugzilla triage see the documentation Triage for Bugzilla
How To Triage
Ensure that the bug is in the proper component. Is it a Layout bug? If not, move it to a more appropriate component and allow the triage owners of that component to take over from there.
Otherwise, if you can reproduce the bug:
- Change its status from
UNCONFIRMEDtoNEW. - Set the severity of the bug using the guidance on severity listed below.
- Preferably, provide a brief comment as to why you believe the bug meets the criteria of the severity you are setting.
If you cannot reproduce the bug:
- Do not set the severity until the bug can be reproduced. Leave it in
UNCONFIRMEDstatus. - Consider asking the reporter for more information or a reduced test case if possible. (Make sure you need-info the reporter as part of your comment.)
- Consider asking others more familiar with the affected component to try and reproduce.
- Consider asking for QA support (MoCo employees only).
Severity
Severity levels in Bugzilla are designated S1 - S4, in decreasing order. For a bug to be considered triaged, the severity level on the bug must be set. Generally, only Mozilla Layout team members or other designated contributors should be setting severity levels on bugs in layout or CSS-related components. Bugzilla users without edit bug access do not have the ability to set severity.
S1 - Catastrophic
Blocks development/testing, may impact more than 25% of users, causes data loss, potential chemspill, and no workaround available. Encountering an S1 layout bug should be very rare!
Examples of S1 layout bugs:
- Any security bug with the
sec-criticalkeyword - Bugs that cause severe layout breakage on high-traffic sites, particularly breakage that results in missing or unintentionally hidden content
- Layout bugs that break the browser user interface in significant ways
- Most startup crashes, unless very, very low-volume
- Crashes on frequently-visited sites, or printing crashes that affect many users
S2 - Serious
Major functionality/product severely impaired and a satisfactory workaround doesn't exist.
Examples of S2 layout bugs:
- Any security bugs with the
sec-highkeyword - Very, very low-volume startup crashes
- Most other crashes unless they are very, very low volume
- Severe performance issues, such as very long restyle times or very long reflows, particularly if affecting frequently-visited sites
- Bugs that cause obviously visible broken layout or unintentionally hidden content
- Print output bugs that cause data loss (such as missing pages, missing content)
- Webcompat issues that cause more than minor cosmetic site breakage, particularly those for which a work around is cumbersome, tedious or difficult for authors to deploy
S3 - Normal
Blocks non-critical functionality and a work around exists
Examples of S3 layout bugs:
- Most
sec-moderateandsec-lowsecurity bugs - Very, very low-volume crashes
- Small webcompat issues that authors can work around in a relatively easy way
- Smaller cosmetic issues on frequently-visited sites
- Layout breakages that do not cause issues accessing/viewing content on any site
- Most smaller to medium-sized performance issues, where performance is not a severe impediment to accessing a site for either desktop or mobile users
S4 - Small/Trivial
Minor significance, cosmetic issues, low or no impact to users
Examples of S4 layout bugs:
- Code cleanliness issues — cleanups — that don’t directly impact users
- Minor cosmetic issues that are not noticeable to most users (e.g. 1px “off”, small alignment bugs, minor rendering differences from competing browsers, unexpected scrollbars, unwanted table borders)
- Minor cosmetic issues related to printing
- Minor line breaking, hyphenation or ligature issues
- Other edge case layout issues — even webcompat issues — that are rarely encountered "in the wild"
- Minor spec conformance issues that are rarely encountered
- Most WPT failure bugs from upstream changes
Common Triage Queries
A list of commonly-used Bugzilla queries for untriaged and recently-triaged bugs:
- Recent Untriaged Layout Bugs: Bugs for all layout components that were created in the last 30 days and do not yet have a set severity.
- Recently Triaged to S1 or S2: Bugs that were triaged at S1 or S2 in the last 30 days, are not stalled, and not resolved.
- CSS Working Group Resolutions: Resolutions from the CSSWG for which we should decide whether or not to file a bug.
How We Track Our Backlog
All tracking of backlog and work-in-progress items happens in Bugzilla.
Flags
There are several flag used to track work in Bugzilla including:
Assigned
A bug is considered "assigned" if it has both a valid assignee AND its status is set to ASSIGNED. Having only one of these fields set is not sufficient for it to be tracked as an assigned bug. nobody[at]mozilla.org is not a valid assignee for a bug to be considered assigned.
Common Backlog Queries
- Untriaged Defects
- Unassigned S1 and S2 Defects
- Triaged S1 and S2 Defects
- Entire Layout Backlog: All bugs that have been tagged as backlog candidates or are on the official backlog. For more detailed backlog tracking see our backlog page.
- High-Priority Quality Bugs: Backlog items specifically related to improving product quality (not new features/enhancements) that will improve Firefox for many sites or users. Bugs in this list should meet at least one of the following criteria:
- Known webcompat bug of some significance (P1 or P2 webcompat priority, or otherwise has known webcompat challenges for multiple sites or users)
- Performance-related bug the fixing of which will likely improve layout performance for multiple sites
- Bug tracking spec changes that could result in future webcompat issues if left unaddressed
- Bugs that have been highly-upvoted by users
- Code Quality Bugs: Backlog items related to improving code quality and reducing tech debt. Fixing these bugs should be primarily motivated by improving code cleanliness and developer productivity.