> > > 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… > > For everything not urgent or a blocker, does it matter whether something has > a fixver of where we think it's going to land or where we'd like to see it > land? At the end of the day, neither of those scenarios will actually shift a > release date if we're proactively putting "blocker / urgent" status on new > features, improvements, and bugs we think are significant enough to delay a > release right?
Ooops, actually we were using the -beta, and -rc fixVersion placeholders to denote the blockers once "the bridge was crossed" (while Urgent and Critical is used more broadly, e.g. patch releases). If we use this approach, then we could add a 5.0-alpha placeholder that indicates a consensus on tickets blocking the branching (if we agree alpha1 should be cut at the same time we branch…). IMHO such tickets should also still be marked as Urgent, but I suggest we use Urgent/Critical as an initial state, and the fixVersion placeholders where we have consensus or it is according to our release criteria :shrug:
