Re: GSoC Bugtracker

On Tue, May 27, 2008 at 2:48 PM, Daniel O'Connor <daniel.oconnor@gmail.com> wrote: > I can't really think of One Simple Thing to fix all of my current > annoyances in one fell swoop. > So I'll ramble a little here, and perhaps this would be useful to > guide your design choices: > > Problems > 1) Joe user is using a PEAR package. They find a bug, and take the > time to write us out a patch. > > Currently; that bug will usually sit unattended and the patch ignored > for months, if not years. > > Problems with that are: > - Joe user never contributes a patch again, because they think no one > cares (Why Bother) > - Other people suffering the same problem aren't aware of the solution > - Quality as a whole takes a hit > > Things that do/would help fix this: > - Bug Triage days, for instance, do work reasonably well > - Provide dedicated, pre-made searches ('Pending patches', 'Bugs not > triaged in the first 7 days') > - Place a real emphasis on easy to use tools for QA / Bug triage type people. > > A Bug triager's common tasks may include analyze / verify / seek > feedback / mark duplicates / review patches / write small test cases > and reassign bugs to different packages/locations. > They tend to passively lurk on multiple bugs, and are more about > quick, short questions and clarifications than robust solutions. > > > > 2) When a bug is lodged wrongly, the current culture of PHP/PEAR tends > to be more "GTFO" than "Oops, let's lodge a new request for what you > want, you were just confused by something, that's a little bit our > fault too." > > It usually is: > - Someone lodges a bug in an underused part of PHP. > - They provide a reproduce script and enough detail, spending a fair > bit of their own time on things. > - Then Someone Else comes along and marks it BOGUS. > - A piece of pre-made text, which frankly, sounds horrible most of > the time is automatically inserted. > - Finally, buried at the bottom of the generic text is more or less a > single line: > "You didn't want to use 'Foo::bar(), you wanted Bar::foo(); RTFM!" > > A better way to handle it would be more along the lines of: > - Oops, you made a mistake > - Bug Type: Bug => Documentation Request > - An emphasis on "Thanks for contributing, you aren't quite right in > this case. We will however take a look at *why* this is confusing / > easily misunderstood." > > The ways the issue tracker could support this is: > - Automatically start replies with the submitter's first name > - Provide a rating for bug report or bug comment quality (And the > ability to notice things like: "Hey, this guy has submitted 5 high > quality bugs recently!" or "Helgi is always quick to help when > triaging a bug, and politely pointing users to the right bit of > manual") > - Having pictures / Putting faces to names > - An easy way to lodge a *new documentation/change request* based on > a *wontfix bug* (but limited to triagers/people who do contribute). > > > What I've seen which works well (or at least does for me): > The two things I love about how Trac works that I find greatly useful: > - put a bug number into a search box, and there you go > - type a changeset or other bug number, and that's a link > > Another example of a really great issue/bug community is BMO or > Songbird's bugzilla > This is partly because: > - There are clear rules: don't clutter up the bug report with noise, > avoid dupes, etc. > - The sheer abundance of bugs in BMO mean you can usually find a useful answer > - The review process for code happens in the same bug for BMO - the > submitter knows *when* their issue is being fixed and can actually > participate in testing it > > > What kind of user am I? > - I'm a minor PEAR contributor > - I like to do bug triage / help fix people's problems > - I nag, hassle, prod and poke other PEAR contributors at times, > mostly when its not my place (and I constantly feel guilty!) > - At work, I do: branch management, quality assurance (write unit > tests, test scenarios), code review (why did you do it that way! OH > NOW I SEE), general support (oh oh, XYZ is complaining that the > FooBarulator is broken, lodge a useful ticket quickly), bug triage > ("That sounds too hard, let's put it in the far off misty future"). You forgot the defacto trash bin, aka feature requests. :-) I agree on the option to provide searches (orphaned bugs, etc. pp.) so maybe QA can address patches sooner. But do you honestly think a piece of software can solve those other scenarios? The behavior outlined in the first part are time management issues of the developer/maintainer (e.g. I don't have time to maintain but I forget to tell "the community" or I don't have time, but I don't want to let anyone down ;-)), the second issue sounds like an education issue to extend the social skills of those involved. Some people are nice enough to transfer the info into the docs and a button is certainly helpful to them. Some people will blog about it, others will tell you to go away. ;-) So I guess other people need to step up in this case and say, "no we can't handle a problem like that" and do it right. Now, I am very curious to see whatever comes up with the "one bugtracker to rule them all" project (that's a pretty cool title, I wish I thought of that ;-)), but some of the things you describe won't be fixed with new software (IMHO :-)). Cheers, Till