Skip to main content

To Fix or "Will not fix"

Posted by thetan on June 2, 2006 at 5:00 AM PDT

Preface

Usually developer starts to work on some issues from understanding the problem. A description represents a problem in a general. Unfortunately the actual difficulties of any particular user are hidden behind the common phrases.

A description is intended to be impersonal, which gives to a developer a chance to clearly understand the problem, evaluate it and find the most effective way to resolve.

Priority

The importance of any particular issue is determined according to its
priority. The Priority in its turn defines how fast the issue will be
processed. (such is the case in an ideal world :))

But the life is very unfair and a user once filled the form
(i.e. reported a bug) then has a very limited ability to
affect that issue. He couldn't participate in discussion etc.

All comments are truncated from a bug report so a user could only add
them via Sun site
(look at the bottom of any CR).

It makes an illusion of involvement
but these comments are not assigned by internal bug tracking
system with a particular bug report.

Yes, it looks rather complicated.

But there is another way to affect developers within Sun.

Have you ever heard about Top25 bugs?

These lists are generated with respect to users feedbacks. Every
registered user could vote for (or against) one or
another bug or enhancement. The number of votes is taken into
consideration for the defect priority estimating.

The more votes - the higher priority!
This is rather simple and might be already known to most users.

However, there is another way : forum.

How could it help to an ordinary user? The point is that
all messages from that forum are read by Sun engineers.
If even a responsible engineer just skipped a message any
other engineer can answer or request a right person to help.

Well, I can share with you a true story from Sun.

Some time ago we've received a request 6404008.

An engineer, responsible for that area has already fixed a
similar defect (that is, here is that defect 5039416)
and was pretty sure that this is not a defect any more.

And such is the real case: If we look on it with curiosity
then we could notice that these defects (well, patches for them)
contradict to each other or something like that.

Considering the ponderability of the first defect
(it had a lot of votes) we just decided not to fix it in
order to avoid users' disappointment and not to change the current behavior.
And this is an exact scenario if user submitted a second bug stopped here.
But instead he came to forum () and asked a community opinion on this.

His message (well there were a lot of them) were reviewed by
our engineers and they initiated the internal discussion.

What is the result?

Finally the problem was described more in detail, a fragment of
code that certainly doesn't work with that fix was posted in the
forum, and a class of applications affected by that fix was
described as well.

At last we re-opened the bug back. Have I already mentioned
that the bug was closed as "Will not fix" in the first day of it's life? :)

I should also note a number of votes against that defect. It grew
up to 12 in two days.

As far as I understood the colleagues of the submitter also
presented their votes for him.

These consolidated efforts lead us to the fix for the critical bug
shortly. Lets call a critical bugs those ones which are important to users.

What is this story about?

First of all, we are interested in your opinion on every our
change. We want to draw your attention and give you a new
capabilities to improve your products, make them more simple
and attractive. We hope that our cooperation will be mutually beneficial.

All you need to do is to report a problem to Sun engineers using
one of these methods. Believe there are also another ways!

If this problem is really important (you probably know how to
increase its priority now :) ), solutions will appear very soon!

Good luck!

Related Topics >>