On Thu, Mar 31, 2016 at 06:47:32PM -0700, Emma Humphries wrote: > What to call these has been a long thread in the document comments, but I'm > starting to lean towards: > > FIX-FOR-RELEASE > FIX-SOON > and > BACKLOG > > as well as adding (see the proposed edit) a FEATURE resolution for bugs > which are feature tracking and individual features. I'd consider adding a > consistency rule requiring a User Story field for bugs in that status.
If we're talking about a bmo-wide change, then a tri-state where one of the state is bound to something being released, then that only leaves two states for components that are not really attached to things making it for a particular release, or are not released at all. If we still get to use Pn and other related fields on top of that, why are we adding another field? Not that I'm against adding fields, but as someone else mentioned in the thread, we've done plenty of adding fields in the past 18 years, and that's what kind of leads to the mess we are in today. Adding a new field should be accompanied with removing other(s). On the other hand, I find it interesting that in some way, it overlaps with the existing bug status (UNCONFIRMED, NEW, ASSIGNED), and I think the document is dismissing it too quickly: "because a bug can go from UNCONFIRMED to NEW, without us knowing how important it is." to which I want to answer with another question: "then why not simply add status(es)?" Bug status is currently, IMHO, completely misused and thus useless: - people with editbug capability file as NEW by default. Why should a bug I file in a component I'm not working on (because I noticed a bug in Firefox) be NEW? - there is a long tail of bugs assigned to people that are not being worked on (I should know, I have a lot of those, shame on me) So it feels to me triage should replace/subsume it in some way. Mike _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
