Fedora scheduling made easy

[John Poelstra]

In this post https://www.redhat.com/archives/fedora-devel-list/2007-March/msg00341.html
Jeremy makes a good point about being able to scale and holding to our schedules.  I believe the Fedora project can scale successfully with detailed schedules and more information about what happens in each step.  I've created a new framework (contrasted with the existing schedule) and taken a few liberties at guessing at a few additional milestones that might be useful: https://poelcat.108.redhat.com/nonav/fedora/schedules/fc7/fc7-sched.png.  Additional steps can easily be added.

As I went through the Fedora schedule here: http://fedoraproject.org/wiki/Releases/7 I found a general outline of what is supposed to happen, but not a lot of explanation about what each step means or what is required for a particular milestone to be considered finished... in other words, "what exactly does String Freeze mean?"

I would like to volunteer to help by maintaining a more detailed schedule and adding some additional wiki pages which define our terms :)

The benefits of having the Fedora schedules in a project planning tool is that it is easier to manage unforeseen delays, plan alternate scenarios, and have a clearer sense of how we are doing at a particular point in time towards meeting the published schedule on time.  We could also combine the docs schedule with the main Fedora schedule in a modular/manageable way.  A detailed schedule would also help our project be more transparent and let others in on how many different steps go into making a release happen.  
Right now I have the source and generated output in my own hosting space, but can easily move it to a Fedora name space if someone can suggest the best place.  I was thinking it could either be part of "infrastructure" or "Fedora board?"

A sample of the scheduling reports are here: https://poelcat.108.redhat.com/nonav/fedora/schedules/fc7/tasks-overview.html  Others can be created for different time periods and varying levels of detail.

Any objections to moving forward with this?

John