BugzillaWorkflowImprovements:FlowChart B
Jump to navigation
Jump to search
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.