[ You may request notification for .LRN release process and roadmap. ] |
Tracy Adams on Apr 14 2004 18:04:49 | [ reply | forward ] |
.LRN release process and roadmap |
The .LRN release process is designed to compliment OpenACS. The goals are to:
Rafael Calvo on Apr 15 2004 22:09:15 | [ reply | forward ] |
Tracy
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
Tracy Adams on Apr 15 2004 23:37:38 | [ reply | forward ] |
Rafael,
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.
Matthias Melcher on Apr 16 2004 07:42:18 | [ reply | forward ] |
Tracy,
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?
Nima Mazloumi on Apr 16 2004 08:03:16 | [ reply | forward ] |
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?
Rocael Hernandez on Apr 16 2004 16:52:55 | [ reply | forward ] |
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.
Tracy Adams on Apr 16 2004 20:43:53 | [ reply | forward ] |
Matthias,
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.
Carl Robert Blesius on Apr 18 2004 20:53:04 | [ reply | forward ] |
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.