TestEngineering/Performance/Triage Process: Difference between revisions

Define priority for important intermittent failures
No edit summary
(Define priority for important intermittent failures)
Line 2: Line 2:


* Triage incoming bugs as early as possible. To be able to do that there should be at least one person who is watching the component for all changes. The triage team decides who is responsible for that task until the next triage meeting.  
* Triage incoming bugs as early as possible. To be able to do that there should be at least one person who is watching the component for all changes. The triage team decides who is responsible for that task until the next triage meeting.  
* Only investigate an intermittent failure if it happened more than once. Otherwise glimpse over the failure details, and if incomplete information has been added as the first comment, add the relevant part of the log as a new comment. If it’s a duplicate bug mark it as such, or if not related to the component move it immediately to the correct one. Intermittent failures should have a priority of P5 by default.
* Only investigate an intermittent failure if it happened more than once. Otherwise glimpse over the failure details, and if incomplete information has been added as the first comment, add the relevant part of the log as a new comment. If it’s a duplicate bug mark it as such, or if not related to the component move it immediately to the correct one. Intermittent failures should have a priority of P5 by default, unless they need investigation and a fix immediately. Then set a priority of P2 and find an owner.
* On Monday the triage owner goes through all the bugs that got updated by the intermittent failures bot. If there is a top-occurring failure make sure to assign the bug to someone familiar with the affected code.
* On Monday the triage owner goes through all the bugs that got updated by the intermittent failures bot. If there is a top-occurring failure make sure to assign the bug to someone familiar with the affected code.
* If it is not clear how to proceed on the bug, or if further input is necessary from stakeholders, add the whiteboard entry '''[perftest:triage]'''. Those bugs will be discussed in the next [https://docs.google.com/document/d/1SeMijarFsdtm-mrxkIQzV4y1PHcJN72JDPWOlxJ7u-A/edit#heading=h.v37yirv4o0rn triage meeting].
* If it is not clear how to proceed on the bug, or if further input is necessary from stakeholders, add the whiteboard entry '''[perftest:triage]'''. Those bugs will be discussed in the next [https://docs.google.com/document/d/1SeMijarFsdtm-mrxkIQzV4y1PHcJN72JDPWOlxJ7u-A/edit#heading=h.v37yirv4o0rn triage meeting].
Line 12: Line 12:
== Priorities ==
== Priorities ==


* P1 - This bug represents an OKR, and has an assignee working on an implementation
* P1 - This bug represents an OKR or an important intermittent failure, and has an assignee working on an implementation
* P2 - This bug represents an OKR, but no-one is working on it at the moment
* P2 - This bug represents an OKR or an important intermittent failure, but no-one is working on it at the moment
* P3 - This bug will be fixed eventually (non-OKR, mentoring)
* P3 - This bug will be fixed eventually (non-OKR, mentoring)
* P4 - Not used (reserved for bots)
* P4 - Not used (reserved for bots)
* P5 - Used for intermittent failures, or no intention to fix but will accept patches
* P5 - Used for intermittent failures, or no intention to fix but will accept patches
canmove, Confirmed users, Bureaucrats and Sysops emeriti
4,714

edits