[asterisk-dev] [policy] Bug Tracker Workflow Discussion

[Joshua Colp]

----- "Leif Madsen" <leif.madsen at asteriskdocs.org> wrote:

> ~~~~~~~~~~~~~~~~~~~~
> 
> BUG TRACKER WORKFLOW
> 
> The workflow in the bug tracker should be handled in the following
> way:
> 
> 1) A bug is reported and is automatically placed in the 'new' status.

Don't forget this is not always true presently. Some individuals are setup to automatically be assigned when issues are filed against certain categories. An example would be Tilghman who gets automatic assignment of func_odbc issues. If this remains then the issue may not show up on the radar of those who are looking for new issues to check categorization on/initial triage. We'll either have to stop automatic assignment or remember to do it.
 
> 2) The Bug Marshall team should go through bugs in the 'new' status to
> 
> determine whether the report is valid (not a duplicate, hasn't already
> 
> been fixed, not a Digium tech support issue, etc.).  Invalid reports 
> should be set to 'closed' with the appropriate resolution.  Categories
> 
> and descriptions should be corrected at this point.[Note1]

Sounds good. Always great to have the right category and a good description.
 
> 3) The next step is to determine whether the report is about a bug or
> a 
> submission of a new feature:
> 
>       a) BUG: A bug should be moved into the status 'acknowledged'.
> The 
> bug may also be assigned to a developer for the creation of the
> initial 
> patch, or review of the issue. Once a patch has been created for the 
> issue and attached, the issue can then be moved to the 'confirmed' 
> status. At this point initial code review and discussion about the
> patch 
> will take place. Once an adequate amount of support for the 
> implementation of the patch is acquired, then the bug can be moved to
> 
> the 'ready for testing' status for wider testing by the community.
> After 
> the testing phase is complete and it appears the issue is resolved,
> the 
> patch can be committed by a developer and closed.

What happens if no testing feedback is received back?
 
>       b) FEATURE: As new features should be filed with a patch, it can
> 
> be immediately moved to the 'confirmed' status, making it ready for 
> basic formatting and code review. From there any changes to style or 
> feel of the patch based on feedback from the community can be
> discussed, 
> and changes to the patch made. It can then be moved forward to the 
> 'ready for testing' status. Once the feature has been merged, or a 
> decision has been made that it will not be merged, the issue should be
> 
> taken to 'closed' with the appropriate resolution.[Note2]

Sounds good.
 
> 4) If at any point in the workflow, an issue requires feedback from
> the 
> original poster of the issue, the status should be changed to 
> 'feedback'.  Once the required information has been provided, it
> should 
> be placed back in the appropriate point of the workflow.

Since this is not automatic someone will have to be watching the issue to see that feedback was received so it can be placed back in the appropriate point of the workflow. It is also possible for it to get missed, in which case we can use the feedback only filter to track them down.
 
> 5) If at any point in the workflow, a developer or bug marshal would 
> like to take responsibility for doing the work that is necessary to 
> progress an issue, the status can be changed to 'assigned'.  Once
> these 
> changes have been completed, it can be placed back in the appropriate
> 
> place in the workflow.

Sounds good, and nice to have a policy for this. Thanks for taking care of this Leif!
 
-- 
Joshua Colp
Software Developer
Digium, Inc.