That is another point that has me confused.
since we can re-open a issue, I am confused by the statement to open
another issue when ready.

Chris Howe sent the following on 12/23/2007 12:25 PM:
> I'm just tossing out 30 days.  But even if it were such a time period, if 
> there was activity with it after 30 days, you would simply reopen the issue.
> 
> ----- Original Message ----
> From: Christopher L <[EMAIL PROTECTED]>
> To: [email protected]
> Sent: Sunday, December 23, 2007 2:19:01 PM
> Subject: RE: Proposal of guidelines for the creation of Jira issues
> 
> 
> IMHO, 30 days is a bit tight.  I like to leave my issues open for
>  comment for at least a week or two before I implement them.  Then add in
>  delays for miscellaneous stuff and time to implement, and I'm way beyond
>  30 days.
> 
> My issues also tend to interest a subset of users and I think my issues
>  would get lost in the traffic on the list.
> 
> I don't object to periodic cleaning of jira.  Jira does perform a
>  valuable service for me, keeping track of my issues so I don't have to go
>  trolling through the list archives.  Admittedly, this system will work
>  well for the main contributors, but it will keep lower volume,
>  intermittent contributors, such as myself, out of the system.  I don't think
>  that's the intended result.
> 
> My 2c.
> 
> Chris
> 
>> Date: Sun, 23 Dec 2007 05:58:06 -0800
>> From: [EMAIL PROTECTED]
>> Subject: Re: Proposal of guidelines for the creation of Jira issues
>> To: [email protected]
>>
>> I realize that many of us are process minded people and so Jira
>  issues that are left open indefinitely tend to irk us a bit.  However, Jira
>  can have some benefit as a repository of ideas and not simply as a
>  workflow tool.  Discussion in a mailing list tends to be time period driven
>  and not so much issue driven.  If you're looking for a guideline to
>  satisfy that process mined mentality, I would suggest that 3) and 4) be
>  replaced with:
>> 3') If an issue that is not a bug is left open for 30 days without a
>  patch, it be closed with the resolution of "Later"
>> 4') If an issue has been in the resolution of "Later" has been
>  without activity for 365 days, change the resolution to "Won't fix"
>> or some such
>>
>> ----- Original Message ----
>> From: Jacopo Cappellato <[EMAIL PROTECTED]>
>> To: [email protected]
>> Sent: Sunday, December 23, 2007 2:34:04 AM
>> Subject: Proposal of guidelines for the creation of Jira issues
>>
>>
>> I would like to discuss with you some guidelines for Jira issue
>>  creation.
>> The idea is to limit the noise in Jira and prevent the creation of
>  Jira
>>  
>> issues with low informative value that will stay open forever.
>>
>> Here are some ideas:
>>
>> 1) If you already have a patch for an improvement/fix then create a
>>  Jira 
>> issue (if there is not one already) and attach your patch to it
>>
>> 2) If you don't have a patch, and you have discovered a *bug*, create
>  a
>>  
>> Jira issue (if there is not one already) providing as much details as
>  
>> possible (including the rev. number and the environment you are
>  using, 
>> and the step to recreate the bug)
>>
>> 3) If you don't have a patch, and you have want to suggest an 
>> enhancement or new feature, then discuss this in the dev mailing list
>  
>> instead of creating a Jira issue; at the end of the discussion, the 
>> community will consider if a summary of the thread should be saved in
>  a
>>  
>> new Jira issue, to facilitate future development
>>
>> 4) If you don't have a patch, but you are planning to work on it, and
>  
>> you want to share your design details with the community, you should 
>> discuss this in the mailing list instead of creating a Jira issue;
>  if, 
>> on the other hand, you don't have time to do this, you have already 
>> decided that you want to implement your patch following your design 
>> notes, and you just want to let the community know about the upcoming
>  
>> patch, you can create a Jira issue (to which you will attach your
>  patch
>>  
>> when it is ready);
>>
>> Summarizing:
>>
>> * bugs: always create a new Jira issue everytime you find a new bug
>> * new features/enhancements: create new Jira issue only if you have a
>  
>> patch (or if you plan to submit it very soon)
>>
>> What do you think?
>>
>> Jacopo
>>
>>
>>
>>
> 
> 
> 
> 
> 
> 

Reply via email to