Date: Thu, 10 Dec 1998 15:09:03 +1030 From: Greg Lehey <grog@lemis.com> To: Warner Losh <imp@village.org>, Eivind Eklund <eivind@yes.no> Cc: "Jordan K. Hubbard" <jkh@zippy.cdrom.com>, Kevin Van Maren <vanmaren@fast.cs.utah.edu>, committers@FreeBSD.ORG Subject: Re: Swat teams (was: problem reports) Message-ID: <19981210150903.Y12688@freebie.lemis.com> In-Reply-To: <199812100432.VAA58834@harmony.village.org>; from Warner Losh on Wed, Dec 09, 1998 at 09:32:23PM -0700 References: <19981210043511.S15330@follo.net> <19981210123002.K12688@freebie.lemis.com> <28264.913255536@zippy.cdrom.com> <19981210124903.N12688@freebie.lemis.com> <19981210043511.S15330@follo.net> <199812100432.VAA58834@harmony.village.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--f0KYrhQ4vYSV2aJu
Content-Type: text/plain; charset=us-ascii
On Wednesday, 9 December 1998 at 21:32:23 -0700, Warner Losh wrote:
> In message <19981210043511.S15330@follo.net> Eivind Eklund writes:
> : So - count me among the replies :-)
>
> I'm in. I'll volunteer to do something to help. I can spend 4 hours
> a week on this task. If there is something that can be done without a
> great deal of thought, then I'll do it.
Well, I don't have my 5 people together yet, but I was snooping around
on my system and found the attached piece of antiquity. It obviously
doesn't apply to FreeBSD, but you may find some of the ideas of
interest. And yes, it is genuine. Nothing has been changed. Anybody
care to hazard a guess what text formatter was intended?
Greg
--
See complete headers for address, home page and phone numbers
finger grog@lemis.com for PGP public key
--f0KYrhQ4vYSV2aJu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment; filename=SUPNOTE
\poff 7
\sect "Page " 1
\foot "Support Note S85???: Responding to TPRs *** PRELIMINARY ***"
\outlen 70
\center 4
SUPPORT NOTE S85???
Responding to TPRs
Greg Lehey
2 September 1985
\text on
This support note describes methods and conventions involved in answering TPRs.
It is intended for use by Tandem Support and Development personnel only; other
employees should not normally respond to TPRs. This is not a complete document.
It is intended as a supplement to Support Note 82007A.
\text off
\ov
1. TPR routing
______________
\text on
TPRs may be entered in the field, at support nodes or at Development
nodes. Field TPRs are then routed through one of the "field" SSGs
(Sunnyvale, Reston or European), where they may be answered or
forwarded to Cupertino SSG (\SSG). Here they may be answered or
forwarded to a Development node. TPRs which arrive at Cupertino SSG
or a Development node without following this route should be returned
unanswered.
TPRs submitted from Support or Development should be send to Cupertino
SSG, where they will be handled as before.
\text off
\ov
2. TPR verification
___________________
\text on
Once a TPR has been assigned to you, you should verify that is is
intelligible and complete. Guidelines for TPR entry are to be found in
Support Note 82007A; you should verify that the TPR conforms to these
standards. In particular,
\text off
- The problem should be concisely described
- The details specified on the "front page" of the TPR should be
correct: It should
- refer to the correct product number
- specify the correct date of the product
- specify the correct location of the accompanying information. The
names should agree with the subvolume naming convention.
- specify the correct customer address
- contain the detail text in the TPR, not on some node at the other
end of the world
- supply all the files needed to solve the problem on a single,
correctly named and correctly secured subvolume.
\text on
If this is not the case, the TPR should be corrected and an
appropriate note placed in the response text, along with reasons for
the change. Repeated offenders should also have the TPR graded 1 (see
below). This function should already have been performed by the SSG.
If you are in Development and receive a TPR which has not been fixed,
you should also contact the SSG person who reviewed it and point out
his error.
\text off
\ov
3. Reviewing/Responding
_______________________
\text on
It is beyond the scope of this document to describe how problems are
analysed and fixed. The important thing is to ensure that either
\text off
1) you can solve the problem yourself, or
2) there is somebody further up the ladder who can, or
3) there is nobody who can solve the problem.
\text on
1) If you can solve the problem yourself, then do so. THEN decide:
Is there somebody further up the ladder who should be informed about
this? This depends on where you are:
a) Field SSG. If this is anything but a trivial problem, it should
be forwarded to Cupertino SSG, at least for documentation
purposes. If the solution involves code changes, it MUST be
forwarded to Development. If not, it should be forwarded to
Development as an FYI TPR. In either case, tick the DEVELOPMENT
box on the Response Screen.
If it is a trivial problem, return to the field. Tick the FIELD
box on the response screen. Do not enter a system name.
b) Cupertino SSG. If the solution involves code changes, it MUST be
forwarded to Development. Otherwise return to the field as
described in a) above.
c) Development. Probably there is nobody. If it involves code
changes, ensure that they get in the next practicable release.
Do not wait until the release before returning the TPR. Enter a
PMN (see the appropriate documentation) and return the TPR to
the field.
2) If you can't solve the problem yourself, then
a) Field SSG. If there is nobody in your group who can handle the
problem, review the TPR as far as you can get. If there is any
hope that it can be solved, forward it to Cupertino SSG with the
request that it be assigned at \SSG. Tick the SUPPORT box on
the response screen.
If the TPR is a hopeless case (especially if there is not enough
information to make a solution possible), return it to the
field. Tell the submitter what to do if the problem occurs
again (what to look for, what information to submit).
b) Cupertino SSG. If there is nobody in your group who can handle
the problem, review the TPR as far as you can get. If there is
any hope that it can be solved, forward it to Development.
If the TPR is a hopeless case (especially if there is not enough
information to make a solution possible), return it to the
field. Tell the submitter what to do if the problem occurs
again (what to look for, what information to submit).
c) Development. You're on your own. Decide with the help of your
manager. Do not "sit on" the TPR - if nothing better occurs to
you, return it to the field with an explanation of why you can't
do anything with it. If possible, describe what action to take
if the problem happens again.
3) If the problem turns out not to be related to the product against
which it was entered, describe your reasoning why the problem is
not related to the product. Then change the product number to what
you think it should be. If you are responsible for this product as
well, then carry on your analysis. Otherwise reassign to your PRS
coordinator for further action. In Development, this may involve
returning the TPR to Cupertino SSG for reassignment. Do NOT just
return the TPR to the field!
\text off
\ov
4. Response texts
_________________
\text on
To make TPR responses, several conventions make life easier for all
concerned. These are not required, but recommended:
\text off
- Enter all texts in dual case (i.e. normal English writing)
- Remember that date formats vary. Use unambiguous forms (e.g.
2 September 1985 or September 2 1985, depending on your
convictions, but not 2/9/85 or 09.02.85 or whatever).
- Use the following standard texts:
Reviewed by <me>, 2 September 1985
- use this if you look at a TPR, but are not in a position to
formulate a definite reply. May occur several times in a
response.
Reply by <me>, 2 September 1985
- use this if you do have a definite answer and propose to
return the TPR to the field immediately.
Sent to \SSG, please assign at \SSG
- (field SSGs only): Use this if you are not able to solve
the problem yourself and need it to be looked at at
Cupertino SSG.
Sent to \SSG, please forward to Development
- (all users in Support and Development): Use this if you
have a solution which should be brought to the attention of
Development, or in the case of an RFE.
Sent to \SSG, please forward to Development FYI
- (all users in Support and Development): Use this if you
have information which should be brought to the attention
of Development.
\text on
In all cases, the message "Sent to \SSG" (or "Sent to Cupertino SSG")
should be the last line in the response text. This makes life easier
for the PRS administrator at Cupertino SSG.
\text off
\ov
5. Response dates and severity
______________________________
\text on
TPRs may be graded with severities between 0 and 3, 3 being the
highest. The exact meanings of these are described in Support Note
82007A. In general, TPRs with a severity of 2 or 3 are considered
extremely serious problems; the allocation of these severities should
be justified in the text. If they are not, you should establish
contact with the submitter and establish why he has allocated this
severity. It is a good idea to include mail messages in the TPR
response.
Similar considerations apply to response dates, which default to one
month after submission.
\text off
\ov
6. Grading TPRs
_______________
\text on
PRS offers the ability to specify what you think of the quality of the
problem report by "grading" the TPR. There are 3 grades:
\text off
1: This is a very poor TPR, worse than 90% of all TPRs
2: This is a normal TPR
3: This is a very good TPR, better than 90% of all TPRs.
\text on
The grading relates only to the quality of the report provided by the
submitter, never to the problem or its handling, either by customer or
Tandem personnel. It also does not relate to responses by people
other than the submitter.
\ov
When to grade?
______________
In case of doubt, don't. If, however, you get a TPR which, by virtue
of the way it was entered, makes life easy or hard for you, then grade
it as grade 3 or grade 1 respectively. If you find it already graded
by somebody who looked at it before, think very carefully before
overwriting it. In either case, the fact and the reasoning should be
documented in the TPR response text.
Typical cases might be:
Grade 3: The submitter has entered a TPR which essentially contains
the analysis performed to such a stage that there is little, if
anything, which you need to do. If a workable solution is provided,
you should certainly grade it 3.
Grade 1: The submitter has neglected to supply information known to
him, has placed his files on the wrong subvolume or secured them such
that you cannot access them, or has neglected to supply available
information such as dumps or CONFLIST.
Before grading a TPR 1, bear in mind that Tandem has a large number of
employees who are new to the business and may not have been told how
to enter a TPR. In case of doubt, explain to the submitter what he has
done wrong, and do not grade the TPR. If he persists, however, the TPR
should be graded accordingly.
--f0KYrhQ4vYSV2aJu--
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19981210150903.Y12688>