<div dir="ltr"><div><div><div><div>My note at the end was a tangent, perhaps I should have avoided throwing it in there. :) When I said "triaged" I was not implying "by QA", I meant it in the most general sense.<br>
</div><br></div>* bugs should be marked qa-/qa+ as early as possible by the first person suitable for making the judgement (this can be QA, the bug reporter, an engineer, people in the planning meeting)<br></div>* doing this marking in the planning meeting is possible, though in general I'd prefer moving away from triage/estimation happening in the large group meetings. Smaller groups or individuals are better for this stuff.<br>
</div><div>* I don't see any value to the "qa?" marker specifically. Can we just get rid of it? <- separate question, completely independent of the above<br></div><div><br></div>Gavin<br><div><div><div><div>
<br><br><div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, May 13, 2014 at 9:37 PM, Anthony Hughes <span dir="ltr"><<a href="mailto:ahughes@mozilla.com" target="_blank">ahughes@mozilla.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">> Why not just assume all bugs assigned to an iteration need to be triaged and assigned qa+/qa- ?<br>
<br>
</div>That's fine but we should also assume some bugs are [qa-] without QA having to triage them. It seems reasonable and wise to me to reduce the amount of triage wherever possible.<br>
<br>
Going one step further, it would be great if we could incorporate qa+/- as part of the work selection process in the planning meetings. We could be setting bug difficulty, points, and qa+/- in one move; thereby easing the burden of additional triage and reducing Bugzilla noise.<br>

<br>
In a more general sense, I think it's paramount to identify and resolve inefficiencies in the process if we ever hope to successfully scale Iterative Development across the Project.<br>
<div class="im HOEnZb"><br>
Anthony Hughes<br>
Senior Test Engineer<br>
Mozilla Corporation<br>
<br>
<br>
----- Original Message -----<br>
> From: "Gavin Sharp" <<a href="mailto:gavin@gavinsharp.com">gavin@gavinsharp.com</a>><br>
> To: "Anthony Hughes" <<a href="mailto:ahughes@mozilla.com">ahughes@mozilla.com</a>><br>
> Cc: "Benjamin Smedberg" <<a href="mailto:benjamin@smedbergs.us">benjamin@smedbergs.us</a>>, "Marco Mucci" <<a href="mailto:mmucci@mozilla.com">mmucci@mozilla.com</a>>, "Firefox Dev"<br>

> <<a href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a>><br>
</div><div class="im HOEnZb">> Sent: Tuesday, May 13, 2014 12:15:10 PM<br>
> Subject: Re: Proposed Revision to Iterative Development<br>
><br>
</div><div class="HOEnZb"><div class="h5">> On Tue, May 13, 2014 at 8:08 PM, Anthony Hughes <<a href="mailto:ahughes@mozilla.com">ahughes@mozilla.com</a>> wrote:<br>
><br>
> > Okay, thanks for clarifying Gavin.<br>
> ><br>
> > To summarize what I think we've agreed to here:<br>
> > A) Near-merge landings that cannot be tested in time will ride the trains,<br>
> > carry over as part of the next iteration's workload, and possibly be backed<br>
> > out of a branch if QA finds serious issues.<br>
> ><br>
><br>
> In general, yes. It's also possible that some "near-merge landings" will be<br>
> delayed, for whatever reason, based on judgement of the involved<br>
> engineers/designers/QA/release managers (though that should be exceptional,<br>
> as Benjamin says).<br>
><br>
> B) Breakdown, UX polish, and Test-only bugs will be tagged [qa-] during<br>
> > work selection instead of first being tagged [qa?].<br>
> ><br>
><br>
> I wouldn't limit it to "during work selection" - they should be tagged by<br>
> anyone able to make the judgement, whenever that judgement can be made<br>
> (e.g. could be when the bug is filed).<br>
><br>
> I've been meaning to start a separate discussion about the utility of<br>
> [qa?]. Why not just assume all bugs assigned to an iteration need to be<br>
> triaged and assigned qa+/qa- ?<br>
><br>
> Gavin<br>
><br>
</div></div></blockquote></div><br></div></div></div></div></div></div></div>