Writing a Decent Bug

As long as we’re on the topic, I should reiterate some of the
guidelines for writing a decent bug. (Violating them will tend to get
your bug bounced back to you or sent to the back of the queue.)

1. File a bug on a specific issue. A bug on a 100-line script that
“doesn’t work” is not specific. A bug on three different problems that
you happened to hit on the same day is also not specific. (In that
case, file three bugs. If you find yourself typing “by the way” or
“while I’ve got your attention,” you’re probably breaking this
2. Use an informative title. “Getting item 0 of a list crashes” is an
informative title. “AppleScript is broken” is not.
3. Read the problem template and follow its instructions. If you don’t
have anything new to say in a section (for example, Notes), delete it.
Always delete the instructional text.
4. Try to reproduce the problem in the fewest steps possible. Short
scripts are better than long scripts.
5. Describe both what did happen and what you expected to happen.
6. Include the OS version, and the application version if applicable.
7. Don’t editorialize. Think Joe Friday: just the facts.
8. Don’t diagnose. That’s our job.

Also, just because it’s “Bug” Reporter doesn’t mean you can’t file
enhancement requests — just check the “enhancement request” checkbox.

–Chris Nebel
Apple Development Tools