Bug backlog - now and future. Some proposals.

[Bill Davidsen]

Small comments thru the text, rant follows.

Jon Stanley wrote:
> Hear ye, hear ye!  At the BugZappers meeting that occurred today,
> March 12, 2008, two proposals for dealing with the backlog of bugs,
> both now and in the future, were discussed.   It was also discussed
> that this would be another useful forum to solicit feedback from.  Our
> goal here is not to disenfranchise bug reporters or cause them more
> work. Instead, it is designed to introduce predictability into the
> lifecycle of a bug.  This is part of the relaunch of the BugZappers
> initiative, which I had announced yesterday.  It's important to note,
> that while you're just now starting to see stuff from us visibly, this
> has been several months in the making and thought through very
> thoroughly.
> 
> These proposals will be presented at the meeting of the Fedora
> Engineering Steering Committee (FESCo) tomorrow, with a vote to be
> rendered on 2008-03-20 if necessary, and execution to begin shortly
> thereafter.  Please feel free to make comments by replying to this
> e-mail or editing the wiki.  We also hang out in #fedora-qa on
> freenode (my nick is jds2001), and our mailing list is
> fedora-test-list at redhat.com for other ways to make contact with us.
> 
> The purpose of the meeting today was to solicit input on proposals for
> dealing with the current unmanageable backlog of bugs. In the long
> term, this backlog will cause Fedora irreparable harm, if it has not
> already. Our most valuable asset, the bug reporter, is feeling left
> out in the cold. Community triagers feel discouraged by what they see
> as a insurmountable task, thereby making the problem feed on itself.
> We have to act, and the time to do it is now.
> 
I agree that the backlog of unsolved bugs is seriously hurting user 
perceptions.

> To that end, I am proud to present two proposals, One has to do with
> dealing with the backlog that we have now, and the other has to do
> with making sure we never get into this situation again -- ever. We
> believe that these proposals are the right thing to do, and now is the
> right time to do them, right before a release.
> 
I would suggest that the time to fix them is now, *instead* of a 
release. To clear the backlog by *fixing* the bugs, not by writing 
clever scripts to mark them CLOSED:WONTFIX or send notes to bug 
submitters to update the version to keep the bug open (unfixed) for 
another two releases.

> I'd also like to give credit where it's due for these proposals. The
> primary author of both of them is John Poelstra, without whom many of
> the things that have been accomplished to date would not have been. In
> just a few short months, we've gone from having almost nothing
> formalized to having a formal bug workflow, and having formal plans of
> dealing with the backlog, both now and in the future.
> 
> It's important to note that these are PROPOSALS at the current time,
> and have not been approved in any way. I am expecting, and welcome,
> impassioned debate on these proposals. In the course of these debates,
> however, lets be civil with one another - we're allresponsible adults
> here. If you have comments or concerns about either of the proposals,
> there's a comments section at the bottom of both of them on the wiki,
> which I encourage you to use. Also, please come to the meeting and/or
> reply to this e-mail if you have comments. Please try to back up
> changes to the proposals with a specific example of where the proposed
> action is wrong/bad/whatever, and what could be done differently to
> alleviate the concern.
> 
> Also note that the framework of the proposals is there. The exact text
> to be found in bugs is still yet to be written, however that will be
> written in the next week or so.  I realize that both this introduction
> and the proposals themselves are extremely long, but please read them!
> The wiki versions of these proposals can be found at:
> 
> http://fedoraproject.org/wiki/BugZappers/HouseKeeping
> http://fedoraproject.org/wiki/JohnPoelstra/BugzillaExtremeMakeOver
> 
I read them, and I find lots of ways to make unfixed bugs exit bugzilla, 
but no indication that bugs will actually be fixed in a more timely fashion.

I think you need a "deadline scheduler" approach, if a bug in a package 
isn't fixed by some (reasonable) time after it's reported, it should be 
evaluated, and unless it's waiting on external info it should be marked 
as TRIVIAL, AVOIDABLE, or RECOVERABLE (all FIXLATER), or mark the 
package as UNMAINTAINED. Then release the UNMAINTAINED packages as a 
separate group in the next release, the way "extras" used to be.

I believe that maintainers would be motivated to avoid having their 
packages marked UNMAINTAINED, and if they aren't, the description is 
accurate. You would hate to drop a package, but having one with serious 
bugs is worse. You can define "serious" any way you want, users know 
"doesn't work" when they report it.

In other words, if the package is still usable by most users, document 
the bug as trivial and live with it, and if a major bug isn't fixed, the 
reason doesn't matter. Developers enjoy adding new features more than 
bug fixing, or become too busy to maintain. Good intentions are nice, 
but they don't buy you a beer.

-- 
Bill Davidsen <davidsen at tmr.com>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot