Search · Index

Current topic: What approach should we use to upgrade the documentation?

See Documentation_Project for the current draft of "the plan".

Here are some recent approaches expressed in one form or another for managing the documentation in the context of "the plan":

Approach 0. Why not use docbook, which was the previous way documentation was being handled?

• docbook is open-source.
• A growing community surrounds DocBook (has mailing lists)
• A number of free and commercial tools are available for editing and publishing DocBook documents.
• docbook enables us to publish in a variety of formats.
• XML separates content from presentation: It relieves each contributor of the burden of presentation, freeing each writer to focus on content and sharing knowledge.
• docbook is well tested technology. It has been in development since the early 1990's).

problems: In 2002, Docbook still was not fully capable of representing online books as practiced by book publishers and expected from readers with regards to usability on the web. That meant DocBook did not entirely meet OpenACS publishing requirements at that time.

In 2004, Docbook released version 4.2, which complies with all the OpenACS publishing requirements. Producing a web friendly book hierarchy arguably remains DocBooks' weakest point. For example, a dynamically built document should be able to extract details of a specific reference from a bibliographic (table) and present a footnote at the point where referenced. DocBook 4.2 allows for this with bibliocoverage, bibliorelation, and bibliosource. Yet, OpenACS documentation does not follow a standard book hierarchy since most of the documentation was written before version 4.2, and re-organizing it in docbook source would be challenging.

Other problems with using docbook:

• Only developers can make changes, which makes it difficult for the rest of the community to coordinate changes and updates, especially when they are seeminly small (such as typos).
• OpenACS docbook has long documents, which puts extra stress on using consistent style to separate topics on the same page. For example, readers get confused when trying to follow the installation documents. Some instructions get missed, other instructions are done when they shouldn't have been.
• OpenACS docbook uses multiple tags for the same function and requires only certain tags to be used in certain contexts. The documentation in html is convoluted and displays inconsistent.

Based on the other recent suggestions, there seems to be a general consensus to move away from docbook, but perhaps keep the docbook organization.

Approach 1. from Proposed_project_goals, Robert writes:

- First: ..attempt to take the rest of Documenation over to XoWiki..

- Secondly: ..try to setup an automated versioning system. We should end up with categories such as 5.2 Documentation, 5.3 Documenation, HEAD Documenation, etc. My current thinking is that we can work on HEAD category of documenation, once 5.3 is release it becomes categorized as such and a copy of the docs gets created and recategorized as HEAD once again. This should allow versioning and easy upgrades/editing of docs (well easy may not be the right word, docs are a lot of work)

Robert, "Secondly" is how versioning has been accomplished using docbook.  This method seems to work fine, and we can do it with xowiki docs by creating a set of static pages from the xowiki ones. --Torben

Approach 2. from [ Structure_Ideas ] , Robert writes:

Documenation: [move] ..the rest of the documents to XoWiki. The idea would be to have categorized documents. We would start by moving the 5.2 docs over and expanding on them. When 5.3 is release we would do an automated copy/paste of the 5.2 docs, recategorize as 5.3 and start the editing process. This is just preliminary thinking at this point..

 Robert, everyone seems to have their own way of slicing and dicing docs into categories.  We ought to use the existing documentation requirements to guide how the documents are organized, and then they can be categorized any number of ways since multiple categories can be applied to each page. --Torben

Approach 3 (and previously 5). from Documentation_Project

STAGE A: CONVERT DOCUMENTATION TO XOWIKI (note: all api docs remain the same) Step #1. Catalog the current documentation.

