RE: Jira maintenance - issue status

["Tim Colson (tcolson)" <tc...@cisco.com>]

Hey gang -

Say, first off, let's start calling them "issues" which includes
features, improvements, tasks, AND bugs. :-)

(This mindset will enable tracking requests like whitespace gobbling,
and enable voting.)

My experience, there is a separate QA or Project Mgr (PM) role that
CLOSES issues. Developers are verboten from closing an issue. 

1) Reporter -> creates bug/task/feature/improvement
2) QA role gets bugs, PM gets others
3) QA verifies bug (dupe check too), sets "verified" and assigns to PM
4) PM sets priority, juggles resources, "assigns" issue to somebody
5) Developer fixes bug, codes feature/improvement, or performs task ->
marks "fixed" 
6) QA team verifies -> markes it "resolved"
7) PM juggles releases and when the issue is in production code, marks
the item "closed"

Roughly that's how it goes... but variations abound. Jira default
settings do not account for the QA steps -- but all status/resolutions
are mutable. 

In our world - no formal QA or PM (a discussion for another time). ;-)
And I do not believe we can rely on reporters to always do QA. 

(aside: I don't do any coding around here, but I might be able to help
more on the QA/PM tasks to free you gents up to work on code. )

> i could be ok with closing resolved bugs for 1.3 once 1.5 work starts.
I think that all issues that are in production code - should be
"closed", otherwise, it means to me that the release went out with
unverified fixes. 

By definition, if we say issues are "closed", I'd like to take for
granted they have been addressed in some way (FIXED, WON'T FIX, CANNOT
REPRODUCE, etc) and are "done" for this release.

>  the point is that if reporters don't close their bugs after they've
> been resolved, the thing that makes the bugs "age out" of the queue
> should be new versions/releases.

I actually agree -- but argue that they should be aged out before a
release, so any issues against released versions are in a "closed"
state. I feel a release should NOT have any non-closed issues assigned
to it. 


> > Step 1: Committer marks RESOLVED.
> > Step 2: Reporter verifies bug fix and marks CLOSED.  
+1 .. also note that a PM/QA person could step in and verify for the
reporter, who might have disappeared. And before a "release" -- all
issues scheduled for that release should be reviewed and marked
"CLOSED". 


> > Step 1: Contributor uploads patch and marks RESOLVED/FIXED
> > Step 2: Committer reviews patch and suggests changes 
> (marking REOPEN) or commits (marking it CLOSED)
> -1  this seems unintuitive and uncommon.

-1 Yeah, reporter/contributer probably will only be able to 'comment' on
the issue, and the issue isn't Resolved as "fixed" until the code is
applied. Also, the commiter probably shouldn't close the issue, because
the patch might not be verified by PM/QA to actually perform correctly. 

(Also keep in mind, if it helps, additional status settings can easily
be created. (ex. "QA-Tested", "Ready for Release", etc) I'm not saying
we should do this, just noting the feature is available in Jira.)


Cheers,
Tim

---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org