Re: [gentoo-dev] [warning] the bug queue has 118 bugs

[Rich Freeman]

On Mon, Dec 27, 2010 at 1:51 PM, Jeroen Roovers <jer@g.o> wrote:

> On Fri, 17 Dec 2010 23:31:28 +0100
> Maciej Mrozowski <reavertm@×××××.com> wrote:
>
> > Well, before I became developer, I had a quite unproductive
> > discussion on IRC with Jeroen on that matter (jer opting for status
> > quo and telling me I have no idea what bug wrangling is :P)
>
> I have no idea what you are talking about.
>
>
I'd like to turn this discussion into a more productive direction (let's
wrangle bugs, and not argue over who said what to who when).

First, I'd like to say thanks to those who put a great deal of care into
bug-wrangling, and I think all will agree that Jer does a LOT in this
regard.  It is very clear to me that when bugs get assigned to me that
they've generally been well-triaged and I'm sure that a lot of cruft gets
pruned before I even get an email.

That said, part of me wants to think aloud about whether we're
over-investing in triaging bugs in the queue and this is leading to the
queue getting out of hand.  The problem I see with our current bug-wrangling
procedures (as documented on the official site) is that they seem a bit
daunting to me.  I see this problem at work all the time - procedures that
are very complex either need to be an assigned job, or they need to be
simplified.  If they remain complex but free-for-all then nobody wants to
touch them, since nobody gets yelled at individually if they don't step in,
but if they step in and mess up suddenly they have egg on their face.

Something that might help would be a "one touch" bug queue (think Getting
Things Done).  Wrangler looks at bug, and bug ends up in one of two
categories IMMEDIATELY:
1.  Bug has required info and can be assigned to a maintainer.  Go ahead and
assign.
2.  Bug is missing required info or seems vague.  Immediately add a comment
stating what is needed, with link to website with bug submission procedure
that wasn't followed, and resolve invalid.  Comment should welcome submitter
to re-open with the required info.

This gets stale bugs out of the queue without a lot of fuss.  It also means
that everything in the queue needs attention and nobody spends time reading
a bug just to find out that it is stuck and needs no attention by a
wrangler.

Also - I think we need to make other forms of triage a best-effort sort of
activity.  If a wrangler wants to try to triage a bug they should be welcome
to try.  If a wrangler notices a dup, they are welcome to handle
accordingly.  If a wrangler misses a dup or doesn't do triage, that is fine
too, as long as they either resolve invalid or assign.  That does mean a bit
more bugspam for downstream devs, but it is pretty easy for me to spot dups
for the packages I'm most familiar with, and it is much harder for a
wrangler to spot them across the entire tree.

The overall goal is to make wrangling simple, but still a value-add.  We can
leave room for those who want to do more.  If we end up with a big pool of
serious wranglers they can just post on -dev saying that they've got things
under control and then those less serious about it can step out and allow
for more triage.  When the wranglers get underwater everybody else can step
in and quickly clean up.

I guess the question is whether the resulting shorter queue and lower
latency is worth the tradeoff in having package maintainers get a few extra
bugs that might have been avoided in triage.  I'd be interested in Jer's
perspective on how many bugs get squashed during triage.

Thoughts?

Rich