TestEngineering/Performance/Triage Process: Difference between revisions

TestEngineering/Performance/Triage Process (view source)

Revision as of 15:53, 10 February 2020

1,414 bytes added , 10 February 2020

Revised triage process for performance team

Whimboo

canmove, Confirmed users, Bureaucrats and Sysops emeriti

4,714

edits

@@ Line 1: / Line 1: @@
-* When triaging, review new, P1, intermittent, and mentored bugs
+Workflow:
-* Set a priority as early as possible (gut feeling is okay)
-* Triage search is based on new bugs since last triage, plus bugs without priority
+* 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.
-* P1: Make sure there are enough to work on
+* 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.
-* P1: Must have someone assigned and actively working on the bug
+* 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.
-* P1: If blocked, link the dependent bugs and prioritise/assign them
+* 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 triage meeting.
-* P2: Must have someone assigned for when it becomes P1 or when P1 work is blocked
+* 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.
-* P3: Backlog and good candidates for community to work on
+* 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.
-* P3: We can plan sprints where we take a break from higher priority work
+* When you start working on a bug, set its priority to P1 and assign yourself.
-* P3: Consider marking as mentored good first bugs
+* When you stop working on a bug or when it is blocked by another one, reset the priority to its original value, and unassign yourself.
-* P4: Not currently in use
-* P5: No intention to fix but will accept patches
+Priorities:
+* P1 - This bug represents an OKR, and has an assignee working on an implementation
+* P2 - This bug represents an OKR, but no-one is working on it at the moment
+* P3 - This bug will be fixed eventually (non-OKR, mentoring)
+* P4 - Not used (reserved for bots)
+* P5 - Used for intermittent failures, or no intention to fix but will accept patches