Reducing the Calendar bug count

We (mostly our lead developer Philipp) have done some heavy lifting with our bug database in recent days. During the last month, we waded through hundreds of bug reports (some of those being several years old) to see whether those bugs had been fixed by all the work that we’ve put into Lightning 1.0 beta1.

The result of this exercise was a reduction of our total open bug count by nearly 18% or in absolute terms, we’ve reduced the number of open bugs by 276 from 1552 to 1276. This chart illustrates our total open bug count from the start of 2010 until mid-March:

It’s important to note that not every bug in our database is a real program error. Our bug list also contains lot of enhancement request, project management issues and enhancement requests. Basically everything that comes up in our project that needs to be tracked somehow is entered in our bug database, so that it can be easily tracked.

9 comments

  1. Hm, yes, but the spectacular effect is only visible in a maximized window. In the RSS/Atom feed viewer in SeaMonkey mail, where I display the feed item text (and pictures if any) in the bottom pane (at near-maximum height but with the usual “folder list” in the open left sidebar) of the main window, the chart is clipped at Feb.22, with a large blank right margin, and it took me some time to realize that maybe I was missing the most important.
    Even in a maximized browser window at 1024×768 pixels, I need to “zoom out” once (with Ctrl+-) before the right border of the graph becomes visible. I wonder why this large blank right margin (something like three inches) overlapping it is there at all. (Try reducing your browser’s width and you’ll see what I’m talking about.)

  2. This is due to the site stylesheet. I’m really no CSS expert, but I would welcome thoughts on how to fix that.

  3. Rule at http://weblogs.mozillazine.org/calendar/styles-site.css, line 98:
    .entry,
    .trackbacks,
    .comments,
    .archive
    {
    position: static;
    overflow: hidden;
    clear: both;
    width: 99%;
    margin-bottom: 20px;
    }

    The culprit is overflow: hidden;. Removing it or explicitly setting it to the (Mozilla) default visible works.
    (You could change it to scroll, but for me, that results in a scrollbar appearing for the comments div in addition to the image’s div. div scrollbars suck anyway; better to allow the viewport’s scrollbars to appear.)

  4. I’m pretty bummed that Movable Type stripped my tags when I posted, but did no such thing during the preview.

  5. Er, that’s supposed to read “…my code tags…” with “code” in angle brackets using appropriate HTML entities, but it seems it was again stripped during post. Again with the preview/post disparity!

  6. Thanks for the work!
    I just got the latest nightly yesterday and it fixed the long-standing bug in the Invite Attendees screen when one of the participants wasn’t known (a Zimbra Resource in my case).
    Some of the enhancements would be nice to see for 1.0b2, especially the convenient access to status (accept/reject/tentative) via context menu….

  7. Simon, all, I already have said it before and will probably say it again in the future: a big thanks to you guys for the tremendous work you’ve been doing. That piece of software is a pleasure to work with (ok most of the time).
    In fact one practice we had back in the days I was a program manager was to regularly go through the bug list with the team. We had longer sessions on this subject just before starting a new version in order not to create duplicate bugs/feature requests and to clear a bit the databse. It’s a hassle to do it but what you have done is importat for the project.
    Keep up the good work and all my encouragements to bring the bugs count even further down.

  8. Colby: To make sure tags appear (as in <html>) use &lt; for a less-than sign, &gt; for a greater-than sign (and &amp; for an ampersand). Also use the [Preview] button whenever it is available, but beware of it clobbering &…; entities as it does here.

  9. Tony: from my comment,

    “…using appropriate HTML entities…”.

    And I did use preview, hence the multiple complaints about “preview/post disparity”.
    Simon: I notice that the column width was changed since yesterday. Does that have anything to do with the image display issues in this post? If so, although I didn’t make the original complaint (my Thunderbird configuration shows post content of the feed, without fetching the associated Web page) I’ll note that the image is still cut off, and I wonder why the column width was changed, rather than the fix I suggested?