Diff for "Bugs/BugHeat"

Not logged in - Log In / Register

Differences between revisions 10 and 11
Revision 10 as of 2010-01-11 11:02:47
Size: 4946
Editor: gmb
Comment:
Revision 11 as of 2010-01-18 04:39:53
Size: 5029
Editor: deryck
Comment:
Deletions are marked like this. Additions are marked like this.
Line 7: Line 7:
 * January's bug heat sprint has a [[Bugs/BugHeat/SprintJan2010|posted schedule]]

Bug heat is one of the stories under development by the Launchpad Bugs team for what is being called Launchpad v4.0.

Plans

10.01 (January 2010)

  • Design algorithm for calculating heat [DONE]
  • Get feedback from stake holders here [DONE]
  • Risky bits of bug heat done early
    • script to calculate bug heat [IN PROGRESS]
    • install as cron to test early
  • File bugs for:
    • Showing heat indicator in bug lists
    • Showing heat indicator in bug page
    • Exposing heat number via the API
  • Create mockups of bug heat indication on bug listings, bug pages, and in search
  • Week 3 sprint show heat across LP
    • Show on bug page
    • Show on bug listings
    • Use in search
    • Draw any connections between this and affected users

10.02 (February 2010)

  • Consider bug heat done
  • Any remaining bits landed week 1
  • Polish based on stake-holder feedback rest of cycle
  • Heavy QA to see how heat algorithm holds up over the cycle
    • Likely updates during cycle due to testing/feedback

Open Questions

  1. How does heat icon related to show number of affected users in bug listings?
  2. What more could we do with heat in search?
  3. Metrics? Anything we can add to lpstats?
  4. How do bugs come off the "Hot Bugs" list?
    • Fixed, of course
    • Does changing importance get bugs off list?
    • Do bugs never come off, i.e. if it's hot, it's hot!

Additional Info

Algorithm

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:

  • In Launchpad (by default, anyway), we don't need to care about:
    • Bug Control membership
    • Specific tags

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

  • Provide a UI to allow bug supervisors to pick specific tags and assign a hotness value to them.
  • Ditto for teams (i.e. if reported by this team, give it this hotness).
  • By default we could have the bug supervisor be the Person whose reporting of a bug gives that bug extra hotness.

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

  • If < n of $item, hotness = x*K.

  • If $item count >= n, hotness = 100 + (x*K).

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.

Note on duplicates: It makes sense that duplicate bugs shouldn't have any heat whatever (though their heat from affected users and subscribers should go to the duplicated bug). If they're un-marked as duplicates they'll get whatever heat they had back again, but otherwise they should simply go cold.

Bugs/BugHeat (last edited 2010-01-18 04:39:53 by deryck)