As a result of what we’ve learned during triage over the last few months, and per discussion earlier today, I’d like to suggest adding milestones to the issue tracker that correspond to our release cycles.
There are several motivators but the pressing one related to the definition of P-high. During the aforementioned triage process we’ve considered P-high to mean “so critical that somebody is committed to working on it right now”. To get sense of what kind of things fall into this category, here is the current set.
This has meant that the set of P-high bugs has been drastically reduced, and some important bugs that we’d like to revisit soon are now P-medium. In theory, we can retriage P-medium regularly to dig out new P-high bugs, except that P-medium is quite a large set, and doesn’t look to be reducing much.
So P-high is “critical” stuff, and there’s effectively no bucket for high-priority bugs.
So I’d like to suggest we instead re-broaden the meaning of P-high to just “high priority bugs, per the opinion of the respective teams”, and move the critical bugs to milestones. Since the critical bugs generally represent things that must be finished this cycle, I think it makes sense to use milestones for this. And I suspect that having milestones scoped to each release cycle will be utilized in the process decided on for roadmapping.
These milestones would represent the release cycle, but not strictly a release. That is, they represent work happening during some 6 week period of time. So e.g. work that must be done in this cycle, before nightly 1.13 becomes beta and before beta 1.12 becomes stable, regardless of whether that work is destined for nightly or beta, goes into the “2016-08-18 - 2016-09-29 (nightly-1.13 / beta-1.12)” milestone. Obviously that naming is a mouthful, but it makes clear all the units of time involved.
Opinions?