= Bug Review Process =

This article describes developer activities and how they are tracked through Redmine. 

The Redmine state is represented as STATE, which can take on the following values: {NEW, TRIAGED, ACCEPTED, IN PROGRESS, IN REVIEW, REVIEWED, CLOSED, FEEDBACK, RESOLVED, REJECTED}. 

A typical state sequencing would be NEW -> TRIAGED -> ACCEPTED -> IN PROGRESS -> IN REVIEW -> REVIEWED -> CLOSED as described below:

 1. Bug is reported (by core dev or external user)
        * STATE <= NEW
 1. Bug is triaged (during weekly meeting, if not earlier)
        * assigned lead developer
        * STATE <= TRIAGED
        * (NOT assigned a target release ... that happens only when STATE <= ACCEPTED)
 1. Bug gets preliminary review by some group member
        * if it is judged eligible for fixing:
          * reviewer sets target release (as next release, not a future release)
          * reviewer verifies or changes lead developer
          * reviewer assigns provisional risk profile and testing requirements
          * STATE <= ACCEPTED
 1. When STATE == ACCEPTED, assigned developer fully assess work and manages estimates for:
        * timing and difficulty
        * target release
        * risk profile and testing requirements
        * STATE <= IN PROGRESS
 1. Assigned developer implements fix        
        * code is checked in to development branch
 1. Assigned developer reassigns issue to a reviewer
        * STATE <= IN REVIEW
        * set "assignee" field to reviewer (Note: the "reviewer" field doesn't notify the reviewer via e-mail, so we don't use it)
 1. Reviewer checks code and reassigns to original developer
        * check code out from development branch
        * for features, use Quality Circles document to verify code meets requirements and fulfills quality aspects ... document findings in Quality Circles table
        * if good: STATE <= REVIEWED ... if the change is for the current release, developer cherry picks it into the current hotfix branch
        * if more work needed: STATE <= ACCEPTED and return to developer ... developer and reviewer can agree to withdraw checkin from development branch
        * set "assignee" field to original developer
 1. Assigned developer sets STATE <= CLOSED
 1. As part of release planning:
        * coordinate testing

*** Note that a target version should be assigned iff STATE == ACCEPTED or beyond. Otherwise STATE should be TRIAGED. ***

== Cherry picking ==

{{{
git checkout FIX-BRANCH
git cherry-pick -x DEV-COMMIT-HASH-CODE
}}}

== Other Redmine States ==

FEEDBACK = waiting for user reply ... could follow TRIAGED or ACCEPTED, and could precede ACCEPTED, CLOSED, or REJECTED

RESOLVED = unknown function

REJECTED = closed and not fixed