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

Comments

links disabled

[bsharitt]

links straight from slashdot.org are disabled, but not from developer.slashdot.org

Bug report

[japhar81]

Bug number: 001
Bug location: Website
Bug symptoms: Site won't respond
Comments:
Slashdotted all to hell.

Inappropriate/Appropriate

[Undaar]

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!!!"

Re:Inappropriate/Appropriate

[TopShelf]

Or worse yet:

"Dude! There's a huge f--king cockroach hanging in my kitchen, generating the following output..."

Re:Inappropriate/Appropriate

[Alien Being]

Try using -squish

XROACH(1) XROACH(1)

NAME
xroach - cockroaches hide under your windows

SYNOPSIS
xroach [-option .,..]

DESCRIPTION
Xroach displays disgusting cockroaches on
your root window. These creapy crawlies scamper
around until they find a window to hide under.
Whenever you move or iconify a window, the
exposed orthopteras again scamper for cover.

OPTIONS
-display display_name
Drop the roaches on the given display. Make
sure the display is nearby, so you can hear
the screams.

-rc roach_color
Use the given string as the color for the
bugs instead of the default "black".

-speed roach_speed
Use the given speed for the insects instead
of the default 20.0. For example, in winter
the speed should be set to 5.0. In summer,
30.0 might be about right.

-roaches num_roaches
This is the number of the little
critters. Default is 10.

-squish Enables roach squishing. Point and shoot
with any mouse but-
ton.

-rgc roach_gut_color
Sets color of the guts that spill out of
squished roaches. We recommend yellowgreen.

BUGS
As given by the -roaches option. Default is 10.

COPYRIGHT
Copyright 1991 by J.T. Anderson

AUTHORS
J.T. Anderson (jta@locus.com)

DEDICATION
Greg McFarlane (gregm@otc.otca.oz.au)

SEE ALSO
xroachmotel(1), xddt(1)

X Version 11 Release 4
XROACH(1)

article text

[Anonymous Coward]

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.

Re:article text

[Pxtl]

Really, I can't say I'm surprised that this happened. Read any forum for any large software project (or popular forum in general: SlashDot) and you'll find that half the internet considers it their personal scrawlspace. Hell, if there's any bad side to the bloggin revolution, its that 12-16 year olds that used to be much more pleasantly silent have found their voice on the internet and are using it to annoy the hell of us who are trying to get some work done.

If you don't have a moderation system, patient moderators, etc, then avoid making your bugtracking or other internal information systems publicly available to unidentified users. Imagine if a guy posted a piece of software to Slashdot and said "hey, any bugs?" the quality of the responses he'd get.

The fact is that most bug-reporting database systems are designed for limited-beta testers, QC people, and developer communication. Not for joe user who just surfed in. Expecting it to be anything better is unrealistic. Look on SourceForge at the bugreport sites of any major game, instant messaging, or other project that appeals to teenagers and you'll see the same behaviour.

Mozilla is a huge project, and they've aimed at mainstream users - so you'll have every tom, dick, and harry using the bug-tracker. This means the bug-tracker has to be something better then a developer bugtracker if they want to get any useful data out of it. Maybe a bugtraq/slash engine hybrid? Mod your way to "take this bug seriously".

RTFM

[FortKnox]

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.

Re:RTFM

[Gortbusters.org]

Unfortunately, we can't even RTFA..

Re:RTFM

[sczimme]

What if some newbie found an integral bug, gets a "RTFM" and is too intimidated to report the bug?

In all seriousness, what are the odds of that? What are the chances that someone brand new to $PRODUCT will find an "integral bug" that somehow eluded the developers and and all the other individuals that use $PRODUCT on a daily basis? I think the odds are minimal; while such an occurrence is not impossible, it is at least very unlikely.

Re:RTFM

[FortKnox]

