== Received vs Open ==
(partial rehash of what said in #duraspace 2010-05-12)
Due to the difficulty in successfully keeping up with new tickets created,
especially during the tail of weekly committer meetings, I like the idea of
having "received". It will help to distinguish what has been submitted, and
it just rotting, vs something that has atleast been considered. If JIRA
could spit out a weekly email of all things {received}, as well as all
things that moved from {received to open} in the past week, and sent that to
dspace-tech, I think that would be helpful to engage the community a little
more. I.e. a ticket about doing something in jetty will get a better
response from the mailing list, than from jira.
Thus, someone can patrol the {received} tickets each week, to make sure they
either become {open} or {closed - won't fix}. Then in committer meetings we
can discuss issues that need more discussion, such as "does this patch make
sense".
Also, with regard to new tickets that are feature requests / improvements. I
think these might be especially good to get community feedback for. Such as
ideas from dsalo like: DS-293 [Update input-forms from the UI, no restart
required].
I like how things like Google Moderator works, and I would recommend adding
{recieved::feature-request} to moderator. Thus far, I've been adding things
somewhat to http://www.google.com/moderator/#15/e=3fb5&t=3fb5.40
This would work somewhat similar to how in times past, a survey went out,
and then a wordle tag helps you to see in big letters what is wanted. But
this could be equally, or more effective.
== Resolved vs Closed ==
I was wondering about the difference between resolved and closed.
When I do my commits that fix the problem (even if I was the reporter), I
choose to resolve the ticket.
To close it, I think should be the responsibility of the tester, the
reviewer, or even the release coordinator. They look over all committed
fixes, and once its been properly tested and solves the problem
satisfactorily, then they get to close it.
Peter Dietz
Systems Developer/Engineer
Ohio State University Libraries
On Thu, May 13, 2010 at 12:52 PM, Graham Triggs <grahamtri...@gmail.com>wrote:
> 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
>
>
------------------------------------------------------------------------------
_______________________________________________
Dspace-devel mailing list
Dspace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-devel
