<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 2, 2016 at 7:44 AM, Benjamin Smedberg <span dir="ltr"><<a href="mailto:benjamin@smedbergs.us" target="_blank">benjamin@smedbergs.us</a>></span> wrote:<br><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
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.<br></blockquote><div><br></div><div>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.<br><br></div><div>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.)<br></div><div> <br></div><div>Justin<br></div><div><br></div></div></div></div>