[Development] Long-lived P1 issues

[Jason McDonald]

On Fri, 4 Dec 2020 at 02:09, Kai Köhne <Kai.Koehne at qt.io> wrote:

> > Was there any outcome from this discussion? Like, re-evaluating priority
> > levels and what they mean in terms of release blockers?
>

I note that the number of open P1's has dropped from 1175 to 1063.  Some of
that decline has been from genuine P1's getting fixed for Qt 6, some is due
to maintainers doing some housekeeping, and I have closed a handful while
sifting through the older half of the Needs More Info bugs.

Thank you to everyone who has contributed so far.

There was no consensus, however, so I've put this on the backburner until I
can finish reading through the rest of the NMI bugs and the Testlib
backlog, which will take me into the new year.

When I'm done with those tasks, perhaps I can find one or two maintainers
who wouldn't mind a little help to straighten out their module's backlog in
exchange for educating me about their module.  (Warning: I can only commit
to a maximum of ten hours per week for the foreseeable future.)

Personally, I don't have a problem with the definitions of the priority
levels.  The only change I'd suggest is to make it explicit that the
availability of an easy workaround should generally cause the priority of a
bug to drop down one step.

What I'm seeing in Jira suggests that collectively we just aren't very
strict about sticking to those definitions.  I've seen some cases where P1
has been set to indicate that "this bug really annoys me" rather than "this
bug seriously disrupts my work".  I also see cases where the reporter set
the priority themselves.  Back in the Nokia days, we had separate Severity
and Priority fields so that Jira could show both the level of disruption
experienced by the reporter and the urgency for a fix set by the
maintainer.  I'm afraid that I can't remember why we merged those fields.

I don't think there was any sort of decision or consensus. Which means we
> keep working with the status quo, as documented in
> https://bugreports.qt.io/secure/ShowConstantsHelp.jspa?#PriorityLevels
>
> I suggest to simplify P3, P4 descriptions though to
>
>   P2: Important, should be fixed.
>   P3: Should be fixed.
>
> (the mentioning that they don't block a release probably stems from a time
> where P1 meant blocking the release. This is not the case anymore, so
> what's the point in highlighting that a P2, P3 doesn't block a release?).
>

I think that would be a good change.  P1's blocking a release only made
sense back in the days where we could only manage one release every three
or four months.

Cheers,
--
Jason
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20201204/f02d2625/attachment-0001.html>