On Tuesday 30 March 2010 11:00:56 Dimitris Glezos wrote: > 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.
That is certainly another way of working. I don't think it scales very well to large numbers of users. I think it works well for docs where most comments are expected from a small number of active reviewers, and where the writers tend to remain with the document. I don't think it works so well for docs where there are a large number of users, referring to the docs all the time, and highly motivated to fix bugs. It works particularly badly where writers get reassigned to other docs for long periods and may not revisit the document except once a year for a release. I have certainly noticed that I refer to Maemo documentation all the time I am doing Maemo develment (as opposed to, for example, Tcl documentation, where I refer to the docs quite rarely even though I do develop in Tcl). Of course, this is because of the large breadth of the Maemo documentation (lots of subsystems, lots of APIs) but I have also noticed that it means I am much more likely to submit a fix or improvement for the Maemo docs, partly to help others and partly because I think I might refer to the document again myself! For these motivations it is important that my change becomes visible quickly, not just when the document is being prepared for the next release. Of course, there is no reasons why both mechanisms cannot be combined: allowing active community improvement while also accepting offline comments for inclusion by the main writer. Graham _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
