<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#FFFFFF" text="#000000">
All,<br>
<br>
I took minutes during the TB QA meeting at MozCamp.<br>
<br>
Minutes can be found here starting on line 18:<br>
<a href="https://etherpad.mozilla.org/tb-qa"><br>
https://etherpad.mozilla.org/tb-qa</a><br>
<br>
Here's a summary:<br>
<br>
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<div class="" id="magicdomid306"><span
class="author-g-fp2xkcspz122zccid7qs b"><b>Summary</b></span></div>
<div class="ace-line" id="magicdomid4217">
<ul class="list-bullet1">
<li><span class="author-g-fp2xkcspz122zccid7qs">The rapid
release has really changed the way we do testing. Community
involvement has dropped off.</span></li>
</ul>
</div>
<div class="ace-line" id="magicdomid4219">
<ul class="list-bullet1">
<li><span class="author-g-fp2xkcspz122zccid7qs">Ludo has no
chance of watching all of Bugzilla, and sometimes somebody
comes in with a patch, and we don't see it because they
don't set the right flags, and then it gets bitrotted and we
lose a potential contributor.</span></li>
</ul>
</div>
<div class="ace-line" id="magicdomid4221">
<ul class="list-bullet1">
<li><span class="author-g-fp2xkcspz122zccid7qs">We need more
people to be active on Bugzilla, to take action on bugs, to
respond when somebody files a bug to get the information we
need to fix it (if you reply within 1 day, you have a higher
degree of probability of getting useful information for
fixing it).</span></li>
</ul>
</div>
<div class="ace-line" id="magicdomid4223">
<ul class="list-bullet1">
<li><span class="author-g-fp2xkcspz122zccid7qs">The "bubbling
up" of bugs from Bugzilla to devs to being fixed is what
needs work. People are getting frustrated when they file
bugs and *nothing happens*. Letting people know that when
they file bugs properly, that things happen...that's
important.</span></li>
</ul>
</div>
<div class="ace-line" id="magicdomid4226">
<ul class="list-bullet1">
<li><span class="author-g-fp2xkcspz122zccid7qs">The notion of
what NEW means on Bugzilla is different from person to
person. Some people think NEW means, "this bug is
reproducable". Others think it means "this bug is
reproducable, and we know where the fix needs to happen."</span></li>
</ul>
</div>
<div class="ace-line" id="magicdomid4228">
<ul class="list-bullet1">
<li><span class="author-g-fp2xkcspz122zccid7qs">IDing of bugs,
of prioritizing them for being fixed - we need to look into
new and better ways of doing this.</span></li>
</ul>
</div>
<div class="ace-line" id="magicdomid4240">
<ul class="list-bullet1">
<li><span class="author-g-fp2xkcspz122zccid7qs">There are 4
dimensions for categorizing bugs:</span></li>
</ul>
</div>
<blockquote>
<div class="ace-line" id="magicdomid4246">
<ul class="list-bullet2">
<li><span class="author-g-fp2xkcspz122zccid7qs">How many
people are likely to be affected</span></li>
</ul>
</div>
<div class="ace-line" id="magicdomid4254">
<ul class="list-bullet2">
<li><span class="author-g-fp2xkcspz122zccid7qs">How serious is
the effect when it occurs (workaround? consequences)</span></li>
</ul>
</div>
<div class="ace-line" id="magicdomid4255">
<ul class="list-bullet2">
<li><span class="author-g-fp2xkcspz122zccid7qs">How much
effort to fix this bug?</span></li>
</ul>
</div>
<div class="ace-line" id="magicdomid4258">
<ul class="list-bullet2">
<li><span class="author-g-fp2xkcspz122zccid7qs">How
reproducible it is</span></li>
</ul>
</div>
</blockquote>
<div class="ace-line" id="magicdomid4260">
<ul class="list-bullet1">
<li><span class="author-g-fp2xkcspz122zccid7qs">We need some way
of visualizing bugs along these dimensions, and then a way
of consolidating that visualization into a prioritized list.</span></li>
</ul>
</div>
<div class="ace-line" id="magicdomid4262">
<ul class="list-bullet1">
<li><span class="author-g-fp2xkcspz122zccid7qs">But generating
lists is easy. We've been generating lists for YEARS. The
problem is that we create a list, fix a few things on it,
and then create a new list, and repeat.</span></li>
</ul>
</div>
<div class="ace-line" id="magicdomid4264">
<ul class="list-bullet1">
<li><span class="author-g-fp2xkcspz122zccid7qs">Fixing old bugs
has taken a backseat in favour of feature development over
the past few releases</span></li>
</ul>
</div>
<div class="ace-line" id="magicdomid4266">
<ul class="list-bullet1">
<li><span class="author-g-fp2xkcspz122zccid7qs">Ludo is
concerned about performance problems in TB - his TB on his
beefy machine is just as performant as TB 1.x was on his old
crappy machine. That's not a good sign.</span></li>
</ul>
</div>
<div class="ace-line" id="magicdomid4268">
<ul class="list-bullet1">
<li><span class="author-g-fp2xkcspz122zccid7qs">Irving advocates
a light-weight, "agile" list that is designed to be easily
changed iteration after iteration, based on what is
happening at the time. The list should make it easy to
visualize the "life-cycle" of a bug, and allow us to measure
how long it takes for a bug to go from being identified, to
being fixed. That lets us know how many things to put on the
list, and we can adjust accordingly.</span></li>
</ul>
</div>
<div class="ace-line" id="magicdomid4270">
<ul class="list-bullet1">
<li><span class="author-g-fp2xkcspz122zccid7qs">We need a way
for developers to examine a bug, and deprioritize it if it
is way too complicated - ie, the rewards are too slim based
on how much work is likely involved. (Spending time thinking
about the hard / impossible bugs is less valuable than
fixing the bugs that we're likely to tackle and complete)</span></li>
</ul>
</div>
<div class="ace-line" id="magicdomid4272">
<ul class="list-bullet1">
<li><span class="author-g-fp2xkcspz122zccid7qs">We're going to
tackle the Papercuts list, and see what happens. If we can
show that we can fix the items on a list, and move the ball
forward, then we'll worry about creating the list.</span></li>
</ul>
</div>
<div class="ace-line" id="magicdomid4274">
<ul class="list-bullet1">
<li><span class="author-g-fp2xkcspz122zccid7qs">QA people think,
"We make lists and you devs ignore them!", devs think, "You
QA people make lists, and we can't do anything with them!".
We need to resolve this.</span></li>
</ul>
</div>
<div class="ace-line" id="magicdomid4276">
<ul class="list-bullet1">
<li><span class="author-g-fp2xkcspz122zccid7qs">The list should
be mutable. We need to be able to change our minds. We don't
want to thrash, but we want to be able to make adjustments.</span></li>
</ul>
</div>
<div class="ace-line" id="magicdomid4278">
<ul class="list-bullet1">
<li><span class="author-g-fp2xkcspz122zccid7qs">We need criteria
to create the initial list.</span></li>
</ul>
</div>
<div class="ace-line" id="magicdomid986"><br>
</div>
<div class="ace-line" id="magicdomid4191"><span
class="author-g-fp2xkcspz122zccid7qs b"><b>Action items</b></span></div>
<ol>
<li><span class="author-g-fp2xkcspz122zccid7qs">Get a list of
people watching each TB component, and make sure we've got
somebody with eyes on each one.</span></li>
<li><span class="author-g-fp2xkcspz122zccid7qs">We're going to
tackle the Papercuts list (10 bugs) to prove that we can deal
with a list.</span></li>
<li><span class="author-g-fp2xkcspz122zccid7qs">rkent(?) is going
to send out a weekly status report on the Papercuts list, and
what needs fixing, on what got fixed.</span></li>
<li><span class="author-g-fp2xkcspz122zccid7qs">When the list is
empty, or close to being empty, QA is going to develop a
process for creating the list (which includes the facility for
devs to indicate that a bug is too difficult).</span></li>
<li><span class="author-g-fp2xkcspz122zccid7qs">We need to come up
with some critiera for choosing bugs like the ones on
Papercuts. Then QA / Support will build the list.</span></li>
</ol>
<br>
</body>
</html>