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