Bug Reporting Etiquette 305
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 disabled (Score:4, Informative)
Solution (Score:2, Informative)
Re:links disabled (Score:2)
Get Proxomitron, suppress the REFERRER http header.
Re:links disabled (Score:2)
or Opera (enable / disable with F12)
Bug report (Score:4, Funny)
Bug location: Website
Bug symptoms: Site won't respond
Comments:
Slashdotted all to hell.
Bugzilla? (Score:2)
Inappropriate/Appropriate (Score:5, Funny)
"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 (Score:5, Funny)
"Dude! There's a huge f--king cockroach hanging in my kitchen, generating the following output..."
Re:Inappropriate/Appropriate (Score:3, Funny)
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
article text (Score:5, Informative)
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 (Score:5, Informative)
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".
Re:It's a two-way street... (Score:2)
RTFM (Score:5, Insightful)
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.
It's not a RTFM though (Score:5, Insightful)
Re:RTFM (Score:5, Funny)
Re:RTFM (Score:3, Insightful)
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 (Score:5, Insightful)
Re:RTFM (Score:5, Insightful)
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'.
Good Testers are Insane (Score:5, Informative)
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."
Re:RTFM (Score:4, Insightful)
Re:RTFM (Score:3, Informative)
Re:RTFM (Score:5, Insightful)
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 (Score:2)
Ahhhh, yes. You get what you pay for, indeed.
Re:RTFM (Score:2, Insightful)
Re:RTFM (Score:2)
Well, they wouldn't get pointed at this document until after they'd filed at least one bug
But anyway, this is part of the reason why the document requests that people politely point out transgressions by private email.
Gerv
(document author)
Re:RTFM (Score:3, Insightful)
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? (Score:2, Funny)
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? (Score:2, Funny)
Nice job there slugger... (Score:2, Informative)
One rule that didn't make it... (Score:5, Funny)
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.
Yeah right (Score:2)
Re:Yeah right (Score:2, Insightful)
Don't take it personally when your bugs are ignored. Fix them yourself if they're so tiny.
Re:Yeah right (Score:2, Insightful)
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 y
Re:Yeah right (Score:3, Interesting)
I've never seen anyone use such a management-speak phrase in bugzilla.mozilla.org.
Gerv
(document author)
jwz get's mozilla.org slashdotted (Score:2)
Re:jwz get's mozilla.org slashdotted (Score:2)
Mirror on mozilla.org.uk (Score:3, Informative)
This story is mirrored [mozilla.org.uk] on mozilla.org.uk.
No obligation (Score:2, Insightful)
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
Re:No obligation (Score:2)
Re:No obligation (Score:5, Informative)
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.
Re:No obligation (Score:2)
Re:No obligation (Score:2)
You interpret that statement differently than I do. I hear the developers saying they will prioritize which bugs get worked on based on more than the opinion of a particular bug reporter. If that person doesn't agree, too bad. This seems very practical to me, sin
Re:No obligation (Score:2)
That's not what it says. It says "If you submit an offensive bug report, or post an offensive comment, you risk being ignored." Which is fair enough.
Gerv
(document author)
Re:No obligation (Score:2)
Er... the only people I heard whining when Safari came out were the Opera team [com.com].
Gerv
(document author)
Appropriate Bugs or not... (Score:4, Interesting)
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: (Score:5, Funny)
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.
FYI: imperious (Score:2)
Re:This raises two important questions: (Score:4, Insightful)
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: (Score:2)
If anybody emails me with a stupid question, regardless of how nice it is, will not get a response. I get this shit all the time, usually from dimwits on here. They read a comment, then email me aski
Re:This raises two important questions: (Score:2, Interesting)
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 yea
Re:This raises two important questions: (Score:3, Interesting)
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.
I
Re:This raises two important questions: (Score:2)
"I will pay fifty thousand dollars for every bug I submit and you fix."
Re:This raises two important questions: (Score:3, Funny)
"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: (Score:2)
I suspect that large amounts of cash thrown at them will cause them to bump the priority of your request...
Re:This raises two important questions: (Score:2)
Try "I have pornographic movies in my apartment, and lubricants, and amyl nitrate... "
Re:This raises two important questions: (Score:2)
Re:This raises two important questions: (Score:2)
Gotta wonder if it work on the IRS auditors though...
Finance Director: "These are not the balance books you are looking for. Everything is fine."
Auditor: "These aren't the balance books we're looking for. Everything is fine."
WTF? (Score:2, Funny)
I'm sure they don't apply to me.
Top 10 Bad Bug Reports (Score:5, Funny)
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!"
Re:Top 10 Bad Bug Reports (Score:2)
Bug Reporting Problems, (Score:5, Informative)
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.
Re:Bug Reporting Problems, (Score:2)
Gerv
(document author)
Re:Bug Reporting Problems, (Score:2)
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.
-Search It, then
This is your responsibility. Searching for bugs is a pain, and learning a new interface is a pain. You're the expert, not to mention presumably responsible in some way for software quality.
Re:Bug Reporting Problems, (Score:3, Interesting)
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
Re:Bug Reporting Problems, (Score:2)
There is an alternative to the overcomplicated "Search for bugs" [mozilla.org] page. It's called Bugzilla QuickSearch [mozilla.org]. I use it for the vast majority of my bugzilla searches. I even have a Bugzilla QuickSearch textbox on my start page [hmc.edu] (along with a Google search box, etc).
I think "Search for bugs" should be renamed to "Advanced
Re:Bug Reporting Problems, (Score:2)
Re:Bug Reporting Problems, (Score:2)
That would be what the Bug Writing Guidelines [mozilla.org] are for. This document serves a different purpose.
Gerv
(document author)
Here's what I recommend (Score:5, Interesting)
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.
Those are good, but also... (Score:3, Informative)
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
A natural extension of Netiquette... (Score:5, Insightful)
Kjella
Re:A natural extension of Netiquette... (Score:2)
Re:A natural extension of Netiquette... (Score:2)
This may actually be an interesting point of research for a socialogist.
Urge to kill: Growing! (Score:3, Interesting)
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.
Damn straights! (Score:2, Insightful)
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 b
I'm surprised (Score:3, Insightful)
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 (Score:5, Informative)
"""
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:Joel Spolsky on bug reports (Score:2)
- What you expected.
- What you did.
- What you got.
It's much more likely to be remembered if you keep it short and sweet.This is also, incidentally, the scientific method in a nutshell. That's not a coincidence.
bug 22274 (Score:4, Informative)
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.
What happens when (Score:2)
See here. [infopop.net]
On the Other Hand, Make It Easy (Score:3, Insightful)
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.
Response (Score:2)
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
Reporting bugs (Score:2)
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
What open source also isn't (Score:2)
Executive summary (Score:2)
Don't be a dickhead.
Re:Executive summary (Score:2)
Gerv
Better UI (Score:4, Interesting)
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 (Score:2, Interesting)
That said, I think the Mozilla developers are doing a GREAT job and I have a ton of respect for them. I
Re:Two Way Street (Score:5, Interesting)
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. (Score:2, Insightful)
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
Re:Some right, some wrong. (Score:3, Informative)
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
workaround.. (Score:2)
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
Pangolins (Score:3, Insightful)
The game worked by trying to guess what animal you were thinking of. It would do this by asking you a series of questions and finally make a guess. If it guessed wrong - say you were thinking of a fish and it suggested a cat - it would ask you for a question that would differentiate between a fish and a cat. So you would type in "Does it live in water?" The game would add the question to its database and next time would "know" what question to ask before guessing "fish" or "cat". Every time it lost a game, it would get a little smarter, building up its tree of knowledge.
The implementation is obvious. A system like this could, I believe, be very helpful in when reporting bugs and the like since related bug reports would all appear on the same branch and identical bug reports would all appear at the same leaf.
Cheers,
Ralph
Here's a bug... what are the steps? (Score:3, Interesting)
<html>
<body>
<ul>
<li>top level item 1
<ul>
<li>
</ul>
<li>top level item 2
<ul>
<li>
</ul>
<li>top level item 3
<ul>
<li>
</ul>
</ul>
</body>
</html>
Notice that the empty interior unordered list items are overwritten by the parent items.
Pertinent details (IMO):
- tested on Mozilla 1.3 binary release for Windows 2000
- rendering bug
Now for my question: How do I effectively search for this bug to see if it is already listed?
Re:And speaking of etiquette (Score:3)
Re:And speaking of etiquette (Score:2)
Re:Speaking of etiquette (Score:2)
Re:ESR said it better. (Score:2)
Gerv
(document author)
Re:Classic! (Score:2)
Actually, no. mozilla.org.uk [mozilla.org.uk] is one of my personal websites (as you will see if you go to the front page) and is not a mirror of mozilla.org.
Gerv
(document author)
Re:jwz? (Score:2)
Actually, he's submitted 82 bugs [mozilla.org] in the last year (although if you really want to confirm I'm telling the truth, you'll have to cut and paste the link.)
Gerv
(document author)
Re:Speaking of Bugzilla... (Score:2)