Accepting Nominations for Thunderbird 3.0a1/3.0 blockers

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.

MozCamp in Vancouver

Next Sunday, just before the Open Web conference, we’re organizing a get-together of people who hack on Mozilla-related code. Details from Shane Caraveo:

MozCamp Vancouver, Sunday April 13, 12pm to 5pm

1700-409 Granville Street

I am glad to announce Mozcamp, an informal gathering of developers who
work on XUL applications and extensions. We’ll start the day with a brief intro from each attendee, covering what they work on and what they are interested in discussing. We can then self organize for the rest of the afternoon. Any topic is accepted, from development issues to strategy and beyond.

Vancouver and Victoria have a number of organizations that currently
develop mozilla-based applications, such as Mozilla Messaging
(Thunderbird), Flock, Songbird, Brand Thunder and ActiveState (Komodo
IDE). Representatives from these organizations will be attending, and
as well this event is also open to anyone who works on mozilla-based
applications, extensions, or related technologies. ActiveState is
providing the space, Mozilla is providing the pizza. Space is limited,
so please RSVP to Shane Caraveo (shanec at ActiveState-dotcom)
as soon as possible.

Should be good!

Think Schools, Think Email?

I spent yesterday at Think Schools, an all-day gathering of people looking for constructive ways to solve a crisis facing the local school district: given that we need to seismically retrofit the existing school stock, can we do so intelligently, not destroying the vibrant community hubs that many of these old schools have become, but instead build upon them?

I was struck by the similarities and differences faced by this group and by the people I work with whether when discussing email or Mozilla.

The differences are easiest to describe: The people involved in Vancouver schools are naturally roughly co-located (although some of the issues go beyond the city boundaries, it’s still a local issue), while the people involved in the future of the internet are stunningly distributed.

On the flip side, at least the people involved in Mozilla, are self-selected and hence roughly aligned on broad themes, such as the Mozilla Manifesto. We’ll argue vociferously on some issues, no doubt — but there is still a stated common goal, and a lot of shared culture. In contrast, the people involved in the future of schools span an wide gamut, including community activists and parents, teachers, principals, custodians, school board staff and elected trustees, provincial ministerial staff and elected representatives, engineering firms, architects, geoscientists, and more. Needless to say, initial thoughts about “ideal outcomes” across these groups are often not even close to aligned.

The differences in vocabulary, perspectives, timelines, budgetary and organizational scales that these groups have to span, and the emotional issues that lie very close to the surface (such as child safety, trust, reputation, integrity), make diplomacy a real requirement for forward motion. Overlaid on this, the governmental regulation and budgetary scale for capital improvements bring in old-fashioned political skills. (On that note, it was nice to see some city councillors in the room like Peter Ladner and Raymond Louie, clearly learning about the issues affecting their city, even though the city has little influence on school construction issues. It was disheartening not to see anyone from the Ministry of Education, who has the most authority over the issue.)

Still, there are strong similarities between the “school renewal” and “email renewal” exercises. The leaders in both cases are deliberately working on a collaborative community building effort, out of necessity as much as ideology. In both cases, there is a constant healthy tension between trying to be thoughtful and inclusive, and needing to make real progress quickly. Also, I am routinely struck by the realization that behind the differences in names, personality types, job titles, backgrounds, or level of commitment, there are such things as Good Ideas, and once they are explained carefully and understood, these ephemeral things can bring very disparate groups in alignment.

In the case of the Think Schools event, it was hard to find people who didn’t appreciate the elegance of an old idea: that our schools shouldn’t be thought of (and budgeted for) as single purpose “teaching boxes”, but instead as multi-purpose community hubs, leveraging precious real estate to provide a variety of civic services (libraries, gyms, meeting spaces, cafeterias, playing fields), with an appropriate funding model. We had a presentation from someone involved in that setup in Seattle, which was inspirational.

The possible synergies from such a model are appealing no matter which perspective you take:

  • From an educational point of view, it creates an educational environment that is part of a broader civic landscape, integrating childhood and education into the broader community, and by bringing in more users into a facility, can provide funding for essential non-funded spaces, such as libraries, music & arts spaces, daycare, and more.
  • From an environmental and energy point of view, you can build and maintain buildings that are used by different populations at different times.
  • From a civic policy point of view, you build neighborhood anchors in a city with few alternative assets to host them.
  • From a public health point of view, you encourage walkable neighborhoods and community sports & health facilities, neighborhood libraries and community centers.
  • From a maintenance and policing point of view, you have buildings and grounds that are in use almost all the time, reducing vandalism and the like.

The largest obstacle before this vision is the as-yet invisible path to that outcome past jurisdictional and budgetary silos, and, so far, a lack of political will. Everyone is aware that it is a huge obstacle. Still, getting 130 motivated people in a room for a day was a great start.

When it comes to the future of email, I don’t feel like we as an industry have yet figured out what the desired outcome is — we’re still at an early stage of visioning, with a rich cacophony of ideas, each one striking an interesting note, but without harmony yet. To stretch the musical metaphor, I’m hoping that what we in Mozilla can do is to provide both a “standard” (in the Jazz standards sense), and a couple of places to jam, and see what happens. Yesterday got me wondering whether having a face-to-face meeting on “envisioning the future of email” would be a good idea, even though the logistical challenges of doing so with a global community are enormous. Something to ponder.

Thunderbird gets Buggy Eyed

This article by Wayne Mery will show up in the next about:mozilla newsletter, and says it all:

Or more correctly, Thunderbird is putting bugs in the cross hairs. As part of it’s attention to users and quality, the reinvigorated Thunderbird team has announced weekly Thunderbird Bugdays. Bug day will be held every Thursday as part of a multi-pronged effort: 1) to reduce the number of bugs in the bugzilla database to a more manageable level – for both confirmed and unconfirmed bugs, 2) to respond to and assist bug reporters in a more timely manner, and 3) to improve the quality of the bugs in the database such that they are more easily acted upon by developers and volunteer hackers.

Bug day brings together seasoned Thunderbird users and users new to the bug process each week for a day of bug squishing/squashing/mashing/improvement. #bugday on IRC is the vehicle for veterans to help and mentor new participants. #bugday is also the collaboration tool that allows everyone can help each other, to gang up on bugs, and have fun.

The Thunderbird team needs your help to make bug days effective and fun, so please take a look at our planning document and add your thoughts to the wiki or post in the dev newsgroup.

To quote k5ehx from our second bugday, “Bug Squashing is fun!” To all Thunderbird enthusiasts, we look forward to your involvement.

Thanks Wayne and Gary for leading this great effort!