On Thu, May 13, 2010 at 04:21:31PM +0100, TAYLOR Robin wrote: > My understanding of these steps would be... > > Received - A new issue that has yet to be reviewed. > Open - Reviewed and not immediately closed. As things stand > the issue may or may not be assigned to someone. > In_Progress - Bit of an anomaly here. More useful to a manager > monitoring someones work.
As you note below, to developers In_Progress really means "assigned":
someone has taken it to work on. It's important for other developers
to know that.
> Resolved - The person to whom the issue was assigned considers
> the item to be resolved eg patch created and committed.
> Closed - The person who reported the issue is satisfied that
> the issue is resolved.
> Re_Opened - Shouldn't have been closed.
>
>
> I am not sure about this but I think it could be possible to change the
> status of an issue to be In_Progress when it is assigned. That would allow us
> to distinguish between those that are Open but not yet assigned, and those
> that have been assigned. On the other hand we could just ignore that step or
> get rid of it.
It isn't too hard to just look at the assigned-to column to see if an
issue is assigned. People who prefer to depend on icons, though, may
need more.
> There also appears to be a divide currently amongst those that choose to
> resolve issues and those that close them. What I have listed above is just my
> interpretation of the workflow but I do think that all issues should
> ultimately be closed. Having said that, I am not sure its practical to expect
> the reporter to close an issue (do they even have permission to do so ?), it
> might need to be the resolver (or reviewer ?).
Have we ever discussed what we mean by "resolved" vs. "closed"? My
usual practice is to move the issue to "resolved", wait a week to see
if anyone throws a flag, and then move to "closed". I feel this is an
important step: "I think this is done -- do others agree?"
It is always nice when the reporter adds a comment on his experience
of using the fix. "Tested, works well" would be enough for me to close.
> On a different subject - Affects Version and Fix Version. My understanding is
> that 'Affects' is the version(s) in which the bug was discovered, 'Fix' is
> the version(s) in which it will be fixed. I have a feeling I once read this
> in the Jira docs but I could be making that up.
To me, "affects version" is all the versions in which the issue is
thought to exist, whether confirmed or not. So if issue X has been
seen in 1.6.0, the code in that area hasn't been touched since 1.5.1,
but that area has already been rewritten or eliminated in 1.7.0, then
it (probably) affects versions 1.5.1 up to but not including 1.7.0.
Whether we work up a new point release for each affected branch is
another question.
I realize that this gets rather messy, and I don't think we need to
fret that we don't get the coverage exactly right, so long as it is
close and does include all confirmed sightings at the time the issue
is opened.
--
Mark H. Wood, Lead System Programmer mw...@iupui.edu
Balance your desire for bells and whistles with the reality that only a
little more than 2 percent of world population has broadband.
-- Ledford and Tyler, _Google Analytics 2.0_
pgpdORrWTQhzQ.pgp
Description: PGP signature
------------------------------------------------------------------------------
_______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