(Malte writes) ..modify the script Gustaf provided to import the whole documentation in one go into a new XoWIKI instance with the structure (page_order) that has been added in XoWIKI 0.42 taken from the chapters of the documentation so that we do have an exact mirror of the documentation as it stands now. [Done, see http://openacs.org/test-doc].

Malte, why would we want an exact mirror of something that is not organized well.. too many topics per page and pages inconsistently presented..  requires a new reader to jump around to get familiarized with material. etc etc?  Why not copy the docbook contents into a cleaner outline and work from there (as in approach 3 above)? --Torben

Torben, the /doc section is organized. That you do not like it is obvious and we could rework it later, but until we have the resource to rewrite the whole documentation, it makes much more sense to improve the documentation we have instead of putting it into the graveyard. And we need to come to terms. This discussion does not yield any results at the moment but keep us from doing the actual work: Improving the documentation -- Malte

[Then] ..assign categories to the documentation, allowing for an alternative view on the documents (so you could say "instead of showing the whole documentation only show the documents for a specific category"). Probably this needs some more detailed discussion with Gustaf finding out how this could be achieved in XoWIKI and what would make most sense. Ideally we could provide a different structure based on the target group (e.g. category) but this is probably shooting too far. Getting categorization and page ordering in a decent shape should provide us a lot of possibilities..

Malte, have you seen docs-admin-toc , docs-end-user-toc and docs-eng?  These are outlines of existing pages in xowiki that represent a revised version of the Table of Contents (TOC) in the docbook version.  Feel free to propose new pages there for us to fill in  content. --Torben

Yes I have seen them. Do they resemble a book in any way to you? They are alternative stuctures, indeed, but you can impose them on a book view as well, any time. A book is what we need, something people can go to and start reading. If the book starts with four different pages, each outlining a different reading path, even the better. But a book it should be nevertheless, because this is how people still learn. If you do not like the book approach, that is fine, then we should open this question up for a TIP. My main goal at the moment is to finally get this done and start working. And I want to get rid of the myriads of confusing advise given at openacs.org. I have someone to work with me on that in the next two months and I want to have a clear way to go forward. So I will just TIP this. -- Malte
 

 

Approach 4 from Documentation_Project.

..port docbook pages to xowiki manually.. look at each part in detail.. separate to subsystems and how they are used (context). Why? "..the human mind can only deal with a relatively small number of independent pieces of data at one time, but if data are chunked together in appropriate ways, the mind can perform higher order abstractions, and these in turn can be chunked together, with successive abstractions, until an entire complex situation is encompassed. The systems approach addresses this property of the human mind by providing strategies for the data gathering, chunking, and abstracting process." George G. Lendaris, On Systemness and the Problem Solver: Tutorial comments 1983.

This work is in progress, with main page here: openacs-handbook

A systems strategy of multiple perspectives has these simple rules:

• Each xowiki page discusses a single topic.
• Topics are linked together by any number of other xowiki pages to present an ordered presentation of the topics with a common thread/topic connecting them. For example, openacs-system-install is a page that links together the topics of installing the component software of Openacs. Similarly, each component software, such as aolserver, has its own view of some overlapping topics.

multiple perspectives meets these significant documentation requirements:

• helps identify subsystems and how OpenACS works --becomes a natural tutorial without more words.
• reduces the burden of keeping documentation up to date since there is only one place to put relevant information for a particular topic --no redundancy
• pages are not organized by a dominant category morphology that tends to address the perspectives of just a few people. Most any perspective can be represented.
• Readers do not have to filter out a bunch of information that is irrelevant to them or their task at hand.

Move all but maybe the first and last 2 items from http://openacs.org/doc/dev-guide.html to http://openacs.org/doc/acs-kernel/ (and what ever else is relevent to kernel only); and move the first item to http://openacs.org/doc/acs-admin etc. That way the core docs are presented in a consistent context with the other packages. Also, do not migrate these docs around as a package is designated part of the core (or subsequently removed from it). This would help developers see appropriate context (and meets one of the documentation requirements).

Allow documentation to link directly to the api-docs, to reduce redundancy and links go to current, local API docs. In other words, http://openacs.org/api-doc/package-view?version_id=358136 becomes: /api-doc/index?about_package_key=acs-datetime The feature has been added to OpenACS 5.3 so will be released soon.[DONE]

Move Administrator's Guide to the xowiki [in progress, see docs-admin and docs-admin-toc ], because this section:

• has the most duplicated work (topics overlap on various pages). For example, more than one page explains how to add a package, how to restart the server, how to start the server etc.
• needs to be updated most frequently because of changing installation requirements. For example, PostgreSQL requires different instructions for different revisions, external links change sporatically etc.

Incorporate the work already done in the first wiki ( http://openacs.org/wiki ), where volunteers have already added a wealth of new documentation. Note that some of this will already exist in xowiki from previous importing of docs etc. [TO DO]

We need to get rid of the myriads of different installation instructions. First of all they are not kept up to date (all of them). -- Malte 

---

References to this Page: en:Documentation_Project, en:Documentation_Project_Plan
Categories: Documentation (OpenACS.org), OpenACS Projects (OpenACS.org)

Comments

Add a comment