Tim,
On 25.08.2009, at 00:30, Bert Freudenberg wrote:
On 24.08.2009, at 23:56, Timothy Falconer wrote:
Hmm, putting the change to the update stream is so far limited to certain users. (And "works for me" just by somebody often is not the right reason to "Close" an item.)
I think my initial process page said that software team members verify and push to the stream (#13):
you meant #14?
http://confluence.immuexa.com/display/sq/Process
Priorities and code review are the primary function of the software team.
We should clarify how to "submit code" in step #12.
Also, when resolving in step 12, I guess the resolution should be "ongoing"? The options are Complete, Reject, Duplicate, Unclear, Cannot Reproduce, Ongoing, Test Passed, Test Failed. So "ongoing" would mean "ready for testing"?
And in step 14, how do we mark a closed issue that is not yet put to the update stream"? Or should rather the tester change the resolution to "test passed", and the developer who pushes an update to the stream closes the issue?
As for the other resolutions, who is going to close these issues, and when?
- Bert -
Maybe I need to rephrase?
We need a JIRA view showing all issues that got a fix attached and are ready for testing.
And we need a JIRA view showing all issues that were tested and got approved but are not yet pushed to the update stream.
Setting the resolution to "ongoing" as I mused above seems to go against the system. I'm not sure how the "test failed" and "test passed" resolutions fit in.
And something else:
The Roadmap view is quite nice, but it mixes the "resolved" and "closed" issues. Can we change it to put closed ones last? Also, can I restrict it to show just etoys tickets?
- Bert -