Forum .LRN Q&A: .LRN release process and roadmap

Posted by Tracy Adams on
Hi Everyone, Now that I've been through a release and have gotten feedback from a lot of people in the community, I've put together a draft of the backbone of a release strategy. Please comment:

.LRN Release Process and Roadmap

The purpose of this document is to outline the .LRN Release Process, how it relates to OpenACS and its release process, and describe where we are going.

.LRN and OpenACS release processes:

The majority of the functionality in .LRN is part of OpenACS. First and foremost, we are interested in OpenACS continuing to be a thriving community. To large part of the .LRN roadmap is the OpenACS roadmap, which is here:

The .LRN release process is designed to compliment OpenACS. The goals are to:

  • Maintain code that is not directly part of OpenACS
  • Ensure .LRN serves the functional needs of its users
  • Ensure .LRN serves the quality and operational needs of its users
  • Provide the assurance that the .LRN label means that the code has met specified quality and testing criteria

.LRN Release Process (starting with .LRN 2.2)

  1. Identify the focus, goals and timing of a particular release.
  2. Work with the OpenACS community to
    • Figure out where specific goals overlap so we can work together.
    • Ensure that our goals and timelines are compatible.
  3. Identify a sponsor for each module or functional area
  4. Identify an institution that agrees to be the first to deploy a release candidate version of the release. This will be the “beta-test” institution for a particular release. The role of beta-test institution will rotate around consortium members.
  5. Identify specific goals/features in each module or functional area.
  6. Development (specific TBD, but will work similar to the OpenACS release process)
  7. When a release candidate is ready, it will be deployed at the beta-test institution. The community will be on alert to assist this institution and respond to any issues during this critical period.
  8. After the beta-test, the release is cut.

.LRN Timeline

.LRN 2.1

The primary purposes of this release will be to:
  • Provide a tarball that includes the multitude of fixes in OpenACS 5.1
  • Fix critical fixes blocking launching and upgrades. Note, if you have fixes in this category, you should have tickets in the bug tracker and email me the ticket number at
  • Timing: Shortly after the OpenACS 5.1 release, expected in May.
  • Next steps – assist in OpenACS 5.1 release

.LRN 2.2

  1. Focus and goals – quality and stability of the major .LRN functional areas:
    • User Administration
    • Class and Community Management
    • Calendar
    • News
    • File Storage
    • Bulk Mail (just clean up bugs as new work is in development)
    • Forums
    • Faq
    • Survey (just clean up bugs as new survey is in development)
    • Homework
  2. Beta Testing Institution - Sloan
  3. Timing
    • Release Candidate and upgrade at Sloan July
    • Final Release – September
  4. Currently looking for module sponsors in each area.
  5. If you would like another module to have focus for the release, you must provide leadership and resources.
  6. Next steps
    • Coordinate/Heads up with OpenACS Community
    • Identify module sponsors
    • Identify specific needs for each module
    • Fill out release process

.LRN 3.0?

(number to be determined)
  1. Focus and goals
    • Merge differences between OpenACS and .LRN
    • Don’s new portal system and portlets
  2. Identifying promising modules and testing and solidifying them for the “.LRN” label. Potentials that have been identified:
  3. Search
  4. PhotoDB
  5. Grading
  6. Jabber
  7. Complex Survey
  8. Assessments
  9. Email Integration
  10. Curriculum
  11. Weblog
  12. Wysiwyg widgets
* Note, this functionality may be available either as OpenACS or contrib. packages before the release. And, of course, institutions are welcome to use them and make investments into this area. When they are distributed in the .LRN tarball, this will mean they have been through the .LRN release process and tested operationally with at least one of the participating institutions.
Posted by Rafael Calvo on

I would like to include Ernie's LORS in 2.1 or 2.2.
I think the interoperability SCORM complliance is very important...
It has some dependencies on the latest file-storage so it will not work until 2.1

Posted by Tracy Adams on

