The 2.10 Schedule and Policy
- From: Shaun McCance <shaunm gnome org>
- To: desktop-devel-list gnome org
- Subject: The 2.10 Schedule and Policy
- Date: 09 Sep 2004 15:39:22 -0500
Originally sent to release-team, resending to desktop-devel-list per
Mark's suggestion. I'm too lazy to rewrite it, so "you" refers to the
release team in this email. :)
The following schedule and policy changes would be really helpful to the
documentation team in the next release cycle:
* In 2.8, you introduced a string change announcement period starting at
the feature freeze. A UI change announcement period, starting at the
same time, would help us get documentation work finalized sooner, which
in turn means the translation team might actually be able to translate
the documentation.
* Strings affect documentation too. I would like string changes in the
string change announcement period to be announced to gnome-doc-list.
Also, string changes can be made after the string freeze with approval
from the translation team. I don't need maintainers asking permission
from the documentation team for string changes, but I would very much
like notification.
* Maintainers are supposed to notify the GDP when they branch. Somehow,
they never do. I suppose I should start humiliating people publicly
like menthos does when they silently branch. I just want to get the
word out there that the documentation team does want to be notified of
branches.
* Some applications don't change much after the feature freeze. If a
maintainer has no intention of changing things around right up to the
respective freezes, I'd like to encourage them to let the documentation
team know. This way, we can start working on some of the documentation
earlier in the release cycle.
* Real technical documentation teams have technical reviews. This is a
review from a developer (not a n00b developer, but one who really knows
the ins and outs) to verify technical accuracy. Technical reviews don't
take a lot of time. The reviewer doesn't have to revise language usage
or anything like that. They just have to skim the document to make sure
everything is *technically* correct. From every module, I would like to
have a primary developer commit to doing a technical review.
--
Shaun
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]