On Tue, Feb 2, 2016 at 7:44 AM, Benjamin Smedberg <benja...@smedbergs.us> wrote:
> To keep focus and avoid creeping scope, an explicit non-goal of this > program is to deal with the prioritization of non-critical bugs within a > team or component. The primary goal here is to solve the flow for incoming > bugs to a clear decision-state. Beyond the bucket of "backlog of work", > teams can continue to use aha or tracking bugs or external spreadsheets. > I'm still a little unclear. The first part seems to imply that a minimal triage process for this program would be to just flag all new bugs as either "this is a critical issue that must be fixed for the next release" or "not". But for many bugs, a "clear decision-state" does involve interplay with how things get prioritized. It also seems to be saying there should be a backlog of unprioritized work, which I think experience with the firefox-backlog flag has shown to work extremely poorly. (* - outside of a teams that are using it as a side effect of closely tracked and prioritized work.) Justin _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
