Sheriffbot taking bugs out of triage queue [Sheriffbot-Auto-triage Rule: Needs-Feedback Bugs, already received feedback 7 days ago] |
||||
Issue descriptionSheriffbot-Auto-triage Rule: Needs-Feedback Bugs, already received feedback 7 days ago. Add Bug number which got updated: Issue 592263 Issue/Concern or feedback: Sheriffbot set the bug status to `Assigned` which took it out of the Mac bug triage queue. The new owner ignored the bug, and it took possibly a week longer for a serious M49 regression to reach the attention of the right owner. That happened in another bug -- Issue 594343 . Luckily, there, Sheriffbot assigned someone on the Mac bug triage rotation who directed it to an owner who could act quickly. Any other important details: This is actually a tricky bug to triage, since it only occurs on specific hardware. So I think all the people involved took reasonable steps. However, setting `Unconfirmed` bugs to `Assigned` is totally the wrong thing to do, since it's effectively confirming the bug as well as triaging it.
,
Mar 22 2016
Related bug 596470 .
,
Mar 22 2016
Raising priority. This caused a RB-S bug to be ignored for over a week.
,
Mar 22 2016
,
Mar 22 2016
> What would you propose for that case, that would have gotten action/ attention more promptly? In this case simply setting an owner, but leaving the triage state as `Unconfirmed` may have worked a lot better. Some may argue that (Status="Unconfirmed" && Owner!="") breaks some invariant, but I'm not one of those people.
,
Mar 22 2016
What about shifting from Unconfirmed to Untriaged (rather than Assigned), since there is some confirmation? The reason I ask is that most teams don't tend to look at Unconfirmed issues in their normal triage flow, so keeping that status may not increase the visibility appropriately.
,
Mar 22 2016
Untriaged would work. I know personally I don't hesitate to move bugs back to unconfirmed if they're not yet. Unconfirmed would also be OK in the workflow we use for Mac. We do tend to de-prioritize Unconfirmed bugs still with a Needs-Feedback label, but Unconfirmed + no Needs-Feedback label is typically a strong triage signal. We can probably tweak our queries so that these get raised up in the list.
,
Apr 4 2016
We made following changes to the rule: When no feedback received: 1."No feedback was received from the reporter (....)," added to comment. When feedback is received: if owner not present: then add the "Needs-Feedback" requester as owner. No status changed. if already has a owner (provided the owner is not the reporter) then ignore setting the owner. Status not changed. Along with that remove "Needs-Feedback" label and add "Needs-Review" for tracking. More details are found in issue 596470 .
,
Apr 5 2016
Thanks! If the status isn't changing then I'd consider this fixed, since that won't hide the bug from our triage process. cc mark/sarah who are on the mac triage rotation this week and can comment if they see anything weird. |
||||
►
Sign in to add a comment |
||||
Comment 1 by lafo...@chromium.org
, Mar 22 2016