On 13 May 2010 16:21, TAYLOR Robin <robin.tay...@ed.ac.uk> wrote: > Indeed with the Enterprise Edition you can customise it by issue type if > you really wanted to. We could add in another step of "Received" at the > beginning of the workflow giving us... > > Received -> Open -> In_Progress -> Resolved -> Closed -> Re_Opened > > Seems reasonable.
> 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. > 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. > That is the long and short of it, yes. > 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. > I don't see the point in this. If you want to distinguish an unassigned item, you can just leave it (or set it) to be unassigned. As you say before, In Progress does mean something - that somebody has stated that they are actively working on it. That does not have to equate to monitoring someone - in our context, it's a useful means to communicate to each other that we are actively working on a specific issue, rather than being an issue that has been assigned that we just haven't got around to doing anything about yet (which someone could easily offer to take up). Unfortunately, we're still on Jira 3, when we do upgrade we will have some nice drag and drop tools for dealing with issues (/cards), and at that point, effective use of the In Progress status will show it's worth. > 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 ?). > I'm actually not a fan of the Closed status. Having worked with Jira in a number of cases where I've needed to re-organise issues after they've been worked on - either to add some additional categorisation, re-organisation of projects, clearing of remaining estimates for reporting purposes - having items in Closed just causes problems in having to re-open them in order to move them around. Of course, there are swings and roundabouts - having Closed items prevents people from accidentally affecting the contents - but my experience has been that Closed isn't that useful. Our needs may well be different though. If we want to make a distinction between something being fixed, and being reviewed, we don't have to use Closed - we could always introduced an 'Accepted' status that we transition resolved items to once confirmed. Or introduce [an optional] 'Review' status prior to resolved. There are always options. > > 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. > Rather than 'discovered', the Affects Version more literally covers any version in which the issue has been known to affect (as you are only going to truly discover it in one version, but you may subsequently test other versions to see if they contain the same issue). But essentially, you are correct. G
------------------------------------------------------------------------------
_______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
