+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
