Koehne Kai added, to the discussion of priorities and LTS, > The current descriptions of the priorities in JIRA [1] IMO aren't too > helpful, since they focus too much on impact on a release.
The release is in the (possibly distant) future when prioritising; and, when doing triage, I don't know which release shall fix a bug, unless it's so high priority it must be in the next release. I'd sooner have priority definitions in terms of what I can see when it's submitted. I think those deciding LTS questions need the same. > But I also feel that the right priority is a computation of several > factors, including Severity, Impact, whether it's a regression, and > whether there's a workaround. > > Based on this I tried to come up with an 'algorithm' for JIRA bug > priorities a while ago: That sounds like the page we should expand for what we want here. I've duly added > https://wiki.qt.io/JIRA-Priorities and > [1]: https://bugreports.qt.io/secure/ShowConstantsHelp.jspa?#PriorityLevels to the links section of our Triage Dashboard in Jira, Eddy. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development