> > One place we've been weak historically is in distinguishing between > tickets we consider "nice to have" and things that are "blockers". We don't > have any metadata that currently distinguishes those two, so determining > what our burndown leading up to 5.0 looks like is a lot more data massaging > and hand-waving than I'd prefer right now. >
We distinguish "blockers" with `Priority=Urgent` or `Severity=Critical`, or by linking the ticket as blocking to a specific ticket that spells it out. We do have the metadata, but yes it requires some work… The project previously made an agreement to one release a year, akin to a release train model, which helps justify why fixVersion 5.x has just fallen to be "next". (And then there is no "burn-down" in such a model.) Our release criteria, especially post-branch, demonstrates that we do introduce and rely on "blockers". If we agree that certain exceptional CEPs are "blockers", a la warrant delaying the release date, using this approach seems to fit in appropriately. When I (just) folded fixVersion 4.2 into 5.0 (and 4.x into 5.x), I also created 5.1.x and 6.x. I (and others) wish to do the exercise of running through our 5.x list and pushing out everything we can see with no commitment or activity (and also closing out old and now irrelevant/inapplicable tickets) (and this will be done via a proposed filter). But a question here is the fixVersion can infer where a ticket can be applied (appropriateness) or where we foresee it landing (roadmap). For example we mark bugs with the fixVersions ideally they should be applied to, regardless of whether anyone comes to address them or not.
