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
>

Reply via email to