Marketing Materials Home

Created by Ryan Gallimore, last modified by Michael Aram 25 Nov 2016, at 01:30 PM

Please find here marketing materials to help you sell OpenACS.

• Sample Proposal
• Comparison between OpenACS and LAMP online communities
• Writing Content that Works for a Living

Documentation for everyone ( docs-end-user ) includes a marketing slant. These docs follow Marketing documentation requirements

End-users - Requirements

Created by Torben Brosten, last modified by Michael Aram 25 Nov 2016, at 12:08 PM

Documentation Requirements for End-users

By the OpenACS Community. This section is a collection of documentation requirements that have been expressed in the OpenACS forums to 4th July 2003.

OpenACS end-user documentation should meet the following requirements. No significance has been given to the order presented, topic breadth or depth here.

• End-users should not have to read docs to use the system.

• Include how to get help. How and where to find answers, contact others, what to do if one gets an AOLserver or other error when using the system. Include types of available support (open-source, private commercial etc.) including references.

• Explain/foster understanding of the overall structure of the system. This would be an overview of the system components, how it works, and how to find out more or dig deeper... To promote the system by presenting the history of the system, and writing about some tacit knowledge re: OpenACS.org and the opensource culture.

• Introduce and inspire readers about the uses, benefits, and the possibilities this system brings (think customer solution, customer cost, convenience, value). A comprehensive community communications system; How this system is valuable to users; Reasons others use OpenACS (with quotes in their own words) "...the most important thing that the ACS does is manage users, i.e. provide a way to group, view and manipulate members of the web community. -- Talli Somekh, September 19, 2001" using it to communicate, cooperate, collaborate... OpenACS offers directed content functionality with the OpenACS templating system. ... OpenACS is more than a data collection and presentation tool. OpenACS has management facilities that are absent in other portals. ...The beauty of OpenACS is the simplicity (and scalability) of the platform on which it is built and the library of tried and tested community building tools that are waiting to be added. It seems that most portals just add another layer of complexity to the cake. See Slides on OACS features...a set of slides on OACS features that can be used for beginners who want to know OACS is about and what they can do with it. Screen captures that highlight features. Example shows BBoard, calendar, news, file storage, wimpy point, ticket tracking. An OpenACS tour; an abbreviated, interactive set of demo pages.

• From a marketing perspective,

  • differentiate "product" by highlighting features, performance quality, conformance to standards, durability (handling of technological obsolescence), reliability, repairability, style of use, design (strategy in design, specifications, integrated, well-matched systems etc).

  • differentiate "service" by highlighting software availability (licensing and completeness from mature to early adopters or development versions), community incident support, project collaborative opportunities, and contractor support availability

  • differentiate price (economic considerations of opensource and features)

  • Discussion and details should rely on meeting criteria of design, completeness of implementation, and related system strengths and weaknesses. Marketing should not rely on comparing to other technologies. Competitive analysis involves mapping out strengths, weaknesses, opportunities and threats when compared to other systems for a specific purpose, and thus is inappropriate (and becomes stale quickly) for general documentation.

  • When identifying subsystems, such as tcl, include links to their marketing material if available.

  • create an example/template comparison table that shows versions of OpenACS and other systems (commonly competing against OpenACS) versus a summary feature list and how well each meets the feature criteria. Each system should be marked with a date to indicate time information was gathered, since information is likely volatile.

   

• To build awareness about OpenACS, consider product differentiation: form, features, performance quality, conformance quality (to standards and requirements), durability, reliability, repairability, style, design: the deliberate planning of these product attributes.

• Include jargon definitions, glossary, FAQs, site map/index, including where to find Instructions for using the packages. FAQ should refer like answers to the same place for consistency, brevity and maintainability.

• Explain/tutorial on how the UI works (links do more than go to places, they are active), Page flow, descriptions of form elements; browser/interface strengths and limitations (cookies, other)

• Discuss criteria used to decide which features are important, and the quality of the implementation from a users perspective. Each project implementation places a different emphasis on the various criteria, which is why providing a framework to help decide is probably more useful than an actual comparison.

Package documentation requirements have additional requirements.

• A list of all packages, their names, their purposes, what they can and cannot do (strengths, limitations), what differentiates them from similar packages, minimal description, current version, implementation status, author/maintainers, link(s) to more info. Current version available at the repository.

• Include dependencies/requirements, known conflicts, and comments from the real world edited into a longer description to quickly learn if a package is appropriate for specific projects.

