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