New issue
Advanced search Search tips

Issue 684919 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Mar 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Sheriffbot-Auto-triage Rule: Needs-Feedback Bugs, already received feedback 7 days ago

Project Member Reported by pwnall@chromium.org, Jan 25 2017

Issue description

Sheriffbot-Auto-triage Rule: Needs-Feedback Bugs, already received feedback 7 days ago.

Issue/Concern or feedback:

The 7-day latency on removing Needs-Feedback is unintuitive. I think that Needs-Feedback should be removed immediately (as quickly as possible) after there is activity on the bug. Having it linger on is confusing for bug reporters who can't remove the label, and for Chromium developers who haven't seen https://www.chromium.org/issue-tracking/autotriage

If there's concern that random activity (+1s) can trigger the removal of Needs-Feedback, would it be possible to have a comment from the bug reporter immediately remove Needs-Feedback?

Any other important details:

My team (OWP Storage) just discussed our bug triage process. The process was inefficient because our filters did not exclude Needs-Feedback issues. Now that we're excluding the Needs-Feedback issues, there's a concern that we won't see responses for a whole week.

In order to make up for this issue, our bug triage process now also requires the developers doing the triage to CC themselves on the bugs that they touch, so they can notice the response. This is error-prone, as it's super-easy for me to update a bug and forget to add myself to CC.

One could argue that Monorail's developer view of the bug edit form should have a "cc me" checkbox that's automatically ticked. This would be similar to how we're automatically involved in reviews that we participate in, unless we uncheck a box. Still, the CC issue is orthogonal to the meaning of Needs-Feedback.

That being said, thank you very much for Sheriffbot! It's been super-useful for us.
 

Comment 1 by cda...@chromium.org, Feb 16 2017

Cc: -cda...@chromium.org rsesek@chromium.org mbarbe...@chromium.org
Owner: cda...@chromium.org
Status: Assigned (was: Untriaged)
We wanted to modify this rule to:

1. Run this rule continuously (every 5 mins)  and remove "Needs-Feedback" label when Feedback is given.
2. Add the requester to the (cc' list ) instead of adding to owner.
3. Don't change status.
4. Don't add "Needs-Review" label.
5. Add comment 'Thank you for providing more feedback. Adding requester "X" to the cc list and removing "Needs-Feedback" label.'

Reason for doing this.
 1. "Needs-Feedback" label cannot be removed by reporter (if they are not a project member.)
 2. We will avoid the above situation (where Feedback Requester [Developer]  already responds and we comment again ) as we run continuously.
 3. Developer(Feedback Requester) no need to worry about removing the labels. They can add "Needs-Feedback" if they need more feedback.

Comment 2 by pwnall@chromium.org, Feb 16 2017

Thank you! This plan sounds pretty great!

Comment 3 by rsesek@chromium.org, Feb 16 2017

That sounds good. Does "when Feedback is given" only count for the original reporter?

Comment 4 by cda...@chromium.org, Feb 16 2017

Yes it counts only the reporter ping.

Comment 5 by cda...@chromium.org, Feb 23 2017

Status: Started (was: Assigned)

Comment 6 by cda...@chromium.org, Feb 28 2017

Cc: cda...@chromium.org
 Issue 643692  has been merged into this issue.
Change is submitted to run the rule continuously.
Thank you very much!

Comment 9 Deleted

Will mark this bug fixed once cleanup is done.

Cleanup Things to do:
1.Check for bugs in between this rule change (i,e bugs in the last 7 days) and remove"Needs-Feedback" label if feedback is received. link for these bugs https://goo.gl/SVFN49

2.Clear "Needs-Review" label which has been added before.
We manually went thro' the missed bugs and removed feedback label where applicable.

Still pending is to clear "Needs-Review" label.
Status: Fixed (was: Started)
Cleanup completed. Marking this bug as Fixed.

Sign in to add a comment