Keep in mind that there may be packages that are available to the community (Ernie's LORS) even though they are not part of the .LRN tarball.  In fact, we expect lots and lots of creative activity and don't want to get in the way of this at all.  In other words, someone could run .LRN 2.1 and still use Ernie's Lors.

What we want to set up is that something that is in the .LRN tarball has gone through a pretty rigorous process of getting operationally tested and used at least one of the constituent institutions.  Lors is a brand new package, which means it first has to pass the test for becoming an OpenACS package.  Then it can evolved into .LRN.

Overall, the question is also getting the collective feedback and putting the joint effort into areas that will benefit everyone.  We all know there is only a limited amount of time and resources. Time and time again, I've heard that some of the low hanging fruit on the core modules and getting them solid is a major frustration, a block to adoption, and a big priority.  Once these base issues are covered, the skys the limit in terms of new stuff to add.  This is why I made the focus of the .LRN 2.2 release the core modules and bug fixes.

I love Ernie's LORS and want to completely leave open the freedom and space for that to evolve.  Don't let the priorities of a particular release stop you.

Posted by Matthias Melcher on
if I understandstand your timetable right, this is what you recommend to institutions who do not want to branch and do not want to knit their own systems from CVS but rely on a tarball out of the box:

If they want to show their learners a webcontent called index.htm, intro1.htm, content1.htm, and summary1.htm, load it up to filestore, rename index.htm to 00index.htm to force it to be on top, and tell their students how to navigate to the filestore and click it? What else could be recommended with a dotLRN that is not branched, not self-knitted, and without Ernie's LORS?

Posted by Nima Mazloumi on
I fully agree to what Tracy said and also think that we should not underestimate IMS/SCORM compliance of dotLRN if we really want to become a cempetitive and accepted LMS on the market.

Still it is very true that we should focus on making dotLRN as robust as possible. There are many things that come to my mind regarding robustness and usability, like

- why are not news and calendar items of open subgroups visible in the supergroup/class?

- the navigation through dotlrn is not usable..for instance there is no way to return back to a class from a subgroup or from customizing the portal layout of a class to the class itself (only via admin page first)

- it is not possible to delete forums, subgroups, classes, departments, user defined portlets, pages in the portal layout if it is not the last page...

- the default pages for a class/group are i18n but you can loose this info by simple overwriting the name. Better to have default pages that can be hidden and user defined pages that need not to be i18n

- there are many pages where the pages My Space, My Calendar, My Files ... are shown ... most of the time when you are navigating to a dotlrn-package (cal, forum, news, ....)

- the file-storage doesn't handle upload of interlinked html files properly if they have a defined folder structure. Instead all files are created in a flat hierarchy and many links are broken.

- we do not have an extranet for aggregated info of the dotlrn groups that exist

- from some posts I understood that copying groups is not working properly, so I turned that feature off

- we really need a support system for dotlrn to handle user problems, questions and suggestions and to maintain a dotlrn instance that has more than 20.000 users


I am sure that some of the problems mentioned are OpenACS specific and will be or are already fixed. So upgrading to 5.1 is important.

From usablity and strategic aspects IMS/SCORM is #1

The rest of the above stuff is bug fixing or constant improvements, right?

Posted by Rocael Hernández Rizzardini on
Everything sounds fine so far, just to remark: Standards (SCORM, IMS, OKI, etc) should become part of the official release of .LRN. Any new package that implements an standard for .LRN and that we might want to make it *official*, will need to pass a lot of testing. But when the testing is passed, and everything works fine, should become part of the official tarball. And even that we might have more than one different package of the same standard implementation, will be real healthy to just oficially support one.

Besides the goals that Tracy has put, we need to have goals for standards as well and the commitment of the partners doing those.

Posted by Tracy Adams on

I didn't understand the specifics of your question. I can, however, give you a broad answer to what I was thinking.

People in the community develop and maintain code as packages. So the next step would be to work toward a package release of Lors.  The process would then be:

-- Install the .LRN tarball
-- Go to the APM manager and install the other packages. This will grab the tarball of that specific package from the OpenACS site and install.

That way, institutions can have the flexibility of getting an official release of .LRN, not fork, and be able to try out some experimental packages.  What you will be running on your site is a combination of the .LRN tarball and also a release of another package.

The .LRN "label" and tarball will be saved for packages that have made the criteria to be an OpenACS package, get deployed in at least one school, and go through the .LRN test/release process.  The goal is to ensure the quality of what is labelled .LRN.

We have a whole bunch of new packages coming that will all be very valuable.  To make things feasible, we just have to start with the highest and take one step at a time.  The core of .LRN and the basic package hasn't gone through extensive testing (these last .LRN release have essentially been releases to pick up the OpenACS fixes).  Case in point were the bugs people found the homework module last week.

Once the core parts of the product are stable, we then move to working on the newer packages.  In the meantime, of course, there will be lots of activity on the other packages led by individual people and institutions.  We never want to get in the way of this creativity and energy.

This is the same type of path the OpenACS community has been following.  Recognizing that there is only so much time and energy, they focused on OpenACS core and not the packages.  First, they fixed the most critical bugs.  Then the next level of priority.  Then the next.  When the core is solid they can expand into some of the broader packages and functionality.

Posted by Carl Robert Blesius on
We really need to fix issues with the core .LRN modules. We need to start small. We need to take care of the low hanging fruit, and move forward from there.

One of the nicest things about .LRN 2.0 (that not many have talked about) is the package manager. It allows a .LRN user to try out software that is not part of .LRN by clicking within the interface and it makes upgrading MUCH easier. This is a key piece which allows individual .LRN installs to test new features. It allows innovation to happen. It allows you to add and test things for the .LRN brand. See how it works for you and if it does start promoting it. Innovation can happen around .LRN and the .LRN brand retains it high quality.

The model fits well with what I have been doing on the new .LRN website (which is running on .LRN). I installed a stock version of .LRN and added OpenACS modules as need (e.g. events, edit-this-page, etc.). It did not take me long to realize that edit-this-page should be shot to put me out my misery (translation: not a candidate for the .LRN brand), on the other hand events is an interesting module for the .LRN brand (e.g. waiting lists for classes, managing rooms with limited space, charging for a course) and it is something that I am going to promote for a future .LRN release (just like LORS and LORSm!).

What I see Tracy saying is: one step at a time (and yes the feature-creep virus inside of me does not want me to agree, but I do).

Nice work Tracy. Keep it up.