Slashdot Mirror
Bug Reporting Etiquette
Jamie Zawinski writes "Mozilla.org has a new article on Bugzilla Etiquette. Relevant to more than just Bugzilla, this should be required reading for anyone who wants to file a bug about any product, no matter what bug tracking system is in use. I especially like the mention that "'Open Source' is not the same as 'the developers must do my bidding.'"" Update: 03/19 21:26 GMT by T : If that link doesn't work for you without cutting and pasting, reader Stephen Ostermiller suggests "you might want to use this link which appears to be the same document mirrored elsewhere."
Doing system testing, one of the most common mis-reported bugs is due to "pilot error", whether that be a misconfigured server, improper use of the application, a missing configuration parameter, etc.
Why do these result? Because people often do not read the documentation (setup instructions, release letters, etc).... OR because things like a README were not included!
--------
Free your mind.
Realize that the developerr has NO idea what is going through your mind, or what you did to make the bug happen.
CLEARLY report the problem like you are explaining it to a 3 year old.
Report your entire platform. OS, vers, ram, vid card, prod vers, etc.
If you take the time to clearly report the bug then you will not waste your time and the developer's time by having to respond to another email asking for more detail.
You SAVE time by being extra clear when you report the issue.
When I was at Macromedia, I determined that a mis reported bug uses 4-6x the manpower than one clearly reported one. This also means that poorly written bugs limit the number of bugs that can be fixed before shipping because of the extra manpower and time used to pass them back and forth.
Good bug:
QA reporter -> Qa manager -> Bug meeting -> Developer -> Bug addressed -> Original reporter -> Bug closed
Bad bug:
QA reporter -> QA manager -> Bug meeting -> Developer -> Bug addressed -> Bug returned to QA -> More info dded, more time spent getting more details -> bug returned to developer -> Bug addressed -> Original reporter -> Bug closed
I know this doesn't look like 6 x the time but when measured, it got up to that high. Especially if a bug has to return more than once.
- Zav - Imagine a Beowulf cluster of insensitive clods...
The Bugzilla Helper is actually quite good. (You'll probably have to cut'n'paste this link)
http://bugzilla.mozilla.org/enter_bug.cgi?format=g uided
It forces you to search for a dupe before submitting. It forces you to enter build IDs, steps to reproduce, and other critical information.
It should also search for dupes before letting you submit the bug based on keywords in your bug report.
Reporting bugs through the Bugzilla Helper should also be made mandatory. Sure that may annoy power users. However, even power users are liable to miss critical info in their bug reports.
In fact you can get the attitude from the Mozilla developers even before you make a comment see here
:-)
Interesting - the author of the Spell Checker FAQ that you reference, and the author of the Etiquette document under discussion are one and the same.
The Spell Checker FAQ was the result of a frankly ridiculous amount of the behaviour decried in the Etiquette document. Rather than be rude to users, we attempted to use humour to make our point. So maybe you think it's not funny; but I think it's evidence of people attempting to be tolerant under difficult circumstances.
Gerv
(document author)