Yo
OK, thanks Flavia. I guess I didn't see Dan specifically mention
CIC-on-duty so assumed he was talking normal users.
It's good that GGUS works like I think it should ;-) And it is obvious
I haven't spent much time trying to use it :(
J "I hope I'm not wrong this time" T
Flavia Donno wrote:
> 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
>>
>>
|