ubuntu-manual team mailing list archive

[Bryan Behrenshausen <bryan@xxxxxxxxxxxxxxxx>]

I agree with the general consensus that reducing the number of annual
releases will not solve our problems (in fact, like others, I believe
such a move will only exacerbate those problems and introduce others).

Our most pressing problems are infrastructural, as we've previously
discussed.  Barriers to entry are quite high, and we can't quickly
channel the enthusiasm of newcomers into something that produces the
kind of immediate results that keep them interested and invested in
the project.

But on top of this, I'd like to suggest that our difficulties in
releasing this version of the manual also stem from problems with
clearly defined roles and responsibilities.  I was quite pleased to
read Kevin's suggestion regarding a release-manger-in-chief who can
take responsibility for overall coordination.  I also think we need to
more firmly "attach" people with certain skills and experiences to
specific section of the manual so they can plant roots there.  Let me
try to explain this.

I joined the project during the Lucid cycle as an editor (and later
became a "super-editor" during the final editorial push).  When I
joined, I immediately noticed that specific individuals had attached
themselves to certain chapters or sections of the manual and were
working diligently on those sections.  Each chapter had a clearly
identifiable writing staff, as well as at least one editor to oversee
production of that chapter or section.  Consequently, accountability
was easy to assess.  At meetings, we'd "run down" each chapter and
receive a progress report from each section editor, so could update
everyone on the state of each section.  We easily reached our writing
deadlines because each section moved in lockstep with the others.

This cadence seemed almost completely absent during the Maverick
cycle.  People seemed to be dropping into chapters at will,
cherry-picking sections they felt needed work, fixing bugs but not
reporting to any editor (largely because some editors disappeared),
and generally traipsing about the release files without specific
goals.  In the end, some new content got written, some sections were
merged, and some edits took place -- but the entirety of the staff
didn't or couldn't know about the group's collective progress because
no one (chapter, section, chief editors) was keeping their fingers on
the pulse of clearly delineated areas of the manual.

I certainly do not want to suggest that we implement a system whereby
contributors are ONLY allowed to work on certain sections of the
manual and not touch others.  However, I DO think we need to identify
individuals who become go-to representatives of certain sections.
Every manual chapter should have a healthy team of contributing
writers and, ideally, two editors who can coordinate content
production and edit that content as its being written (because editors
can push writers to think about additions/subtractions, revisions,
etc.).  Ideally, these teams would have above-average knowledge of the
contents of the chapters.  Presently, I've been editing the "Advanced
Topics" chapter, which deals with the command line and security
mechanisms.  While I don't mind doing this, I can really only edit the
style/grammar and not much actually CONTENT because these are not
really my areas of expertise in Ubuntu.  I think we need to
collectively recalibrate and reassign jobs and duties, so newcomers
with certain skills and knowledges can easily be channeled into areas
of the project that will fit them -- and show them the results of
their work immediately.