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

[George Prowse]

On 28/12/2010 21:11, Rich Freeman wrote:
> On Mon, Dec 27, 2010 at 1:51 PM, Jeroen Roovers <jer@g.o
> <mailto:jer@g.o>> wrote:
>
>     On Fri, 17 Dec 2010 23:31:28 +0100
>     Maciej Mrozowski <reavertm@×××××.com <mailto: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

If it was just a case of checking if the right info was there then it 
could be done by a few reasonably-Gentoo-savvy volunteers who check the 
list a couple of times a day. Otherwise you're pretty much adding in 
just another step in the process which seems like the opposite of what 
you are trying to accomplish.

G