on the point of time periods, I would like the process minded and bean counting people to realize we are not in a static but a dynamic environment. I can see, for instance, in the branch, of having the written in stone time frame, since it is a static, for all intent and purposes. However the trunk just went through a major revision not more than a month ago that reset the time frame, as of that point, for projects that were being worked, on before that point. They were revisions, that though good, were not discussed or warned about so those projects in progress could evaluate and make corrections as the changes were discussed.
Chris Howe sent the following on 12/23/2007 5:58 AM: > 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 > > > > > > >
