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

From EGIWiki
Jump to: navigation, search
(Created page with "{{GGUS-header|FAQ GGUS-Waiting-For-Submitter-Process}} = Introduction = After discussions in the [https://indico.egi.eu/indico/conferenceDisplay.py?confId=1265 GGUS-AB] and the [...")
 
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 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 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:
 +
* set ticket status "in progress"
 +
* decide on accepting or rejecting the ticket as bug
 +
* provide an ETA (estimated time of availability)
 +
* implement the bug fix or patch
 +
* close the GGUS ticket after the bug fix or patch is made available
  
= Accept as bug =
+
All reminder dates are calculated as working days excluding Saturdays and Sundays. National and public holidays are not considered in the calculation.
The status value "waiting for reply" should only be used in case of input from the ticket submitter is required. Setting the ticket status to "waiting for reply" in GGUS triggers an email notification to the submitter's mail address registered in the ticket.<br>
 
After the submitter has replied either by
 
* sending an email using the same sender mail address as registered in the ticket or by
 
* updating the ticket in web portal using the same credentials/certificate used for submitting the ticket
 
the ticket status changes to "in progress" automatically.
 
Updates on the ticket done using different credentials/certificates or mail addresses than registered in the ticket will not be recognized as reply by the system and hence have no impact on the work flow.
 
<br>The status value "waiting for reply" must not be used in case of waiting for input of any other person involved in the solving process.
 
  
= Provide estimated time of availability (ETA) =
+
= Work flow =
= Implement bug fix =
+
== Set ticket status "in progress" ==
= Close ticket =
+
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.
  
== First action ==
+
== Accept ticket as bug or reject it ==
5 working days after setting the ticket status to "waiting for reply" the '''first reminder''' is sent to the ticket submitter requesting input. The ticket will also be added to the [https://ggus.eu/pages/monitor.php ticket monitoring dashboard]. The ticket monitoring team will make sure that the status value "waiting for reply" is used in a correct sense.
+
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"
  
== Second action ==
+
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.
In case the submitter does not reply the '''second reminder''' is sent to the ticket submitter requesting input after 5 more working days.  
+
 
 +
== Implement bug fix ==
 +
 
 +
== Close ticket ==
  
== Third action ==
 
In case the submitter does not reply after another 5 more working days the ticket monitoring team gets notified.
 
The monitoring team will check the ticket for any updates by the submitter not recognized by the system and set the ticket status to "unsolved" if none. The ticket will follow the usual process for "solved"/"unsolved" tickets and be closed after 10 working days without re-opening the ticket again.
 
 
<br>
 
<br>
 
{| cellspacing="0" cellpadding="2" border="1"
 
{| cellspacing="0" cellpadding="2" border="1"

Revision as of 15:25, 19 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 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:

  • set ticket status "in progress"
  • decide on accepting or rejecting the ticket as bug
  • provide an ETA (estimated time of availability)
  • implement the bug fix or patch
  • 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" 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.

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.

Implement bug fix

Close ticket


Action Ticket Status Working Days Work Flow
1 waiting for reply 5 first reminder to submitter; adding ticket to monitoring dashboard
2 waiting for reply 5 second reminder to submitter
3 waiting for reply 5 notification to monitoring team; the monitoring team sets status "unsolved"
4 unsolved 10 automatic status change to "closed"

Summary

In this work flow there is always a human intervention before closing a ticket. The submitter has 15 working days in total for replying to 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.