 |
 |
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 >