Created by OpenACS community, last modified by Gustaf Neumann 01 May 2015, at 09:43 AMTo try OpenACS, you might lease a hosted system with OpenACS installed on it:
Created by OpenACS community, last modified by Gustaf Neumann 01 May 2015, at 09:43 AMTo try OpenACS, you might lease a hosted system with OpenACS installed on it:
Created by OpenACS community, last modified by Benjamin Brink 09 Sep 2013, at 07:44 PM
Through a modular architecture, OpenACS has packages for user/groups management, content management, e-commerce, news, FAQs, calendar, forums, bug tracking, wiki (XoWiki ), full-text searching etc. See OpenACS repository.
Testimonials posted to forums on OpenACS
See: History of OpenACS en:docs-history
See: Documentation Credits en:doc-credits
Created by OpenACS community, last modified by Gustaf Neumann 12 Mar 2011, at 11:40 PM
See also: OpenACS Mentorship Program
LPI certification exam preps - A series of articles from IBM developerworks on basic and intermediate Linux skills (requires registration)
UNIX Power Tools - An excellent introduction to the command line tools and basic programs of UNIX
UNIX System Administration Handbook (formerly the "red book" - now the "purple" book)
UNIX System Administrator's Bible - (LePage and Iarerra 1998; IDG)
Created by OpenACS community, last modified by Torben Brosten 22 Aug 2008, at 08:37 AM
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 ;)
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: http://openacs.org/doc/index.html 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:
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.
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.
Created by OpenACS community, last modified by Torben Brosten 22 Aug 2008, at 08:32 AM
Besides the quality components of Openacs (See: en:openacs-system), OpenACS has these enterprise-quality features for developers:
will be pulling in docs from here: http://openacs.org/doc/acs-package-dev.html and http://openacs.org/doc/acs-plat-dev.html
These text editors are commonly used when coding on OpenACS:
Created by OpenACS community, last modified by Torben Brosten 22 Aug 2008, at 08:29 AM
will be pulling in docs from here: http://openacs.org/doc/acs-admin.htmlGetting help: en:docs-admin-help
Install OpenACS: en:docs-install
set up database environment variables.. see end of http://openacs.org/doc/openacs.html
http://openacs.org/doc/backup-recovery.html and http://openacs.org/doc/snapshot-backup.html
creating custom pages: see developer tutorials ( http://openacs.org/doc/tutorial.html )
Also, these OpenACS packages are your friends:
Created by OpenACS community, last modified by Malte Sussdorff 26 Jun 2007, at 09:32 AM
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":
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:
Based on the other recent suggestions, there seems to be a general consensus to move away from docbook, but perhaps keep the docbook organization.
- 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
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
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
..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: en:openacs-handbook
A systems strategy of multiple perspectives has these simple rules:
multiple perspectives meets these significant documentation requirements:
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 en:docs-admin and en:docs-admin-toc ], because this section:
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
Created by OpenACS community, last modified by Torben Brosten 18 Mar 2007, at 09:38 AM
Bibliography: Where did this document come from?
This document is really just plagiarism from a number of documents that came before it. If something is used without proper credit, let us know so we can fix it right away.
The short bibliography:
Acknowledgments for versions of the above documents go (in no particular order) to Bryan Quinn, Adam Farkas, Brian Stein, Doug Hoffman, Ravi Jasuja, Hiro Iwashima, Ryan Lee, Jonathan Goler, Audrey Mcloghlin, Doug Harris, Zvi Boshernitzan, Michael Yoon, Cesar Brea, Dennis Gregorovic, David Fullagar, Chris Spears, Kevin Tupper, Michael Duffy, Simon Carstensen, Dave Bauer, Tracy Adams, Greg Haverkamp, Philip Greenspun, Jin Choi, Sean Yamamoto, David Cohen, Chris Rasch, Richard Li, Jon Griffin, Roberto Mello, Gilbert Wong, Don Baccus, Ben Adida, Michael Cleverly, Janne Blonqvist, Jonathan Ellis, Janine Sisk, Jade Rubick, Chris Hardy, Jonathan Marsden, Vinod Kurup, Charles Hall, Tom Jackson and Karl Lehenbauer.
Others who have contributed to this document: Robert Taylor, Ryan Gallimore, Gustaf Neumann, Torben Brosten, Don Baccus, Roberto Mello, Talli Somekh, Dave Bauer, Jim Lynch, Jon Griffin, Daryl Biberdorf, Bjorn Thor Jonsson, Jade Rubick, Fred Yankowski, Dan Chak, Sebastiano Pilla, Reuven Lerner, Malte Sussdorff, Stan Kaufman, Pascal Scheffers and Rocael Hernández.
Contributers to xowiki documents, including this one: en:contributors
Finally, much appreciation and thanks goes to the OpenACS community, who have provided much valuable feedback in the fora, which compromises the goals of this documentation.
Created by OpenACS community, last modified by Torben Brosten 22 Jan 2007, at 06:19 AM
Documentation Credits doc-credits
Documentation Project Documentation_Project
Created by OpenACS community, last modified by Torben Brosten 15 Jan 2007, at 01:37 AM
Created by OpenACS community, last modified by Torben Brosten 15 Jan 2007, at 01:36 AM
Created by OpenACS community, last modified by Torben Brosten 15 Jan 2007, at 01:35 AM
Created by Carl Robert Blesius, last modified by Torben Brosten 12 Jan 2007, at 01:51 PM
This page has been deprecated. See en:Documentation_Project
This WikiDoc Replaces:
Created by OpenACS community, last modified by Torben Brosten 09 Jan 2007, at 10:00 AM
The history of OpenACS documentation: ..began by building on a good documentation base from ArsDigita's ACS in the late 1990's. The ACS documentation was largely written in docbook. Some sections of the documentation, however, lacked details and examples; others simply did not exist. The OpenACS community began meeting the challenge by identifying needs and writing documentation on an as needed basis.
By having documentation dependent on volunteers and code developers, documentation updates lagged behind the evolving system software. As significant development changes were made to the system, existing documentation became dated, and its value significantly reduced. The valiant efforts that were made to keep the documentation current proved too difficult as changes to the system sometimes had far-reaching affects to pages throughout the documentation. System integration and optimization quickly rendered documentation obsolete for developers. The code became the substitute and source for documentation.
There are many thousands of lines of code, and few developers tracking changes and publishing the changes. Subsequently features and advances to the OpenACS system went unnoticed or were not well understood except by the code authors. Work was duplicated as a consequence of developers not realizing the significant work completed by others. New developers had to learn the system through experience with working with it and discussion in the forums. Informal sharing of experiential and tacit knowledge has become the OpenACS community's main method of sharing knowledge.
Created by Robert Taylor, last modified by Torben Brosten 25 Oct 2006, at 08:37 AM
The OpenACS Documentation is to be organized as follows:
- Core Documentation ( 1:1 direct copy of what exists )
- Package Documentation ( 1:1 direct copy of what exists )
- Subsystems Documentation ( systems multiple-perspectives view )