ubuntu-manual team mailing list archive

[Bryan Behrenshausen <bryan@xxxxxxxxxxxxxxxx>]

Hi all,

My email was being wonky today.  Below is a response to this recent
discussion, sent (or attempted) earlier today.  I don't know if it
went out.  (If it didn't -- thank goodness!  I took the time to fix
some embarrassing spelling errors.)

==========

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
onthe 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 themanual
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
editorscan 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 actual 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.