[Development] Long-lived P1 issues

[Eike Ziller]

> On Nov 3, 2020, at 11:34, Alex Blasche <alexander.blasche at qt.io> wrote:
> 
> 
> 
>> -----Original Message-----
>> From: Development <development-bounces at qt-project.org> On Behalf Of
>> Jason McDonald
> 
>> Looking at the huge list of P1s we have right now, I have absolutely no idea
>> what issues are genuinely blocking Qt 6.0 or if there are any that I could help out
>> with. I could spend literally weeks just reading through all the P1s to try to figure
>> out what's really important. I would not like to be in the shoes of whomever has
>> to make a go/no-go decision for Qt 6 in the near future.
> 
> I don't believe reserving P1 for release blockers (as suggested by Eike) solves this problem. A release blocker for timed releases (which is what Qt's been doing for years) is not just a prio field but also a timing issue. After all the trinity of quality - time - resources must be adhered to. Resourcing is generally fixed for a release, the prio field reflects quality and "fix Version" field maps to time. Therefore we have to make tough calls to leave some P1 bugs out as time runs out. Therefore the blocker list for a release is a combo of Fix version and prio
> 
> Here is Jani's link for them:
> https://bugreports.qt.io/issues/?filter=22682

I think that this split is very hard to see, realize and understand at the minimum for non-Qt-developers / customers / users, and sometimes even for developers.
It is something that we interpret into a combination of two separated fields in JIRA, with the meaning of Fix Version even having dual meaning depending on the “Resolution” state of a task, it requires a custom filter to see which tasks actually were important enough to warrant some of the resources for a fix in the next version.

Also it introduces a split within the P1 tasks: Some of them are were deemed more severe than others, so we committed to allocating resources to them (by setting a fix version), and some were considered less important.

It is simply easier to see, if this is reflected in the priority. Will my issue be fixed?

P0: Yes, as soon as possible.
P1: Yes, it was deemed important enough to be allocated resources so it should be fixed in the next release.
P2-P5: No idea.

In the P2-P5 range differences in priority, timing/fix version whatever, can still be used to differentiate.

Br, Eike

> 
> The priority field is a standard field. There is no way to remove it. One can hide it somewhat but it is known to show up in different places. Mind you, our triaging process is based on unset prio fields. We check for data to assess the prio and ask for more until we can set the prio. It still doesn't imply that we can verify the bug on our side. One could do that too but this will expand the scope of triaging significantly and I am not sure whether we want to go this far.
> 
> --
> Alex