• Create a long bulleted list of features. Feature list should go deeper than high-level feature lists and look at the quality of the implementations (from the user's perspective, not the programmer's). Example issues an end-user may have questions about: Ticket Tracker and Ticket Tracker Lite, why would I want one of them vs the other? And, before I specify to download and install it, what credit card gateways are supported by the current e-commerce module? There are some packages where the name is clear enough, but what are the limitations of the standard package?

• End-user docs should not be duplicative. The package description information and almost everything about a package for administrators and developers is already described in the package itself through two basic development document templates: a Requirements Template and Detailed Design Document.

dotLRN Roadmap

Created by Gustaf Neumann, last modified by Gustaf Neumann 15 Nov 2016, at 01:11 AM

Current Version: .LRN 2.9.0

• .LRN 2.5.0:
  • Full accessibility
  • validated HTML for all packaged .LRN packages
• .LRN 2.9.0:
  • Improved flexibility on package and installation management
  • Ability to install .LRN from existing OpenACS installations and via "install from repository"
  • thus no need to have only pre-packaged installations
  • Removed calls to deprecated code
• .LRN 2.9.1:
  • Improved security: Content Security Policy (CSP) support
  • Improved theme-ability including theme switching (Bootstrap  theme in preparation)
  • Improved stability (various fixes in application packages)

Old Roadmap

.LRN Governance

Created by Caroline Meeks, last modified by Gustaf Neumann 07 Nov 2016, at 07:52 PM

Definitions

.LRN Consortium  – A nonprofit corporation incorporated in Massachusetts

.LRN Organizational Member  – An organization that has paid its yearly membership fee of $250 (or more).

.LRN Voting Member  – The individual designated by a .LRN Organizational Member to vote on its behalf.

.LRN Board  – A member of the 7 person board of directors that is elected by the .LRN Voting Members.

.LRN Chairman  – The chairman is a member of the .LRN board elected to chair the board by the .LRN board.

.LRN Leadership Team  – A group of people decided on by the .LRN Board and Leadership Team. .LRN Leadership Team members do not have to be voting .LRN members. 

.LRN Decision  – A decision that has gone through the decision making process described below

*******DRAFT**********DRAFT**********DRAFT***********DRAFT********

Please note that the decision making process is being modified as of July 8, 2007  

The Decision Making Process

Goals

• Make it easy for motivated people to make decisions and implement them with minimal overhead.
• Give the elected .LRN Board oversight over .LRN decisions without requiring too much of the Board's time. 
• Give the appointed (in the future - elected?) Leadership Team (authority || permission) to move forward on technical decisions if the Board can not give input.

Informal description of the process

If you have an idea you'd like to implement, discuss it with people who care, post in OpenACS and/or talk about it in a .LRN meeting as appropriate. After you have listened, post your suggestion to the .LRN Decision board. Then implement it.  Mostly we all want the same things and we need action.  The .LRN Board vote is available as an oversight and in those hopefully infrequent times when there is significant dissent.
 

Formal Process

