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 _______________________________________________ Mailing list: https://launchpad.net/~launchpad-dev Post to : launchpad-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~launchpad-dev More help : https://help.launchpad.net/ListHelp
