Too Many Bugs

MattyT mattyt-spam at tpg.com.au
Mon Jan 19 12:44:04 UTC 2004


On Mon, 2004-01-19 at 22:29, Gervase Markham wrote:

> Yes there is :-) You may decide that fixing it would be too disruptive 
> for too little gain, and so you're going to live with it indefinitely. I 
> can think of at least two examples of this recently. One is the renaming 
> of database fields.

Then suspension *might* be warranted, but WONTFIX certainly isn't.  And
things like renaming database fields are "bugs" only in a loose sense.

This threads is about bugs, not what lies in the grey area between bugs
and enhancements.  They are the vast majority, and there is no room for
interpretation or WONTFIXing.  And this is about practical solutions for
the majority.

> > Strong ownership would perhaps be useful in another way however, in that
> > people currently feel no responsibility to fix bugs.
> That's somewhat of a generalisation. I invite you to look through the 
> Reporting and Charting component as a counter-example. :-)

Loose language perhaps, but the generalisation is relevant in that
clearly true to a large extent.  I feel that I keep sanity check in
pretty good shape too.

Some of the problems have been caused by component owners who were never
really very involved with their components.  I don't mean this in a
derogatory way, it may be they have too many responsibilities, or too
little time, in the first place.  And a half-hearted component owner is
better than none.

But I do think it means we need to think about how components are
assigned to owners, and some components might do with an official
deputy.

I think smaller components are better from this perspective, although
perhaps not from a bug reporting one.  I can imagine it would be hard to
get a perspective on a component that has 150 bugs.  Obviously the
solution is to work away at it, but if we split up the components, at
least in spirit, it can feel like an easier task.

For example, although justdave is the official owner of the
administration component (at least last I checked), which includes
sanity check, I am the de facto owner of sanity check.  I have rewritten
copious quantities of this since I started with it.

With a smaller component, it is easier to take control, have pride in
"your" component.  At the moment, no one really owns anything, and hence
no one feels any bugs are their responsibility.  When you have pride,
you will feel it's your responsibility to fix even if its not your
fault.  And no one needs to tell you any of this.

Pride as a greater motivator than money is supposed to be part of the
reason individual volunteers are supposed to often produce better
quality software than businesses.  And I feel that people's lack of
connection with the Bugzilla code is in part responsible for some bugs
sitting around for years.

A great example of this is the bug in the notifications of status
changes on dependent bugs.  When you add a dependency, you get all the
status changes the bug has ever been through.  Or something like that.

I'm pretty sure this bug has been in Bugzilla since dependencies were
introduced before even I was involved with Bugzilla.  And I'm sure most
of you have seen these notifications that come through periodically and
thought someone should fix it some day, but everyone's hoping someone
else will do it.  There's few feelings of responsibility, because
there's few feelings of true ownership.

> > I don't really see how this matters.
> It matters because people can only be doing one thing at once, and you 
> can't focus your resources across the board. IMO it's important to be 
> focussed on getting a high-quality upgraded b.m.o. up and running ASAP. 
> Triaging old bugs helps this goal only in a very indirect way.

Part of the problem is there is never a time.  I don't doubt getting a
release out is more important in comparison to adding the next feature. 
But this thread isn't just about being reactionary and triaging the bug
system.

It's about being proactive, and to do this it has to be kept in people's
minds, even if nothing is done about it today.

-- 
         Matthew Tuck: Software Developer & All-Round Nice Guy        
 My Short Autobiography: 1985 Grade Bin Monitor 1990 Class Clown Award
1992 Awarded Most Likely To Spontaneously Combust 1996 Crowned Galactic
         Emperor 1998 Released From Smith Psychiatric Hospital





More information about the developers mailing list