Bugs/BugHeat/Scratchpad

Not logged in - Log In / Register

Bug heat notes

Bug gravity algorithm

Bug gravity is calculated from these values:

Item

Value

Bug Control member

400

regression-updates tag

300

regression-proposed tag

250

regression-release tag

200

regression-potential tag

150

apport-package tag

100

apport-crash tag

100

apport-bug tag

50

private bug

151

num duplicates

x*6

num subscribers

x*4

num users affected

x*2

Thoughts:

However, we could still make use of the last three items on the list. In addition, we could (in the world of jam tomorrow):

Proposed general-purpose algorithm

So, here's a proposed algorithm (well, hotness-giving-thing-index anyway). The algorithm is pretty much:

hotness = 0
for item in hotness_index:
    hotness += item

Which is horribly simple, but it's better to have a simpler algorithm and alter the items and weightings that we feed into it than to have a complex algorithm that we keep needing to tweak.

List of hotness-making items

(We need a better name for these... Scovillizers? Anyway...)

I think we should use similar basic weightings to those used for bug gravity for the items that we pilfer from it, thus:

security bug

250

private bug

150

num duplicates

x*6

num users affected

x*4

num subscribers

x*2

Note that here I've made affected users more important than subscribers. This is based on the principle that we want affected users to be carried over from dupes.

It might make sense to have some thresholds here, so that after a certain point, the number of (dupes|subscribers|affected users) makes hotness jump up a level (we could have some fun with mathematics here, but let's keep it simple for now). So, for $item

Where K is whatever constant we use for weighting.

However, the downside of doing this is that it allows the system to be gamed more easily than just using $item * $constant.

User stories

Bugs/BugHeat/Scratchpad (last edited 2010-01-06 10:39:07 by gmb)