Re: BugReporter: was Recipients in Mail.app
Re: BugReporter: was Recipients in Mail.app
- Subject: Re: BugReporter: was Recipients in Mail.app
- From: Christopher Nebel <email@hidden>
- Date: Thu, 26 Jun 2003 23:36:15 -0700
On Thursday, June 26, 2003, at 2:01 PM, Dave Stewart wrote:
On Thursday, June 26, 2003, at 11:19 AM, John Baltutis wondered:
On 6/25/03, Dave Stewart <email@hidden> wrote:
FYI, I seriously doubt anyone from Apple is paying much attention
*in that respect*. File a bug report with Apple's BugReporter
<https://bugreport.apple.com/cgi-bin/WebObjects/RadarWeb>.
I'll also take the opportunity to point out that Paul Marcos from
Apple politely corrected me on the assumption I based that entire
paragraph on. I've heard on the other apple lists (java-dev
particularly) that if you want bugs fixed you need to file reports on
them in order to ensure the bug was in the reporting system (Glen
Fisher repeats his BugReporter motto often ... "vote early, vote
often") and erroneously assumed the exact same thing applied on this
list as well. My apologies for the misunderstanding there ...
You didn't entirely misunderstand. If you have a bug, we still
recommend filing it in BugReporter, because it's the only way you can
truly guarantee it makes it into the system. All bugs that are filed
*will* be read. (Added bonus: you can find out what's happened to bugs
you file.)
While various Apple engineers do read this list, mentioning a problem
here does not guarantee that it will be looked at. It's not that we're
ignoring you, but it's not a formal channel. Things get missed
sometimes, and there's no auditing.
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
guideline.)
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
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.