Jira might not be the best place for new ideas and desired features that won't be acted on in the near future. I think the point Jacopo is making is that the issue tracker is more about issues, about things that need attention in the near future.
After a brief discussion on the mailing list, or even without that, I think a great place to organize thoughts around new enhancements or ideas for things is the wiki section of the Confluence server (OFBIZ space on docs.ofbiz.org). Things are much more flexible there, can be hierarchical more naturally, and can live for a long time as part of research and such by multiple people.
Does that strike anyone as a good or bad idea? -David On Dec 23, 2007, at 12:25 PM, Chris Howe wrote:
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 forcomment 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 beyond30 days.My issues also tend to interest a subset of users and I think my issueswould get lost in the traffic on the list. I don't object to periodic cleaning of jira. Jira does perform avaluable service for me, keeping track of my issues so I don't have to gotrolling 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 thinkthat's the intended result. My 2c. Chrisissues that are left open indefinitely tend to irk us a bit. However, JiraDate: 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 Jiracan have some benefit as a repository of ideas and not simply as aworkflow tool. Discussion in a mailing list tends to be time period drivenand not so much issue driven. If you're looking for a guideline tosatisfy that process mined mentality, I would suggest that 3) and 4) bereplaced with:3') If an issue that is not a bug is left open for 30 days without apatch, it be closed with the resolution of "Later"4') If an issue has been in the resolution of "Later" has beenwithout 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 ofJiraissues 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*, createaJira issue (if there is not one already) providing as much details aspossible (including the rev. number and the environment you areusing,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 listinstead of creating a Jira issue; at the end of the discussion, the community will consider if a summary of the thread should be saved inanew Jira issue, to facilitate future development 4) If you don't have a patch, but you are planning to work on it, andyou 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 upcomingpatch, you can create a Jira issue (to which you will attach yourpatchwhen 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 apatch (or if you plan to submit it very soon) What do you think? Jacopo
smime.p7s
Description: S/MIME cryptographic signature
