[Development] Long-lived P1 issues

[Mitch Curtis]

> -----Original Message-----
> From: Development <development-bounces at qt-project.org> On Behalf Of
> Jason McDonald
> Sent: Friday, 4 December 2020 5:25 AM
> To: Kai Köhne <Kai.Koehne at qt.io>
> Cc: development at qt-project.org
> Subject: Re: [Development] Long-lived P1 issues
> 
> 
> On Fri, 4 Dec 2020 at 02:09, Kai Köhne <Kai.Koehne at qt.io
> <mailto: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.

There was a discussion related to this recently:

https://lists.qt-project.org/pipermail/development/2020-February/038988.html

> 
> 
> 	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