In general, 3.1 wants to be a very light platform-update / fixup release
with very little product-y aspect to it.  After some discussion with
davida and clarkbw, we'd like to push forward with the feature roadmaps
fairly quickly, in the interest of prepping for the post 3.1 work.  
We'll start driving that separately shortly.  In the meantime, my
suggestion for folks doing code work is to work on polishing off rough
edges from 3.0, along with landing small, scoped features that were
intended to make 3.0 but didn't.

Here's a road map that's based on 1.9.2 for Thunderbird 3.1 that I think
could work, and it would start next Monday:

http://www.flickr.com/photos/dmose/4151232741/

If you have trouble reading it, remember Firefox's zoom feature in the
View menu.  :-)  Each tick on the timeline is intended to be 5 working
days. There are effectively 3 milestones (M1, M2, and RC1), and the last
20 working days are baking time for RC1 and an RC2 if necessary.  Note
that string and feature freeze is proposed to happen when the tree
closes for M2, and RC1 is for bug-fixing only.

Things to keep in mind:

* Any UX changes with non-trivial string implications (eg > 20 strings
or so) early in either M1 or M2, and localizers should be notified with
a message to dev-l10n at that time of landing.

* Reviewers will be requiring changes to mail/, mailnews/, editor/, and
directory/ to have automated tests unless there are specific, cogent
reasons why that's impractical or wrong-headed.

* In order to help keep the number of live branches at any given time
manageable, it would be ideal if we could follow Firefox 3.6 and 3.7's
lead and do a "minor" update (automatic with no way to opt-out) from 3.0
to 3.1 fairly quickly after 3.1 is released, so that we could then stop
supporting the 1.9.1 branch entirely.  The fewer changes (particularly
API and front-end changes) that we allow into 3.1, the more likely it is
that we'll be able to do this.

Thoughts on all this?

Dan