So what about ignoring the bits we disagree on for the moment. I think there is a consensus that it would be useful to have an additional extra step, as the Fedora guys have, something like 'received'. This would allow us to easily identify those issues which had not yet been reviewed. Any objections ?
Cheers, Robin. Robin Taylor Main Library University of Edinburgh Tel. 0131 6513808 > -----Original Message----- > From: Graham Triggs [mailto:grahamtri...@gmail.com] > Sent: 14 May 2010 15:15 > To: dspace-devel@lists.sourceforge.net > Subject: Re: [Dspace-devel] Jira workflow etc > > On 14 May 2010 13:43, Mark H. Wood <mw...@iupui.edu> wrote: > > > Closing could be part of the release process. When a fix is > incorporated into a release, the issue should be > closed. To revisit it > after a release, a new issue should be linked to the old. But I > wouldn't want to do that without an intermediate > "reviewed" state. > > > > I would still urge you to consider what the real implications > of using the 'Closed' status are. > > Unlike 'in progress', or 'resolved' - which give a reasonably > clear indication of what they mean, there really aren't any > inferences that can be taken from 'Closed'. > > Other, that is, the actual implication of making something > closed, which is that you can't alter the state of any field > in the item without first re-opening the item. So, if you do > want to reclassify something - maybe you change the > configuration later to add new components or classifications > that you want reflected in previously resolved issues - then > you have to re-open it, and then resolve it again, > remembering to set what the resolution was initially (ie. > Fixed, Won't Fix, Duplicate, etc.) > > Yes, we can try and impose our own meanings on to Closed, but > if we really want to mean something specific, then it is > much, much better to create a new status that provides that > meaning. If we want to say something is released, then we > should create a 'released' status - but that's actually not > very useful when you have an issue that might affect multiple > versions, and we may choose to have multiple releases for the > resolution - ie. if we found a serious enough issue in 1.5.2 > now, we might choose to release 1.5.3 AND 1.6.2. Those > releases would not occur at precisely the same time, so when > would you transition the issue to 'released'? > > I have absolutely no problem with us using Closed if we want > to take the administrative step of actually preventing an > issue from being edited - but I stress that I believe we > should only be doing because we want to take that > administrative step, and not because we want to infer a > meaning that 'Closed' doesn't convey. > > > And note that we don't even have to take something to Closed > just to prevent people (in general) from editing it. You can > define different permission levels for different statuses. > > > > I think the important states to distinguish are: > > o we have an issue. > > > > 'found', 'received', etc. > > > > > o someone is working on it. Others should either > avoid duplicate > effort or contact the assignee to offer help and receive > coordination. > > > > 'in progress' > > > > o assignee thinks the work is done. > > > > 'resolved' > > > > o fix is independently tested and judged to work. > > > > 'verified' > > > > o fix is in a release. > > > > I'm actually not convinced that we should have a status for > this, for the reasons I gave above (multiple releases). > Rather, you specify the fix version(s) in the issue, and the > 'verified' status says that it will be in those releases - > whether those releases have actually been released or not at > that point, is known elsewhere. > > > Additionally, it's important to have > > 'Open' - the issue is confirmed to exist and is awaiting > someone to work on it > > 'Awaiting Response' - which means that it can't be progressed > without additional information > > > > It would be nice if the tool could also help us track > *where* in SCM > space the fix is incorporated. That is, if it affects several > branches, have all known affected branches (and the > trunk) been fixed? > > > > It can track where it has been incorporated - providing the > commit message contains the issue number. So, if you commit > with the message: > > ' [DS-544 <http://jira.dspace.org/jira/browse/DS-544> ] > Removal of mapped items can lead to NPE ' > > you can go to the issue in Jira and see what commits / source > is related to that issue: > > http://jira.dspace.org/jira/browse/DS-544?page=com.atlassian.j > ira.plugin.ext.subversion%3Asubversion-commits-tabpanel > > Or indeed, you can go to the FishEye panel: > > http://jira.dspace.org/jira/browse/DS-544?page=com.atlassian.j > ira.ext.fisheye%3Afisheye-issuepanel > > which then links through to the information about that > checkin in FishEye: > > http://fisheye3.atlassian.com/changelog/dspace?cs=4941 > > G > > -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. ------------------------------------------------------------------------------ _______________________________________________ Dspace-devel mailing list Dspace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dspace-devel
