Sorry for jumping on the thread when it's already in close mode, but let me express my thoughts on this subject.
Currently we don't have any formal process to nominate features and jiras to a given release. Having said that, the whole community can come at any given time and suggest a given feature or jira to be included in a release, or even suggest minor releases for specific issues (as we saw with 1.2.1 and 1.3.1). If we introduce a formal process (e.g "Blocker" and "Critical" jiras must get into the release) I'm worried this would have some undesired side effects, and would force us to stop doing frequent releases, as we will have to wait for all the jiras in these categories to get fixed. Having said that, I believe we haven't missed any important JIRA that contains a patch in our past releases. On Tue, Aug 26, 2008 at 12:29 PM, haleh mahbod <[EMAIL PROTECTED]> wrote: > Any more comments? If not, I document this on the website. > > On 8/22/08, Ramkumar R <[EMAIL PROTECTED]> wrote: >> >> +1 from me. >> >> On Fri, Aug 22, 2008 at 12:08 PM, haleh mahbod <[EMAIL PROTECTED]> wrote: >>> >>> Taking a vote at the beginning of each release cycle can be one way of >>> handling prioritization. >>> >>> It really does not matter if there is a prefect approach for handling >>> this as long as there is an approach that is understood by all. The chosen >>> approach can always be improved if it does not work. >>> >>> So far, one combined approach based on the feedback might be to use JIRA >>> priorities and consider including blocking JIRAs for the next release as >>> well as the most voted Critical, Major and Minor JIRAS. Voting can be >>> done at the end of the release cycle for the start of the next release. I am >>> assuming that JIRAs here mean issues as well as feature requests. >>> >>> Does this seem like a good first try? >>> >>> On 8/21/08, Vamsavardhana Reddy <[EMAIL PROTECTED]> wrote: >>>> >>>> JIRA itself provides for voting for an issue (look for Voting link under >>>> Operations when viewing a JIRA). Are you suggesting to have a vote after >>>> each release on what are the top features and bugs to be addressed in the >>>> next release? >>>> >>>> ++Vamsi >>>> >>>> On Thu, Aug 21, 2008 at 11:41 PM, Dan Becker <[EMAIL PROTECTED]> >>>> wrote: >>>>> >>>>> Oh, I agree. I like the idea of a vote to help prioritize issues. I >>>>> believe several developer sites have some system like this where each >>>>> developer gets to vote for their top 3 bugs or feature requests. >>>>> >>>>> haleh mahbod wrote: >>>>>> >>>>>> These are good suggestions. However, what if my JIRAs are of the >>>>>> major or >>>>>> minor category. Will I have a chance to provide a weight for the major >>>>>> JIRAs >>>>>> that I would like >>>>>> to have considered. IMO That's where vote can be helpful to decide >>>>>> which of >>>>>> the Major or Minor JIRAs are wanted by many users. This can also be >>>>>> useful >>>>>> for making decisions for critical JIRAs. >>>>>> >>>>>> >>>>>> On 8/21/08, Dan Becker <[EMAIL PROTECTED]> wrote: >>>>>>> >>>>>>> I like the idea of adding some release meta-info to the priority >>>>>>> levels. >>>>>>> However I would slightly clarify your wording on the release info >>>>>>> for the >>>>>>> priority levels: >>>>>>> >>>>>>> *Blocker* - Must have. Release not complete until issue is resolved. >>>>>>> *Critical" - Should have. Release not complete until issue is >>>>>>> resolved or >>>>>>> all parties agree to drop/postpone until next release. >>>>>>> *Major* - Likely have. Release is likely to have issue resolved. >>>>>>> However >>>>>>> due to workload or other major blocking items issue may be postponed. >>>>>>> *Minor* - May have. Issue is low priority for this release and will >>>>>>> be >>>>>>> completed for release time permitting. >>>>>>> *Trivial* - May have. Issue is low priority for this release and may >>>>>>> be >>>>>>> completed for release time permitting. >>>>>>> >>>>>>> It is a similar idea to yours, and I tried to put a release-related >>>>>>> statement next to each level. >>>>>>> >>>>>>> >>>>>>> Ramkumar R wrote: >>>>>>> >>>>>>>> One way, I could think as a solution to this issue is to re-define >>>>>>>> the >>>>>>>> definitions of the existing priority levels in the JIRA system. An >>>>>>>> issue >>>>>>>> has >>>>>>>> a priority level which indicates its importance. >>>>>>>> >>>>>>>> The currently defined priorities are shown below. >>>>>>>> *Blocker* Blocks development and/or testing work, production could >>>>>>>> not >>>>>>>> run >>>>>>>> *Critical* Crashes, loss of data, severe memory leak. *Major* Major >>>>>>>> loss >>>>>>>> of >>>>>>>> function. *Minor* Minor loss of function, or other problem where >>>>>>>> easy >>>>>>>> workaround is present. *Trivial* Cosmetic problem like misspelt >>>>>>>> words or >>>>>>>> misaligned text. >>>>>>>> I believe, re-defining what this priority level means for a release >>>>>>>> as >>>>>>>> shown >>>>>>>> below would help. >>>>>>>> *Blocker* Release will not be completed until issue is resolved. >>>>>>>> *Critical >>>>>>>> * Issue will most likely be resolved for release. *Major* Issue >>>>>>>> should be >>>>>>>> resolved for release. *Minor* Issue may be resolved for release. >>>>>>>> *Trivial* Issues >>>>>>>> that might be resolved before a release. >>>>>>>> >>>>>>>> OR another way to achive the same would be to add additional >>>>>>>> priprity >>>>>>>> levels >>>>>>>> (other the default levels) at the admistration section of the JIRA >>>>>>>> system. >>>>>>>> >>>>>>>> >>>>>>> -- >>>>>>> Thanks, Dan Becker >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Thanks, Dan Becker >>>> >>> >>> >> >> >> -- >> Thanks & Regards, >> Ramkumar Ramalingam >> > -- Luciano Resende Apache Tuscany Committer http://people.apache.org/~lresende http://lresende.blogspot.com/
