On Mon, Dec 27, 2010 at 1:51 PM, Jeroen Roovers <[email protected]> wrote:
> On Fri, 17 Dec 2010 23:31:28 +0100 > Maciej Mrozowski <[email protected]> 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
