Differences between revisions 1 and 9 (spanning 8 versions)

Contents

Plans
Open Questions
Additional Info
Algorithm

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

Current focus: story-bug-heat bugs
Drivers: Graham Binns and Deryck Hodge

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

How does heat icon related to show number of affected users in bug listings?
What more could we do with heat in search?
Metrics? Anything we can add to lpstats?
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

See Brian's algorithm for heat/gravity

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.

-  ⇤ ← Revision 1 as of 2009-12-07 18:02:03 → 
  Size: 1759
  Editor: deryck
  Comment:
+   ← Revision 9 as of 2010-01-11 06:44:51 → ⇥
  Size: 4644
  Editor: mbp
  Comment: moin bite me
-Deletions are marked like this.
+Additions are marked like this.
 Line 1:
-Bug heat is one of the stories under development by the [[Bugs|Bugs team]] for what is being called [[/VersionFourDotO|Launchpad v 4.0]].
+||<tablestyle="float:right; font-size: 0.9em; width:30%; background:#F1F1ED; margin: 0 0 1em 1em;" style="padding:0.5em;"><<TableOfContents(1)>>||
 Line 3:
-<<TableOfContents(1)>>
+'''Bug heat''' is one of the stories under development by the Launchpad [[Bugs|Bugs team]] for what is being called [[/VersionFourDotO|Launchpad v4.0]].
 Line 5:
-= UDS Notes =

''What follows is the notes Deryck has from discussions at UDS (unedited, except for wiki-fying).''

See [[http://qa.ubuntu.com/reports/bugnumbers/yesterday.html|Brian's algorithm for heat/gravity]].

 * Show heat indicator in bug lists, bug page
 * Also show number of affected users
 * These two are different and shouldn't be conflated

Issues:
 * Number of affected users should follow when a bug is duped
 * Last modified time should be considered
 * Comment time should be considered
 * How do you get bugs off the list (based on importance? based on something else? Or never?)

After working out algorithm --
 * get bugs and ask QA if the algorithm will work for them
 * work from the output, rather than trying to get too much input
+ * Current focus: [[https://bugs.edge.launchpad.net/malone/+bugs?field.tag=story-bug-heat|story-bug-heat bugs]]
 * Drivers: [[http://launchpad.net/~gmb|Graham Binns]] and [[http://launchpad.net/~deryck|Deryck Hodge]]
-Line 28:
+Line 10:
-== 3.1.12 ==
 * Design algorithm for calculating heat
 * Get feedback from stake holders here
+== 10.01 (January 2010) ==
-Line 32:
+Line 12:
-== 3.2.1 ==
+ * Design algorithm for calculating heat [DONE]
 * Get feedback from stake holders here [DONE]
-Line 34:
+Line 15:
-     * script to calculate bug heat
+     * script to calculate bug heat [IN PROGRESS]
-Line 36:
+Line 17:
+ * 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
-Line 40:
+Line 26:
-     * Draw any connections between this and Bug Q&A
+     * Draw any connections between this and affected users
-Line 42:
+Line 28:
-== 3.2.2 ==
+== 10.02 (February 2010) ==
-Line 51:
+Line 38:
-. Need to get a list of bugs for the feature tagged story-bug-heat
 2. Need to get a list of all heat-related bugs tagged
+. 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 =

 * See [[http://qa.ubuntu.com/reports/bugnumbers/yesterday.html|Brian's algorithm for heat/gravity]]


= 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.

launchpad development

Diff for "Bugs/BugHeat"