On 03/18/2013 12:45 PM, Knoll Lars wrote:
> On 3/14/13 1:00 PM, "Jason McDonald" <macadd...@gmail.com> wrote:
>
>> On Wed, Mar 13, 2013 at 11:48 PM, Anttila Janne <janne.antt...@digia.com>
>> wrote:
>>> Jason McDonald wrote:
>>>> On Wed, Mar 13, 2013 at 2:42 AM, Thiago Macieira
>>>> <thiago.macie...@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
voters/watchers.
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
checked)
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.")
Assignee
Attachment
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.
Cheers.
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
