canmove, Confirmed users, Bureaucrats and Sysops emeriti
4,714
edits
TestEngineering/Performance/Triage Process: Difference between revisions
TestEngineering/Performance/Triage Process (view source)
Revision as of 12:54, 12 February 2020
, 12 February 2020Update for monday triage and less often failures
(→FAQ) |
(Update for monday triage and less often failures) |
||
| Line 3: | Line 3: | ||
* 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, unless they need investigation and a fix immediately. Then set a priority of P2 and find an owner. | * 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. Failures which happened less often (like lesser than 10 times in the last week) you can simply ignore. | ||
* 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]. | ||
* Bugs without a priority set should move to P3 by default, which means it will be fixed at some point. Only set P2 if the bug blocks current OKRs. | * Bugs without a priority set should move to P3 by default, which means it will be fixed at some point. Only set P2 if the bug blocks current OKRs. | ||