Fedora scheduling made easy

[Bill Nottingham]

A slightly longer reply...

John Poelstra (poelstra at redhat.com) said: 
> schedules.  I believe the Fedora project can scale successfully with 
> detailed schedules and more information about what happens in each step.  

Where are we failing to scale now?

Is it (to use string freezes as an example):

1) people don't know about dates like string freezes (a schedule
  distribution issue)
2) people don't know what string freezes are (a terminology issue)
3) people don't care about string freezes (a management issue)

1) can be solved with more communication, and potentially with tools
2) can be solved with better documentation.
3) can't be solved with tools without going to extremely draconian measures
that I don't feel are truly worth it.

> 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?"

This is the sort of doucmentation we should have for newer developers; for
those that have been around long enough, this is sort of assumed knowledge.

For example:

- "Development freeze"

The package set is frozen. Only packages that fix significant issues found
in testing are added to the tree.

- "Release"

Availability for download.

- "Feature freeze"

All features must be complete in a testable state. Anything that's not will
either be dropped or reverted.

- "String freeze"

Translatable Fedora-specific strings and user-interfaces should be frozen,
to give the translators time to finish their work.

- "Translation freeze"

This is the last point for translations to be contributed and be guaranteed
to get in the release. Any translations after this need to be officially requested
to get pulled in.

> 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.

How does this do this in the absence of information? The majority of features
haven't had any updates since they've been initially entered. (I know I'm
pretty guilty in this regard). I don't see how a project tool by itself
can solve this - it's still garbage in/garbage out.

Bill