Bugzilla upstream workflow changes, and our response - mozilla.dev.planning

The old Google Groups will be going away soon, but your browser is incompatible with the new version.
mozilla.dev.planning
Message from discussion Bugzilla upstream workflow changes, and our response
Path: g2news2.google.com!news1.google.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!nntp.mozilla.org!news.mozilla.org.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 29 Oct 2010 22:09:57 -0500
Received-SPF: pass (gmail.com ... _spf.google.com: 209.85.212.50 is authorized
	to use 'n.netherc...@gmail.com' in 'mfrom' identity (mechanism
	'ip4:209.85.128.0/17' matched)) receiver=notorious.mozilla.org;
	identity=mailfrom; envelope-from="n.netherc...@gmail.com";
	helo=mail-vw0-f50.google.com; client-ip=209.85.212.50
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:content-type;
	b=chE9xpsLOARW8rvTEsk04DAQbeUkrI7rQKyut0ofd19MsCLWGVPNxirY1rnqv4218U
	nrajgQsBjnPUsXXen8wgQfpI7VrLBEkqTqApX5Qc2/c5i8q+I794YpOcaepmjwQqVxsC
	ZMmH2Bx5axU3YQFTHGKW0PwP3j1PtHvWnO8RA=
MIME-Version: 1.0
In-Reply-To: <4CCB2064.50800@mozilla.com>
References: <A7udncY6z7K9G1TRnZ2dnUVZ_t-dnZ2d@mozilla.org>
	<4CCB2064.50800@mozilla.com>
From: Nicholas Nethercote <n.netherc...@gmail.com>
Date: Sat, 30 Oct 2010 14:08:41 +1100
Subject: Re: Bugzilla upstream workflow changes, and our response
To: dev-plann...@lists.mozilla.org
Content-Type: text/plain; charset=ISO-8859-1
Precedence: list
Newsgroups: mozilla.dev.planning
Message-ID: <mailman.2170.1288408197.21996.dev-plann...@lists.mozilla.org>
Lines: 47
NNTP-Posting-Host: 63.245.208.166

I might as well add my two cents, I think some of what I'm about to say
hasn't been covered already...

Some basic principles:

- STATUS is used inconsistently -- some people update it, some don't.

- From a bug reporter's point of view the STATUS isn't much use.  Comments
  will indicate if someone is actually working on the bug.

- In fact, an inappropriate STATUS can confuse/annoy bug reporters.  Also,
  STATUSes whose meaning is unclear lead to big email threads that consume
  everyone's time.  So fewer STATUS alternatives is preferable.

- On the other hand, STATUS *is* useful to devs/QA/managers for searching
  for groups of bugs.  We want to facilitate important kinds of searches.

Applying those principles:

- Minimum is obviously two STATUSes:  OPEN and CLOSED.

- A common search would be from someone wanting to know which bugs have been
  triaged and which haven't.  So we need a third STATUS indicating that a
  bug has been viewed and is considered valid:  CONFIRMED.  Might as well
  take this chance to rename the three states CONFIRMED, UNCONFIRMED,
  RESOLVED.

- As for knowing if somebody is assigned to work on a bug, we have the
  "assigned to" field already, so adding a STATUS for that is silly.  Well,
  except for the awkward fact that there isn't a way to indicate that a bug
  doesn't have anyone assigned to it, because there's always a silly default
  assignee like "gene...@js.bugs".  (I could be wrong about that.)  If that
  could default to empty, it would allow easy searches for unassigned bugs.

- Then there's VERIFIED.  It seems to hardly ever be used and doesn't seem
  necessary to me but maybe I'm missing an important use case.  It's certainly
  not part of the lifecycle of most bugs, so if it is needed maybe it
could be in
  the whiteboard or a keyword.

And that's it.  IN_PROGRESS and READY_TO_FIX appear to be unnecessary.

I'm probably wrong about some of the above, but I think the basic principle
"STATUS is good for searching and not much else" holds;  if you want to add
a STATUS, ask whether anyone will do important searches based on it.

Nick
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
Account Options
