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."
links straight from slashdot.org are disabled, but not from developer.slashdot.org
Bug number: 001
Bug location: Website
Bug symptoms: Site won't respond
Comments:
Slashdotted all to hell.
Appropriate bug reporting: ..."
"Upon clicking on Submit in ProgramX release X.X.X the system hangs and generates the following output:
Inappropriate bug reporting:
"Dude! There's a huge f--king cockroach in my kitchen!!!"
~ "When I'm of that age I'm just going to live up a tree."
Bugzilla Etiquette
There's a number of faux pas you can commit when using Bugzilla. At the very least, these will make Mozilla contributors upset at you; if committed enough times they will cause those contributors to demand the disabling of your Bugzilla account. So, ignore this advice at your peril.
That said, Mozilla developers are generally a friendly bunch, and will be towards you as long as you follow these guidelines.
1. Commenting
This is the most important section.
1. No pointless comments. Unless you have something constructive and helpful to say, do not add a comment to a bug. In bugs where there is a heated debate going on, you should be even more inclined not to add a comment. Unless you have something new to contribute, then the bug owner is aware of all the issues, and will make a judgement as to what to do. If you agree the bug should be fixed, vote for it. Additional "I see this too" or "It works for me" comments are unnecessary unless they are on a different platform or a significantly different build.
2. No obligation. "Open Source" is not the same as "the developers must do my bidding." The only person who has any obligation to fix the bugs you want fixed is you. Never act as if you expect someone to fix a bug by a particular date or release. This is merely obnoxious, and is likely to get the bug ignored.
3. No personal abuse. Bugzilla is a window into the world of Mozilla development. The fact that we permit anyone with an account to add a comment does not mean you may harass, harangue or otherwise hassle contributors. Do not make weak threats like "I won't use Mozilla until this bug is fixed!" If a respected project contributor complains about your Bugzilla attitude, then you may have your account disabled. If you don't like this possibility, become a respected project contributor.
2. Changing Fields
1. No messing with other people's bugs. Unless you are the bug assignee, or have some say over the use of their time, never change the Priority or Target Milestone fields. If in doubt, do not change the fields of bugs you do not own - add a comment instead, suggesting the change.
2. No whining about decisions. If a respected project contributor has marked a bug as INVALID, then it is invalid. Someone filing another duplicate of it does not change this. Unless you have further important evidence, do not post a comment arguing that an INVALID or WONTFIX bug should be reopened.
3. Applicability
1. Some of these rules may not apply to you. If they do not, you will know exactly which ones do not, and why they do not apply. If you are not sure, then they definitely all apply to you.
If you see someone not following these rules, the first step is to point this out by private mail. They may well not be aware of this document. Flaming people publically in bugs just causes resentment. In the case of persistent offending you should report the matter to Gerv.
This entire document can be summed up in one sentence: do unto others as you would have them do unto you.
Amazing. A post to what's basically a "RTFM" to anyone submitting a bug.
Doing this simply creates intimidation. What if some newbie found an integral bug, gets a "RTFM" and is too intimidated to report the bug?
Anyone who has been assailed by "RTFM" in chat rooms can understand where I'm coming from.
Honestly, if open source takes over, the gripe will go from MS to RTFM. Its something that should be addressed now instead of later.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
Always add bitch at the end of the feature request.
Example
Incorrect
The program could use a print preview feature, please add it.
Correct
The program could use a print preview feature, please add it, bitch.
At least that's rule #1 where I work.
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.
b) What is the phrase or action that will get the developers to actually do my bidding? I'm very busy and quite imperious.
You may answer me now.
It isn't that at all, though... all they are asking for are some very simple things, things that a newbie would probably do anyway. They are just asking that you don't put pointless comments, that you don't feel that the bug HAS to be fixed, and that you don't abuse or troll in the bug post. Most newbies would probably follow that pretty good on their own already... this is probably more aimed at those who have been around for a little bit, and have posted aimless comments, or have lost sight of the fact that the developers don't have to fix their bug immediately.
And so we go, on with our lives
We know the truth, but prefer lies
Lies are simple, simple is bliss
10. My program died. I have stapled an explanation to the install diskette and it is in the mail.
9. I submitted my e-mail address to a dubious web site, and now I get spam. Could you get them to stop? It is your fault: I found the page in your browser.
7. It happened when I hit one of the keys in one of the screens and I saw a message that said something appear. I think it was that version with the 1 in the name. It might have been Mozilla or Opera, don't ask me.
6. Every time I click on the monkey to win $10,000, I never get anything. Could you add a feature in your future version that makes sure that clicks hit the right monkey?
5. The word "Ayatollah" was not spelled right in one of your web pages, www.cnn.com. Please fix immediately.
4. Mothra is attacking!!!!
3. My el33t boxen broke da bugz. 2 u now.
2. Author Stephen King dead at 54
1. My preying mantis is not housebroken, no matter how much I do. What is there to do besides scold him with "Bad bug! Bad bug!"
Don't blame Durga. I voted for Centauri.
I work for a small company (5 employees), with a user base floating around 1M. And I can't even begin to explain the lost man hours dealing with bad bug reports. I have personally closed over 20 duplicate bugs for a single incident, seeing 3 of the 5 most recently submitted bugs were the same was the first bad sign.
/when/ you find the same thing allready there, post a comment with your input, and stats on your OS and machine.
We also deal with the common problem of perception; users think they are doing us the ultimate favour by posting bugs. And as such, feel that any and all means of telling us about them is apropriate, email to 5+ accounts, multiple forum posts, bugtracker, etc. This just wastes time that could have been spent fixing the bug in the first place.
While I would agree that bug reports are helpfull, and nesesary. Condecending tones, foul language, and thinly veiled threats do little.
All i would ask of posters is:
-Replicate it, If you cant make it happen more than once, it doesnt matter (s/w under windows has special quirks of which i am sure you are aware).
-Search It, then
-Include relevant details, killing bug reports under 100chars is really tempting 'it doesnt work', 'the installer breaks', 'its too slow' are all to common.
-Include information on what you were trying to do, and what you were expecting, 'Bugs' are often just a difference of perception between coders, and end users as to what a feature should do.
paul reinheimer
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...
Seriously, behave like you would if you were talking to his face. A redundant comment would be met with "Yes, I _know_" even though noone would add that (also) redundant comment to the comments board. Also it'd cut down on flamefests. So many people get real obnoxious for no particular reason except they can sit in front of a computer screen and do it, kinda like the online version of the school bully. About as mature too.
Kjella
Live today, because you never know what tomorrow brings
From Painless Bug Tracking:
"""
It's pretty easy to remember the rule for a good bug report. Every good bug report needs exactly three things.
1. Steps to reproduce,
2. What you expected to see, and
3. What you saw instead.
Seems easy, right? Maybe not. As a programmer, people regularly assign me bugs where they left out one piece or another.
"""
Stop worrying about the risks of nuclear power and start worrying about the risks of not using nuclear power.
An interesting example illustrating many of these bad practices over and over and over can be found in the comment section of bug 22274, a not-quite-valid-but-frequently-reported-"bug" involving tabled images, alignment, descenders, and Quirks mode.
The first time I noticed that functionality in Moz I found my way to the above page and spent a good hour or two reading through all the comments. Aside from gaining an education in some of the nitty gritties of html and css standards, I was struck by how frequently the bug was re-reported and by how abusive the commenters became (especially when their bug was labeled "invalid"). It's nice to see a page with explicit etiquette standards. Lets hope the bugzillians abide by them.
The angel in the oatmeal.
Actually, it is.
Reading bug reports that are full of information on what exactly the bug is, where it is reproduced, how to reproduce it, why its doing it, when its doing it, etc.. is going to give the developer a usefull report with information that he needs to fix the bug..
If you add extra information that is not needed, inflamatory or not, that is extra work the developer has to do to fix the bug. It is equivilent to sorting through your spam mail every day. You pick out the bugs you see have usefull information, and proiritize them above the rest. Since bug reports continuously flow into the database, there is usually no time for a bug report that gives no worthwhile information because all the developers time is spent fixing bugs that have REAL bug reports.
It is signal to noise ratio, and if you can't understand that, your a fucking idiot.
Two infinite things: your stupidity and mine. But I'm not sure about the latter. If my sig offends you, I'm sorry.
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)
One of the best tester's I'd ever worked with was thoroughly insane. His biggest joy in life was to think up things no normal person would expect software to do. (Dan, a big jovial Floridian with a beard. Nice guy, just completely out of control once he starts having fun!)
As an example, he simulated a "sporadic network failure" between the primary and hot-backup systems by unplugging and re-plugging the cabling every few seconds for five minutes straight. (The sad thing is that a real sporadic network failure can do this for hours or days before it's identified and fixed, especially if it's just one of dozens of connectors that is loose.)
Another one of his favourites is to always close windows with something like xkill to see how the code responded.
His worst brutality was entering invalid data into every field of a GUI, including copy-paste of control codes, trying to paste GIFs into text edit areas, pasting entire screens of text into 10 character fields, etc.
The sad thing is, I have never seen him take more than 20 minutes to crash an application when he puts his mind to proving that "all software is crap."
I do not fail; I succeed at finding out what does not work.