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."
Isn't it ironic that the site redirects back to /., because slashdot never has had the etiquette to consider the load it has on other people's servers and working off the back of others without so much as running a spell check themselves.
And we are expected to pay for this!
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!
Isn't there some precedent here by which Mozilla doesn't allow referer from Slashdot to hit their website?
And now we've just slashdotted them through a different page.
If tits were wings it'd be flying around.
Maybe hygiene guidance. Or which hairstyle to pick. Or a spring fashion review.
Stick to what you know, jerking off to japanimation and pointing out the flaws in sci-fi movies.
Cunning linguists
How many times do the people at Mozilla.org have to tell you to NOT link to Bugzilla so the poor servers can actually be usable by companies who are spending real money on employees to work on Mozilla?
Google cache
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.
Someone should post a bug report on their webserver first.
Slashdotted, yiah!
Note to self: get smarter troll to guard door.
How rich, for developers to lecture ME on how to properly toady to them. It doesn't matter how politely I submit my bug report, it still gets ignored with the classic phrase, "we are concentrating our resources in other directions", which is programmer-ese for "can't you see we have better (i.e. more fulfilling for the developer) things to do than fix our tiny bugs!"
Shutting down free speech with violence isn't fighting fascism. It IS fascism!
That's rich. Hey Jamie, should we slashdot DNA Lounge next?
I'll just have to pretend I read that article on bugzilla and pretend it said "don't write 'omg that program crashes! :(', we have no idea what to make out of that"
This story is mirrored on mozilla.org.uk.
I especially like this one:
Yeah, real professional there. You don't like the tone of the bug notice so you're just going to ignore it. Way to take pride in your work. Listen, guys, if someone points out a bug -- and if you take any pride in your work -- then make an attempt to fix it even if the submitter didn't phrase it nicely. After all, do you really give a shit what some pimply faced puke thinks of you? No, you just want your code to be the best it can be. Don't think you're "teaching this submittor a lesson" by ignoring the bug report. That's just playing childish games.
BURNINATION!!!
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.
Otherwise, no one will use your project.
-1, redundant as hell AND trying to karma whore
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.
I'm sure they don't apply to me.
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.
Drag the link to the address bar.
Post it anonymously, you fucking jackass! Besides, it's already been posted by someone before you!
A link for those folks imperiously wanting to know what the heck that word means.
----- rL
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
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."
In other words:
Mozilla is trying to avoid the slashdot affect with some clever DNS switching. Here's a loophole, now slashdot that f*cker!
How about we cut them some slack seeing as 4 people already posting the info in the comment section?
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
In case you can't get in from Slashdot and you are too lazy to type in the address, here it is in lazy plain text.
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.
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.
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.
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
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.
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
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.
Other useful documents: The Bug Writing Guidelines.
Las cosas mas triviales se vuelven fundamentales...
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...
Beeeeotch, fix it!
I get bug reports like this all the time!
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
When you ignore a bug just because you do not like the tone is certainly unprofessional and hurts you more than it does the user. After all, you do want people to use your software? Right? However, I think that what the article means is that if the developer does not think "fixing" a particular "bug" is a good idea, then he is not under any obligation to do it. "No obligation" is not the same as "I'll ignore all your bugs if you are not nice to me", but it is also not the same as "customer is always right". If you want unconditional respect, then you should pay for it. Open source software developers *cough*likeme*cough* are always open to generous contributions of funds... (*hint*)
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
I have to salute any of these developers that don't rip any of the whiners a new one. I recently went to Magic Workstation which is a site for beta game software. The message boards are filled with crap like:
You mean we have to wait another half month to download it? What are the updates, anyways?! and
i AM WAITING TO LONG!!!!!!!!!!!!!!!!.
Personally, I'd be giving these guys the verbal-bitchslap, but they and other developers I've seen are pretty calm and take whining as a part of the process.
Does it *really* have to be posted fifty million times here? ;)
-uso.
Dreams, dreams, don't doubt dreams, dreaming children's dreaming dreams. Sailor Moon SS
Look at my sig, see my little sig? That's my brother in law's website i've been working on for 2 years, Unpaid, volunteer if you will.
/s's or other characters like & with /a's. Not to mention some of the messy installs by postnuke modules. Over the last 2 years, there were 3 occasions I cleaned it up, got it running on another server, said "Here look! I just spent 40 hours putting the database back together, can I implement the cleaned up database now? Unfortunatly he didn't understand what I was doing, and rather than make the smart choice, he went with the safe choice. I.e. it appears to be workin right, so it must be working right, let's not fuck with it.
Well, yesterday I had one of those straws that broke the camels back. I quit! We've been hosting happily on hurricane electric for the last 2 years now, but recently a buddy of his from a competing website offered to host the site for us. Since I am the only guy that can read PHP, move databases and the site around, I thought I'd ask the new hoster a few questions...
My brother in law told me you were gonna stoke us out? How far are you willing to stoke us out?
I'd like to run 2 daemons. One will be a shoutcast radio station supplied by licensed local bay area talent. The other doesn't really have anything to do with zero, it's called kaillera, it basically allows you to play emulator games online, and I'd like to run a small 20 person server(optional, up to you of course).
Also minimally we'd like 4 databases. I'd like two for a playground, then I need 2 for production.
How about 1u of rack? We have a dual PIII Xeon, but no place decent to put the little red bsd devil.
Now I didn't make any demands, I just asked a few questions about the enviroment, and was checking to see if they would let us have any "extra's"
Well I got a call from him the day after sending that mail out accusing me of making demands on the new hoster, and how it wasn't my place as webmaster to ask these kinds of questions, blah blah blah. Instead of getting upset and arguing with him on the spot, I just calmly said "O.K." and took the last 2 years into consideration before I gave him a response.
The database on the site is a mess, mainly due to being moved off an old host that was doing weird things to our data (sometimes normal behavior) by replacing apostrophe's with
I feel for these open source developers. Sometimes, hell most times bugs are user error, but the users pride is so great that it's just easier to "blame the tech" instead listening to the good advice the tech is trying to give them. (I can't recall how many times I told this guy to NOT use the paralell port zip drive because it would fuck up his win2k system)
The worst is when something is broken and you, the developer doesn't know what's going on, and the user is calling every 15 minutes suggesting what it will take to fix it, despite their suggestions having absolutely no bearing or effect on the problem itself. It's very distracting to have them calling every 15 minutes with their obvious inferior skills trying to tell you what to do. When I work, I don't tell the accountant how to count beans, I don't tell the janitor how to empty trash, it's not what I'm skilled at, so I just leave it up to them.
But why, why in gods name is it that in my career, there are so many accountant, janitors, plumbers that think they are expert tech people?
Maybe bugzilla should have some sort of quiz to make sure the person submitting the bug has the qualified intelligence to do so. Having to sort the real bugs from the fake one's i'm sure is time consuming.
Just my 2cents and a rant. Hopefully I wasn't too off topic with this one.
time to go change that sig.
He has an article entitled How to Ask Smart Questions.
Sorry, links to Bugzilla from Slashdot are disabled.
How considerate of Slashdot to link to a site that explicitly doesn't want them to link to them, and then tell people how to get around the block!
rooooar
#8 bad bug report:
"Allow me to introduce myself. I am H.M. Wogglebug, T.E. I will immediately commence to deliver my report. Mind you, some of the tidings therein are bad...."
Don't blame Durga. I voted for Centauri.
christ you didn't even format it correctly...
All the comments I keep seeing are things aluding to programmers not actually doing anything about bug reporting.
This might be true of some companies, but as far as Open Source, I've not found it to be the case at all. I've reported bugs for kmail, gentoo, crystal space as well as many others. In every case, the bug was handled quickly. Sometimes with a fix or workaround the same day. For example I wanted to sent the subject header from emails to a speech synthasizer. And had problems. The lead programmer put the fix in immediatly, and sent me the source so I could do it myself. Not only that, but several other people sent me work arounds, to the point where I didn't need to bother with modifying the source. Open source is great in this respect.
Gentoo bugfixes are also very fast in this respect. Although like a doctor's office, the important cases get handled first. But I wouldn't want it any other way.
So I say, report the bugs. Do it as carefully as you can. (After all you and the programmer have the same goals, why not help each other out as much as possible).
OTOH, I've not had the same experience with closed source.... Sometimes the newsgroups have workarounds, but usually it's just people who have experience the same things. The lead programmer does not make an appearance ever.
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.
& pretending it's won of the liesense feechurns. the last BIG DOWnload. then you'll have trouble, trying to browse for anything that isn't packed in billonlyUS FUDge.
i cr osoft-Warning.html
http://www.nytimes.com/aponline/technology/AP-M
it'll be like the storIE of the felonious billyunerr, who crIEd 'patch', won too many times.
consult your creator often, about this, & other matters relating the wholesale deception that's been wrought upon US, buy evil greed/fear based megalomaniacs.
lookout bullow. don't come crying to us, when there's only won channel left (for US, that is).
gov.va.msn.?net? (VAST)
In Soviet Russia, bugs report you!
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.
You submit a catastrophic bug that can take down entire AD domains from inside to Microsoft, and they ignore for 3 months?
See here.
fslg503-985-8686503-985-8686503-985-8686503-985-8
It soaks up all the goth posers who would otherwise be fucking with code that matters.
I mean, come on: this is the code base from NETSCAPE, for ghod's sake. (The only company I know of that ever got beat by M$ on QUALITY.)
I'm not a developer, at least I don't think of myself as one. I've spent the last year and a half programming in Perl and I'll be doing it for another year (I hope less), but I'm only doing it because it's a great opportunity for right now. I used to teach and, within the next year (I hope), I'll be writing and producing video full time.
I've reported a few bugs to AbiWord and one or two other places. Then I filed a bug report for Open Office -- files that were originally done in Word Perfect would import with margins intact into ALL word processors except Open Office. (Even if it was imported to Word, then imported to OOo, it still got messed up.) I submitted it as a bug report. Several months later I got an e-mail saying it wasn't a bug and that I sent it through the wrong channels. I brought it up in the OOo Users mailing list and a number of people connected with OOo and Star Office/Sun encouraged me to re-submit it. I followed up on the original "closed" report by saying it was a bug -- that ALL word processors could handle WP margins BUT OOo. This time the response was scathing. It was basically a programmer going into technical (I don't mean simple -- I mean long technical) explainations about why it wasn't a bug and why I was being a pest.
I know people are working hard on OOo to produce a solid filter for importing WP docs. I know, from the mailing list, that they want bug reports like this so they can improve the program.
Personally, I won't bother with any more bug reports. While this one would help me, I've got a work-around. I see no reason why I, as a user (and even though I am programming in Perl, I am not trained to be a programmer), should be jumped on by a programmer for not knowing "programmer things" and just trying to submit a bug report.
I don't know if bug reports help developers or users more, but I do know that I will be less likely to submit them in the future (that OOo bug was the last I ever submitted).
While I do think it is the responsibility of the user to RTFM, I think there's another side of the story -- those responding to bugs should make it as easy as possible for users to submit bugs (assuming the developers want to fix all their bugs).
My point? The user should use brains in submitting a bug report, but this sword has two edges and if the developers want bug reports, they need to make it easy and painless for users to report bugs.
116th post!!!! HASP!!!
This is the first mention of bugzilla not allowing /. referrals in the comments. How the fuck is that redundant?
Motion to remove redundant from the moderation system. All in favor...
Overrated / Underrated : Moderation
If he's not being paid; if he's working solely for personal benefit or out of benevolence, then he is under no obligation to tolerate rudeness. If you want to be rude, then you can damned well pay for the privilege!
Why does anyone care what jwz thinks about Mozilla? He hasn't been involved with the project in any way at all during the last four years. None whatsoever. Except griping from the sidelines of course.
One thing I would like to see added to that list is "Make sure you respond" and this is the submitter I'm talking about. I found there is a certain group of people who will submit a bug (or problem) and demand it be fixed now as it is absolutly necessary for me to work.
So you ask them for more information. What do you get back? Nothing. You ask them again. Still nothing. Great. You try your best and get nothing back
Rus
Cheap UK and US VPS
The first thing is use the bugzilla helper it will help you create a good bug that includes: what you did, what you thought should happen, and what happened instead. It will also include what your platform is.
Duplicate bug reports are discouraged on bugzilla but they are useful. They give the developers an idea of how many people are seeing a given bug. This is especially important for triage, deciding which bug to fix first. Even better, is to find the relevant bug that's already open on the issue, and to add your bug report to that one (give all the details). That will save the developers a bit of time and provide useful contextual information that can help narrow down (or expand) the focus for a bug.
simon
home page
"Open source" is not the same as "- I don't like this feature. - Yeah? So fix it, submit a patch and stop whining!"
Don't be a dickhead.
How much longer until they finally get around to fixing the 4000-characters cut-n-paste bug that's been around for THREE YEARS?
- A.P.
"Remember when the U.S. had a drug problem, and then we declared a War On Drugs, and now you can't buy drugs anymore?"
CLEARLY report the problem like you are explaining it to a 3 year old.
This is a good rule of thumb, but you can get over-simplified. I have seen people raise bugs that contained wayyyyy too much information. Remember, the developers can't read your mind, but they aren't idiots either.
One good thing to separate out is the PROBLEM and the STEPS TO REPRODUCE. They are not the same thing. If you can reproduce it, and document the steps, all the better. If you can tell a developer WHY a bug is a bug, and how to reproduce it, it makes their jobs much easier. Sometimes it isn't obvious to everyone else WHY you think something should be changed. Some people like to suggest solutions in their bugs, and this isn't a good idea most of the time. I have found that developers tend to see that as "don't tell me how to do my thing". The only way I would suggest doing it is if your proposed solution isn't the obvious one. You could always preface it with "One possible solution could be..." instead of "You should fix it by..."
Report your entire platform. OS, vers, ram, vid card, prod vers, etc.
I would say this is a case-by-case basis, but generally a good tip. You could flood them with too many details. If you don't know something about your system, or if it is irrelevant to the problem, make sure to point that out too. "I don't remember what other applications I had running, but there were several" is better than not mentioning at all that you had other apps running. It could give them a lead.
My beliefs do not require that you agree with them.
And here you have proof: http://alleg.sourceforge.net/help.html
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.
Bugzilla- did Mozilla change their name again?
Manipulate the moderator system! Mod someone as "overrated" today.
Read the 3rd post, ass pilot.
Respect is a two way street. It would be nice if the Mozilla Developers would show the same respect they desire from bug reporters to bug reporters. The fact is you can get rude and dismissive comments from the Mozilla developers even if you do your absolute best to be as respectful to them as possible. In fact you can get the attitude from the Mozilla developers even before you make a comment see here.
That said, I think the Mozilla developers are doing a GREAT job and I have a ton of respect for them. I just woouldn't ever want to work with them.
There is some obligation. Sure, the developers don't have to fix the bugs you want fixed when you want them. But as an honest, well-meaning, well-researched bug submitter, there is an obligation for the developers to treat you reasonably.
To me, treating bug submitters reasonbly involves the following three things
1) Assume that the bug submitter isn't making the problem up. They may have misidentified it, or made a small error in description, etc. but they aren't inventing it out of whole cloth. If you follow this assumption up with a read of well-researched and documented bug description information, then you should assume the problem is likely correctly identified, and treat it as such.
2) "Works 4 ME!!" is not a problem resolution. It is a reasonable explanation of why a problem isn't going to be fixed too quickly: hard to troubleshoot what you have to imagine. It isn't proof the bug doesn't work.
3) If the truth is that it's low priority, that's fine, but don't go to a lot of effort to discredit the submitter/problem to justify your low priority classification. That's rude and a waste of time.
So it cuts both ways. Developers who can't give basic respect to bug submissions aren't going to get any value out of them, and there is an obligation to provide this basic respect. The bug submitters don't write them up just to waste their own time.
-------
Secondarily, if the bug is marked "INVALID", this means it's probably invalid. But the developer can be wrong. Through the last several software houses I've worked out, I've seen rampant miscategorization and misclassification of bugs by lazy developers. I think pointing out genuine errors and/or lies is acceptable and helpful, and helps avoid data corruption of the defect tracking system. That said, for this to have any value it has to be reasonably applied, and with tact.
-josh
Another little tip when submitting bug reports:
- Don't lie!
I have a little trouble believing people when they say things like, "My database crashed, and I wasn't doing anything!"
> If you agree the bug should be fixed, vote for it
What if you could donation money to a bug,
that would be cool.
Knud
you snagged at least 4 responses!
If my copy of Mozilla worked, I might be able to read the document.
Yes, I know it's a troll
Queen BHDGary secures my bank
Cause Internet Explorer has NO bugs!
Often times, I've wanted to report a bug, but run into a number of obstacles...like the requirement that I create yet another account, on yet another server, with yet another password. While I have a great deal of respect for those that participate in open source development, one of the ways that developers help us help them is allow the means to report bugs without hassling with a bunch of unnecessary overhead.
Being someone who has written open source software and had people file bugs, I do fix them, if they are bugs. If they are feature requests or something that does not work the way that they expect, I then would usually discuss either the workaround, or a fix.
As someone who has filed bugs at bugzilla and redhat, I can see the issue they face. I have seen a few "bugs" that are just bad design rather than bugs.
One example of this is the whole password changeing / password manager in Mozilla. As of Mozilla 1.2 there is no where to "change" passwords. You must delete the password from the profile and then go to the web site and have it add it back to the profile. The mail application also has the same problem. This is just a bad design, and not a "bug". Hey UNIX has a passwd command, windows has ways of changing passwords, mac does to, its pretty much a standard that you CHANGE your password, instead of delete and re-add. Yes this is what most software is doing behind the scenes, but from the UI it does not look like that. This issue was filed by someone and somehow it got related to another bug that I filed, which is how I know about it. There was a heated debate in this bug and I keep getting email about it so I chimed in at the comment of 'well how should it work?'. I then said hmm I'll explain what I see in Outlook mail and let them go from there.
Typically my reaction to bugs has never been 'I'll stop using the software' or a 'fix it or else', but I have debated that something is or is not a bug. Not really a debate, as more of an explaination of why I think this is really a bug and am not just a wining pia. I also try to find a workaround if there is one, or if I find a workaround on my own, I try to update the bug report with my woraround.
Something that open source developers should thing about. 1) Major software companies do fix bugs. Especially if it is accounting software and there is an accounting glitch. 2) Bugs also have priorities. In the one that I mentioned above, I'd think that the 'bug / bad design' is a very low priority. There is a workaround (delete / re-add). 3) If your making software and you want people to use it then do you want to be making buggy software that people hate to use? Even Microsoft realizes that software must improve over time and Win XP is much better than Win98 (even though there are a few things they could have left out).
Lastly, I fix bugs for a living. Just yesterday I stomed out this huge spider (LOL), no seriously... I fix software bugs for a living. When there is a bug in my code, I want to fix it. To me, 'my code is my art'.
Only 'flamers' flame!
I've successfully used this technique to report bugs over the years. It always works:
1. Question the programmer's ability.
2. Call the programmer "you stupid bitch".
3. Aks for the manager.
I hope I was unlucky.
Hit a problem with the mail client - I wanted to be able to delete mouse selected text from a Usenet post that I was replying to.
Logged on to Mozilla
got an account
read the guidelines
searched for my problem
filled in bug report
(total elapsed time something like 20 minutes by now)
Smartass developer in USA posts comment that implies that I work for Microsoft and that I am wrong (ie that you should not be able to edit Usenet posts when replying to them). Bug report closed.
Outcome: Mozilla will not be getting any more bug reports from me.
hear me out. sorry for the long mail.
i use linux 24x7 on various machines and also use windows and mac's and solaris. i aint a newbie. i remember when i was playing around with apt-get
i removed the
once by mistake [instead of just the archives/*.deb] and tried to use apt after
that. the errors it spewed out were _BS_
and totally non-related, especially it spewed
it out multiple times. me not being a debian developer [yet] and thinking that this is something that can be improved - i looked at the bug reports. none of it at that time had this, so i thought i would report. before that i decided to check out the #debian channel on irc.debian.org whether this was ok.....my mistake! it was a horrible experience. basically the people said i was a) a troll b) just want to point out problems in debian c) a deadrat user
d) maybe i should stick with windows e) some affirmative responses. no, it was not SOME
folks just trolling as usual on irc, they are easy to spot. its more the uniform mindset of the "power users" and "developers". i got so pissed off and i have never been in irc after that. well i _know_ these things happen and can shrug them off. i also can assure you that i am not hyping up a single incident.
coming to the pt, wtf are you guys thinking newbies will do ? you are telling bug reports to be "proper" ? yeah right. i cant begin to tell you the hypocrisy that exists in the minds of most of the developers/power users.
frankly it feels like most of the folks write
open source software for _their_ name and use
it to show _their_ coolness rather than anything else. i know everybody isnt like that, probably pareto's rule applies in that 20% of the folks do 80% of the work.
thanks for reading.
vv
Joel's articles used to be good, but now they seem to just be lame repetitions of things already said more clearly by other people. It's kind of disappointing. I suppose he feels like he needs to keep writing, even if he has nothing new to say. That said, "Painless Bug Tracking" (from 2000) is pretty clear.
To be more kind, perhaps some of it is new to some of his audience. I guess all the VB programmers and slashdot kiddies are wetting their pants over him because they don't read many books.
// mbp (obviously in a bad mood this morning)
What do you think would happen if the 30 second "create an account" process was removed? We already have childish idjoits posting idiotic comment after comment, then creating a new bug all because they have something misconfigured. Without the extra 30 seconds to create an account, it would be impossible to filter and ban said idjoits.
Give a man a fish, he'll eat for a day, but teach a man to phish...
On the other hand, I can see your point about built up frustration and the results upon your comments, a very human thing to do. I can't find it now but once there was a document adapted for the web that was ironically about etiquette written well over 5 decades ago. (in regards to published editorials) Basically it ranked the forms of humor by tolerance and forgiving factors really based upon the reality of time and circumstance involved in fabricating a communique. You had a range of instant "pop offs" that ranked the highest for forgiving while novels ranked the lowest. Editorials were much closer to the novels than spoken word yet the focus of the article was that many times people forgot this and just jacked their jaws like they were talking to a drinking buddy (or were picking a fight in a biker club).
here is another similar sentence... Maybe you think that Baboon's are smart, but I just saw a really nice looking red sports car yesterday. I think I know what you are saying but I don't think that anyone is really going to see it as anything but a snotty response to some snotty bug reporters.Back to the whole issue of this ever being "an issue" in the first place (i.e. the Mozilla suite) keep up the good work! I am doubting that social etiquette or even consistency or lack of hypocrisy in demands of it from others really matter that much to good design and implementation principles. (however, I think I will call someone a "pumpkin toothed, goat rapist" and see if it effects my work tomorrow)
they have removed any potential for situations like this by removing any sort of tracking system in the first place. Everything is adhoc and follows no pattern. (I refuse to even say process in something so chaotic) Of course, the "ASP expert" on board knows about as much about programming, development methods, system component interaction, etc as does a 14 year old kid who thought that it would be cool to automate the Blizzard server status on his website with a short script. Then I see so many people out of work (or filling in paper pushing positions) that just blow these clowns away in skill, vision and professional methodology.
- State loudly that ethical science is about advancement of knowledge not personal empire building
- Lie, misrepresent "findings" and use FUD to gain more funding
- While driving home to your upper class home in your gas guzzling SUV, make sure to shake your fists at some redneck for being such a right winged brute for having a "support our troops" bumper sticker.
No, this seems to be the rule rather than the exception so I am guessing that you are referring to the OLD method.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.
Despite the problems associated with getting advanced users to patrol newbie message boards and find such reports and take the time to reproduce and report the bug, newbies are invaluble (as is being stated elsewhere in this thread) in reporting true bugs. Just because the programmer or QC person hasn't tried something in testing doesn't mean the newbie, fresh off of handholding by AOL, won't be able to crash it.
"Make The Fucking Manual Readable"
Is generaly my own crass response to a RTFM.
A lot of documentation is hard to find or sometimes just isn't there. And even when it is there's no point in being an ass about it. Just point out the sections that should answer a person's question.
Nowehere does the article suggest that it would be a good idea for bug reporters to read any form for documentation before reporting a bug.
/. moderators.
I understand that such suggestions is considered unbearable rude by the new generation of software users, but no such suggestion was made.
I, however, would suggest that moderators should read the article before moderating comments that claim to summarize the article as "insightful".
Hopefully such a suggestions are not yet considered unbearable rude by
If you look for something in the documentation and doesn't find it, or does not understand the explanation, a bug report about the documentation is very helpful. Assuming, of course, the project has any documentation to speak of.
Always state what the problem is and where you looked to find answers. Be specific, i.e. if you looked in the index, tell what words you looked for. If you did not understand the explanation, tell what paragraphs you found unclear.
If you actually somehow found an answer (possible in a support forum), try to suggest a formulation that you would understand.
As always with free software, try to be part of the solution. That is the only way free software will work. If you can't work like that, find a commercial alternative.
As you use moz for a while and realize some simple bugs are 3yrs old with half a thousand dupes, you kinda get pissed off and say such on your comment.
Instead of fixing the problem, they want to fix the symptom by telling us how many hoops we should jump thru to report THEIR bug.
Yeh, so it's free. Other programs are free, and they fix their bugs quickly as a matter of pride. So it's no excuse for moz ppl not to do the same, esp when a bunch of them are paid full-timers.
Quoth the poster:
There are two aspects to user 'bug reports': improving product quality (fixing bugs) and user support (helping the user with a problem). Organizations doing much of the latter distinguish 'incidents' from defects (bugs). An incident is a user report of a problem; other users might have experienced the same problem, but no matter, the incident is recorded and a user-support person provides assistance. The user is not responsible for recording bugs at all; the user-support person (or someone else) does that. Thereby, all bug reports are produced by internal staff, rather than customers, so you can enforce good bug reporting. Also, the organization is set up so the user has only one point of contact, the user-support department, so duplicate incident reports are eliminated too.
If this is new to you, you might be interested in the ITIL Guidelines
Ne mæg werig mod wyrde wiðstondan, ne se hreo hyge helpe gefremman.
. . . closed source apparently doesn't mean "the developer must do my bidding" either. In fact, it usually means "the help lines are staffed by those who will require you to spell the name of the product several times before wasting more of your time."
Arguably, the developers shouldn't be able to close bug reports. They should be able to report them as fixed, but a neutral third party should close them after testing and confirmation of the fix.