Re: Bug reports and documentation updates
Re: Bug reports and documentation updates
- Subject: Re: Bug reports and documentation updates
- From: Phill Kelley <email@hidden>
- Date: Thu, 24 Jul 2003 00:24:44 +1000
At 23:56 +1200 23/07/2003, Keith Bauer wrote:
>
>> There's a 6. case.
>
>
And 7. in my experience:
Personally, I have had good feedback from Apple on all the bugs I've
reported, (even if it wasn't quite as speedy as I might've hoped). With one
exception, all the bugs that I've filed which have been marked "can't
reproduce" have also gone away in subsequent Mac OS X releases, so I
suspect that this status can actually mean one of two things:
a. Apple genuinely can't reproduce because of a poor explanation etc; or
b. The people inside Apple get more frequent updates than the rest of
us; updates which have addressed issues between the time I notice
and report them and an engineer gets to consider my report.
However, there is one thing about the whole bug-reporting process that does
irritate me. I don't mind spending hours developing a test case or
painstakingly transcribing panic screens, then carefully writing a report
and revising it so that it is as clear and concise as I can make it. But
what I *do* object to is investing all that time and effort, only to find
that my report is subsequently marked as a duplicate.
I don't think it's good enough for Apple to say that they judge how
important a bug is by the number of people who report it. In my opinion, it
really isn't open to Apple to decide to waste the time of the second and
subsequent reporters. In particular, and as some of the previous
contributors to this thread have made clear, having your time wasted acts
as a strong disincentive to making future contributions to the Apple
community.
There *is* an alternative. Simply make the Radar database searchable. That
way, when you or I notice a problem, we can go and see if it has already
been reported.
If it hasn't been reported already, then we know it is worthwhile expending
the time to develop the test case and make the initial report.
If the problem *has* been reported already, then we should have the option to:
a. Register an interest in the bug; and/or
b. Supply additional information.
Being able to register an interest in an existing bug gives Apple the
feedback they need on the impact of the bug. They also get all the
information in one place without any real effort on their part. They
probably have people now who have to spend a significant amount of time
sorting through the incoming reports, trying to match up the duplicates. A
thousand original reports vs one original plus 999 registrations of
interest still amounts to the same thing.
Being able to supply additional information achieves a couple of things.
The obvious case is that the initial report has gotten the gist of the
problem but someone else finds a new wrinkle or is otherwise able to shed
further light on the issue. The less obvious case is that someone may even
be able to supply the fix (eg where it is something under the user's
control such as a hosed preference, or order of doing a series of steps,
etc).
Now, before anyone cries, "a searchable problem database can't possibly
work!" or "nobody in the IT industry has ever done anything like that
before!", I'll preempt such objections by saying that it has been done
before and does work. Roughly 20 years ago, I worked for a company called
Control Data Corporation based in Minneapolis MN. Control Data had a
database system called SOLVER which behaved in *exactly* this manner. The
principal customer contact (typically a Systems Programmer at the site;
much like a registered developer in the Apple context) could search SOLVER
to see whether a problem had already been reported, and could then file an
original report, or register an interest in or add information to an
existing report. Quite often, problems would be jointly researched and
solved by the developer community, so that all Control Data had to do was
pick up the fix in the next release.
In short, it has worked before and I see no reason why it could not work
equally well within the Apple developer community.
Regards, PK
_______________________________________________
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.