Can anyone take a look at this?

I can take a look this week if needed. If I don't hear back I'll assume this isn't actively being worked on and steal the bug.

Martin, this bug is not being actively worked on.

Thank you Alex for pinging on this bug, Austin is on vacation for a month now (coming back on Thursday) and I didn't get chance to spend time on sheriffbot due to release activities.

Both of the rules related to release blockers seem straightforward. Modifying the priority is trivial and it should be easy enough to determine which milestone should be applied if it's missing.

What to do for the Pri-1 rule is a bit less obvious, though. I don't think that requesting that someone apply a milestone would be very fruitful, but we could default to something like the current dev. Maybe we should also leave a comment requesting that it be adjusted to something appropriate manually, but I don't think this will be effective. WDYT?

Sorry should have commented on this earlier.  We shouldn't be modifying the priorities, that's a partial signal on the appropriateness of a blocker (i.e. potentially nice to have versus not).  That would just incentivize people set P1 for everything.

I agree w/ the second part though, for P1 and RB, we should comment that there should be associated milestones.  

With RB, you could (in theory) infer the milestone, based on the channel indicated... I believe that I wrote a service on chromepmo that does that for the issue tracker wizard.

I have a way in sheriffbot to work out the milestones from channels, that part should be fine.

For P1 I'm not sure how effective simply commenting would be, but I also don't think throwing a default milestone on there necessarily makes sense. I'm happy to implement the comment if it's the best solution.

Commenting instead of automatically changing stuff is fine for me if we want to start there.

Also since I can't find the other bug, an associated request - RB bugs should have an OS associated with them.  Let's nag for this as well?

Cleaning up my old bugs. Not sure if I'll be able to get around to this, or if there's actually anything to do based on c#5 and some offline discussions. I'm hesitant to comment about missing priorities, though commenting for missing OS on RB bugs seems reasonable.

We just had a Pri-0 RB-Stable bug go unnoticed until the last minute since there was no milestone attached ( issue 698315 ).  Contrary to c#8 I do believe there is work to be done here.  Is there anyone still working on this that can pick this up?

I can pick this up. Will work on adding comment based on #5 #7.

Things to do:

1. Add comment when "P0/P1 RB" issues don't have milestones. 

2. Add comment when "RB bugs doesn't have an OS associated.". [Do we need to ignore certain components when implementing this?]

Please do let me know how many/ often times we need to nag them.

Weekly would probably be appropriate.  I'd also suggest ensuring the person who added RB-Foo or Pri-0/1 is on cc (assuming that they aren't the owner or filer).

Thanks will add that too.

> 1. Add comment when "P0/P1 RB" issues don't have milestones. 

Let's always add a comment for any RB issue, not just P0/P1; all RB issues should have milestones.

> 2. Add comment when "RB bugs doesn't have an OS associated.". [Do we need to ignore certain components when implementing this?]

No, we don't need to ignore certain components, release blockers should always have OS'es.

Thanks cdavid@ for looking at this, appreciate it!

CL submitted.

Now we should see comments for 

1. All RB issues with no Milestone 
2. All RB issues with no OS labels

Also note that the RB label adder will be cc'ed(if they are not owner/reporter.)

I think we might have a bug here somewhere - please see the comment applied to this issue: https://bugs.chromium.org/p/chromium/issues/detail?id=703599#c7

It looks like we're CC'ing wayyyyyy too many people there...

Reverted the change and cleaned up all the affected bugs. We will fix and re-land.
Thanks

This issue mentioned in comment #15 is fixed and change is landed.