On Tue, Mar 30, 2010 at 12:54 PM, Graham Cobb <[email protected]> wrote: > On Tuesday 30 March 2010 06:47:37 [email protected] wrote: >> There are pretty strict legal regulations, depending on sales location, on >> what kind of documentation has to be available to the person purchasing a >> mobile phone. The legal requirements for netbooks are different, as are for >> in-vehicle systems. So this will require a bit of differentiation depending >> on system type. > > Making it easy for the community to submit changes, fix bugs, improve (or > create) translations and rewrite parts of the documentation is not > incompatible with legal restrictions, just as it is not incompatible with > translation, good editing and, even branding policing.
Just to make sure we have all the options in the table, here's another one. Some projects choose to have a carefully selected group of editors and accept bugfixes/improvements in the form of comments (instead of direct patches or commits). An example is a pre-written documentation which would benefit from external comments. In the following example, the Django folks have written a book and receive feedback from the community, which they later on merge manually. See the small baloon in the left-hand-side: http://djangobook.com/en/2.0/chapter01/ Positives: Immediate feedback/very low learning curve for contributors, control. Negatives: No frequent updates, bottleneck-ed, no *real* community/distributed work. -d > The critical thing is to make it easy for (i) the community to submit > improvements, and (ii) users to have speedy access to those improvements. > There is no reason why those changes should not ubsequently be carefully > reviewed, edited and, possibly, even rejected as part of a release process. > > This is the big advantage of a Wiki-based approach. The commmunity can make > changes and those improvements can be immediately available to users in the > Wiki (which can include a legal disclaimer). The techical author/editor can > review the changes and fix any problems before taking the material and using > it to create formal documentation. Reviews by legal, marketing and other > interested parties can still occur before the formal documentation is > released. > > However, the key thing is that for the process to be effective, the version > the community is working with, and the formal released version, have to be > kept in sync. As legal (and other) reviews happen, the changes have to be > fed back into the version the community uses and is fixing. > > Unfortunately, the tools generally used by technical writers, in my > experience, are not designed for that sort of co-operative development (and, > also, often have high barriers to entry such as training or, worse, > commercial licences). > > Graham > _______________________________________________ > MeeGo-dev mailing list > [email protected] > http://lists.meego.com/listinfo/meego-dev > -- Dimitris Glezos Transifex: The Multilingual Publishing Revolution http://www.transifex.net/ -- http://www.indifex.com/ _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
