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

From EGIWiki
Jump to: navigation, search
Line 1: Line 1:
 
{{GGUS-header|FAQ GGUS-Waiting-For-Submitter-Process}}
 
{{GGUS-header|FAQ GGUS-Waiting-For-Submitter-Process}}
 
= Introduction =
 
= Introduction =
After discussions in the [https://indico.egi.eu/indico/conferenceDisplay.py?confId=1265 GGUS-AB] and the [https://indico.egi.eu/indico/categoryDisplay.py?categId=1235 OMB] members agreed on implementing a work flow for closing tickets waiting for Product Team (PT) input after a reasonable time. This work flow show help informing the ticket submitter on he could expect a solution for his problem in a reasonable time and avoiding GGUS tickets being open for a very long time. It consists of 4 steps to be processed:
+
After discussions in the [https://indico.egi.eu/indico/conferenceDisplay.py?confId=1265 GGUS-AB] and the [https://indico.egi.eu/indico/categoryDisplay.py?categId=1235 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:
 
# set ticket status "in progress"
 
# set ticket status "in progress"
 
# decide on accepting or rejecting the ticket as bug and provide an ETA (estimated time of availability)
 
# decide on accepting or rejecting the ticket as bug and provide an ETA (estimated time of availability)
Line 11: Line 11:
 
= Work flow =
 
= Work flow =
 
== Set ticket status "in progress" ==
 
== Set ticket status "in progress" ==
After a ticket gets assigned to a PT by DMSU the PT should set the ticket status "in progress". In case the status is still "assigned" after 5 working days the system will send a 1st reminder to the PT and add the ticket to the 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''' and set the ticket status "unsolved" giving a meaningful explanation why the ticket was closed.
+
After a ticket gets assigned to a PT by DMSU the PT should set the ticket status "in progress". 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''' and set the ticket status "unsolved" giving a meaningful explanation why the ticket was closed.
 
<br>
 
<br>
 
{| cellspacing="0" cellpadding="2" border="1"
 
{| cellspacing="0" cellpadding="2" border="1"

Revision as of 09:47, 22 April 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. set 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.

Work flow

Set ticket status "in progress"

After a ticket gets assigned to a PT by DMSU the PT should set the ticket status "in progress". 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 and set the ticket status "unsolved" giving a meaningful explanation why the ticket was closed.

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"

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 and set the ticket status "unsolved" giving a meaningful explanation why the ticket was closed.

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 and set the ticket status "unsolved" giving a meaningful explanation why the ticket was closed 5 working days later.

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

Summary

In this work flow there is always a human intervention before closing a ticket. Additionally he has 10 more working days for re-opening the ticket in case he does not agree with setting the ticket to "unsolved".

Work flow graph

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

Please submit a GGUS ticket.