Trac ticket workflow: Difference between revisions

From OLPC
Jump to navigation Jump to search
mNo edit summary
No edit summary
Line 1: Line 1:
[http://lists.laptop.org/pipermail/devel/2008-July/016278.html First draft]
[http://lists.laptop.org/pipermail/devel/2008-July/016278.html First draft]


An approximate common path. Set the action needed field in trac to:
Here is an approximate common path, subject to circumstances.
Set the 'Action Needed' field in Trac sequentially to:
code ->
diagnose,
package ->
design,
add to build ->
code,
test in build ->
package,
qa signoff ->
add to build,
finalize
test in build,
qa signoff,
finalize.


After testing, the developer tags the bug with the results, e.g.:
After testing in a build, the developer tags the bug with the results, e.g.:
joyride-2126:- or joyride-2126:+
joyride-2126:- or joyride-2126:+

( '-' means bad result, try again, whereas '+' means good result )


:I presume this is after the "test in build" state, which I presume means the developer who coded the fix tested it in a build. That could be clearer. Then, what does the developer do? Just set it to "qa signoff"? Assign it to some QA person? At what point does it get tagged into the 8.2 release stream, and should it be assigned to someone to ensure that? --[[User:Morgs|morgs]] 09:59, 17 July 2008 (UTC)
:I presume this is after the "test in build" state, which I presume means the developer who coded the fix tested it in a build. That could be clearer. Then, what does the developer do? Just set it to "qa signoff"? Assign it to some QA person? At what point does it get tagged into the 8.2 release stream, and should it be assigned to someone to ensure that? --[[User:Morgs|morgs]] 09:59, 17 July 2008 (UTC)
Line 21: Line 26:
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'.
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.
Finally, the other 'Action Needed' 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]]
[[Category:Trac]]

Revision as of 04:09, 17 August 2008

First draft

Here is an approximate common path, subject to circumstances. Set the 'Action Needed' field in Trac sequentially to:

 diagnose,
 design,
 code,
 package, 
 add to build, 
 test in build, 
 qa signoff,
 finalize.

After testing in a build, the developer tags the bug with the results, e.g.:

 joyride-2126:-    or   joyride-2126:+

( '-' means bad result, try again, whereas '+' means good result )

I presume this is after the "test in build" state, which I presume means the developer who coded the fix tested it in a build. That could be clearer. Then, what does the developer do? Just set it to "qa signoff"? Assign it to some QA person? At what point does it get tagged into the 8.2 release stream, and should it be assigned to someone to ensure that? --morgs 09:59, 17 July 2008 (UTC)

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 'Action Needed' 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.