launchpad-dev team mailing list archive

[Robert Collins <robertc@xxxxxxxxxxxxxxxxx>]

So, I've run out of steam reevaluating all our 'high' bugs, for a
while at least.

We have more than 6 months work backed up there, by any metric :).
Thats a shame, because it makes it kindof pointless when triaging;
Aaron's long ago suggestion of infinite granularity between bugs
(roughly allowing any two bugs to be given a relative sort) would make
this a lot easier: just count 300 bugs from the top and bam, we are
there.

That said, I have learnt a few things doing this, and I think in
another 6 months doing another pass and trimming it some more will be
well worth doing.

I have some observations I'd like to share with you though.

Firstly, the -vast- majority of our bugs are small niggly things;
sometimes fallout from changes we've made, things we intended to do as
part of a project but fell by the wayside - that sort of thing.

I think that many of those bugs (even though they aren't labelled as
such) would be worth calling tech-debt, and to reduce their occurrence
we need to be much more aggressive about /not/ context switching with
the issue still existing.

Secondly, bugs with 'X should Y' are incredibly incredibly incredibly
annoying to revisit years later. They usually don't describe the
observed behaviour, nor why the observed behaviour is a problem; when
they do describe these things they still very rarely include an
analysis of the alternative solutions, merely concluding that a
specific thing makes sense - and years later, our standards, our
tools, and even the problems we are trying to solve have evolved out
of sight.

Thirdly our 'new' triage rules are working pretty well I think - there
were no more dupes in the most recent 1000 bugs than in the first 1000
still open ones, going by my unscientific gut feel. Well done! Please
do take a little time to look for a duplicate though - while there
were no more in the recent open bugs, there are still a staggering
number of duplicates across our bug database. This is exacerbated by
the tension between 'defect report' and 'root cause item' uses for
bugs, where there may be genuinely different symptoms for something
with one cause. I think the right thing here is to combine bugs (via
duping) when they have a single identifiable root cause. But -not- to
combine them if the only reason to combine is that *a* fix for one
would fix them all: if someone implements a different fix, the other
variants may still exist. Bug links will help manage this sort of
thing a lot better.

Fourth, an astonishing fraction of our bug database are things that
*cost us time or money*. 6% are tech debt. 2% are tickets affecting
webops.

This is, to me, confirmation that the current strategy for maintenance
- focusing on root causes, fixing complexity, test coverage, fragility
and duplication in the system is entirely sensible.

The only thing I think we need to change, is to be much less willing
to accept increasing the interest payments we need to make. As
discussed in Budapest, I'm putting together a draft policy for that; I
will mail separately about that.

-Rob