issue triage

[William Reade]

On Wed, 2012-08-29 at 11:43 +1000, David Cheney wrote:
> I've always felt the most important job of the triage person was to close issues that were not possible to be actioned in a reasonable timeframe. 
> 
> I think the issue tracker is a place of things that should get done, so of it is not realistic to do them, close the ticket.

Isn't there an excluded middle here? Aren't there things that "should"
get done, but which still aren't realistic given our current focus? EG
constraints: given the milestone resolution we have, I certainly can't
think of a milestone to put it in that isn't a lie; but if someone were
to open a "hey, we should have constraints" bug, closing it would send
entirely wrong signals.

> After watching the ill will the festered watching open issues stagnate for a decade on the JIRA project, I am of the view it is more honest to close issues that won't get done. 

I feel this is eliminating a valuable distinction: closed wontfix, to
me, implies that a suggestion is a "bad" one, in some way, and that we
would never work on it given all the time in the world; while a bug that
just sits around for 2 years implies that, yeah, it's a perfectly
reasonable suggestion, and it would be nice if someone picked it up,
even if the core devs don't expect to do it any time soon.

Closing everything also STM to eliminate the possibility of leaving
"bitesize" bugs in the latter category lying around as, er, "bait" for
potential new devs.

But I'm not familiar with the JIRA situation; maybe there's something
I'm missing?

> This constitutes the plank for my nomination. All issues assigned to a milestone or closed. No issue shall be left behind.  

I'm not sure "No X left behind" has entirely positive connotations,
sadly ;).

Cheers
William


> 
> On 28/08/2012, at 23:29, Gustavo Niemeyer <gustavo.niemeyer at canonical.com> wrote:
> 
> > 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?
> > 
> > 
> > gustavo @ http://niemeyer.net
>