Malone suggestions: bug-filing advice and dupe-finder

[Henrik Nilsen Omma]

Hi Launchpadders!

For the past few days I've been helping Fabio with triaging xorg bugs. 
Except for filing and commenting on a few odd bugs in the past, this is 
my first real view of Malone, and esp. on the receiving end. After 
working with it a bit, I have two suggestions for improvements. I wasn't 
sure if this should be written up in the wiki, here or filed in LP, so I 
opted to start here.

These two suggestions have the one thing in common that they are meant 
to help the original submitter to 'do the right thing' from the 
beginning, thus improving the quality of the bug reports and making life 
easier for the maintainer and community triage volunteers.

== Package-specific guidelines ==

Taking the xorg package as an example there are certain things that are 
nearly always useful when submitting bugs against it, namely getting the 
xorg.conf file, the xorg.0.log file in case of crashes, and often the 
output from lspci and ddcprobe. Digging into the bug could start 
straight away if this info was supplied with the first bug report, 
reducing the need for any real triaging. We have just recently started 
using a simple script written by Seveas to simplify this process. We 
just instruct the reporter to run these two commands:

wget http://www.ubuntulinux.nl/files/pastebin
python pastebin --debug-x

And the output appears like this: http://paste.ubuntu-nl.org/11955

So, getting to the point: For many packages it would be good to be able 
to provide some custom advice on how to report a bug against it. For 
xorg that would also include 'If your screen looks garbled, it's likely 
a driver problem and should e filed against the appropriate package: 
xorg-diver-<name>, if it's a keyboard config problem, please file 
against xkeyboard-config, etc.

I would suggest implementing it as an expanding section on the bug 
reporting page. 'Click here for guidance on reporting bugs against xorg.'

== Fuzzy duplicate matching ==

Another major task in triaging is finding duplicates. The person who 
makes the initial report may often be in a good position to spot a 
duplicate because he/she knows the situation or hardware in question 
well and might have a better chance at recognising a similar report than 
some random person (me in this case) helping out with bug triage.

However, the original submitter may not know Malone well enough to do an 
effective search for it or not be motivated enough to do one. One 
possible solution is to have the person report the bug and then have 
Malone do a fuzzy search for similar content on bugs reported on the 
same package. This could be a general word comparison, but each package 
could also have certain key words defined for it that would weight in 
strongly in finding matches. For xorg this would be 'wxga', 'i915', 
'nvidia', 'crash', 'gdm' etc.

Upon submitting the bug the reporter would be given some suggestions for 
possible duplicates and asked to look them over. 'It is possible that 
some of these existing bug reports already describe the situation you 
are reporting. Please read and help us identify possible duplicates.' 
Possible duplicates could be tagged by the original reporter and later 
reviewed by a triager or maintainer.



  - Henrik

--
http://www.ubuntu.com
http://www.theopencd.org