+1 lot of times I want to toss something out and get feedback. Don't see the Dev list or Jira the most appropiate but the only resouces currently. Up till now I have seen the wiki more as a resources of information that does not fit into other constructs.
David E Jones sent the following on 12/23/2007 12:59 PM: > > 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 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 >>> >>> >>> >>> >> >> >> >
