[Development] Long-lived P1 issues
ulf.hermann at qt.io
Tue Nov 3 09:07:43 CET 2020
> 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. 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
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.
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.
More information about the Development