Re: Bug statistics

[Karl Fogel <kfogel@red-bean.com>]

Richard Stallman <rms@gnu.org> writes:
>    4594 reports  [1]
>    2647 closed reports
>
>Amost 2000 bug reports not closed
>is rather disturbing.
>
>    14% have been marked "minor"
>    20% have been marked "wishlist"
>    9% are tagged "moreinfo"
>    5% are tagged "wontfix".
>
>That is about 40%.  It seems to imply there are around 1200 bug
>reports which are not marked in these ways, and not fixed either.
>Is that true?
>
>Can you compute the number of bug reports that are waiting for action
>by the maintainers?

Percentage of bug reports not closed is not in itself a problem.  It's
possible that bugs-not-triaged is a problem, but that really depends on
many things about the project.

  http://ostatic.com/blog/fixing-the-perception-of-bugs

(And yes, I'm quoting someone quoting me in order to give my opinions
more authority. :-) )

IMHO the poor web interface of our bug tracker is an impediment to
finding and triaging bugs.  Heck, I can't even find the tracker half the
time.  If I start at http://gnu.org/software/emacs and click on the link
to [what is purported to be] the Emacs bug database, I am taken to the
generic top of the Gnu tracker: http://debbugs.gnu.org/.  Then there is
a table there, with a row for Emacs.  Since what I want to do is search
the Emacs bug database, I take the closest option to that, which is the
"Browse bug reports" column with its cell for "Emacs reports".  Clicking
on that brings me to:

http://debbugs.gnu.org/cgi/pkgreport.cgi?package=emacs;max-bugs=100;base-order=1;bug-rev=1

That page turns out to be just a random 100 out of many bug reports --
not that this is in any way obvious.  You have to actually read the text
at the top of the page ("Showing results 0 - 100 of 2003", which of
course my eye glazes over because "2003" looks like a date and I'm not
interested in dates) to realize that what follows it is unintentionally
insincere, e.g.:

   If you find a bug not listed here, please report it.

    * Outstanding bugs -- Normal bugs; Patch Available (2 bugs)
    * Outstanding bugs -- Normal bugs; Unclassified (46 bugs)
    * Outstanding bugs -- Normal bugs; More information needed (2 bugs)
    * Outstanding bugs -- Minor bugs; Unclassified (16 bugs)
    * Outstanding bugs -- Minor bugs; More information needed (1 bug)
    * Outstanding bugs -- Wishlist items; Unclassified (11 bugs)
    * Resolved bugs -- Normal bugs (16 bugs)
    * Resolved bugs -- Minor bugs (5 bugs)

That first line is wrong in an obvious way.  The remaining lines are
wrong in the same way, though it's slightly less obvious.  There are far
more than 2 outstanding bugs (one presumes).  That summary is just
referring to the bugs *on the current page*.  But for a randomly
selected listing page, I'm not really sure what the point of a summary
block at the top is.  It can, however, confuse people who might think
they're looking at project-wide stats rather than page-wide stats.

All of which misses the main point: there's no search box.  Oh wait,
there is.  It's all the way at the bottom of the page, where I'd never
think to look for it, because these days search boxes are all (sanely)
at the top of the page, as befits the single most useful feature of a
bug tracker.

I don't know if my periodic rants about our bug tracker have any
constructive effect.  I feel better after them, though.  In any case,
bug tracker web UI aside, there is nothing inherently good or bad about
a growing bug database.  An analysis of the number of unique submitters
would tell us far more.

-K