how do you determine this > However I think that we should not use the OFBiz Jira as our own diary for > hobby programming (done in the spare time).
Jacopo Cappellato sent the following on 12/23/2007 9:54 PM: > I agree with David about the Wiki site being a better tool to prepare > design notes with the community rather than Jira. > > About time frames: I'm not against having Jira issues that stay open for > a long time (months, years), and I don't want to put pressure on > contributors (that is why I don't think that setting strict rules, such > as a fixed number of days, is a good idea). > > However I think that we should not use the OFBiz Jira as our own diary > for hobby programming (done in the spare time). > Also, if we create an issue (not for a bug) without a patch, then we > should make sure that the issue's content has some informative value in > it (design notes, results of a research, a summary of comments from the > mailing lists etc...): unfortunately there are a lot of issues that are > not interesting, for example: > > 1) "the screen XY needs to be converted to the widgets": this is not > useful, because we already know that we need to convert (possibly all) > the ftl templates to the widgets... there is no need to create separate > issues for each of them > > 2) "quotes are only implemented for customers, not for suppliers": this > is not useful, because there are several processes that are still not > implemented (especially if you consider specific industries and > processes) and we don't want to record all of them in Jira > > Jacopo > > > David E Jones wrote: >> >> 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 >>>> >>>> >>>> >>>> >>> >>> >>> >> > > > >
