[Development] Long-lived P1 issues

[NIkolai Marchenko]

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
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development


On Fri, Dec 4, 2020 at 7:27 AM Jason McDonald <macadder1 at gmail.com> wrote:

>
> 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
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> https://lists.qt-project.org/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20201204/825fcdd5/attachment.html>