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
