<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Aug 12, 2015 at 2:16 PM, Benjamin Smedberg <span dir="ltr"><<a href="mailto:benjamin@smedbergs.us" target="_blank">benjamin@smedbergs.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF" text="#000000"><span class="">
    <br></span>
    I do have a plan for how bugzilla fits in with our broader quality
    efforts<br></div></blockquote><div><br></div><div>\o/<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
    Bug reports are the primary unit of quality assurance in software.
    Bug reports from our users, but especially pre-release users, are
    essential to building a quality product. We at Mozilla have lived so
    long in a world where we don't triage and make a decision about
    every bug report that we're numb to the pain that it's causing us.
    We need to make some dramatic changes in how we handle bug triage
    and the tracking and decision-making process around bugs.<br></div></blockquote><br></div><div class="gmail_quote">A worthy goal, let's just not repeat past mistakes of hoping for big, resource-intensive changes without the realistic people-power and prioritization to actually do it. Headcount for dedicated roles is a fine start, as is the recognition that this is going to be a large change.<br></div><div class="gmail_quote"> <br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
    Relative to the specific firefox-backlog bug flag, my experience has
    been that we don't really use it. We were supposed to pick bugs for
    the priority backlog from the larger list of firefox-backlog bugs.
    But in practice, tech leads have in their head the list of bugs they
    need to accomplish for particular projects, and so the backlog is
    mostly not looked at once things have been added to it. I don't have
    a stake in whether we keep it or throw it out for now, but
    eventually when we have a bugmaster who can spend their full
    attention figuring out the best way to organize bugzilla flags
    across multiple teams, I'm hoping we can come up with something more
    organized and available across multiple teams.<br></div></blockquote><div><br></div><div>Thanks. This thread has spawned some good discussion on how we should improve our bug flows. But back to the specific question of the firebox-backlog flag, it feels clearer that:<br><br></div><div>* It's not filling it's original purpose<br></div><div>* It's doesn't have a clear role in the future of Bugzilla<br></div><div>* At least some groups who we thought might have been using it are not, or misunderstand its meaning<br><br></div><div>So it still sounds to me like we should get rid of it. I don't think we should conflate this flag with the broader topic of improving everything in Bugzilla -- many of these issues people have noted are long-standing problems (which this flag didn't improve), and keeping it or removing it isn't going to have a material effect in that respect.<br><br></div><div>Justin<br></div></div></div></div>