[Development] Long-lived P1 issues

[Eike Ziller]

> On Nov 3, 2020, at 09:07, Ulf Hermann <ulf.hermann at qt.io> wrote:
> 
>> Currently, there are 1175 open P1 issues in the QTBUG project.  583 of those issues had that priority set more than one year ago, 342 of those had their priority set more than two years ago, and 175 of those more than three years ago.
> 
> Let's be honest about this: The priority field is meaningless. There have been so many P1 issues that didn't stop any release that many people, including me, just ignore P1 by now.

I wonder why you don’t just set a different priority if you don’t agree with an issue being of so high priority that it _really_ should be fixed soon.

> Furthermore, anything below P2 effectively means "we're never going to fix it". There is no point in having 3 different priorities for that. The only priority that still prompts an immediate reaction (from me at least) is P0, as those are usually build failures that block work elsewhere.
> 
> I currently use a combination of tags and the "Fix version" field to prioritize my own tasks.
> 
> To summarize, the actual meaning of priorities, as perceived by me, is as follows:
> 
> Unprioritized: See magic tags, fix version, etc
> P0:            Immediate action on the way
> P1, P2:        Will probably get fixed sometime
> rest:          Won't be fixed unless it has magic tags, fix versions ..
> 
> That's not only quite different from the documented meaning of the priorities but even if it was documented that way, it wouldn't convey a clear message to any observers. In particular, you have no idea what time frame to expect when a bug has P1 or P2.
> 
> 
> Here is a proposal to improve this situation:
> 
> Drop the priority field and instead use the fix version universally.
> 
> The fix version is a clear enough indication of the urgency of a task.

I disagree, especially if the fix version is a planning tool for the individual developer.
The point is that you still at least need the rough categories of

1. must be handled _immediately_ (build breakage “P0”)
2. release management decreed that this must be fixed for the (a) upcoming release (what P1 was supposed to be)
3. other issues

Just if a fix version is set, this doesn’t mean 1 or 2, it just meant that someone thought it would be a good idea to fix it in this version, and this can change anytime.

IMO tags are not very well integrated into JIRA to use it for 1 and 2, for one it would be difficult to find the tag to use - all tags are equal to JIRA, no grouping, nothing.

If you use priorities 2-5 to prioritize issues in the 3rd category “other issues” or use fix versions for planning or whatever, is a different question.

We had this discussion before and I still think we should make P1 actual blockers again, move all bugs one level lower that are not blockers, and then release management has to enforce the meaning of P1, as currently the meaning of “P1 with fix version” is enforced.

Br, Eike

> It prompts you to reconsider all bugs that slipped once a new version has been released. It doesn't force you to bump the fix version on every release, but a bug with a past fix version that isn't fixed is clearly abandoned. That's in contrast to a 3 year old P1 bug that isn't fixed. For the latter, as an observer, you have no idea what the actual status is.
> 
> Tasks that currently receive P1 or P2 will then have a fix version of the next release they qualify for. That would be 6.0 for bugs at the time or writing, or 6.1 for new features. If the task qualifies for fixing in LTS, you'd additionally set the next LTS release(s) as a fix version. Tasks with lower priority will have something like 6.x to signal "sometime in the Qt6 time frame". This way, it is also possible for individuals to plan work ahead in a more fine grained way and set, for example, 6.2 as fix version.
> 
> We may need an "immediate action required" tag in addition, to signal the current meaning of P0.
> 
> best,
> Ulf
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development