View Source

Writing good bug reports isn't easy... they need to be written when something didn't work and typically are something people are just trying to getting done, before moving on to something else.

However, as in all open-source projects, good bug reports can save a lot of time in the long run. It prevents the same issues from getting raised multiple times and the better the bug description the less time is spent on non-bugfixing work.

Here are some guidelines on how to write good bug reports, based on the years of Open Source experience from the Membase team:

* Search for the bug before filing a new one.
If you've run into a bug, there is a good possibility that someone else has as well. In fact, there may even be a workaround. Search for your issue first and possibly add to the comments to an existing issue if there is new data.
\\

* Use a good summary for the bug report.
The search result page will list the summary for the matching bugs, and by using a good description of the bug report the reader may easily filter out the bug report without having to look at it.
\\

* Include as much information as you can about the bug.
The more information you provide about the bug, the easier it is for the person who is going to fix the bug. You should try to explain what you did, what you experienced and what you expected (unless that is obvious). By explaining all this, people may be able to answer your bug without having to download and analyze the logs / stats. This will also help people searching our bug database to figure out if this is the same bug they are seeing.
\\

* Try to write in a search-friendly matter.
If you're seeing an error message, please write it _exactly_ as it is printed (use copy'n'paste), and don't write approximately the same.. In addition to this _please_ paste part of the error messages you're seeing in the logs in the description field even if you're attaching the zip-file. (the search functionality don't search the zip files...)
\\

* Stay professional.
Don't let your mood affect what you write in the bug report. You may think something is a "pain in the ass to use"; that someone must have been drunk while designing this; or should have done stuff differently, but writing it in the bug report doesn't fix the bug. Nor does it help us in fixing the bug. Use a professional neutral tone and keep your focus to the facts.