Release cycle triage proposal

We’ve done this a few times now, so maybe a good time to review. I have thoughts on a few specific topics.

P-high - what’s it mean?

We are down to 3 P-high bugs!

This is awesome. We are ruthless at triage. It’s probably time to think again about what P-high means based on what we’ve learned, as well as how to make sure the right bugs are P-high.

My best guess is that P-high means ‘critical to fix right now’. As a corollary, that also means ‘somebody is assigned’. If we’re not willing to assign somebody thin it must not be critical.

P-high - how do we get more of them?

Is it really only 3 bugs that we think are important to fix right now? We’ve structured this to be great at demoting P-high bugs, but not uncovering new ones - most P-medium seem to stay P-medium. Should we incorporate triage of new bugs into this process? If so, it’s not clear when we’ll have the time, since there’s a steady stream of new bugs.

Regressions

Similar to the last, we’re not doing anything in particular to uncover regressions and promote them to P-high. Just hoping that individuals are watching the incoming issues and tagging them right.

Frequency

We still haven’t gotten through the backlog of P-medium bugs, and per the previous topics there’s still more useful triage we probably should be doing. Anybody interested in bumping the frequency from every 3 weeks to every 2 weeks?

cc @compiler_subteam, @lang_subteam, @sanxiyn @steveklabnik @alexcrichton @jntrnr reviewing the triage process