Re: [Nms-cgi-devel] nms project - moving forward

[Nick C. <ni...@cl...>]

On Tue, Jan 14, 2003 at 12:32:49AM +0000, Simon Wilcox wrote:
> > Our current standard of support is less than perfect, but I hope you'll
> > agree that it's a lot better than none at all, so it's still a big win
> > over Matt's scripts.
> 
> Definitely but I think that Dave is right to consider how we organise the 
> group to go forward in a sustainable fashion and to do it before it 
> becomes really critical.

fair point.

> > > These groups will also be responsible within themselves for assign rotas
> > > of people who will deal with support issues. These will designate a
> > > "first line support" person. This person will be able to call on other
> > > people within the group to help them solve problems that they can't work
> > > out on their own.
> > 
> > That would be a good idea if we all did this 9 to 5, but given that we
> > don't, internal escalations are really going to kill support turn around
> > times.
> > 
> > Anything that moves away from the existing scheme (first person who
> > both sees the question and knows the answer replies) is going to
> > extend turnaround times as far as I can see.
> > 
> > If people are ignoring support requests to which they know the answer
> > because they aren't in the right group then turn around times will be
> > even worse.
> 
> I put my hand up to this one. I've found that I tend not to answer 
> requests because I know that Nick is likely to do it. This has two 
> explanations.
> 
> 1. I don't think we should be sending multiple, possibly contradictory 
> messages to new users. I would prefer a more consistent approach.
>
> 2. I don't think it is a good use of resources to duplicate the support 
> effort.

Both valid points, but are those considerations important enough that we
should be sacrificing turnaround times to meet them ?  Maybe they are.

> I would rather know that it is my $timeperiod to respond to support calls 
> and that I should be paying attention to the list. When $timeperiod is 
> over i would carry on with any open calls but someone else would take over 
> the new ones.

Having a single person follow each call through is nice for user
comfort, but not optimum for a quick turnaround.  IMO the speed at which
users get a satisfactory answer is the most important thing, as that is
what stops them giving up and using another (maybe less secure) script.

Many times, one of us has answered an initial query with a request for
further information, and another has answered the reply with the
solution.  This is a good thing IMO.

> As it is, it is all too easy for me to slack-off knowing that the calls
> will probably get answered by Nick. This isn't good but as you say, we all
> have other demands on our time. If you're going to answer the call anyway,
> why do I need to spend the time ?

Because you answering it now is better in terms of turnaround time than
me answering it later.

> In respect of escalations, I feel bad that when I had reached the end of 
> my knowledge there was no backup to help get the call resolved. Giving 
> explicit ownership to individuals helps to encourage that support. 
> Handled correctly with the user, they should understand that more help is 
> needed and the developer should actually have more time to help with such 
> things if they are not busy answering lots of other calls.

You're talking about the TFmail upload problem, right ?  I looked at that
(quite hard) but I couldn't think of anything that you hadn't already tried.
The escalation method of posting to nms-dev *didn't* let you down there - I
would have failed just the same had it been escalated to me via a fancy
ticketing system.

> > I don't like that.  Lurking on the dev list is a nice way to get into a
> > project, and I wouldn't like to see us close that door.
> > 
> > If this is meant to encourage people to join support groups, I would
> > have though it would be better to take commit privileges away from
> > those who won't.
> 
> I'm not sure that closing the dev list will help establish a community but 
> I do think there needs to be an invite-only list of people that drive the 
> development of the project.

We could do that with CC in email with our leader posting the outcome to
the dev list as a policy announcement, couldn't we ?

--
Nick