Search · Index

Documentation Project Plan

The managing of OpenACS documentation has evolved through a few phases. This is a draft plan for the current phase that we are beginning. Please direct any comments about this plan to the OpenACS Development forum (or in context with the appropriate wiki page ;)


See en:doc-history


to write superb documentation, so that users, developers and administrators of OpenACS installations can enjoy working with and using the system (with fewer headaches! =)


API Documentation: there are no plans to move the API docs to XoWiki. That ought to remain as is.

DocBook docs at: need significant work done.


Requirements is about setting specifications and milestones we can verify, and includes exploration of scenarios, use cases etc.

Here are documentation requirements for:

Available resources

  • volunteers dedicated to regularly managing and updating the documentation
  • other volunteers who contribute arguably more valuable documentation less frequently (such as magazine articles ;) (and may need some assistance etc. to have their work fit into docs well.)
  • website, including use of xowiki
  • open-source software, text editors, spell checkers, html code validators etc.

Approaches in docs management explored

See en:Documentation_Project_Discussion


Strategy is about creating an approach to doing work. It guides behavior and tactical decisions on the work effort.

Shape ongoing documentation efforts by using principles of continual improvement to re-engineer documentation production and management.

OpenACS documentation development is subject to the constraints of the software project development and release methods and cycles (the section called “Using CVS with OpenACS”). Essentially, all phases of work may be active to accommodate the asynchronous nature of multiple subprojects evolving by the efforts of a global base of participants with culturally diverse time references and scheduling idiosyncrasies.

The documentation strategy is to use project methods to involve others by collaborating or obtaining guidance or feedback (peer review) to distribute the workload and increase the overall value of output for the OpenACS project.

Work Breakdown Structure

Is about explicitly stating the way to implement the strategy as a set of milestones and the methods to use.

Status: this is a draft document, so there is no consensus on a WBS at this time. See en:Documentation_Project_Discussion for current activity.


This is where we measure how well this plan was implemented. Success is measured by A) verifying if the project has met the established goals and requirements, and B) reviewing for ongoing problem areas etc. Observations then help to modify the plan for the next documentation revision.

OpenACS follows verification through different means on different projects, but in all cases, the OpenACS community verifies the project as a success through feedback including bug reports, user and administrator comments, and code changes.

Related links and sources

Previous Month March 2017
Sun Mon Tue Wed Thu Fri Sat
26 27 28 1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 (1) 20 21 22 23 24 25
(1) 26 27 28 29 30 31 1

Popular tags

17 , 5.9.0 , 5.9.1 , ad_form , ADP , ajax , aolserver , asynchronous , bgdelivery , bootstrap , bugtracker , CentOS , COMET , CSP , CSRF , cvs , debian , emacs , fedora , FreeBSD , hstore , includelets , install , installation , installers , install-ns , javascript , libthread , linux , monitoring
No registered users in community xowiki
in last 30 minutes