[Development] Priority field in Jira

[Volker Hilsheimer]

> On 26 Feb 2020, at 11:45, Mitch Curtis <mitch.curtis at qt.io> wrote:
> 
>> ________________________________________
>> 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.


The priority field changes it’s meaning during the lifetime of the bug report:

* in the beginning, it tells us how important it is for the reporter of the bug. This is useful.
* after triaging (which we do regularly, at least in The Qt Company), it tells us how important it is for the Qt Company (and perhaps the Qt community/project at large)

Anything that is still a P0 after triaging should be treated as such: unplanned work that needs to be fixed so urgently that it preempts any planned work.

For everything else: if you are in a team that plans their work weeks based on JIRA tickets, then the priority of a ticket is one piece of information for that planning process.

Not allowing reporters to set priority removes a piece of information, but shouldn’t change anything else, so I’m not convinced that we should limit things by default. If reporters consistently abuse their privilege, in spite of dialogue and feedback, then we might need to find more effective ways to deal with those particular reporters.



Cheers,
Volker