TestEngineering/Performance/Triage Process: Difference between revisions

TestEngineering/Performance/Triage Process (view source)

Revision as of 21:08, 28 April 2020

1,435 bytes added , 28 April 2020

m

clarify goal of triage duty

Mjzffr

Confirmed users

378

edits

@@ Line 1: / Line 1: @@
 == Triage Workflow ==
+=== Triage Duty ===
+Your main goal during triage duty is to make sure bugs are labelled appropriately and quickly based on recent bug activity. This might mean checking bug activity once a day, perhaps doing some minimal investigation, and then updating the bug's priority, severity, product, status, need-info, etc.
+See [[#Queries|Useful Queries]].
+* Triage incoming bugs as early as possible or at least once a day.
+* Intermittent failures:
+** Only investigate an intermittent failure if it has happened more than once.
+** 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 or person on triage duty 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.
+* Untriaged bugs:
+** 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.
+* Mentored bugs:
+** It's generally up to the bug mentor to keep these bugs in good shape. Feel free to need-info the mentor if you have any doubts.
+** Set needinfo on the most recent contributor if they haven't replied for more than a week.
+** Never set a contributor as assignee. This will be done automatically by Phabricator when the initial patch gets submitted. Reset the assignee and set the bug to new if no further response comes in within a week.
+** Leave the priority as is and don't change it to P1 if such a bug gets assigned.
+* 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].
+=== Queries ===
+* [https://bugzilla.mozilla.org/buglist.cgi?priority=--&keywords=meta%2C%20&query_format=advanced&product=Testing&resolution=---&list_id=15153821&keywords_type=nowords&component=AWSY&component=Performance&component=Raptor&component=Talos Untriaged bugs]
+* [https://bugzilla.mozilla.org/buglist.cgi?priority=--&keywords=meta%2C%20&query_format=advanced&product=Testing&resolution=---&list_id=15153821&keywords_type=nowords&component=AWSY&component=Performance&component=Raptor&component=Talos Intermittent failures]
+* [https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&o1=isnotempty&component=AWSY&component=Performance&component=Raptor&component=Talos&f1=bug_mentor&resolution=---&product=Testing&list_id=15153825 Mentored bugs]
+=== Triage Duty versus Triage Owner ===
+* Every bug component has a Triage Owner. This is an ongoing, long-term role.
+* Anyone on the team may be assigned to Triage Duty. This is a short-term role that involves monitoring incoming bugs on a daily basis.
 * The triage team decides who is on triage duty until the next triage meeting, which means triage duty usually rotates on a weekly basis.
-* Triage incoming bugs as early as possible or at least once a day. To be able to do that there should be at least one person who is watching the component for all changes. * Only investigate an intermittent failure if it has 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 or person on triage duty 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].
-* 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.
-* Check regularly for mentored bugs, and set needinfo if there wasn’t a reply from the contributor for more than a week. Never set a person as assignee, given that this will be done by Phabricator itself when the initial patch gets submitted. Reset the assignee and set the bug to new if no further response comes in within a week. Also leave the priority as is and don't change it to P1 if such a bug gets assigned.
 === Bugs being worked on ===