Re: OT: How to file a radar
Re: OT: How to file a radar
- Subject: Re: OT: How to file a radar
- From: JohnG Otto <email@hidden>
- Date: Wed, 19 Jul 2006 15:25:48 -0400
> On 2006 Jul 19, at 13:47, Laurence Harris wrote:
I'm of the mind that if a bug hasn't been fixed in a few years and a
couple of major releases of Mac OS X, it's pretty much in that black
hole. ;-) Seriously, I think some bugs do just get pushed onto a
perpetual back burner and never get resolved or closed. I have several
open bugs going back to Dec 2001 (rdar://2833846) that I have no
reason to believe are still being discussed. Many were filed in 2002
and 2003 and based on the nature of the bug I don't expect anything to
ever be done with them. Sure seems like a black hole to me. ;-)
I know others see the same thing. I think people would be less
inclined to get discouraged about filing Radars if more bugs were
closed, even if they aren't going to be fixed.
In ye olden days I developed a couple bug and feature request tracking
systems. We sorted pre-release (in-house) bugs and features separate
from post-release. Beta testers were flown in to our facilities, so
their reports were classified as pre-release/in-house.
But I saw some bugs that were carried over for several years until a
management champion (usually a release manager) came along who wanted
them cleared.
Developers were closing bugs with the comment "known problem". What
that boiled down to was that we'd looked at it a couple years before
and didn't see any good solutions at the time, and then some of us got
in the habit of thinking of it as one of those things held in abeyance
without revisiting it. Even with one layer of management confirming
"closure" the process was broken.
One minor case that always pops to mind when such discussions come up
was simply a bit of poor documentation. It had to do with paging
through a graphical document (before scroll-bars) and the example shown
had the user setting the option to 50%. They couldn't tell whether
that meant 50% new material would be shown with each page or 50% old
material would be shown with each jump, and in that example it did not
matter. It drove some big money customers (several million dollars per
year each) nuts, and it would've taken the authorized tech writer 5
minutes to change, but the bureaucracy kept resisting change. It
wasn't exactly a bug. It wasn't associated with a new feature. It
wasn't a huge deal but a constant annoyance that customers kept
reporting. Getting the example changed to illustrate a more realistic
10% old, 90% new setting took several years.
In some cases, the sales-people had to intervene to get corrections for
bugs that had drifted into one of the zombie categories.
Eventually, we put in a means for the urgency and severity to be
negotiated (or at least keep track of customers' designated levels for
urgency and severity AND our consensus -- weighted by management --
levels).
So it comes down to will, communication, and some means for negotiation
of the status among developers, product management and customers. The
only recourse Apple customers have now, if there's a dispute over
whether a bug has been corrected, is to keep filing new reports after
they've been officially "closed" and hope that they get through the
gauntlet.
Of course, if we developers were even more inexpensive and didn't need
to keep investing in training and books and new computers, and if
communication were better, then it would be possible to throw more
developers at it to reduce back-logs... until the additional developers
produced an excess of chaos. :B-)
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden