On Oct 16, 2011, at 1:48 PM, Mattmann, Chris A (388J) wrote:

> +1, Suresh.
> 
> Regarding Re-opening issues -- I'd generally advise against ever doing so. 
> The experience is that if you use JIRA 
> changelogs to generate release notes, you will find you deliver a release 
> with an issue closed. Then, if later someone 
> re-opens that issue, (and naturally re-assigns it to a new version), you'll 
> have:
> 
> * issues fixed in > 1 versions
> * a period of invalid time for your last (or some prior) release
> 
> Instead, I'd recommend if there is a problem with an issue that's already 
> been marked resolved, encourage someone 
> to open up a new issue, and then *link* back to the resolved issue by 
> reference in the comments, or via JIRA's link 
> feature.

+ 1. 

Thanks Chris for the feedback and suggestion.
Suresh

> 
> HTH,
> Chris
> 
> On Oct 16, 2011, at 8:01 AM, Suresh Marru wrote:
> 
>> Hi All,
>> 
>> To make the project better organized, I want to resurrect the discussion on 
>> - http://markmail.org/thread/c6bmzb7pb5t3ywl3 and in addition I propose the 
>> following guidelines in effectively utilizing JIRA. We can iterate, agree 
>> and document on the website. 
>> 
>> 1) Assign appropriate JIRA type to all the new issues. Pick among: Bug, New 
>> Feature, Improvement, Wish, Task, BrainStorming.
>> 
>> 2) As much as possible, lets attach the JIRA tasks to a target release. This 
>> will help in quickly prioritize blockers for next immediate release. 
>> Secondly, it will make the release management easy by quickly browsing 
>> through a tagged JIRA release and get the full change log. We do not want to 
>> slow down adding JIRA tasks, so at the If a task/sub-task is not decided or 
>> cannot be determined then assign it to a release called WISHLIST (a version 
>> i added to JIRA).
>> 
>> 3) Resolve Vs Close: Once the developer fixes the issues and commits the 
>> change, he/she will resolve the issuer. The reporter verifies the issues and 
>> if fixed/addressed closes the issue. In cases where users do not close the 
>> tickets, based on confirmation (within mailing list of by comments) that the 
>> issue is fixed, the dev may close the ticket. In the most common cases where 
>> a developer opens a ticket and works on a problem and resolves it, if they 
>> believe that the issue is addressed to their satisfaction, or no further 
>> work is needed, then they can directly CLOSE the issue bypassing the 
>> RESOLVE. As much as possible, we have to encourage developers to resolve the 
>> issues and reporters to close the tickets. In the case, when none of the 
>> above criteria apples or lack of response, any developer may choose to go 
>> through the tickets, understand the report, verify the resolution and if 
>> addressed, close the issue. 
>> 
>> Alongside this discussion, please spare some time to go through current 
>> RESOLVED JIRA tickets http://goo.gl/cUOPo and verify if the issues and close 
>> them appropriately. 
>> 
>> Cheers,
>> Suresh
>> 
> 
> 
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Chris Mattmann, Ph.D.
> Senior Computer Scientist
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 171-266B, Mailstop: 171-246
> Email: [email protected]
> WWW:   http://sunset.usc.edu/~mattmann/
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct Assistant Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 

Reply via email to