[Development] Priority field in Jira

Mitch Curtis mitch.curtis at qt.io
Wed Feb 26 11:45:14 CET 2020


>________________________________________
>From: Development <development-bounces at qt-project.org> on behalf of Lorn Potter <lorn.potter at gmail.com>
>Sent: Wednesday, 26 February 2020 11:15 AM
>To: development at qt-project.org
>Subject: Re: [Development] Priority field in Jira
>
>On 25/2/20 8:11 PM, Joerg Bornemann wrote:
>> On 2/25/20 10:31, Edward Welbourne wrote:
>>
>>> How about: because we can always over-ride them if we really disagree;
>>> and their prioritising of the bug is an opening for discussion of why
>>> it's so important to them - which, after all, we might have missed.
>>>
>>> I'd rather have a dialog than a privilege,
>>
>> This is about expertise, not privilege. For reporters, the priority is
>> usually muuuuuuch higher than for us or even other users of Qt, because
>> the priority is assessed from the viewpoint of their project.
>>
>> Let's say I've written this audio player app and found some quirk in
>> QtMultimedia that makes skipping impossible every once in a while. Users
>> give one star ratings and complain loudly.
>> What priority is this bug for me? Well, P0 of course.
>> For us? Not so much...
>
>That's when one uses the privilege of being the assignee to change the
>priority to what you think it is, with an explanation to the reporter
>why it isn't a P0.

How is this different in the end? I can probably count the number of times a priority set by a reporter didn't need to be changed on one hand. So in the end it's simply extra work that has be done on top of an already massive backlog of bugs.

>Removing the ability for a reporter to change priority does not seem all
>that inclusive to me.
>my 2c...

I must have missed something here, because I'm not aware of any issues with "exclusion" in our bug tracker, and don't know how this can be construed as being exclusive. There are processes that we follow to ensure that we have an accurate overview of which bugs need the most attention. This is (or should be) standard practice at every company that develops software, most of which don't have public trackers in the first place. I fail to see how preventing people who are unfamiliar with our prioritisation process from changing the priority is excluding anyone, _especially_ when the means for disputing a priority is already present and is the same regardless of whether or not the priority field is open to everyone.


More information about the Development mailing list