Frequently, newcomers to the ApacheWorld are frustrated by how little help they receive for their BugReports. Often its because they approach the community the way they approach a vendor with whom they have a support contract. They had a problem that they don't feel is in their software, therefore it must be the Vendor's problem. Their usual approach is to say "X doesn't work" and the vendor contacts them, walks them through figuring out the problem and either determines that its not a bug or determines it is and hopefully sends them a patch.
This approach doesn't work with many communities inside the ApacheWorld. The problem is that folks are doing this often in their FreeTime or in support of work they are performing for their client. This means they aren't obligated to fix YourProblem. However, many of the developers/committers take great pride in their project and want to see it succeed. Therefore, they appreciate your BugReport even if they don't always take the time to tell you. However, this doesn't mean they'll get back to you pronto. The goal of the BugReport is more to help the software than you. If YOU need help you need to as "HowDoIAskAQuestion"?
Another problem with legitimate bug reports is that often they contain insufficient information to warrant tracking. For instance "Downloaded (apache project name) and it threw an exception when the servlet loaded". This isn't the makings of a good bug report. What was the Exception? What did you call which threw the exception? Which servlet threw the exception? So probably the filer of the BugReport intended to start a discourse. The trouble is that 5 useful bug reports got filed and 10 useless ones. The useless BugReport is probably filed by someone who does not yet understand the technology they are working with. We're not here to teach you the OneTrueLanguage. Most of us will try to be helpful, but ultimately if you just learned how to do "HelloWorld" in C then you're not going to write ApacheHttpd modules the next day. The useless BugReport may be a duplicate of a more useful one. The useless BugReport just doesn't contain enough information to even begin to find the problem. So frequently these are summarily closed, a faq is posted within one, or some other rude or seemingly rude action is taken.
So we've heard about how to make a useless bug report. How do we make a useful one?
- Ask questions on the mail list. The best bug reports are after discussions are had and someone says "Oh thats a bug, please submit it?" -- And you MAY even get a work around and thanks!
- Include:
- Operating system, Operating System Version (usually via a field)
- Find the appropriate project / module / subcomponent and select it.
- Version of the software you're filing a bug against
- stack traces, error messages, exceptions
- Walk through of what you did
- configuration information (for example: Classpath, Httpd directives, etc)
The Minimum amount of executable code necessary to reproduce it (In Java, PERL or C this would usually include a "main" function of some sort)
- An xUnit test (if possible) which shows the bug (you will get accords for that one)
- Any data files inputted or outputted in the process which are necessary to reproduce or demonstrate the bug.
- Any other information YOU would want or gathered while tracking down the bug.
Related: HowDoIAskAQuestion? HowDoISubmitAFeatureRequest?