reducing emails

[Marshall Schor <ms...@schor.com>]

Hi everyone -


If you use all the workflow states, a simple fix generates these emails:

[jira] created
[jira] commented (n times - maybe, but n can be 0)
[jira] assigned
[jira] Work started:
svn commit:
[jira] Work stopped
[jira] Resolved
[jira] Closed

I propose we reduce our email reading load slightly by eliminating some 
of the jira workflow when it seems less interesting.

     For instance, for things which are quick to do - skip the Jira 
"Work started"/ "work stopped" updates.
     And when you "resolve" an issue, do you also need to "close" it? 
(The velocity project seems to "resolve")

-Marshall

Re: reducing emails

[Adam Lally <al...@alum.rpi.edu>]

On 11/25/06, Marshall Schor <ms...@schor.com> wrote:
> I propose we reduce our email reading load slightly by eliminating some
> of the jira workflow when it seems less interesting.
>
>      For instance, for things which are quick to do - skip the Jira
> "Work started"/ "work stopped" updates.

I would say not to use "work started" unless the work will take
multiple days to complete.  And I don't see much point at all in "work
stopped" immediately followed by resolve/close.  I would only use
"work stopped" if I were stopping work in an incomplete state.

>      And when you "resolve" an issue, do you also need to "close" it?
> (The velocity project seems to "resolve")
>

The idea is that issues in "resolved" state still need to be reviewed
before closing.  I think all issues should eventualy be "closed".  For
minor issues where no review is needed, I think it's fine to just skip
"resolve" and go straight to "close".

When you "resolve" an issue you can also change the assignee to the
person you want to review the issue.  I did that a couple of times
recently.  In other cases I put stuff in "resolved" state and then
sent an email to the list asking for confirmation that I did the right
thing.  I think these are useful uses for "resolved" state.

-Adam