Being someone that has worked on both sides of the fence, you'd be truely surprised at how a newbie can find crashing and other bugs simply because people haven't thought to do something (because they've been doing it their 'normal' way for so long).

Re:RTFM

[CrayzyJ]

"In all seriousness, what are the odds of that"

Very high. Users with the least amount of knowledge usually can do the most damage. Developers and regular usuers use the system with preconceived notions of what should and should not be done. Newbies almost always do something which causes the application(s) to crash.

In Software Engineering the phrase is something like, 'the least trained tester is the best tester'.

Re:RTFM

[BZ]

This is not for people _submitting_ a bug. This is for people commenting on an already-submitted bug.

Re:RTFM

[WNight]

Honestly, if open source takes over, the gripe will go from MS to RTFM. Its something that should be addressed now instead of later.

Okay. RTFM.

If you buy Microsoft's software, they're obligated to listen to you bitch about its problems. If you download something I offer for free, I'm not obligated to you in the slightest.

If you can say something both coherent and polite, I'll listen. I do want my software to be better, but I'm not going to be abused by you in the process.

Why do you think people are entitled to anything else? I've very rarely seen people told to RTFM for asking a polite question. They almost always get pointed to docs. If they fail to read those, they get told off, but what else do you expect when you rudely demand someone walk you step by step through something you aren't willing to read a help file for?

It's no different in any other circumstance. Ask for directions in a mall and you'll get pointed to the map. If you ignore the map and ask something it would answer, expect to be ignored. Nobody has respect for whiners who demand that other people solve their problems for them.

Re:RTFM

[Anonymous Coward]

How is this RTFM? It's just a guide to appropriate behaviour when using bugzilla. I don't know if you've ever used bugzilla.mozilla.org but, for some bugs have such a large number of useless comments, ranging from 'This bug is really irritating', through 'I'll use IE until you fix this' right up to personal abuse of the developers involved. Not only does this prevent people from doing useful work in the bug report, but it activley discourages developers from working on the project. If your email regually included abuse from strangers, how willing would you be to continue giving up free time for the project?

The situation is particually bad for bugs where there is significant amount of disagreement about the best solution or where a section of the community disagrees with the relevant module owners decision, a famous example being the 'display alt text as a tooltip' bug. In those cases, people usually start ranting about it being 'against the open source spirit' to non implement the features that they want immediatley. That is the direct motivation behind section 1.2.

All this document does is set out clearly what is and is not acceptable behaviour. It is quite specific that offenders should not be publicly shamed, but instead should be referred to the document by private email (see section 3). As far as I know the document is not even linked at mozilla.org yet (although I personally believe it should be linked from the bug writing guidelines). So it's hardly likely to put off new users.

Re:RTFM

[JourneymanMereel]

I've found that many "newbies" find installation errors as a lot of developers don't install all that often. There are also the cases of discrepensices between the FM and the way it actually works... after all, most developers don't read the docs very often so if the doc person is too busy to notice a change when it happens it may get missed entirely.

Re:RTFM

[axxackall]

Check Gentoo forums - "RTFM" answer is ruled out by the Gentoo community, perhaps even by the forum etiquette, which I've never read btw :)

Seriously, Gentoo forums are ones of the friendliest open-source communities. I don't remember if anyone answered to anyone with RTFM. It gives me the hope that it is not true that "the gripe will go from MS to RTFM".

As for Bugzilla's etiquette, it's a good document: short, clear, not intimidating. I don't see anything wrong with this document.

Geeks discussing etiquette?

[l33t j03]

Whats next, some tips on how to pick up chicks?

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.

Re:Geeks discussing etiquette?

[Anonymous Coward]

Eric Raymond has some pointers on the art of making sweet love.

Nice job there slugger...

[chrisgeleven]

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?

One rule that didn't make it...

[japhar81]

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.

Mirror on mozilla.org.uk

[DeadSea]

This story is mirrored on mozilla.org.uk.

No obligation

[Anonymous Coward]

I especially like this one:

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.

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.

Re:No obligation

[Natalie's Hot Grits]

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.

Appropriate Bugs or not...

[Gortbusters.org]

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!

This raises two important questions:

[burgburgburg]

a) What is the same as "the developers must do my bidding"?

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.

Re:This raises two important questions:

[Jim Hall]

Probably the most irritating phrase I see as an open source software person is "thanking you in advance for your prompt reply!!" That just makes me want to not respond to your email right away. I am a coordinator for a fairly large and active project. I can't always get to your email right away all the time.

But seriously, some of the staff at my work seem to think that CC'ing my boss on emails is the same as "you will do my bidding." :-)

Re:This raises two important questions:

[Gerv]

a) What is the same as "the developers must do my bidding"?

"Hi, I'm Greg, your new manager."

What is the phrase or action that will get the developers to actually do my bidding?

"Please", backed up by a good reason, often works wonders. Seriously.

Gerv

Re:This raises two important questions:

[wirelessbuzzers]

Dude. Chill. Remember that while reading TFM is an excellent map from {Linux commands} to {what they do}, there is not a simple inverse map from {what you want to do} to {Linux command}. apropos and Google are decent steps, but they don't always give you the answer even if you know how to search.

It is much easier just to ask someone who knows what they're doing and can answer in 5 minutes than to spend hours googling and crawling the man pages. I have several friends who have been using Linux for a year or so, and when we can't figure something out, we IM / write each other and ask, and it's better that way. If you have a fish that you're not going to eat, why not give it to a man?

Re:This raises two important questions:

[Xerithane]

Dude. Chill. Remember that while reading TFM is an excellent map from {Linux commands} to {what they do}, there is not a simple inverse map from {what you want to do} to {Linux command}. apropos and Google are decent steps, but they don't always give you the answer even if you know how to search.

