Documentation Release Scheduling

[Matthew East]

Hi Tim,

This thread is now addressing two issues (stable release updating and
unstable release scheduling), so I'm going to reply separately.

On Jan 13, 2008 5:54 AM, Tim Bosse <taim at bosboot.org> wrote:
> If we added one or more "major change" freezes several weeks prior to
> the string freeze, I would be more inclined to contribute.  This would
> allow for proper testing of documentation from a technical aspect and
> allow for the "cleanup crew" to get grammar and the ilk touched up.  As
> Phil noted, this doesn't fix anything that occurs after string freeze.

I understand your frustration with this. However, we need to remember
that what we have to work with here is a pretty tight schedule - in
the past we've had a situation where the software in Ubuntu could
change pretty substantially at any time basically up to the
documentation string freeze, and our policies have had to cater for
that. Furthermore, it's often quite difficult for docteam members to
"commit" to upgrading to the unstable distribution and review any
changes until quite late in its development, which means that we are
often discovering new features quite late on.

I think the schedule for Hardy looks pretty good in that there are
three weeks between UI Freeze (which includes user visible strings)
and the documentation freeze, so we should certainly aim to have that
whole period dedicated to cleanup and review of the documentation.

It would also be good to have some "soft" freezes before that to
ensure that the major work is being done in the early part of the
release schedule, and a good part of the schedule can focus on
cleanup.

How about something like the following:

* Major new documentation to be completed by the FeatureFreeze (in
Hardy 14 February)
* Between FeatureFreeze and UserInterfaceFreeze (in Hardy 28 February)
- mainly targetted at cleanup and bugfixes. Substantive changes only
permitted when they arise out of changes which occur in the software
during that period. Any exceptions to this would have to be very
important. We could potentially ask the developers to notify the
docteam of any changes between that period (not currently the case).
* Following UserInterfaceFreeze, no further substantive changes:
cleanup and bugfixes only.

This sort of schedule would also permit us to get the translators
started on the documentation as early as FeatureFreeze.

-- 
Matthew East
http://www.mdke.org
gnupg pub 1024D/0E6B06FF