The most important part of reporting a bug is giving the programmer the ability to duplicate the bug on his machine. If we cannot find a bug, we cannot fix it. Hence, bug reports like "hey, it crashed when I clicked on it" aren't of much value to anybody.
Finding a Bug: Repeatability
So, if you think you've found a bug, before you do anything else you should quit the app and attempt to find that bug again. And try to find the shortest set of steps necessary to make that bug appear.
Also, see if the bug is specific to a certain piece of media -- sometimes playback will fail or be strange on one file but work fine on plenty of others. If so, make sure you indicate that and try to make such files available to the programmers for debugging.
If you're comfortable with the fact that you can repeat the bug continually, then you should look through bugzilla to see if someone else has already found that bug. If so, you can comment on that bug with your own information.
Reporting a Bug: Clarity
If the bug is not already in Bugzilla, you should make a new bug.
Please, for the sake of our sanity, make one bug per report. Don't report a list of things -- each item in that list should have its own bug (and a tracking bug to which they are all dependencies may then be created if they all really are related).
In addition to correctly selecting the Component against which the bug should be assigned as well as selecting the proper Platform and OS you're running on, make sure you include in the description:
- What version you are using (and/or nightly date, or svn revision)
- A detailed set of actions that cause the bug to appear
- A detailed description of what you see as the bug
- Optionally, what you would expect the program to properly do there
Using the our New Bug Template is highly recommended.
A proper summary
Without a doubt, the summary string for the bug is very important. It's necessary to put just the right amount of information in the summary so we can properly identify it from other bugs in a list display.
"Deleting entire library leaves blank lines" is a good summary, but "Deleting fails," or "Deleting is ugly," or "Blank lines" are not.
Try to include information about when and/or why in your summary, not just what.
Other Opinions
Mozilla's Bug Writing Guidelines are another fine set of instructions.