Ok, asking for a hosting providor that costs less than $100 when I post a comment that says, "There are plenty of hosting sites that offer dedicated servers for around $100" is the line that I will not respond.

It is much easier just to ask someone who knows what they're doing and can answer in 5 minutes than to spend hours googling and crawling the man pages. I have several friends who have been using Linux for a year or so, and when we can't figure something out, we IM / write each other and ask, and it's better that way.

There is a difference between IM'ing a friend and emailing someone you don't know. Finding out a simple solution in google takes them less time.

If you have a fish that you're not going to eat, why not give it to a man?

Because it promotes laziness, however, I will gladly trade it for services. I do not give things away, I make people work for them. Very few things in life were given to me, and I had to work for everything I have. I'm not saying it's the way I'll raise my kids, but I'm not going to help someone out just because they need a fish. They're going to work for it, then they get a fish.

Re:And speaking of etiquette

[Gortbusters.org]

More ironic how because of that redirect, the majority of the comments on this article will be people trolling for karma by posting the article text? ;)

WTF?

[spells]

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's not a RTFM though

[xactoguy]

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.

Top 10 Bad Bug Reports

[AtariAmarok]

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!"

Solution

[hackwrench]

Drag the link to the address bar.

Bug Reporting Problems,

[PktLoss]

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.

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 /when/ you find the same thing allready there, post a comment with your input, and stats on your OS and machine.
-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.

Re:Bug Reporting Problems,

[theBrownfury]

One of the biggest problems with bug management is the ability of the bug viewing audience to find bugs that may match the problem they are having.

I've worked within a major corporation (RAID queries) and also worked closely with Mozilla and in both instances I found it extremely frustrating to find bugs, often when I knew the exact keywords that are associated with a given bug.

If there was a search tool akin to Google for searching accurately through large bug databases where users could easily find bugs then the issue of duplicates would be solved almost entirely.

Here's what I recommend

[azav]

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.

A natural extension of Netiquette...

[Kjella]

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

Urge to kill: Growing!

[ohboy-sleep]

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.

I'm surprised

[iplayfast]

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.

Joel Spolsky on bug reports

[XNormal]

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

Re:Yeah right

[ruriruri]

That classic phrase is also the truth. At this moment I have 60 "priority 1" "bugs" in my queue, for our particular produkt. Each one would probably take on average 3 days to fix. At the same time I'm developing new features unrelated to those bugs. Last time I checked I was exactly *one* person.

Don't take it personally when your bugs are ignored. Fix them yourself if they're so tiny.

bug 22274

[!splut]

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.

Re:Yeah right

[row314]

Hmmm. So, what you're saying is, they have no right to ignore you? To ignore their obligations to you?

If that's the case, then please consider this: if you're not paying them, and they haven't otherwise contracted with you to produce the feature/bug fix/etc. you desire, then how exactly are they obligated to you? They aren't forcing you to use the software; if you do, you (usually) don't have to pay for it. Better still, you are able (even welcome!) to grab the whole mess and start playing with it yourself. No need to be limited to "Hey, this could be done better!"; instead, you can show them how to do it better! Or not... except that even if you personally can't code it up, nothing prevents you from hiring someone else to do it.

On the Other Hand, Make It Easy

[TheWanderingHermit]

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.

Re:Yeah right

[Gerv]

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"

I've never seen anyone use such a management-speak phrase in bugzilla.mozilla.org. :-) But it's still a fair response - "thanks for the bug report, but we aren't going to fix it. However, if it's important to you, you have the source."

Gerv
(document author)

Those are good, but also...

[gosand]

I have been in QA for about 10 years. (no, it is not just a stepping stone to something else as many people seem to think.) I have always told other people that they should raise bugs so that nobody should have to call and ask you any questions.

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.

Better UI

[Screaming Lunatic]

Bug tracking tools need a better UI to encourage better bug reports.

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.

Two Way Street

[darkstar101]

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.

Re:Two Way Street

[Gerv]

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)

Some right, some wrong.

[k8to]

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.

Re:Some right, some wrong.

[Gerv]

"Works 4 ME!!" is not a problem resolution.

It is; it often denotes that the bug has been fixed between the time it was reported and the time the QA person got to look at it.

Through the last several software houses I've worked out, I've seen rampant miscategorization and misclassification of bugs by lazy developers.

But developers on an open source project have no incentive to misclassify bugs in this way, because they have no obligation to fix them. So, simply ignoring a bug is a reasonable thing to do.

So, if a bug gets marked INVALID, it almost always is.

Gerv

My Bugzilla experience

[ishmaelflood]

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.

the bug is in the community.....

[vvikram]

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 /var/cache directories of apt
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

Good Testers are Insane

[msobkow]

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

MOD PARENT UP

[ibennetch]

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.