Mozilla project planning, for those not in the know, happens primarily through bugzilla entries, which include bugs, feature requests, work items, everything. It may not be the best way to organize things that aren’t really software defects, but it’s what we have, and somehow it works out ok.

As a case in point, the way releases get planned (what should be in which release) is through flags — bugs can be nominated for a release (by anyone), and then a group of people with a good overall perspective on the release (called “release drivers”) either accept a nomination or reject it — or redirect it to another release. Furthermore there are bugs that are considered blocking, while others are considered wanted. The former are the bugs that we’d delay a release in order to get them fixed, while the latter are nice-to-haves, but they wouldn’t block a release.

It’s a remarkably distributed process, with discussions about which bugs should be addressed and why distributed across the bugs. We then use bugzilla queries to get a holistic picture of the release, which gets particularly important close to the end-game. Over time, I think we can build better mechanisms, but the bird in the hand…

Importantly, release planning starts with people nominating bugs for either ‘wanted’ or ‘blocking’ status. We currently have flags in place for two releases: Thunderbird 3.0a1, and Thunderbird 3. The former is imminent, the latter not so much.

For 3.0a1, our release goal is first and foremost to actually do a release, which will exercise a bunch of muscles and mechanisms which have not been exercised in a while. Nominations for 3.0a1 should focus on bugs which significantly impact the ability of alpha users to give feedback on the product. Common crashers, bugs causing data loss, and significant usability problems are the most obvious candidates. We’re not being feature-driven for this early alpha, so don’t bother nominating new features for this release.

For 3.0, we’re definitely willing to consider all kinds of bugs. These will help us scope the extent of work needed, but also help us get a broader, “crowd-sourced” picture of the state of the product — what, among the thousands of contributed ideas and bug reports, impacts the most people. The easiest way to express “support” for a bug is simply to vote on it. Don’t add comments to the bug if you’re not contributing new information beyond your support — that makes the bugs harder to read, hence harder to fix. Instead, vote on your favorites. (I know voting on bugs is far from ideal — but it’s better than any other current alternative)

To nominate a bug, you need to be logged in to bugzilla, and you should set the appropriate flag (under the CC area) to ?. Only drivers are allowed to set + or – flags, so please don’t.

For more information, see the wiki.