launchpad development|
⇤ ← Revision 1 as of 2010-01-05 08:32:11
Size: 2672
Comment:
|
← Revision 2 as of 2010-01-06 10:39:07 ⇥
Size: 3052
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 82: | Line 82: |
== User stories == * As a user of Launchpad <<BR>> I want to be able to sort a list of bugs by their "hotness" <<BR>> so that I can better see which ones need fixing first * As a user of Launchpad <<BR>> I want Launchpad to calculate bug hotness at regular intervals <<BR>> so that changes to the bug affect its hotness within a reasonable space of time. |
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:
- 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 += itemWhich 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.
User stories
As a user of Launchpad
I want to be able to sort a list of bugs by their "hotness"
so that I can better see which ones need fixing first
As a user of Launchpad
I want Launchpad to calculate bug hotness at regular intervals
so that changes to the bug affect its hotness within a reasonable space of time.
