BugzillaWorkflowImprovements:FlowChart B
Draft wiki flowchart below illustrates how the suggested ideas fit together, including unconfirmed bug expiration, and splitting triaging into confirming NEW and preparing to be READY.
- Bugzilla:
- warns reporter after 30 days unconfirmed.
- automatically resolves EXPIRED after 90 days unconfirmed.
- Confirmers:
- 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)
|
v
reporter:
{has canconfirm
and confirms?}
| |
Yes No
| | bugzilla:
| -> [UNCONFIRMED] -> {age of bug in days?} - 90+ -> [RESOLVED: EXPIRED]
| | ^ | (tell reporter
| | | ~30 can refile if
| | | | bug still in
| | | <---------------- recent builds)
| | | (warn reporter once: will expire)
| | |
| | <-------
| v ^ (ask for details, steps,
| confirmer: | clarification, etc.)
| {clear?} ---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 or reporter:
| {reproducible?} --No--------------------------> [RESOLVED: WORKSFORME]
| | (only if on same OS as reporter?) |
| Yes |
| V reporter:
| confirmer: (reopen if clarified)
| (recategorize if needed) |
| | v
v v [REOPENED (EVERCONFIRMED No)]
reporter or confirmer:
{has canprepare and
testcase minimized?} -No-> [NEW (EVERCONFIRMED yes)]
| |
Yes preparer:
| {clean report?} ---- No ---->
| | |
| Yes preparer:
| | (maybe clarify, recategorize, retitle,
| v divide into dependent bugs, etc.)
| preparer: |
| (maybe add clean-report keyword) <---
| |
| v
| preparer:
| {minimal test case?} -- No --->
| | |
| Yes preparer:
| v (minimize test case)
| preparer: |
| (maybe add testcase keyword) <------
| |
v v
----------------> [READY (EVERREADY yes)]
|
v
developer:
(diagnose component, maybe recategorize, maybe [ACCEPT])
^ ^ |
| | v
| | developer:
| | (attach patch, request review)
| | |
| | v
| | reviewer:
| <-Retry- {approve patch?} -- Never --> [RESOLVED: WONTFIX]
| | |
| Yes reviewer: |
| | -- (reopen) <--
| v |
| reviewer or developer:
| (check patch into cvs) ---------> [RESOLVED: FIXED]
| |
| | v
| v QA:
[REOPENED (EVERREADY yes)] <----------- <--No-- {verify fixed?}
|
Yes
v
[VERIFIED]
Notes:
- Labels {decisions} by role/permissions of decision maker, one of:
- reporter
- confirmer
- preparer
- developer
- reviewer
- QA
- bugzilla (automatic timeouts).
Issues:
- Suggests REOPENED behaves as READY if EVERREADY flag is set.
- Suggests 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.
- Participants may REOPEN from any RESOLVED state that they can set.
- Reviewer may resolve bug to WONTFIX before bug receives attention 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.