Redmine Issue Lifecycle
Revision as of 22:31, 5 March 2012 by BradWhitlock (talk | contribs) (→Nominal State Transition Table)
The 'Status' field is used to communicate the state of an issue by tracking where in the Issue lifecycle it currently stands. Note: Our process deviates from the redmine default lifecycle and is loosely related to the LLNL VisIt team's previous ticket lifecycle. This process/lifecycle is not set in stone - suggestions are welcome.
|New||The first state for issues submitted to the system.|
|Developer Review||State used to solicit developer feedback. During this state developers will discuss an issue, if necessary obtain more information from the submitter, & adjust issue prioritization. After this process issues are scheduled as Pending or are Rejected if they will not be addressed.|
|Pending||State for issues that have been reviewed and are awaiting resolution.|
|Resolved||State for issue that were addressed & resolved. When resolving an issue VisIt developers should note which commit(s) addressed the issue.|
|Expired||Pending issues may be closed as 'Expired' if they are not picked up by the development team after a long period of time.
The 'long period of time' has not been selected.
|Rejected||After a developer review it was determined that the issue should not be addressed.|
More on the difference between 'Rejected' and 'Expired':
- 'Rejected' is used for issues that after review was determined they cannot or should not be resolved.
- 'Expired' is used for issues that should be possible to resolve & the team would like to address, however due to prioritization have languished.
It is useful to differentiate between the two so the fate of these issues is known if similar/related issues are submitted in the future.
Nominal State Transition Table
|Developer Review||Pending, Rejected|