ticket status report

[Luke Schierer]

I want to start out by giving everyone a big congratulations, we have
closed over 120 tickets for this release, not counting many of the
tickets that have been detected as duplicate submissions and closed
without a milestone.  While not a record, this is one of the best
releases we have had in terms of tickets closed!  Right now we are
closing an average of 108 tickets per release.  Not shabby by an
measure.  

The bad news is that it looks like we will be rolling over 150 tickets.
To close all the tickets currently assigned *would* require a record
number of tickets being closed, particularly when you consider the many
new tickets that will come in, some of which will be important to fix.
Indeed a significant number of the tickets closed with each release have
been just such new submissions, that prove easier, more interesting, or
both than many of the backloged tickets.  

I would ask everyone to try to devote at least a few hours in the days
following our 2.2.0 release to the 100 oldest tickets.  Lets close those
that are unfixable for lack of information, and the feature requests
that time is proving we won't get around to implementing short of a
patch.  If we can close a signficant number of these, I feel confident
that we will be rolling over far fewer tickets each release.

You will have noticed that I have stopped attempting to to assign
tickets to mile stones.  It simply isn't worth it, when most of the
tickets attached to our previous mile stones have been passed over in
favor of new work and newer bugs.  What can I do to make it easier to
close *old* tickets?  As our high numbers show, we are not having
trouble closing tickets in general, but the number coming in is
continuing to out-pace us.  We now have 741 tickets with no mile stone,
363 of which are defects.  While I could weed through the enhancement
tickets, probably closing many of them as things we do not wish to work
on or which could be done as a plugin, I still feel that the best way to
slow the incoming stream of tickets is to close the outstanding issues
as our highest priority.  That way fewer of the tickets will be
duplicate, and more importantly, the existing code will be that much
more stable, that much more reliable, to build out all the new cool
ideas on top of.  

luke