I personally think that there are too many tasks in Trac for the next release, they should be split up into separate versions. Currently releases are feature driven, which means that you will not see anything until all those Trac tickets are closed, and at the moment there's still 131 active (only 3 have been closed). Instead, I think that releases should be driven by a release cycle - quarterly is good - monthly better (depending on resources of course) - add a realistic amount of tickets to each see more planned release, allowing time for bugfixes and testing, and then stick to it. This means that the release is planned out before anyone even starts working on it.

Currently Trac is not being utilised correctly. As with any project management tool, goals need to be realistic, and putting ALL of the tasks into one release (7.1) means that Trac is little more than one giant 'things to do list'. As I mentioned previously in another post, a decent road map is needed - this means mapping out the next years releases, with a realistic schedule, and splitting these tasks up between the releases, this also means that the tasks have to be prioritised. All of this is standard project management stuff, and my guess is that coders are driving trac, not managers.

The worst part of planning releases is that some features will get pushed way out, which will upset some of the users, but after everyone gets used to having a regular release, and can see when their particular feature / ticket is due to be addressed, things will settle down. Also, if management make a faux par by pushing X feature out into the 1st quarter 2011, everyone will soon let them know.