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