[Development] [QA] Suggestion -- Setting Up the Priority in JIRA

Mitch Curtis mitch.curtis at digia.com
Wed Mar 20 12:05:31 CET 2013

On 03/18/2013 12:45 PM, Knoll Lars wrote:
> On 3/14/13 1:00 PM, "Jason McDonald" <macadder1 at gmail.com> wrote:
>> On Wed, Mar 13, 2013 at 11:48 PM, Anttila Janne <Janne.Anttila at digia.com>
>> wrote:
>>> Jason McDonald wrote:
>>>> On Wed, Mar 13, 2013 at 2:42 AM, Thiago Macieira
>>>> <thiago.macieira at intel.com> wrote:
>>>>> On terça-feira, 12 de março de 2013 13.28.37, Motyka Rafal wrote:
>>>>>> Hello,
>>>>>> I want to suggest another change for JIRA: - A Reporter should be
>>>>>> able
>>>>>> to set the Priority starting from the Create Issue window. -
>>>>>> Guidelines for setting Priority should be provided (already working
>>>>>> today).
>>>>>> Please feel free to comment on this. If there are no serious
>>>>>> objections, this change will be introduced soon. The impact of the
>>>>>> change will be evaluated.
>>>>> I disagree. The priority should be set by the triager, the person who
>>>>> can make a dispassionate, objective assessment of the bug's priority.
>>>>> The bug reporter is way too involved to make that assessment.
>>>> When we first introduced Jira, we allowed the priority field to be set
>>>> by the reporter, and this resulted in me spending rather a lot of time
>>>> turning P0's and P1's into P3's and P4's.  Before long my boss decided
>>>> to hide the priority field from the Create Issue form.  I don't know
>>>> whether the climate has changed enough since then for it to be
>>>> reasonable to expect a different result if we were to put the priority
>>>> field back in the form.
>>> Would it be possible to bring priority field back for certain JIRA
>>> roles,
>>> if not for everyone?
>> Sure, approvers and maintainers were not the source of the problem.
>> The grossly exaggerated priorities mostly came from Qt users (as
>> opposed to those developing Qt) and from a subset of Nokia's QA
>> contractors.
> We could certainly benefit from better initial information on the bug. The
> way to solve this could be to use some sort of questionnaire during the
> creation of the bug (does it cause crashes, do you have a workaround,
> etc.) and compute an initial priority depending on the answers.
> Still I think we need to make it easy for people to get 'bug evaluation'
> privileges in Jira without requiring them to be Approvers. So a group for
> people with somewhat extended Jira editing rights would be a good thing
> IMO.
> Cheers,
> Lars

The idea of allowing everyone to set priorities for bugs originally 
sounded risky to me, but the more I think about and discuss the 
alternatives, the better it sounds. I'm going to propose something:

Everyone with a Qt Project Jira account can set the priority for a 
*bug*; suggestions should probably not have a priority field at all. The 
importance of a suggestion can be determined by the amount of 

The Create Issue form (when creating an issue of type "Bug") is altered 
like so (* = mandatory):

Summary *
Affects Version/s *
Component/s *
Compilable, reproducible example * (was "Description", has text under 
the field name that says "Please use {code}{code} tags to provide code 
samples or attach files below. Click the (?) icon for formatting help.")
Tested environments * (as opposed to just "Environment" - this makes it 
clear that only the listed environments were tested by the reporter and 
that others could be affected)
Causes a crash * (checkbox)
Is a regression * (checkbox)
    Latest known working version (shown/enabled if "Is a regression" is 
Has a workaround * (checkbox)
    Workaround (shown/enabled if "Has a workaround is checked")
Priority * (has text under the field name that says "Please click the 
(?) icon for an explanation of which priority is appropriate for this bug.")

Each new field (where it's not already mentioned) would of course need 
accompanying help text/a help icon describing the field.

Renaming the "Description" field to "Compilable, reproducible example" 
is not going to stop people from providing too little information to 
reproduce the bug, unfortunately. I feel that this is more important 
than the issue of untriaged bugs. More time is wasted by trying to 
reproduce something than setting the priority after a quick glance of 
the reported negative effects of a bug.


More information about the Development mailing list