1. All members of the .LRN Board and Leadership Team subscribe to the .LRN Decision Forum.
2. The Leadership Team is the governing body primarily responsible for technical decisions with respect to .LRN. The Leadership Team has been appointed carefully by the Board hence there is implied trust by the Board in the Leadership Team. (NOTE: I am not sure how this would change if the Leadership Team changes to be elected.) 
3. There is no formal process for small technical decisions. The Leadership Team will keep discussions as open as possible via open meetings where anyone is free to attend. Ideally, most technical decisions will be made at the weekly Leadership Team Meetings (currently Tuesdays at 16GMT on #openacs at irc.freenode.net), but some informal discussions may take place via the Leadership Team mailing list (honchos at dotlrn.org) in order to be more efficient.
4. Members of the .LRN Board and Leadership Team are jointly responsible for making large technical and non-technical decisions with respect to .LRN.
5. There is a formal process for large technical and non-technical decisions. What constitutes a large technical decision is determined by the Board and the Leadership Team.  (NOTE1: Though most decisions for .LRN may be technical, I feel .LRN is much more than just a technical framework and will encounter non-technical issues/decisions; NOTE2: I consider a large technical decision to be something along the lines of: "Are we going to do the Zen Project?")
6. For all large decisions and all non-technical decisions, a new thread is started in the .LRN Decision Forum.  The first posting will contain the issue up for decision and the possible solutions on which the Board and Leadership Team members can vote. Once the thread is posted, voters have  (48 hours || 72 hours || 7 days) to vote.  A simple majority (51%) based on the members attending the vote will decide the decision up for vote. The Board and the Leadership Team members receive 1 vote each. In case of a tie, the present Board Members + (1 || 2) member(s) of the Leadership Team (which members are to be decided by the Leadership Team) will have a revote. Again a simple majority, will decide the vote. (NOTE: I don't know wtf to do if there is a tie after the revote.) (DAVEB: What is the motivation to make the votes scheduled and held in IRC, as opposed to a longer voting period on the forums. I think it would be easier to get participation from more members of the board and leadership team with a voting period on the forums. Since these are "large" decisions a few days of voting should not cause a signifigant delay.)(AVNI: Dave - that makes sense. Changed 17 july 07. :-) )
7. If a member of the Board or the Leadership Team disagrees strongly with a small or large technical or non-technical decision made, s/he may post his disagreement (the reason for the disagreement must be made clear in the forum posting) on the .LRN Decision Forum. If (2 || 3 || 4) other Board or Leadership Team members in distinct locations (distinct university, company, country, etc) agree with the dissenting member and post as such with their own reasons for dissenting in the same thread, the decision is overturned.  Other Leadership Team and Board Members along with community members may post on this thread also to inform the Team and the  Board about their views.

---- Have cut the six below out for now. Feel free to add back in: ----------------------------------------------

1. Members of the .LRN Board and Leadership Team are jointly responsible for making decisions. All people are expected to discuss and reach an appropriate level of consensus on issues. 
2. When an individual believes he has done an appropriate level of communication and consensus building on a decision he posts it to the .LRN Decision Forum 
3. If no one objects or calls for a vote the decision is confirmed in 2 weeks.
4. If people agree they need take no action; however if there is disagreement or concern, any member of the Board or Leadership Team may “Call for a Vote” on any decision posted to the decision forum within 2 weeks of the post.
5. If a decision is called for a vote only the .LRN Board members vote. .LRN Leadership Team members are encouraged to post their views to help inform the board.
6. A decision is upheld with 2 Yes and 0 No’s or a 2/3 majority of all members (usually 5 people).

---- End cut ----------------------------------------------------------------------------------------------------------------

*****END DRAFT********END DRAFT********END DRAFT*****

The .LRN Board

• Board members typically serve 3 year terms. (See Start Up procedure for exceptions)
• Board members must be .LRN Voting Members from a .LRN Organization
• Elections are held once per year for all vacant posts.
• Board terms are staggered so that each year at least 2 or 3 posts are up for election.
• If a Board member resigns or is no longer a .LRN Voting member prior to the end of his 3-year term then that post is filled during the yearly vote.  All candiates are voted on together. The people with the highest number of votes are given the longest terms.

Start Up Procedure

For this year's elections all 7 positions will be available.  Because we are still in startup mode all terms will be for 1 year.  Next year all 7 seats will be up for election again, at that point we will transition to 3 year terms.  The 3 people who receive the top 3 votes will get 3 year terms, the next two, 2-year terms and the next two, one-year terms.This will set up up to have 1/3 of the positions available every year in the future.

The current board will immediately begin to designate the Leadership Team. We will not wait for the election.

The .LRN Decision forum will be put into place in the next 2 weeks after the server is moved.

The current Board will have oversight, but anything that has a “Call for Vote” will be delayed until the new board is in place. That is, noncontroversial decisions can be implemented immediately, but controversial decisions will be postponed until we have a duly elected Board to vote.

Discussion

This proposal was created by Carl Blesius, Rocael Hernandez, Carlos Kloos and Caroline Meeks over lunch at the Argentina E-Lane meeting. It was written up by Caroline Meeks.  Our goal was to create the simplest possible start up plan and leave complex or controversial decisions to an elected board.

This is not meant to be the final plan. Specifically we discussed but did not reach conclusions about how large organizations vs. small should be represented, individual vs. organizational power or how parties that contribute more money should be rewarded. We also discussed but did not decide on issues around official/certified vendors and vendors contributing back to .LRN. We will work on these issues with the newly elected board.

We ask that the community look over this proposal and see if you agree that it will work for startup purposes. We also ask that you think about what you would like to see as part of permanent governance and policy; however, the appropriate time to fully engage in decisions around long term issues is after we have an elected board.  At that point all parts of this initial governance plan can be modified via the decision policy laid out above.

I would especially ask those familiar with our nonprofit incorporation if there are any legal requirements we need to meet as part of governance.

.LRN 2.5 Release Management

Created by Rocael Hernández Rizzardini, last modified by Gustaf Neumann 06 Nov 2016, at 10:02 AM

About

• Next stable release: 2.5.0
• Las stable release: 2.4.1
• Tentavive deadlines:
  • may 31, 2009: code freeze and branch
  • june 1, 2009: alpha release process starts
  • june 15, 2009: beta release
  • july 15, 2009: final release

.LRN 2.5 will contain the packages included in the following cvs modules:

• acs-core
• dotlrn-all
• dotlrn-extras

See Aliases at CVS for a detailed list of the packages included in those modules.

Releases are coordinated by the .LRN Leadership Team.

Weekly technical meetings in IRC at openacs channel:

• Summer: Wednesdays, following the OCT one at 16:00 GMT
• Winter: Wednesdays, following the OCT one at 17:00 GMT.

To-do List

• Databases support:
  • Postgresql 8.2 and 8.3
  • Oracle 10 and 11
• Replace "html_p" by "mime/type" and richtext widget for input (news, bulk-mail, others?)
• calendar: localize notifications
• forums:
  • DONE: localize notifications
  • removed the SC implementation of search to avoid confusion (search now implemented with callbacks)
• assessment:
  • review daveb changes
  • added "views" support (explicit dependency)

Wish List

NOTE: xowiki was NOT part of .LRN 2.4 or earlier. Since noone from the accessibility group has checked, whether xowiki is compliant with WCAG 1.0 double-A, the DotLRN consortium board meeting decided in Valencia to include xowiki and maybe some other packages in a dotlrn-extras distribution in 2.5. This extra-distribution should not have the strong accessibility requirement as dotlrn-all, where every package must be manually checked in detail by some "accessibility expert".

Note by Don Baccus:  Honchos, not an ad hoc group of .LRN consortium members, decides what goes into .LRN.  Honchos proposed, and the board agreed, that a MINIMUM requirement for inclusion is accessibility compliance.  If xowiki hasn't been checked, by default it DOES NOT go in, not vice-versa.

New features

• Removal of .LRN applets:  see the Removal of Applet thread
• Wiki (xowiki with special policy set designed for .LRN, i.e. avoid professors writing their own tcl scripts or access the DB (DONE), probably a simplified UI?) Galileo will work on this and a few additions to have a wiki for .LRN, in late may / early june 2008.
• Content package: tools for creating content online for .LRN
• xo-S5: online presentation tool (and get rid of wimpy-point)
• Replacement of static portlets by xowiki portlet pages (need to figure out if we use the same xowiki instance for "portlet pages" and for the wiki)
• Blogger replacement with xowiki blogger? (have to review funtionality list, upgrade from actual blogger, others)

Having the idea of a macro-tool (xowiki) that can be easily customized for specific use with prototypes and others will help us to the reduce the code to maintain.

To do

• xowiki (What's missing?)
• content: produce an standard release that work atop .LRN (oracle & PG).
• s5
• xo static portlet (supported via xowiki-portlet and dotrln-xowiki; what else?)
• blogger

Packages that could be xoified?

There are packages that could be replaced with xowiki/xotcl.
xowiki might need a finer granularity (object level) for permissions (parties), categories, comments.

• news (if we manage to tell xowiki to use dates to display and archive a news item
• edit-this-page
• bulkmail (like news but with email being sent out and ui for selecting role/users)

I would even to that far to say that we can replace forums (using page_order) and calendar (similar to news/bulkmail but special UI).

.LRN 2.3 Release Management

Created by Emmanuelle Raffenne, last modified by Gustaf Neumann 06 Nov 2016, at 10:02 AM

.LRN 2.3.1 was released Sept. 9th 2007.

.LRN 2.3.1 contains acs-core, dotlrn-all and dotlrn-extras packages. See Aliases at CVS for a detailed list of the packages included in those aliases.

Releases are coordinated by the .LRN Leadership Team. Weekly technical meetings: Tuesdays at 17:00 GMT in IRC at openacs channel.

To do and goals for release:

• Bugs fixing (a wiki page with a summary will be created): please test and report bugs at bugtracker.
• WC3 WAI WCAG level AA compliance (see Accessibility for more info)
• CSS rewrite (See Zen Project for more info)

.LRN 2.2 bugs

Created by Emmanuelle Raffenne, last modified by Gustaf Neumann 06 Nov 2016, at 10:01 AM

Last modified: 2016-11-06 10:01:45.739891+01

OPENED BUGS

BUGS WHICH PRIORITY TO BE DOWNGRADED

RESOLVED/FIXED/CLOSED BUGS

.LRN 2.2 Release Management

Created by Carl Robert Blesius, last modified by Gustaf Neumann 06 Nov 2016, at 09:59 AM

Last modified: 2016-11-06 09:59:42.237915+01

Release Status

.LRN 2.2.1 Final has been released on January 3, 2007.

.LRN 2.2.1 use OpenACS 5.2.3

en:.LRN_2.2_bugs

List of Packages that are part of .LRN 2.2

Installed by Default (.LRN Standard Install)

dotlrn/install.xml

• en:dotlrn-assessment (applet not installed by default)
• en:dotlrn-bm
• en:dotlrn-calendar
• en:dotlrn-dotlrn
• en:dotlrn-evaluation (applet not installed by default)
• en:dotlrn-faq
• en:dotlrn-forums
• en:dotlrn-fs
• en:dotlrn-homework (applet not installed by default)
• en:dotlrn-news
• en:dotlrn-portlet
• en:dotlrn-static
• en:dotlrn-random-photo
• en:theme-selva

CVS MODULE: DOTLRN-ALL

• en:acs-datetime
• en:acs-events
• en:acs-mail-lite
• en:assessment
• en:assessment-portlet
• en:attachments
• en:bulk-mail
• en:bm-portlet
• en:calendar
• en:calendar-portlet
• en:categories
• en:dotlrn
• en:dotlrn-portlet
• en:evaluation
• en:evaluation-portlet
• en:static-portlet
• en:faq
• en:faq-portlet
• en:file-storage
• en:fs-portlet
• en:forums-portlet
• en:forums
• en:general-comments
• en:new-portal
• en:news
• en:news-portlet
• en:notifications
• en:profile-provider
• en:oacs-dav
• en:random-photo-portlet
• en:rss-support
• en:user-profile

Optional Included (Not installed by default)

CVS MODULE: DOTLRN-ALL

• en:acs-developer-support 
• en:dotlrn-admin 
• en:dotlrn-syllabus
• en:lars-blogger
• en:weblogger-portlet
• en:dotlrn-weblogger
• en:trackback
• en:user-preferences
• en:workflow
• en:xml-rpc

 CVS MODULE: DOTLRN-EXTRAS

• en:views
• en:clipboard
• en:lors
• en:lorsm
• en:lorsm-portlet
• en:dotlrn-lorsm
• en:lors-central
• en:photo-album
• en:photo-album-portlet
• en:dotlrn-photo-album
• en:survey
• en:survey-portlet
• en:dotlrn-survey
• en:xotcl-core
• en:chat
• en:chat-portlet
• en:dotlrn-chat

List of Packages that do not get the vote (will not be included)

• en:curriculum
• en:curriculum-portlet
• en:dotlrn-curriculum
• en:wp-slim
• en:wps-portlet
• en:dotlrn-wps
• en:news-aggregator
• en:news-aggregator-portlet
• en:dotlrn-news-aggregator

.LRN Installation

Created by yesten dan, last modified by Gustaf Neumann 06 Nov 2016, at 09:55 AM

Before OpenACS 5.8.1, DotLRN installations required a different installer than its base system OpenACS. There was no way for an end-user to upgrade from an existing OpenACS installation to DotLRN without loosing data, or to make hybrid installations (maybe in the future to use e.g. as well components from Project Open, etc.).

Starting with OpenACS 5.8.1 (and DotLRN 2.8.0) one can upgrade from OpenACS to DotLRN via the standard OpenACS package manager. Therefore, one easy approach to install DotLRN 2.8.0 is to install first a minimal OpenACS system and upgrade in a second step:

1. Install OpenACS 5.8.1. For details, check out openacs-system-install.


2. On the running OpenACS system
   • browse to YOUR_SYSTEM/acs-admin/
   • Click on "Install Software" 
   • Click on "Install from Repository"
   • select "dotLRN" and click on the button "Install..."

This will install dotLRN with the required core components. More packages can be installed a some later times if desired.

Install instructions for .LRN 2.5.0.

Packaged installations

For platforms like Linux/Ubuntu, Linux/Debian, FreeBSD or Windows, one can use the packaged solutions installing separate databases for DotLRN and OpenACS:

• OpenACS/dotLRN Windows Installer Installation Instructions
• Installing dotLRN on debian
• Installing dotLRN on Ubuntu
• Installing dotLRN on FreeBSD (ports)

.LRN Installation (up to .LRN 2.5.0)

Created by Carl Robert Blesius, last modified by Gustaf Neumann 06 Nov 2016, at 09:54 AM

Index

Introduction 

Installing .LRN: Using the VMWare Virtual Machine 

Installing .LRN: Using the Tarball

Installing .LRN: Using CVS

Installing .LRN: Using Debian/Ubuntu Packages

Introduction

VMWare virtual machine: simple (for a testing and evalution). Tarball: medium to hard (for a production install without source control). CVS: hard but flexible (e.g. makes it easier to update your installation from the code repository between official releases). Debian/Ubuntu: simple to medium (fast and easy install for novices, easy infrastructure deployment for professional users).

Installing .LRN: Using the VMWare Virtual Machine

to be announced. 

Installing .LRN: Using the Tarball

Before you start

Quickly read the OpenACS Installation Overview and if you still feel like you can progress start with the first part of the next section: Install a Unix-like system and supporting software

(skip the obvious portions if you are already running some unix like OS). Download the latest .LRN distribution from the .LRN repository (currently 2.4.1).

Move the tarball into your /tmp directory (replace dotlrn-2.4.1.tgz with the name of the tarball you downloaded, if you downloaded another version):

mv dotlrn-2.4.1.tgz /tmp/

untar it in that directory

cd /tmp
tar zxf dotlrn-2.4.1.tgz

Installation Process

Continue with the other sections of the installation document, but instead of downloading the OpenACS tarball mentioned in the docs (section "Unpack the OpenACS tarball" in the Install Linux and supporting software document), use the .LRN tarball you just downloaded above. This .LRN distribution includes all OpenACS packages needed to install and run .LRN. Throughout the documentation, use your unpacked .LRN tarball under /tmp/dotlrn-2.4.1 (or name of the directory you unpacked it to) instead of instead of the OpenACS tarball referred to in the documentation.

.LRN is automatically installed and configured as part of the installation process if you install using a standard .LRN distribution.

When installation is complete, restart AOLserver as described in the OpenACS installation instructions.  You'll need to wait a few minutes while dotLRN configures itself.  Reload your browser page.  If installation was successful, you'll see a login page. Use the user name and password you entered for the system administrator.  A page will come up that includes a link to sitewide administration.  Visit the link, then click on the "users" link and then approve the system administrator's .LRN membership.

Explore .LRN

Go to .LRN Administration at http://yourserver/dotlrn/admin.  Create a .LRN Community and a couple of users.

Here are some suggestions for things to check out in dotlrn:

Goto /dotlrn your "workspace". Click the "My Account" link at the top and try the "Customize this portal" link there.  Goto the admin pages for a class or community and try the "Manage Membership" link. Create a new sugroup for a class or community. Edit or create new "Custom Portlets".

Installing .LRN: Using CVS

Setting up the Required Infrastructure

The OpenACS documentation page has extensive installation instructions describing how to install needed database and webserver. Follow the instructions up until the point where you are told to download OpenACS and then continue with this document instead.

Notes on using CVS

CVS commandlines are given in terms of anonymous users, if you have an account on openacs.org, use your login where appropriate. Don't forget to set the CVS_RSH variable in your shell envrioment to "ssh".

Checking out the code

Go to /var/lib/aolserver (create the directory if it is not already present). Checkout the code (this is a complete code checkout and might take a while):

cd /var/lib/aolserver
cvs -d anonymous@cvs.openacs.org:/cvsroot login
cvs -d anonymous@cvs.openacs.org:/cvsroot -r oacs-5-4 co openacs-4
mv openacs-4/packages/dotlrn/install.xml openacs-4

Proceed

You can then proceed with the normal OpenACS installation instructions.

Explore dotLRN

Go to dotLRN Administration at http://yourserver/dotlrn/admin. Make some dotLRN users, terms, departments, classes.

Here are some suggestions for things to check out in dotlrn:

Goto /dotlrn your "workspace". Click the "Control Panel" link at the top and try the "Customize this portal" link there. Goto the admin pages for a class or community and try the "Manage Membership" link. Create a new sugroup for a class or community. Edit or create new "Custom Portlets".

Enjoy!

Automated Installation

As an alternative to the manual CVS checkout and installation described here there are scripts that will automate the install for you. See the OpenACS installation documentation for more details.

Installing .LRN: Using Debian/Ubuntu Packages

Debian

Ubuntu