Redmine Issue Lifecycle
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.
Issue States
| State | Description |
| 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
| From | To |
| New | Developer Review |
| Developer Review | Pending, Rejected |
| Pending | Resolved, Expired |
| Resolved | (terminal) |
| Expired | Developer Review |
| Rejected | (terminal) |
