Re: Bug reports and documentation updates (was Re: Subclassing NSPort (or NSSocketPort))
Re: Bug reports and documentation updates (was Re: Subclassing NSPort (or NSSocketPort))
- Subject: Re: Bug reports and documentation updates (was Re: Subclassing NSPort (or NSSocketPort))
- From: Bill Cheeseman <email@hidden>
- Date: Wed, 23 Jul 2003 06:32:07 -0400
on 03-07-22 11:05 PM, publiclook at email@hidden wrote:
>
In my experience, submitting bugs to Apple is a waste of valuable time
>
and an exercise in frustration and futility.
My experience is very different. I spend about 10 minutes on my bug reports,
mostly to make sure I explain fully (but not excessively) how Apple can
reproduce the buggy behavior. I send in about a dozen a year. Over time (a
couple of years, now), I find that roughly 70% of my bug reports result in a
reply asserting that the bug is now fixed in a beta release of a new version
of the Mac OS (usually the one I just grabbed at WWDC) and asking me to
confirm it's fixed. I respond to all of these replies. About 90% of my
replies are confirmation that the bug is fixed, and I ALWAYS get a thank you
note in return. As to the 10% of my responses that say the bug is not in
fact fixed, I usually find that I hadn't fully explained how to reproduce it
in my initial bug report, so I explain it better. I ALWAYS get a thank you
note telling me that my supplemental report has been forwarded to the
appropriate engineer. Occasionally I get a reply in a few days saying
they're aware of the bug and working on it.
I don't think I'm specially favored by the DTS folks, so there must be some
other reason why the experience some people have with the bug reporter is so
different from my experience. Anybody who doesn't get replies to their bug
reports should consider why that might be. Here are some possibilities:
1. The author of the bug report is too impatient. It can take Apple a year
or more to fix a bug. (Actually, they may fix it the first day, but they
know developers can't test the fix until Apple has made a new beta release
of the next version of the system available, so the author of the bug report
probably has to wait until the next WWDC timeframe for a reply. Replies from
Apple tend to be bunched around WWDC time.)
2. The author didn't do a good enough job of explaining how to reproduce the
bug. The harder the author makes it for Apple to understand the problem, the
less likely it is that the bug report will be assigned a high priority.
3. The bug report is couched as an angry diatribe against the stupidity of
the Apple engineering team. A good life lesson is that it is generally
counterproductive to insult the person one expects help or thanks from.
4. The bug report discloses an obvious misunderstanding of C or the Apple
frameworks on the part of its author, and the Apple engineer moves on to the
next bug report immediately (perhaps neglecting to mark the bug as closed).
So think the problem through before sending in a bug report.
5. The bug report is real and good, but the solution appears to be extremely
difficult and the seriousness of the bug is ranked relatively low compared
to others that are easier to fix. Good business sense suggests that these
bugs should sink to the bottom of the list or be sent to the Mac OS XI bin.
--
Bill Cheeseman - email@hidden
Quechee Software, Quechee, Vermont, USA
http://www.quecheesoftware.com
The AppleScript Sourcebook -
http://www.AppleScriptSourcebook.com
Vermont Recipes -
http://www.stepwise.com/Articles/VermontRecipes
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.