launchpad-dev team mailing list archive

[Aaron Bentley <aaron@xxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11-08-04 09:24 AM, Gary Poster wrote:
> I spoke with Aaron on IRC.  he identified 820510 and 820511 as the biggest bang for the buck.  He did not want to mark these as critical.  I don't really agree, but I also don't really care a lot.  Yellow hopes to tackle at least one of those RSN.

I think these bugs are important to fix, but I don't want to mark them
critical in order to justify fixing them.  Marking bugs critical when
they really aren't makes us take longer to fix bugs that actually are
critical, such as 556245, "librarian1 non responsive and gobbling
excessive memory".

I think we're experiencing importance inflation, where things are
getting marked higher than they should be, in order to increase their
priority.  Instead of using "importance" to determine priority, I think
priority should be an ordered list that we control directly.  That gives
us much finer control, makes escalation trivial, and removes the
temptation to inflate importance.

When I'm doing triage, I have the incentive to mark a bug "critical" if
I care about it, because our focus on critical bugs means that high bugs
are rarely fixed.

In scheduler theory, this is called "starvation".  However, this is also
a solved problem: instead of trying to process all items in the highest
priority class first, use ratios of classes.  That way, progress is made
on all classes, but priorities are respected.  If we applied this to
Launchpad, we could say, "For every 5 critical bugs you close, close a
high bug.  For every 5 high bugs you close, close a low bug."

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk46qZgACgkQ0F+nu1YWqI2ziACfdshWda67scmnc6KymwMmy218
WO8An2enJJKi7lCLA6c7q24LCoWm9SpS
=5+Hn
-----END PGP SIGNATURE-----