User:Dmose/Tb Roadmap Scratchpad

	THIS PAGE IS A WORKING DRAFT
	The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly. If you have any questions or ideas, please add them as a new topic on the discussion page.

At the moment, this page is merely a scratchpad where I'm putting together ideas for post Tb3 work. Before any of the things here become real, I'll be iterating on them with feedback from the community.

Part of the plan for Thunderbird is to move our development process in a more agile direction. Now that we've just about got Tb3 out the door, there are some process changes I'd like to propose to help us get there.

Dev Cycle

Rather than having super long releases, we'd like to release significantly more frequently than we have historically done. Key reasons for this include:

• keeping in closer sync with Firefox, so that we get the benefit of both the latest features and security fixes
• shorter plans tend to be more accurate than longer ones
• pressure to land features before they're ready is reduced, because the next shipping train isn't so far in the future

A proposal:

• Shoot for one major release every 4-6 months, from the nearest aligned Firefox/Roadmap release.
• Shoot for an alpha or beta milestone every 4 weeks (down from 8-10 in the Tb3 cycle.
• Make 3.next a short-cycle release based on 1.9.2 or (opportunistically) 1.9.3. It would be strongly focused on low-hanging fruit rather than large features.

Testing

To increase quality, and to improve our ability to make non-trivial changes to the codebase without regressing functionality, I'd like to bring our code review policies in line with those of browser and toolkit: all patches to directory, editor, mail, and mailnews should include tests unless there's a specific reason why that's impractical or not sensible.

(I suspect we'll also want to sync up with the revised mozilla-central super-review process, but I think that can probably wait until after we get more critical stuff nailed down).

Product & Component Roadmaps

Rather than having a single big roadmap that then ends up having lots of things cut from it at the end, davida has suggested that we instead have individual roadmaps for different feature and code areas, particularly those where we can avoid a lot of cross-dependencies. We can then pick appropriate pieces of work from various different road maps and target them at a given release, and if some don't make the release they're originally slotted for, it doesn't disrupt the overall roadmap for that release.

Clearly, the devil here is going to be in the details, so the next thing on my to-do list is to come up with a few such straw-man roadmaps, probably in concert with clarkbw and davida, so that we can get a feel for how they will and won't work.

UI Iteration Via Extension

We did some UI iteration in extensions in Thunderbird 3, with varying degrees of pain-upon-landing. The big win, it felt like, was the ability to get UI to a workable and understood state before imposing it on everyone using nightly builds. We'd like to explore this methodology more going forward, but we'll need to nail down more details about our process and what sorts of experiments with it that we'd like to do. In particular, we'll need to think about how we handle:

• UI-review
• code-review
• test writing
• l10n

such that things happen appropriately sized chunks at the right time. It feels like we're likely to want an extension process that's somewhat more lightweight that in our in-tree process. My current thinking is to prioritize the product/feature definition stuff above sorting out these processes, and do more thinking here once we're ready to start poking at individual extensions.

I'd like to drill down into this after we get some of the product stuff a bit more defined and as we start working on individual extensions. though if someone else wants to pick this piece of sooner, that could work as well.