Bug#704874: [bugs.debian.org] Ticket priorities
Package: bugs.debian.org
Severity: wishlist
X-Debbugs-Cc: debian-project@lists.debian.org
The ITS currently assigns each ticket a severity. This is very useful
for users, for example by letting them check the worst problems of a
package without having to read its entire ticket list.
Severity is also useful for developers as a means of prioritizing
tickets - for example, if a developer wants to debug LibreOffice, he'd
better start looking at critical, grave and serious tickets rather than
those marked wishlist. However, severity is not a measure of priority;
the two are merely correlated. In particular, old packages will have a
low correlation between severity and priority, as severe bugs which
survived years of maintenance efforts will be those which are
particularly difficult to fix.
http://blog.abahgat.com/2012/01/09/we-need-smarter-issue-trackers/#broken-priorites
discusses this issue in more details.
Having just severity is particularly problematic for tickets which do
not report bugs, and not just for developers here. Currently, all
wishlist tickets show together, without any distinction according to
costs or benefits. An intermediary step would be to track issue
importance. For bug reports, severity is the same as importance. For
RFEs, importance corresponds to the usefulness of a new feature (for
example).
This ticket is itself a good example of the nuance between importance
and priority; even though its importance may be high, its priority may
not be highest since addressing it will require great efforts. The first
step would be to decide how a ticket's priority should be determined. I
would consider a change as having 2 fundamental properties : importance
and (estimated) investment needed to implement. Both of these can be
argued independently. For example, an installer bug could have an
estimated cost to solve of 1000 €. If that bug breaks some installs, it
may have an importance of 10 000 € / year. This would give us an
estimated "global profit rate" of 1000 %/year. On the other hand, a typo
on the website's download page could have an estimated cost of 500 € /
year but an estimated cost of solve of 5 €, corresponding to a higher
estimated profit rate of 10 000 %/year.
The advantage of computing a priority this way is that there's less
subjectivity and any change to importance would directly change priority
(as opposed to a system where importance and priority would be both
manually set). Similarly, a change to cost would directly change
priority - if it is discovered that the installer bug is caused by a
simple typo, the estimated cost can be reduced to 1€, and its priority
would automatically increase to 1000 000 %/year, so it would now show
above the website typo ticket.
The drawback is it needs numeric importances and investments. Debbugs
users may not be comfortable with numeric importances, and even if they
do, some transition from relative to numeric would be needed.
Furthermore, what is the cost of a 1-hour fix? 40€? Indians may
disagree. Would we use the average worldwide hourly wage of a developer?
Or should we measure cost in time? Similarly, what is the value of a fix
which saves each user 15 minutes on average? Which wage do we use to
compute that? And how many users are there? Should we rather measure
value in time saved per user? If so, how much time would a user save for
having a prettier Icedove icon? Or maybe it's best to just have a
relative cost and some magic saying that a high importance issue with a
high cost has a normal priority.
Finally, although asking submitters to set the severity may be
reasonable, setting difficulty is even harder. Can we use an average
difficulty as default? Or should the cost default to unknown?
Reply to: