Re: AN IMPORTANT MESSEGE FROM SYMBOLICS SOFTWARE SUPPORT

[Richard Shu <rshu@ADS.COM>]

In article <19891027135140.3.JR@WHIPPOORWILL.SCRC.Symbolics.COM> JR@YUKON.SCRC.SYMBOLICS.COM (Johanna Rothman) writes:


>...  We always accept bug reports,
>especially email reports from anyone, regardless of their software
>support status.  We want bug reports from anyone who runs into a problem.

>Anyone on software support should and does received an acknowledgement
>that we received the original bug mail, and mail when we have a closure
>on the problem.  

Why can't you acknowledge *all* bug mail regardless of source?  I thought
the automatic bug mail response mechanism worked just fine.  It told me
that Symbolics received the bug report and might work on it someday.


>One problem we do have is in response time when an
>incident takes a long time to close.  
>When something takes a long time to close (say more than 2 weeks?),
>would you like to see mail saying that we're still working on it, and
>that we either have made no progress, or what progress we have made?

Yes, and why is this something you would limit to software support
customers?  If you get bug mail from someone who is not on software 
support, you could do the following:

1) Reply:  We received your report but since you are not on software
           support it will receive lower priority than those from
           customers on software support.

2) Advise: We got around to looking at your report and have determined
           that the problem is not caused by a bug in Symbolics software.
           Note: this advice is only generated if someone at Symbolics
           has looked at the problem out of curiosity and a desire to
           maintain the quality of Symbolics software.  A detailed
           explanation is not necessary (as it would be to a customer
           on software support).  Customers not on software support 
           have to expect long (possibly infinite) response times.

3) Advise: Your report represents a bug in Symbolics software and has
           been assigned the following priority (based on the criticality
           of the bug).  In other words, the priority is that which
           would have been assigned if a developer had found the bug.
           The customer's need for a fix is irrelevant since they are
           not on software support.  One possible priority is -infinity
           meaning Symbolics doesn't really care about this bug just now
           so don't hold your breath waiting for a fix.

4) Advise: The bug you described in your report will be fixed in Genera X.Y
           Patches are being made available to software support customers.
           Thank you for reporting the bug.

>I've had an incident open for about 6 weeks that the developers were
>completely stymied on for a long time.  If you were the customer I was
>dealing with, would you want to see a response saying "We're still
>stuck, don't know when I'll have something for you, but we're still
>working on it"?

Yes.  Why not?  Remember Symbolics software is different in that much of 
the source is accessible by customers.   If the response described the
reasons the developers were stymied, the customer might be able to provide
more info.  I thought the exchanges on MIT's bug-lispm were informative and
productive.  Software support customers deserve that level of support.

>  I suspect that might be irritating to a large number of users.

I don't think so.

>Do you have recommendations for a procedure when software support takes
>more than a week or two to close a reported incident?

Is there some sort of weekly or monthly progress report that developers have 
to submit?  If so, they could report on the status of any bugs they are working
on and these stati could be forwarded to the originators of the bug reports.
The generation of the status reports should be no extra work on the part
of the developers other than what it takes to generate a regular report of
what they are working on.  Collating the status report with the original
bug report takes a little extra effort but an automated bug tracking system
should make that task trivial.

In summary, originators of bug reports deserve the courtesy of a reply and
some update on the status of the bug regardless of their software support
status.  They are not entitled to a fix before it is relased to the general
public.

Rich



(responsible-p ADS message)
NIL
(si:halt)