Jeff,
I thought Dan was talking about the CIC-on-duty operations.
For normal users (of course!) the system works already as you describe!
Flavia
Jeff Templon wrote:
> Yo,
>
> hmmm.
>
> The problem Dan brings up is one that's going to happen more and more
> often, so it would be good to approach it the right way. I disagree
> with Flavia and Dan about what that way is.
>
> The system should be designed so that it is *possible* but not
> *mandatory* to specify which center. Also I think it's just plain
> dreaming that a user will take the trouble to figure out how to use
> some far-flung ROC's ticketing system; the objection "yes but then
> make all ROCs use the same system" is also dreaming.
>
> A user will in general know two support channels at most.
> Firstly his / her local expert (if there is one) or else the local ROC
> support structure.
> Secondly GGUS.
>
> If the user knows it's not a local problem, and has a good idea where
> it is, why not allow the user to submit the ticket to GGUS and to
> specify a 'likely responsible site'. This makes intuitive sense to
> me: "the problem is not at my site, so I submit it to the LCG support
> desk instead and tell them where I think it is".
>
> A large fraction of the time (getting larger every month), the user
> simply *does not know* where the problem is. We got a mail yesterday
> from a user here who said "i can't put a file on the storage element".
> no indication of what command used, *which* storage element, manually
> or from within a job, etc. Then it doesn't help to let the user
> specify the problem site ... this is why it should not be mandatory to
> specify one.
>
> JT
>
> Flavia Donno wrote:
>
>> Dear Dan,
>>
>> Dan Schrager wrote:
>>
>>> Hi everybody,
>>>
>>> I have noticed that it appears to be a problem related to the way
>>> tickets are handled in general.
>>>
>>> I have received tickets from various issuers and then in order to reply
>>> to them I had to get access to various centers.
>>>
>>> I find this situation wrong and I would suggest that the "ticketer"
>>> first assesses which regional organization the "offending" site is
>>> part
>>> of and then submits the ticket through that regional organization
>>> designated office.
>>
>>
>>
>> I agree with you. The ticketer does not really need to assess which
>> regional organization the offending site is part as this information
>> is published and therefore known.
>>
>>>
>>> This would mean for the "ticketers" to get access to all regional
>>> offices.
>>> Since there are far less "ticketers" than "ticketees" (I could guess it
>>> from the fact that I am a "ticketee" but not a "ticketer") this
>>> would be
>>> better than ending up with all "ticketees" getting access to all
>>> regional offices.
>>>
>>> Don't you agree ?
>>
>>
>>
>> I totally agree.
>>
>>> There is another issue related to escalation.
>>> I would suggest that escalation should occur only if the reported
>>> problem is not solved at site level.
>>>
>>> Escalation should not happen just because a ticket has been ignored
>>> for too long (while the problem is already gone, in a cab, divine
>>> intervention, etc.).
>>> "Ticketees" may prefer to solve the problem first and then ignore a
>>> ticket for lack of access to "ticketer"'s office.
>>
>>
>>
>> I do not agree with this since there is the danger that a ticket gets
>> totally ignored.
>> The person responsible for the ticket, assigning the ticket to the
>> ROC, should also make sure that an answer is provided. Therefore
>> he/she needs to be notified if nothing is happening.
>>
>>> Some human intervention would be required to close the ticket from
>>> "ticketer"'s part. He is, after all, the one who generated the
>>> ticket. And there are a few "trigger-happy" "ticketers", for sure...
>>
>>
>>
>> :-)
>>
>> Flavia
>
|