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