DPN workflow (Re: Debian Project News 2012/07 frozen. Please review and translate.)
On 2012-03-30 19:59, Francesca Ciceri wrote:
[TL;DR: frozen means frozen. we'll not accept major changes not
grammar/spelling/style related. if you want to join the fantastic process
of draft DPN, do it *before* the freeze. Thanks for understanding.]
we just finished the latest bits of the Debian Project News to be sent on
We'd really appreciate reviews and translations.
Here's the link:
Please note that according to our current workflow we'll not accept major
changes in the content, if not related to grammar/spelling/style issues.
This is due to the fact that last minute changes on the content are
really problematic for translators: the right moment to propose changes different
from minor grammar/spelling/style fixes is *before* the freeze.
I don't read the current workflow as requiring an extraordinary freeze.
The freeze has traditionally been a classic freeze on new content. We
currently just have one freeze, so although it would be good to fix the
content before starting the translations, we can't make our freeze
You contrast major content changes with localization changes. What about
non-major content changes?
This means also that if you want to contribute writing an article, or
reviewing one (proposing a different approach to an argument, or a different way of
talking about something, etc) you just need to pick up a todo item (in
the index.wml file at publicity/dpn/en/current/ ) and write the related
article *before* the call for reviews.
Please respect this workflow: we don't like to waste your contributions
and ideas but we also can't make translator's life too hard :).
If you think that the quality of text we submit to review need to be
improved, feel free to join us in the drafting process. You can reach us
on #debian-publicity at irc.debian.org or via this mailing list.
A last note: regular contributors and DDs are welcome to directly submit
their changes on the repository, if are l10n-english related (or other
minor issues as for instance fixing a wrong url or a tag).
Content-related changes will be discussed in ML.
The preferred form of proposing changes is sending a patch.
We can occasionally accept changes not in form of patches, but please,
don't abuse of that.
I'd rather have a contributor directly apply a change, unless he's unsure.
If a contributor is unsure, it would be most important to explain what
problem it addresses as well as why the change may be undesirable. A
patch is of course a bonus.
If proposing a change not in the form of a patch can constitute abuse,
it would be more efficient to prevent that by explaining which such
proposals constitute abuse than to just ask not to send such proposals...
Thank you very much for contributing and understanding,
Thanks to you for this detailed request. Changes or clarifications to
the workflow will surely help optimize our work and improve the result.