BugzillaWorkflowImprovements:FlowChart B

Draft wiki flowchart below illustrates how suggested ideas fit together, including:

• NEEDS-INFO status,
• UNCONFIRMED and NEEDS-INFO bug expiration, and
• splitting triaging into confirming NEW and preparing to be READY.

New roles:

• Bugzilla daemon:
  • after 90 days UNCONFIRMED, automatically resolves to EXPIRED.
  • after 90 days NEEDS INFO, automatically resolves to DEFICIENT (a.k.a. INSUFFICIENT_DATA, INCOMPLETE).
  • not shown: after 30 days, send a warning to bug participants.
• Confirmers:
  • confirmers can set status to NEEDS INFO
  • confirmers can resolve DUPLICATE
  • confirmers can resolve INVALID (garbage or Netscape bug)
  • confirmers can resolve WORKSFORME (if on same OS).
  • confirmers can add dependency on another bug (partial dup)
  • confirmers can change category
  • confirmers can set status to NEW (EVERCONFIRMED yes)
• Preparers:
  • preparers can also add keywords
  • preparers can also set status to READY (EVERREADY yes)

Some issues listed below chart.

---

   reporter:        
  (enter bug)       
      |             
      |      reporter:   
      |  <-- (add info)  
      | |        ^     
      | |        |         buzilla:
      | | [NEEDS INFO] -> {bug age?} -> 90+ -> [RESOLVED: DEFICIENT]
      | |        ^                      days
......|.|........|....................................................
      v v        |         bugzilla:
[UNCONFIRMED] --|||-----> {bug age?} -> 90+ -> [RESOLVED: EXPIRED] 
      |          |                      days   (inform: can refile
      |      confirmer:                         on recent build)
      |      (ask for details, steps,  
      v       clarification, etc.)
  confirmer:     ^
 {clear and      |
 sufficient?} -- No
      |              
     Yes             
      v
  confirmer:     
{appropriate?} -- No ------------------------> [RESOLVED: INVALID]
      |        (may be garbage/trial, Netscape bug, etc.)
     Yes
      V
  confirmer:
 {duplicate?} -- Yes ------------------------> [RESOLVED: DUPLICATE]
      |        (mark duplicate or dependent of prior/clearer bug)
     No
      v
   confirmer:
{reproducible?} -- No -----------------------> [RESOLVED: WORKSFORME]
      |         (only if on same OS as reporter?)
     Yes
      V
   confirmer:
(recategorize if needed)
......|...............................................................
      v
[NEW (EVERCONFIRMED yes)] 
      |
      v
   preparer:                 
{minimal test case?} -- No ---> 
      |                        |
     Yes                   preparer:
      v              (minimize test case)
  preparer:                    |
(maybe add keyword <-----------
  'testcase') 
......|...............................................................
      v
   [READY] <---------------
      |                    ^
      v                    |
lead developer/manager:    |
 (assign bug)              |
......|....................|..........................................
      v                    |
[READY (has Assigned-to)]  |
      |                    |
      v                    |
  developer:               |
{accept bug?} -- No ------> 
      |
     yes
......|...............................................................
      v
  [ASSIGNED (EVERASSIGNED yes)] 
      |                        ^
      v                        |
   developer:                  |
(develop and attach patch, <--|||-- [REOPENED (EVERASSIGNED yes)]
 request review(s))            |         ^
......|........................|.........|............................
      v                        |         |
  [ASSIGNED, Review requested] |         |
      |                        |         |
      v                        |         |
  reviewer:                    |         |
{accept patch?} -- no -------->          |
      |                                  |
     Yes                                 |
......|..................................|............................
      v                                  | 
  [REVIEW+]                              |
      |                                  |
      v                                  |
reviewer or developer:                   |
(check patch into CVS)                   |
......|..................................|............................
      v                                  |
[RESOLVED: FIXED]                        |
      |                                  |
      v                                  |
     QA:                                 |
  {verify?} -- No -----------------------
      |
     Yes
......|...............................................................
      v
  [VERIFIED]

---

Notes:

• Labels {decisions} by role/permissions of decision maker, one of:
  • reporter
  • confirmer
  • preparer
  • developer
  • reviewer
  • QA
  • bugzilla (automatic timeouts).
• Horizontal dotted lines indicate change of state, storing status during likely delay. Delay is usually because responsibility for next step belongs to a different person. In addition, accepting an assigned bug may also be followed by delay because developer accepting it may not work on it immediately.

Issues:

• Suggests REOPENED behaves as ASSIGNED if EVERASSIGNED flag is set.
• Delays suggest developers should be able to confirm and prepare their own bugs, but perhaps the bugs should default to unconfirmed and the developer should need to explicitly check confirmed and/or ready on their initial form.
• Developers should be able to set READY bug back to NEW if turns out it is not actually READY (not shown).
• Components may not have an owner, but many reviewers.
• Emphasis is on common transitions. Other transitions are omitted for clarity. For example, the following possible transitions are not shown:
  • Permission required for reviewer > developer > preparer > confirmer > reporter, so the participants with greater permissions can modify any of the prior settings set or neglected by the participants with equal or less permission, and can revisit any of the earlier decisions.
  • Participants may REOPEN from any RESOLVED state that they can set.
  • Reviewer may resolve bug to WONTFIX before bug receives patch from a developer.
  • Bug may be fixed by another patch while it is waiting in NEW or READY state, so preparer or developer may resolve it WORKSFORME.
  • "Short-cut" paths, such as when a developer files a preconfirmed bug or a pre-ready bug, or when a developer assigns preaccepted bug to self, are also omitted.

• This diagram looks like a cascading waterfall with just a few iterative cycles. It may be representative for bugs, for which it is usually easy to specify the expected behavior. It is less representative for enhancement requests (new features), which often require larger iterative feedback cycles between designers, developers, and users as they try to build prototype designs and refine them.