[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Dear Users Group Members,
I think some valid concerns were raised in these messages, and that these
concerns need to be addressed. Let me begin, however, with an introduction. My
name is Alan Alters, and I am the manager of Symbolics Software Services. To
most of you that means either the customer-reports mailing list or the software
support hotline. I can be reached through any of the following media: Phone:
(800) 824-4263; Electronic Mail: Alters@stony-brook.scrc.symbolics.com; US Mail:
Alan D. Alters, Symbolics, Inc. 21605 Plummer Street, Chatsworth, CA 91313,
should any of you wish to contact me personally.
Now to the messages.
Date: Sun, 7 Feb 88 20:27 PST
From: Mabry Tyson <TYSON@AI.SRI.COM>
This is in reply to Jerry Bakin's message "Re: A bug with defconstant?".
Things we've been banging our head against for years...
Symbolics doesn't really have the staff to give out many individual patches.
I think their idea of customer support is to listen to people and determine
whether it is a bug in their code or in the way you are trying to do something.
Fine, but then if it is a bug in Symbolics's code, they don't usually send out
patches. (Occasionally they can't as the patch is too pervasive.)
Like most organizations, there never seems to be sufficient resources to do all
the things we would wish to have done. Nevertheless, Symbolics Software
Services is committed to providing our customers with the highest quality of
technical support we can. To this end, there have been some recent changes made
which we feel will enable us to better serve our customers.
The Software Support Contract Service is defined to include a
subscription to the software technical bulletin (distributed in hardcopy
approximately six times a year). Symbolics SHOULD be sending out those
bulletins. But we all know that Symbolics is having hard times and the
question often is what things can go that, while they impinge on current
needs of the customers, may allow the company to weather its roughest
times. I would rather the company survive.
I am pleased to announce that one of the first changes we have made is to
reissue the Software Services Technical Bulletin. The current issue is
presently being prepared for mailing, and should be reaching customers with
Software Subscription Contracts sometime this month. This issue is the result
of the joint efforts of each and every member of the Software Services
organization. It contains several patches, status updates of known bugs, and a
lot of general information relating to both technical and administrative issues.
As you will notice immediately, its new look is also reflective of the changes
being made in Software Services.
One of the sore points between customers and Symbolics has been the
restriction of sources. Not just the lack of some sources but also the
restriction that one PLA (Program License Agreement) holder can not give
any form of Symbolics code to another PLA holder. This prohibits me
from sending to others patches for bugs that I have found and fixed
myself (whether or not my fix is the one Symbolics would choose).
I know that this has been a point of avid discussion since this policy was
instituted. Unfortunately, I have no updates on this at this time. I can only
suggest that your concerns about this or other Symbolics policies continue to be
raised constructively through your organization.
Symbolics and SLUG Inc. have a method for distributing larger pieces of code
that contain Symbolics code. I applaud this but it is somewhat cumbersome
and doesn't allow for relatively quick bug fix distributions.
Perhaps this is the time that Symbolics could consider alternative methods of
allowing users some supporting of other users. If Symbolics doesn't have the
current manpower to help users with bugs in Symbolics' code, then maybe they
can let other users help with that support.
A suggestion: Let Symbolics maintain an electronic mailing list (at
Symbolics) that only goes to those people with PLAs. This would not be
a direct mailing list but instead would be one in which someone from
Symbolics reads the incoming mail and redirects it to the appropriate
mailing list of customers with PLAs. (That way, SRI wouldn't get to see
anything about PASCAL since we haven't bought that product.) The header
of each message sent out would contain whatever legalese that would make
the contents not be redistributable. (eg, "Portions of the following
message are copyright Symbolics and may not ...") Thus I couldn't take
the message and forward it to someone outside my own company (or
whatever legal entity that holds the PLA). All outgoing messages would
have just a TO: address of the list itself (incoming mail sent to that
address wouldn't get sent out automatically). The FROM: address could
be the incoming address. There would be no CC: addresses.
This would allow the customers to distribute bug fixes, albeit
indirectly. We legally send them to Symbolics and Symbolics sends them
to the appropriate people. Of course such mail would not contain any
stamp of approval by Symbolics. If I sent in mail describing a patch I
made, others would see it but it might not be what Symbolics would
suggest (whenever they got around to fixing it or explaining why what I
thought was fixing wasn't a bug).
At present, the Software Services organization is doing some work for SLUG
concerning DIALnet and Internet access. While I can make no immediate
commitments as to whether what you propose above can be done, I have asked our
staff to assess its feasibility with respect to current resource availability.
Mark Hannon, manager of the Future Technologies for Software Services group will
be contacting you next week to discuss this further.
On a similar note, however, FTSS is presently involved in the initial phases of
setting up a bulletin board service for Symbolics Customers. This would be used
to disseminate bug status updates, patches as available, and other information
of interest. This would allow for a greater flow of information from Symbolics
to its customers as it would allow customers to access approved patches, thereby
eliminating patch distribution problems. I think that this would pretty nearly
address the requirement stated in the following paragraph.
I have heard people from Customer Support say that we users don't want to
see all the mail that they get. That may be true, but some of us would
rather wade through the drivel than to run into problems that have been
solved elsewhere. The mailing list I am thinking of would not overlap with
Customer-Reports. Ie, if I wanted to ask about how to do something, I would
send mail to Customer-Reports. If I wanted to report a bug (and patch) to
a standard system function, I could send my report to Customer-Reports and
In addition to this, there have also been some recent organizational changes
made at the Western Support Center. The support staff has been divided into
product specialization teams. The intent here is to grow local expertise and
increase the competence level of the support staff through concentrated
technical development. Calls that come in will be transferred to the team
specializing in the involved area. Additionally, mail requests will be handled
by members of the appropriate team.
Members of each team will also be responsible for reviewing the associated
documentation, and for testing the products we support. Thus we hope to be able
to help the customer pro-actively by bettering our products before they are
released, and afterwards, by providing quality support after product release.
We are also instituting a revised service request escalation procedure which
will specify the actions to be taken as a service request ages. In conjunction
with these plans we are also reducing the incoming load by setting guidelines as
to what will be supported by Software Services. Service will continue to be
provided only to those customers with valid service contracts or product
warranties. Additionally, requests which fall outside the bounds of technical
support, that is, requests which require user code to be written, revised or
debugged, will be referred to Symbolics Consulting Services. In this manner,
each service request can be allocated sufficient resources to ensure that it is
responded to and resolved in a courteous and timely fashion.
In conjunction with these improvements, however, we also will need the help and
support of our customers. Over the next few months, we will begin to issue
surveys to be answered in the context of a single service incident. This "Every
10" survey will allow Symbolics Customer Services to continually evaluate how
customers perceive our services. It will elicit direct customer feedback on 10%
of the service incidents closed. Additionally, our annual Customer Satisfaction
Survey will provide customers with an opportunity to assess the overall
strengths and weaknesses of Symbolics Customer Services. This survey provides
us with a yardstick against which we can measure our performance from year to
year. This will be translated into positive actions which will allow us to
continually improve our services.
Finally, and most importantly, if you have a concern which you feel needs to be
addressed further, please feel free to contact me directly. I thank each of you
for your time and for your efforts in helping Symbolics Software Services to
better understand your needs.
Alan D. Alters
Manager, Software Services,
Symbolics, Chatsworth, CA