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 > >
