Let's be honest with your users: P0: almost sure to block a release. P1: We will act on it if the maintainer is in the mood some day when it's still fresh P2: We will fix it, maybe P3: thank you for informing us.
> I suggest to simplify P3, P4 descriptions though to >> >> P2: Important, should be fixed. >> P3: Should be fixed. >> > _______________________________________________ > Development mailing list > [email protected] > https://lists.qt-project.org/listinfo/development On Fri, Dec 4, 2020 at 7:27 AM Jason McDonald <[email protected]> wrote: > > On Fri, 4 Dec 2020 at 02:09, Kai Köhne <[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. > > 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 >
_______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
