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
|