ubuntu-manual team mailing list archive

[Ilya Haykinson <haykinson@xxxxxxxxx>]

>
> So in conclusion, i don't think we should release less often, we should
> just work to improve our workflow and the workflow of new contributors
> whether they be authors, editors or translators. Also i do remember that
> Ilya was around a lot during the lucid cycle sort of being an editor in
> chief, but since then we haven't had anyone doing that.
>
>
I've been keeping up with the mailing list traffic, but have been very busy
at work for the last 5 months or so -- so much so that I couldn't really
contribute to the Maverick release. I completely agree that the main thing
that is required is some small group of people who serve as the editors and
drive the process along -- making decisions on where to cut and where to
focus, etc. Obviously I couldn't spare the time for the Maverick cycle, and
am not yet sure how the Natty cycle will look for me (the first couple of
months are going to be tough for sure).

However, I think it's critical to release every 6 months, even if the
quality isn't great. Only through frequent releases combined with small
improvements can the end product end up great -- if you take 2 years to do a
release, I think the team will fall apart.

My recommendations are (some are the same as what others have recommended):

 - manage translations separately, and do not release the manual to
translators until after the manual is ready to go. this will yield a
smoother translator experience as the content won't be changing from under
them, and will simplify the manual itself.
 - delay the manual publishing date for 3-5 weeks after each release, to
allow content and screenshots to catch up
 - by beta1, have a firm list of changes to be included in the manual; a
week after release date, cut anything that hasn't been written or is
possible to get to the highest quality.
 - work to improve the process. I think this is the least important item,
honestly, since core contributors will always be ok with downloading TeX and
dealing with compilation etc, and while it's key for long-term project
health to bring in casual contributors, I think that a) this is a
stand-alone process that shouldn't be mixed into shipping the manual itself,
and b) the manual comes first, well before automation or better processes.

Thoughts?

-ilya