[Koha-devel] Patch status workflow (for Bugzilla)

[Ian Walls]

Community,


As I'd mentioned in a previous thread, I think we should consider removing
the custom attribute "patch status" from Bugzilla, and keeping track of this
information in the regular Status attribute.  This has several advantages:

   - Easier searching, since it's a default value, not a custom value
   - We can enable Workflows between Statuses
   - We no longer have the dependency on Priority to control the display of
   this critical value

The Workflows allow us to specify how tickets are allowed to change status,
from which to which.  Here's an example workflow:

   - NEW (default for all incoming tickets)
   - ASSIGNED (to the developer working on it)
   - NEEDS_SIGNOFF (once a patch has been submitted)
   - SIGNED_OFF (after signoff)
   - PASSED_QA (once QA'ed successfully)
   - PATCH_PUSHED
   - RESOLVED

For a patch that fails testing, it would look more like this:

   - NEW
   - ASSIGNED
   - NEEDS_SIGNOFF
   - FAILED QA (some obvious problem found by tester)
   - NEEDS_SIGNOFF (again, now that the problem is fixed
   - SIGNED OFF
   - FAILED QA (less obvious problem)
   - NEEDS_SIGNOFF
   - SIGNED OFF
   - PASSED QA
   - PATCH_PUSHED
   - RESOLVED

Workflows could prevent jumping a status straight from ASSIGNED to PASSED
QA, for example; that status could only be reached from SIGNED OFF.  All the
changes to these statuses are recorded in the bug reports history, so we
have a record of the life cycle.

I think this is what Status was initially designed to do, so we just need to
leverage it.


-Ian



-- 
Ian Walls
Lead Development Specialist
ByWater Solutions
Phone # (888) 900-8944
http://bywatersolutions.com
ian.walls at bywatersolutions.com
Twitter: @sekjal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20111025/65f38ca5/attachment.htm>