Good bug reports require effective communication, whether written, verbal, or visual.
Good bug reports are specific and reproducible.
Part of my job here is to translate incoming support cases into “good” bug reports for the development team.
Here’s a few tips for writing good bug reports:
Write a clear summary of the problem
The summary is a one-line description of the problem. This is the first thing that the bug reviewer is going to see, so it should clearly describe the problem. Try to be specific, and include keywords. The summary should include enough information to differentiate the report from other issues in the same general category. For example:
- Bad: “render tree bug”
- Good: “Missing connections after loading a pass preset in render tree”
Include repro steps
Do include the specific steps to reproduce the problem. Don’t leave out details.
Repro steps are probably the most important part of a bug report. Without them, IMO, it’s unlikely that the bug will ever be fixed.
Ideally, a bug report includes the minimal repro steps that isolate the problem.
If writing step-by-step procedures is not your thing, then recording a video could be an alternative.
If necessary, include scene files, models, or scripts to help reproduce the problem. For example, a stripped-down version of whatever you’re doing in your production scene may be helpful.
Describe the expected results, and the actual results
For further reading:
eX-SI 
A neat summary might look like this:
When I do x, the software does y; the expected result is z.
O
Stephen, where do we send these reports?
Here:
http://usa.autodesk.com/adsk/servlet/item?id=12331406&siteID=123112&SelProduct=Softimage