Trac ticket workflow: Difference between revisions
Jump to navigation
Jump to search
(New page: [http://lists.laptop.org/pipermail/devel/2008-July/016278.html First draft] A approximate common path: code -> package -> add to build -> test in build -> qa signoff -> f...) |
No edit summary |
||
| Line 13: | Line 13: | ||
joyride-2126:- or joyride-2126:+ |
joyride-2126:- or joyride-2126:+ |
||
The purpose of the finalize state is for the release team to provide any user-facing documentation or to conclude that no documentation is necessary. |
The purpose of the finalize state is for the release team to provide any user-facing documentation or to conclude that no documentation is necessary. |
||
| Line 21: | Line 21: | ||
Finally, the other 'next action' states can be used to describe ignorance about what sort of action is needed. The regular trac triage process will be responsible for pushing these tickets along. |
Finally, the other 'next action' states can be used to describe ignorance about what sort of action is needed. The regular trac triage process will be responsible for pushing these tickets along. |
||
[[Category:Trac]] |
|||
Revision as of 21:47, 16 July 2008
A approximate common path:
code -> package -> add to build -> test in build -> qa signoff -> finalize
After testing, the developer tags the bug with the results, e.g.:
joyride-2126:- or joyride-2126:+
The purpose of the finalize state is for the release team to provide any user-facing documentation or to conclude that no documentation is necessary.
The workflow can be exited early by resolving a ticket as 'worksforme', 'invalid', etc.
At various times, someone (e.g. the developer or the release team) may need an answer to a question. In this event, the ticket's next action should be set to 'communicate'.
Finally, the other 'next action' states can be used to describe ignorance about what sort of action is needed. The regular trac triage process will be responsible for pushing these tickets along.