| Here is more mumble from me. I sent it to the CIG committee just now!
I don't expect I will be at your CIG meeting, I have made some of my
views known in the notes file, I don't feel that all of them have been
understood too good though! I am putting down a few points here to clarify,plus
some more stuff!.
1. The whole thing about writing up calls is to make it easy for me and
others to find out what has gone on with a call and what the current status is
without too much brain damage.
(looking through many of the groups calls is a NIGHTMARE and very time
consuming. You can mail the call to yourself, but it don't read in
chronological order - also a lot of them are too long for mail to work). Doing
show description 20 or so times is no fun either.)
To this end I think ONE description (I suggested 'A' for this) to
summarise all the action plans, technical conclusions locations of dumps etc.
Hopefully an ops/backup/manager person could look at this one description and
get a summary of all that has gone on. If they want more info they can look at
other descriptions and find
technical updates by various specialists (gory details)
diagnosis notifications to the branch
canasta summary (for proposed search tool also)
comments from people outsinde the group (eg ops, ccd)
What codes we give these don't matter too much as long as we all agree and
it is easy to remember/not too confusing. (I think the only bit that is
in dispute is the first two, what we should call them eg p and dn or P and
ta/td)
Also the number of updates don't matter too much, if the call goes through a
new phase it might be appropriate to create a new 'a' description, likewise
if different specialists have a go it makes sense to have different technical
updates if they have a lot to say. I just want us to get away from the current
thing where you may have the same person put half a dozen updates on in a
couple of days...
--------------------------------------------------------------------------------
2. As well looking at calls when asked, I have been going through the calls
in the systems and bug_hold queue on an ad-hoc basis. I time stamp the call
using the opt-sup field and if I can think of anything useful to say I will
put an update on. Also if I think the call needs some action I will
say - eg escallating.
A number of questions comes to mind on this
> I would like to do this through individual queues. Does the group
want me to do this - or should I leave other peoples queues alone?
> if I timestamp the calls can I ask others to leave that field alone,
if it gets used for other things my system will get confused!
I don't want to sound too pushy but if I put an update on a
call saying should do this - I would rather have an argument about
it than be ignored. (I can think of a recent example when I put
update in evening with a comment on the front saying to check my update
- but was told the next day that hadn't get around it because he wasn't
too sure about ....) If I haven't made myself clear please mail or
phone me, especially if it is an important customer.
(I am not making this a high priority, I will aim to look at most calls
about once a week, but only when I have the time. I don't want chaps to
start relying on me to do it, if you want help on a call please still
ask.
--------------------------------------------------------------------------------
3. Regarding call ownership. I like the way that the calls are
owned by the group rather than one person. Much better way of doing
things. to make it work best need to sort a few things - if not already
what happens if someone is away, especially aes calls, who responds to
the updates
how do we ensure that an indepth analysis is performed (rather than
several people having a quick look). I expect that is where I can
help, but think it should be part of the procedure independant of me??
(as I think I mentioned, need clearer updates, if you are passing
calls around all the info must be on the calls in an easy to find
format)
--------------------------------------------------------------------------------
4. > Can you make sure that dumps are not automatically deleted when the
call is closed. (If it is a call I have worked on please mail me just
in case - I have been caught out before when I have resequenced a
call and lost the dump AND the tape got sent back! These ongoing
problems where the call is closed pending a recurrance, it would
be advantagous to retain the dump or at least the tape for a month
or so.
(i will be setting up something (oneday) to help archive dumps...
--------------------------------------------------------------------------------
5. Please make the use of the available information. With the high volume
of calls you guys do it is easy to not to use what you
have already. I do this myself, often miss the obvious.
eg.
Non-fatal bugcheck, set bug-check fatal but not check the error-log
to see what crash it is.
hangs - getting the customer to force a crash but not getting them
to halt/continue a few times to see what it is doing.
Not getting the customer to check the console/search operator.log
etc ...
--------------------------------------------------------------------------------
6. When you want to get hold of me - the details of when I am expecting
be contacted should be uptodate on router, (normally when I am awake.)
If you can't get through you should get a voice mail instead. Please
leave a message I should get it as I check voice mail quite often. If
you can try again a little later if you don't mind as them
yuppy phones don't always get thru first time.
<<< Note 173.0 by COMICS::GLEDHILL >>>
-< Dave Gledhill - team mascot >-
|