This totally breaks the mac team's triage process. 

Agreed, this rule should only fire if the original reporter commented after the Needs-Feedback label was applied.

To the second point... The problem w/ past usage of Needs-Feedback was that people weren't going back and evaluating once a response was provided/ nor clearing the labels  (i.e. we'd accumulate them en masse, and wouldn't take action in the few instances where we got a response).

Without some form of ownership to push forward on issues w/ legitimate responses (again this case was a bug that needs to be fixed), teams historically have not been good about making progress/ finding these issues (since it relied on people to notice).  For teams w/ rotations, the follow-up action on the assignee could simply be to flip it to Untriaged and let the normal triage process take care of it... my suspicion is that (w/ out bugs) the volume of these re-assignments will be low/ manageable based on regular response rates.

The volume of this triggering is too high. One can easily add Needs-Feedback to half a dozen bugs in a two-day sheriff rotation. For all these to come back to you as an assigned issue is too much. This is already happening to me.

But another issue I have with this is that it's also changing the Status. Not all bugs that get feedback are necessarily confirmed (i.e. go to Untriaged), sometimes they need more information. So there can be multiple rounds of fighting with sheriffbot over a bug.

A weaker form of this would be to just ensure that whomever added Needs-Feedback is CC'd when the original reporter responds. Don't muck with the Status or Owner field.

We fixed this to check "Needs-Feedback" label in the reverse chronological way. Now this rule will only fire when original reporter replies after the last "Needs-Feedback" label. This change was landed on mar 15th.
Thanks

Has it been deployed? https://bugs.chromium.org/p/chromium/issues/detail?id=582100#c14 happened yesterday.

Let me check again.

Thanks rsesek@ for letting us know.
Looks like this a bug with issue tracker as the comments are not returned after an automatic comment added. we are tracking this in issue 596607

Related  bug 596740 .

Is there any particular reason that we aren't moving forward with:

"""
A weaker form of this would be to just ensure that whomever added Needs-Feedback is CC'd when the original reporter responds. Don't muck with the Status or Owner field.
"""

Doesn't this accomplish your goal of getting the person who requested Needs-Feedback to take another look at the bug?
[While simultaneously not implying that the bug has been triaged, and also has an owner]

Perhaps a different approach.  (Assuming that no owner was specified) We could set the owner as the person who requested feedback, but not change the status if it's Untriaged (jury is out for Available).

That creates two opportunities for triage, one by the person managing their own bug queue (which hopefully people do) and another by the regular triage cycle for the team (which maybe done by a different person).  This would increase the visibility of important issues w/ out being overly burdensome on any party.

What about if the status is Unconfirmed?

What is the goal of setting an OWNER, rather than just cc-ing? Is the idea that by setting an OWNER, the person is more likely to respond to the bug? In the example given, setting an OWNER appeared to not make a difference.

Right now in the crbug system, the defacto assumption is that an OWNER is responsible for fixing a bug. Attempting to override this field to have a different meaning (the OWNER is responsible for responding to the feedback) is confusing.

Re-raising to Pri-1 since this is still interfering with existing workflows. This new automation was rolled out without announcement or comment, where this issue could have been identified ahead of time.

Can we either disable this automation until a resolution is implemented, or implement what I suggest in #4?

Outside of the the Mac team's triage practices, in many cases the owner will likely be the requester... which has added benefits to visibility for things like weekly reporting (i.e. it will come up in people's reports).

That being said, let's change the behavior so as not to change the status, since that seems to be the root of the concern here (in addition to the original logic error).

Chatted with Anthony (laforge@) and cdavid@ is going to implement what Anthony suggested at comment #12.

Implemented as suggested in #12

if owner not present: then add the "Needs-Feedbac" 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.

We should see this change from tomorrow's run.

Thanks

Thanks! This is definitely an improvement.