[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    Re: [RFC] Documentation Freeze Policy
From:       Burkhard =?iso-8859-15?q?L=FCck?= <lueck () hube-lueck ! de>
Date:       2010-01-15 20:14:10
Message-ID: 201001152114.11048.lueck () hube-lueck ! de
[Download RAW message or body]

Am Montag, 11. Januar 2010 19:09:09 schrieb Rolf Eike Beer:
> Am Montag, 11. Januar 2010 schrieb Burkhard Lück:
> > Hello translators,
> >
> > techbase.kde.org/Schedules says about doc freeze (usually around 9 weeks
> > before tagging a major release like 4.x.0):
> >
> > 1) "Documentation/Handbook Freeze
> > No more substantive changes to documentation or handbooks after this
> > date. Typos, spelling and simple grammar changes are permitted."
> >
> > The second sentence should be changed to something like:
> > "Exception: Typo, spelling fixes and simple grammar changes are permitted
> > until RC1 but you have to mail kde-i18n-doc saying you made such a
> > change."
> >
> > Then it is similar to the current Message Freeze policy.
> 
> That sounds reasonable.
> 
> From my point of view as application developer it would be helpful if the
>  doc freeze would be moved a bit closer to the release data. For 4.4 it was
>  one week after the code freeze (i.e. the scheduled release of beta1). I
>  suggest moving it to the same time as beta2.
> 
I completely agree with you, that one week  between GUI + Doc freeze is way 
too short, but extending it to three weeks won't really help.

> The idea behind this is:
> 
> -One would only have one week to write/update documentation, especially for
> small projects (e.g. KGpg is a one-man-show). In a timeframe of 3 weeks
>  it's much more likely that the developers will finally sit down and write
>  that stuff. Until the feature freeze everyone is coding, and new features
>  don't make sense to be documented if it's unclear if and how they will
>  show up in the upcoming release. After all we are all lazy humans and will
>  be in a hurry before feature freeze ;)
> 
Maybe other devels are rushing to get their application release ready after 
gui/feature freeze? Or they are busy with other stuff?

> -Translators will do messages first anyway. Most teams (even bigger ones)
>  will not be done even with core modules messages until long after beta2.
>  Currently e.g. Spanish and German teams (listed as 5th and 6th on
> http://l10n.kde.org/stats/gui/trunk-kde4/toplist/) are not completely done
> with the core SC components (well, probably mostly the weather strings) but
> that was way worse like 3 weeks ago. So it's very unlikely that a later
>  freeze of documentation would lead to a greater hurry for translators than
>  they have anyway.
> 
Maybe this is true for the german team, but I'm not sure, if this is valid for 
all different teams.

With the new backport policy everybody can work the whole life cycle of a 
major release on updating docs and translations.

The big benefit of this will be, that the gap for doc and translation between 
branch and trunk is getting smaller at the end of a major release.

That means it is easy to get up to date wrt doc and translations for the 
following release.

-- 
Burkhard Lück

[prev in list] [next in list] [prev in thread] [next in thread]