[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: