DQ and RFC process

From UG

(Difference between revisions)
Jump to: navigation, search
(Definitions Process Etc)
(Definitions Process Etc)
Line 7: Line 7:
* how to manage
* how to manage
-
=== Urgent Bugs: definition, process, etc.
+
=== Urgent Bugs: definition, process, etc ===
*U-bugs are managed by Sup Man, must be posted into mantis, estimated and fixed ASAP. Decide if they require Emerg Release.
*U-bugs are managed by Sup Man, must be posted into mantis, estimated and fixed ASAP. Decide if they require Emerg Release.
*Non Urgent Bugs are managed through RFC
*Non Urgent Bugs are managed through RFC
-
RFC: definition, process, etc.
+
=== RFC: definition, process, etc ===
*RFC (Requests For Changes) is a list of changes to CT2 requested by users, managers, dev team, etc and Non Urgent Bugs.
*RFC (Requests For Changes) is a list of changes to CT2 requested by users, managers, dev team, etc and Non Urgent Bugs.
Line 19: Line 19:
*RFC Review Meeting is a regular bi-weekly meeting during which all requests are reviewed by participants (Sup Man, Dev Man(KU), Sol Arc(Alex), PM(Perry)) and given tentative solution (posted in mantis note) and rough estimate (posted into emh/emhR fields with "r" prefix). SA time must be estimated es well. Also at this point some requests might be combined, rejected, comments to Prod Man posted, etc. Also Dv field must be assigned (whenever possible to "any" or if not then to specific developer).  
*RFC Review Meeting is a regular bi-weekly meeting during which all requests are reviewed by participants (Sup Man, Dev Man(KU), Sol Arc(Alex), PM(Perry)) and given tentative solution (posted in mantis note) and rough estimate (posted into emh/emhR fields with "r" prefix). SA time must be estimated es well. Also at this point some requests might be combined, rejected, comments to Prod Man posted, etc. Also Dv field must be assigned (whenever possible to "any" or if not then to specific developer).  
-
DQ: definition, process, etc.
+
=== DQ: definition, process, etc ===
*DQ (Development Queue) is a list of bugs and minor changes to the CT2 system approved for development by Product Manager (Marc)
*DQ (Development Queue) is a list of bugs and minor changes to the CT2 system approved for development by Product Manager (Marc)

Revision as of 20:36, 31 May 2012


Contents

Definitions Process Etc

Key processes:

  • how to SA/document
  • how to manage

Urgent Bugs: definition, process, etc

  • U-bugs are managed by Sup Man, must be posted into mantis, estimated and fixed ASAP. Decide if they require Emerg Release.
  • Non Urgent Bugs are managed through RFC

RFC: definition, process, etc

  • RFC (Requests For Changes) is a list of changes to CT2 requested by users, managers, dev team, etc and Non Urgent Bugs.
  • RFC is managed by Support Manager (Denise)
  • As request that make sence comes in Denise creates a mantis with ph="RFC"
  • RFC Review Meeting is a regular bi-weekly meeting during which all requests are reviewed by participants (Sup Man, Dev Man(KU), Sol Arc(Alex), PM(Perry)) and given tentative solution (posted in mantis note) and rough estimate (posted into emh/emhR fields with "r" prefix). SA time must be estimated es well. Also at this point some requests might be combined, rejected, comments to Prod Man posted, etc. Also Dv field must be assigned (whenever possible to "any" or if not then to specific developer).

DQ: definition, process, etc

  • DQ (Development Queue) is a list of bugs and minor changes to the CT2 system approved for development by Product Manager (Marc)
  • DQ is managed by Support Manager (Denise)
  • This list has a limited number of items (max=40)
  • DQ is re-filled from RFC list through regular bi-weekly RFC2DQ Meetings (Sup Manager + Prod Manager). On this meeting approved record gets ph="DQ" and T defined.
  • Weekly DQ Development meet
Personal tools