
Quite some time ago, Dave Abrahams announced that I was the new Boost Documentation Wizard. I said I'd write something on the subject and that is long overdue. Herewith, I describe what I think the DocWiz should do and what is needed from volunteers to make it happen. That is, I'm trying to document the new DocWiz role and solicit your help. Please have a look and comment on what I'm proposing. If you don't like the direction I'm planning, say so. If you think I've missed something, let me know. If you think you can help in some way, please let me know; I can't do the job alone. The DocWiz's purpose is to try to foster better documentation for Boost. Since this is something new at Boost, some measures will be grandfathered* of necessity, while others will likely be retrofitted to existing documentation. Some things will be purely stylistic, but most will be substantive. A significant problem with writing library documentation is that English is often not the library author's primary language.* It is all too common that those who can write C++ fluently cannot write English well. Thus, we need a means to ensure that the library author's ideas are well communicated. Another problem with writing library documentation is knowing what to write. How much detail is sufficient? How many code examples should there be? How much material should be relegated to a reference section and how much should be presented in a tutorial? What is a sufficient rationale for the library? Many of these issues can be addressed by seeking insight from what has been written well already and by seeking advice from those expert on the tasks. From that information we can capture best practices to assist new documentation authors. Still another problem is consistency. As Boost grows, having a reasonably consistent look and feel to our documentation becomes increasingly important. Naming and organizing sections in our documentation must be consistent across libraries to simplify locating desired information in each library. Given the rate at which new libraries are proposed, I cannot do this task alone. I'm the father of eight (yes, 8!) children (so far, at least), I have a full time job, etc. Like everyone else, I'm quite busy. Thus, I need help. I intend to be the manager of a group of folks who can divide the workload to make it manageable. To that end, I propose the following positions to assist in improving the state of Boost documentation: Editors - Folks with demonstrably good English skills who can assist library authors by clarifying and correcting the documentation at various times, as determined by the author, so the meaning is clear. Editors also advice the author on structural changes necessary to conform to Boost guidelines. Editors are not so much concerned with content as with clear communication of what is included. Domain Experts*** - Folks with special skills in writing certain types of documentation such as concepts or tutorials; when a library author is struggling to write a portion of the library's documentation, the author can call upon the appropriate domain expert for assistance. Mentors - Folks with skills and desire to write good documentation who can come alongside a new library author to ghost write, share writing tasks, suggest content, etc. The output from author/mentor collaboration must still be approved by an editor. The workload of an editor will be varied since the number of authors writing documentation varies and based upon their update schedules. The workload of a domain expert should be quite low as folks writing concept descriptions, for example, should not need a domain expert's input often or long. The workload of a mentor likely will be as high as the mentor wishes. Initially, anyone acting as an editor will need to prove his/her skills by relying on trusted editors to proof the results. Once proven, a new editor can act autonomously. The expected result of this group of folks is documentation that is acceptable to Boost. I propose that a library cannot be fully accepted by Boost without the DocWiz's approval. IOW, a library can be conditionally accepted pending documentation approval. (That approval may be given based solely upon the word of a trusted editor; the DocWiz needn't read every document to give approval, but the responsibility does lie with the DocWiz for deficient approved documentation.) Note that the DocWiz is not the final authority on what is acceptable documentation. Users of that documentation are. An author will likely need to update documentation based upon user experience. Such changes should be subject to an editorial review, too, in order to maintain high standards. -------- * That means that existing documentation needn't be changed to conform to new policies, but may be if the author chooses. ** Another problem is that English *is* the library author's primary language. :) *** The name "domain expert" smacks too much of someone who is expert in the domain of the library rather than of a particular aspect of library documentation. Please suggest a better name. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;

| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Rob Stewart | Sent: 27 October 2005 23:21 | To: boost@lists.boost.org | Subject: [boost] Documentation Wizard | | Quite some time ago, Dave Abrahams announced that I was the new | Boost Documentation Wizard. I said I'd write something on the | subject and that is long overdue. Herewith, I describe what I | think the DocWiz should do and what is needed from volunteers to | make it happen. That is, I'm trying to document the new DocWiz | role and solicit your help. My first impression is that this is a bit over-bureaucratic. You obviously need this sort of style managing 8 offspring ;-) , but Boosters are all volunteers and we have to be greatful for all the help we can get. Authors are severely handicapped when writing documentation by knowing too much. And they are often exhausted by the process of getting the code to work on the myriad of inconsistent platforms and versions. So _any_ documentation editing is likely to be an improvement. So I think you should just ask for someone (usually only one - we don't have _common_ tools for handling versioning and changes well) willing to contribute to editing each library. The code author and the editor will have to try to agree: only if they are uncertain should theygo out to the wider Boost audience. Since I have the advantage of having English as my first language (and not the corrupted version of those renegage ex-colonials ;-), and I have enough knowledge of other languages to greatly admire those whose first language is not English struggling with the erudite esoteric elite Boost discussions, I may offer to edit some documentation. HTH Paul PS And I've read Eats, Shoots and Leaves. -- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB Phone and SMS text +44 1539 561830, Mobile and SMS text +44 7714 330204 mailto: pbristow@hetp.u-net.com www.hetp.u-net.com

Rob Stewart <stewart@sig.com> writes:
Given the rate at which new libraries are proposed, I cannot do this task alone. I'm the father of eight (yes, 8!) children (so far, at least), I have a full time job, etc. Like everyone else, I'm quite busy. Thus, I need help. I intend to be the manager of a group of folks who can divide the workload to make it manageable. To that end, I propose the following positions to assist in improving the state of Boost documentation:
Editors - Folks with demonstrably good English skills who can assist library authors by clarifying and correcting the documentation at various times, as determined by the author, so the meaning is clear. Editors also advice the author on structural changes necessary to conform to Boost guidelines. Editors are not so much concerned with content as with clear communication of what is included.
Domain Experts*** - Folks with special skills in writing certain types of documentation such as concepts or tutorials; when a library author is struggling to write a portion of the library's documentation, the author can call upon the appropriate domain expert for assistance.
Mentors - Folks with skills and desire to write good documentation who can come alongside a new library author to ghost write, share writing tasks, suggest content, etc. The output from author/mentor collaboration must still be approved by an editor.
Rob, I like the direction you're going in but I think your plan may be a bit too elaborate to manage. I suggest that you start with something more lightweight --- like a group of trusted volunteer editors and no further classification --- and start handing out jobs as necessary. I think you'll quickly discover the different kinds of roles that people need to play. In other words, I suggest that you let the structure of this effort evolve more organically. It will surely reveal itself as you go along. And --- though I really don't have time --- I volunteer to help anyway :) -- Dave Abrahams Boost Consulting www.boost-consulting.com

Do the responsibilities of this group only involve editing, or is this also to help authors with the technical aspects of writing docs?
From my experience, the Boost-recommended way of writing documentation (quickbook) is far from trivial. Too much time is spent trying to properly set it up -- too many tools are involved. It would be _extremely_ nice if somebody could collect all the necessary pieces of information, related to bjam, Boost.Build, quickbook, Boost.Book, Docbook, etc., and put it all together in one document, something like "Writing the Boost documentation for Dummiest".
No, I am not volonteering :) Regards, Arkadiy

Arkadiy Vertleyb wrote:
Do the responsibilities of this group only involve editing, or is this also to help authors with the technical aspects of writing docs?
From my experience, the Boost-recommended way of writing documentation (quickbook) is far from trivial. Too much time is spent trying to properly set it up -- too many tools are involved. It would be _extremely_ nice if somebody could collect all the necessary pieces of information, related to bjam, Boost.Build, quickbook, Boost.Book, Docbook, etc., and put it all together in one document, something like "Writing the Boost documentation for Dummiest".
I always clamored for a tool that one can use straight out of the box. Rene Rivera started an installer for quickbook. It would be awesome if someone can pick up on it and package it with something like Arkadiy is suggesting.
No, I am not volonteering :)
No, I can't volunteer here too. I'm already swamped. I'd be very willing to help anyone who's willing. Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net

Rob Stewart wrote:
*** The name "domain expert" smacks too much of someone who is expert in the domain of the library rather than of a particular aspect of library documentation. Please suggest a better name.
Along this line it would seem that "Documentation Manager" might be more consistent with other boost titles - "Review Manager" and "Release Manager" than DocWiz I think that much could be gained by expanding upon William Kemps original document. http://www.boost.org/more/writingdoc/index.html Having personally tried to use it, I found it helpful - up to a point. I think its in the right direction but its not detailed or complete enough. We need better examples so we can "boiler plate" different situations. (e.g. simple class usage, template usage, override/hiding of functions, etc. Also this document doesn't make any mention of a tutorial. The thread documentation seems to be in line with the above document document. And it shows the value of what's been done so far along with its short comings. Having this page(s) enhanced to the point that it could more easily be used as a model would go along way toward making boost documentation more consistent accross libraries. Robert Ramey

"Robert Ramey" <ramey@rrsd.com> writes:
Rob Stewart wrote:
*** The name "domain expert" smacks too much of someone who is expert in the domain of the library rather than of a particular aspect of library documentation. Please suggest a better name.
Along this line it would seem that "Documentation Manager" might be more consistent with other boost titles - "Review Manager" and "Release Manager" than DocWiz
Those are transient positions. For long-term positions we have "wizards" (c.f. the Review Wizard, Tom Brinkman) -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (6)
-
Arkadiy Vertleyb
-
David Abrahams
-
Joel de Guzman
-
Paul A Bristow
-
Rob Stewart
-
Robert Ramey