Re: GSoC Bugtracker

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").