Alert.png The wiki is deprecated and due to be decommissioned by the end of September 2022.
The content is being migrated to other supports, new updates will be ignored and lost.
If needed you can get in touch with EGI SDIS team using operations @ egi.eu.

Difference between revisions of "FAQ GGUS-Waiting-For-PT-Process"

From EGIWiki
Jump to navigation Jump to search
Line 16: Line 16:
== Respond to a ticket ==
== Respond to a ticket ==
After a ticket gets assigned to a PT by DMSU the PT should set the ticket status "in progress". Setting status "in progress" indicates the PT has noticed the ticket ([[FAQ_Report_Generator_(GGUS)#Response_time | response time]]). Adding a comment can not be recognized as response as users are not explicitly mapped to support units in GGUS. Hence responding to a ticket is strongly related to setting the ticket status to "in progress".<br>
After a ticket gets assigned to a PT by DMSU the PT should set the ticket status "in progress". Setting status "in progress" indicates the PT has noticed the ticket ([[FAQ_Report_Generator_(GGUS)#Response_time | response time]]). Adding a comment can not be recognized as response as users are not explicitly mapped to support units in GGUS. Hence responding to a ticket is strongly related to setting the ticket status to "in progress".<br>
Once 75% of the maximum response time defined in the [[FAQ_GGUS-PT-QoS-Levels | level of service]] are over the system sends a notification to the PT. This feature is kept from the EMI era and well known to the PTs.<br>
In case the status is still "assigned" 5 working days after assigning the ticket to the PT the system will send a 1st reminder to the PT and add the ticket to the [https://ggus.eu/pages/monitor.php ticket monitoring dashboard]. After 5 more working days the ticket status is checked again. If it is still "assigned" the system will send a 2nd reminder to the PT. 10 working days later the status is checked again by the ticket monitoring team for any response of the PT. In case of no response the ticket monitoring team will take this as an [[#Implicit_reject | implicit reject]].<br>
In case the status is still "assigned" 5 working days after assigning the ticket to the PT the system will send a 1st reminder to the PT and add the ticket to the [https://ggus.eu/pages/monitor.php ticket monitoring dashboard]. After 5 more working days the ticket status is checked again. If it is still "assigned" the system will send a 2nd reminder to the PT. 10 working days later the status is checked again by the ticket monitoring team for any response of the PT. In case of no response the ticket monitoring team will take this as an [[#Implicit_reject | implicit reject]].<br>
{| cellspacing="0" cellpadding="2" border="1"
{| cellspacing="0" cellpadding="2" border="1"
Line 50: Line 51:
* adding a reference to the PT bug tracker if any
* adding a reference to the PT bug tracker if any
* setting ticket status "on hold"
* setting ticket status "on hold"
 
The ETA should give a quite concrete estimation on when a fix will be available. However adjusting the ETA in case it does not fit the PT's release calendar is possible at any time.<br>
3 working days after setting status "in progress" a reminder is sent to the PT if no ETA is specified  and the ticket is added to the monitoring dashboard. After another 5 days without ETA a 2nd reminder will be sent to the PT. 10 working days later the status is checked again by the ticket monitoring team for any response of the PT. In case of no response the ticket monitoring team will take this as an [[#Implicit_reject | implicit reject]].
3 working days after setting status "in progress" a reminder is sent to the PT if no ETA is specified  and the ticket is added to the monitoring dashboard. After another 5 days without ETA a 2nd reminder will be sent to the PT. 10 working days later the status is checked again by the ticket monitoring team for any response of the PT. In case of no response the ticket monitoring team will take this as an [[#Implicit_reject | implicit reject]].
<br>
<br>
Line 116: Line 117:
<br>
<br>
== Differences to former EMI work flows ==
== Differences to former EMI work flows ==
The objective of this work flow is avoiding unattended tickets open for months or even years. There is always a human intervention by the ticket monitoring team before closing a ticket. The submitter has 10 working days for re-opening the ticket in case he does not agree with setting the ticket to "unsolved".
The differences to ticket processing in EMI era are as follows:
The differences to ticket processing in EMI era are as follows:
<br>
<br>
Line 126: Line 126:
|-
|-
| Response to tickets
| Response to tickets
| status change to "in progress" required. Not changing the ticket status is taken as [[#Implicit_reject | implicit reject]]
| Status change to "in progress" required. Not changing the ticket status is taken as [[#Implicit_reject | implicit reject]].
| status change to "in progress" required, but no further action if not doing it
| Status change to "in progress" required, but no further actions if not doing it.
|-
|-
| ETA
| ETA
| required for '''all''' tickets; not providing an ETA is taken as [[#Implicit_reject | implicit reject]]
| Required for '''all''' tickets; not providing an ETA is taken as [[#Implicit_reject | implicit reject]].
| required for "top priority" and "very urgent" tickets only
| Required for "top priority" and "very urgent" tickets only.
|-
| Response times
| Response times per PT depending on the [[FAQ_GGUS-PT-QoS-Levels | level of service]] and ticket priority
| Generic response times for all EMI support units depending on ticket priority
 
|-
|-
| Implicit reject
| Implicit reject
| Ticket monitoring team requests repsonse from PTs and closes tickets of unresponsive PTs.
| The system requests response from PTs by sending notfications and adding tickets to the monitoring dashboard. The monitoring team closes tickets of unresponsive PTs.
| Ticket monitoring team reminds support units on missing response. Ticket closing however is only done by the EMI support units.
| The ticket monitoring team reminded support units on missing response manually. Ticket closing however was done by the EMI support units.
 
|-
|-
| Notifications
| Notifications are sent automatically.
| Notifications sent after manual intervention of the monitoring team.
|}
|}
<br>
<br>
== Work flow graph ==
== Work flow graph ==
[[File:Graph_WaitingForPT_Workflow.pdf]]
[[File:Graph_WaitingForPT_Workflow.pdf]]
= Summary =
The objective of this work flow is avoiding unattended tickets open for months or even years. There is always a human intervention by the ticket monitoring team before closing a ticket. The submitter has 10 working days for re-opening the ticket in case he does not agree with setting the ticket to "unsolved". The actions to be taken by the PTs are:
* set status "in progress"
* give an ETA
* adjust the ETA if necessary
* provide the bug fix
* close the ticket


= What if I have questions which are not dealt with by this FAQ?  =
= What if I have questions which are not dealt with by this FAQ?  =

Revision as of 09:35, 14 June 2013

GGUS-logo.jpg


GGUS wiki / GGUS Documentation


FAQ GGUS-Waiting-For-Submitter-Process


Introduction

After discussions in the GGUS-AB and the OMB members agreed on implementing a work flow for closing tickets waiting for Product Team (PT) input under specific circumstances. This work flow should help informing the ticket submitter on he could expect a solution for his problem in a reasonable time and avoiding GGUS tickets pending for a very long time. This work flow consists of 4 steps to be processed:

  1. respond to a ticket by setting ticket status "in progress"
  2. decide on accepting or rejecting the ticket as bug and provide an ETA (estimated time of availability)
  3. implement the bug fix or patch
  4. close the GGUS ticket after the bug fix or patch is made available

All reminder dates are calculated as working days excluding Saturdays and Sundays. National and public holidays are not considered in the calculation.

Implicit reject

If any step of the ticket processing described in the work flow chapter is not followed this will be taken as an implicit reject of the ticket. This means the ticket monitoring team will set the ticket status "unsolved" and give a meaningful explanation to the submitter why the ticket was closed. The submitter has 10 working days for re-opening the ticket in case he does not agree with setting the ticket to "unsolved".

Work flow

Respond to a ticket

After a ticket gets assigned to a PT by DMSU the PT should set the ticket status "in progress". Setting status "in progress" indicates the PT has noticed the ticket ( response time). Adding a comment can not be recognized as response as users are not explicitly mapped to support units in GGUS. Hence responding to a ticket is strongly related to setting the ticket status to "in progress".
Once 75% of the maximum response time defined in the level of service are over the system sends a notification to the PT. This feature is kept from the EMI era and well known to the PTs.
In case the status is still "assigned" 5 working days after assigning the ticket to the PT the system will send a 1st reminder to the PT and add the ticket to the ticket monitoring dashboard. After 5 more working days the ticket status is checked again. If it is still "assigned" the system will send a 2nd reminder to the PT. 10 working days later the status is checked again by the ticket monitoring team for any response of the PT. In case of no response the ticket monitoring team will take this as an implicit reject.

Step Ticket Status Working Days Work Flow
1 assigned 5 first reminder to PT; adding ticket to monitoring dashboard
1a assigned 5 second reminder to PT
1b assigned 10 monitoring team checks for updates and sets status "unsolved" if none
1c unsolved 10 automatic status change to "closed"


Accept ticket as bug or reject it

Setting the ticket status "in progress" does not mean the ticket is accepted as a bug. The PT can decide rejecting it by setting status "unsolved". The PT accepts the ticket as bug by

  • providing an ETA
  • adding a reference to the PT bug tracker if any
  • setting ticket status "on hold"

The ETA should give a quite concrete estimation on when a fix will be available. However adjusting the ETA in case it does not fit the PT's release calendar is possible at any time.
3 working days after setting status "in progress" a reminder is sent to the PT if no ETA is specified and the ticket is added to the monitoring dashboard. After another 5 days without ETA a 2nd reminder will be sent to the PT. 10 working days later the status is checked again by the ticket monitoring team for any response of the PT. In case of no response the ticket monitoring team will take this as an implicit reject.

Step Ticket Status Working Days Work Flow
2 in progress 3 first reminder to PT; adding ticket to monitoring dashboard
2a in progress 5 second reminder to PT
2b in progress 10 monitoring team checks for ETA and sets status "unsolved" if none
2c unsolved 10 automatic status change to "closed"


Implement bug fix

The bug fix should be available at the end of the ETA at latest. The ETA should be updated if the fix is not available in time. For open tickets with expired ETA the system sends a reminder to the PT and adds the ticket to the monitoring dashboard. 5 working days after the ETA expired a 2nd reminder is sent to the PT. In case of no response the ticket monitoring team will take this as an implicit reject.

Step Ticket Status Working Days Work Flow
3 on hold ETA first reminder to PT; adding ticket to monitoring dashboard
3a on hold ETA + 5 second reminder to PT
3b on hold ETA + 10 monitoring team checks for updates and sets status "unsolved" if none
3c unsolved 10 automatic status change to "closed"


Close ticket

After providing the bug fix the PT should set the GGUS ticket to "solved".

Differences to former EMI work flows

The differences to ticket processing in EMI era are as follows:

Feature Current process Former EMI process
Response to tickets Status change to "in progress" required. Not changing the ticket status is taken as implicit reject. Status change to "in progress" required, but no further actions if not doing it.
ETA Required for all tickets; not providing an ETA is taken as implicit reject. Required for "top priority" and "very urgent" tickets only.
Implicit reject The system requests response from PTs by sending notfications and adding tickets to the monitoring dashboard. The monitoring team closes tickets of unresponsive PTs. The ticket monitoring team reminded support units on missing response manually. Ticket closing however was done by the EMI support units.
Notifications Notifications are sent automatically. Notifications sent after manual intervention of the monitoring team.


Work flow graph

File:Graph WaitingForPT Workflow.pdf

Summary

The objective of this work flow is avoiding unattended tickets open for months or even years. There is always a human intervention by the ticket monitoring team before closing a ticket. The submitter has 10 working days for re-opening the ticket in case he does not agree with setting the ticket to "unsolved". The actions to be taken by the PTs are:

  • set status "in progress"
  • give an ETA
  • adjust the ETA if necessary
  • provide the bug fix
  • close the ticket

What if I have questions which are not dealt with by this FAQ?

Please submit a GGUS ticket.