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. _______________________________________________ Mailing list: https://launchpad.net/~ubuntu-manual Post to : ubuntu-manual@lists.launchpad.net Unsubscribe : https://launchpad.net/~ubuntu-manual More help : https://help.launchpad.net/ListHelp
