issue triage

[Clint Byrum]

Excerpts from Gustavo Niemeyer's message of 2012-08-28 06:29:02 -0700:
> On Tue, Aug 28, 2012 at 9:35 AM, David Cheney
> <david.cheney at canonical.com> wrote:
> > Hello,
> >
> > At the moment I find myself creating a lot of bugs on LP. Sometimes those
> > bugs don't need to be fixed right now, so I don't set a milestone/severity for
> > them. At the moment, they go into the great unwashed pile of 'not assigned
> > to a milestone'. I don't think this is a good idea and I would like someone to
> > step up and nominate themselves bug master to flesh out those details.
> 
> This is a tricky problem to solve, and I've seen it happening whenever the
> number of bugs filed are larger than the ability of the team to solve them in
> a timely basis.
> 
> My feeling is that it's fine to keep bugs unassigned if we really can't
> (or don't want to) do them in the foreseeable future, because otherwise
> what we'll end up doing is having a "later" milestone where put all the
> bugs we can't care about right now, which then creates a distinction
> between the "we've assigned to later" and the "we've lost unassigned"
> bugs. My perception of past experiences is that more recent bugs end
> up in "later", while older ones end up unassigned, which is a
> non-reasonable way to draw the line.
> 
> That's my feeling, anyway. Do you have a better idea of how to handle
> that problem?

Its exciting to see juju-core start to move from a period of green field
development to bug collection. Lets call this juju-core's "teenager"
phase.. pretty hard to get it to work, and showing potential.

I want to stress just how important bug management is to me, and to any
active open source project. These are some tips I hope you will all adopt:

* Bugs opened by non-core-developers should be given the highest priority
for triage. This is invaluable information and the contributors who are
willing to take the time to file a bug are generally the most enthusiastic
about responding, as long as the response is timely. Ideally any bugs
like this should be responded to within 1 or 2 "business days".

* Bugs opened by developers should be assigned to the developer who
opens them. These bugs can be confusing and are often hastily opened as
reminders to come  back and address these things whenever. Its important
to keep these assigned as they tend to get overlooked in the above
"community response" type of triage. If the developer has no desire to
see the bug through, find another developer who is willing, or close
the report because it is very unlikely to get done.

* One exception to the above is very simple issues that are good for new
contributors to pick up to help get comfortable with the code base. Figure
out a tag for these and stick it on any unassigned developer bugs. Ubuntu
uses "bitesize" for these.

* IMO, do not milestone more than 1 or 2 releases into the future. A
milestone is a promise, and whenever that promise is not delivered on it
damages the credibility of the project. Its perfectly fine, IMO, to have
a huge backlog of unplanned bugs that are pulled in to the next milestone
after the current one is reached. In fact, it makes more sense, because
priorities change and sequencing issues often are not clear until the
current WIP changes are done.