Forum OpenACS Q&A: The Big Bang for dotLRN
On September 1st, eLearn Magazine will be publishing a long (probably 4,000-word) review of dotLRN that I'm writing for them. The article will be accompanied by a column on eLearn's home page about why eLearning needs Open Source. A press release will also be blasted out about the article to all the major media outlets. I assume that Sloan will also be doing some PR, although I don't know what their plans or timeframe are.
It's in the community's interest to make sure that dotLRN (and therefore OpenACS) make as good a first impression as possible. I'm going to spell out the issues that I think are most critical to making that happen. Some of these issues are ones that Sloan and Berklee are dealing with (AFAIK), but others are really for the whole community to consider:
- dotLRN must be finished, QAed, and documented (preferably on PostgreSQL as well as Oracle). My impression is that Sloan, Berklee, and their vendors are working hard on this. If there is anything the community can do to help with this, I'm sure they will let us know.
- There needs to be a functional and informative dotLRN web site and community space. I know Caroline has been working on this as well.
- We need a plan for easy installation and
administration. There has been some good discussion
about creating installers and a basic webmin package for
OpenACS on this thread:
This is a great idea and will be critical to the success of dotLRN as well as any other vertical apps. If the community can't get these pieces together, it would be extremely adventagious to at least have specs for them in place so that somebody with the appropriate itch will find it easier to scratch.
- We should have at least some level of Windows
compatibility. After going round and round on this through
many threads, it seems like we're very close to having at least
one answer to this challenge:
(I'm aware of at least one other person working on an alternative solution, but since he hasn't announced his intentions publicly I'm going to respect his privacy.) Again, the work on this should benefit other OpenACS-based projects.
I'm sure there are other things we'll need too, but that's a pretty good list to start with. Any thoughts about how to move forward?
We also need a download available of AOLserver for Windows. This all needs to be nicely bundled, presumably into a zip archive.
I don't think this is terribly difficult once Jamie's AOLserver installer is ready. We just need a champion to make it happen.
I've been steeped in installation/migration work but will check in with Caroline this weekend and make sure one of us posts a follow-up about website plans.
In the meantime...aside from a marketing-type webpage for nontechs, what do folks think about putting up a "dotLRN Development Central" area, with a bboard and some static pages? Perhaps that's what Michael was referring to with the term "Community space". I envision this area being used for planning and tracking etc. There should probably be, for example, a link off the homepage to a list of major to-do's and their owners.
This is the sort of thing we did at ArsDigita each time the strategy changed 😉 and it IMO it worked pretty well.
It seems to me that the "community space" should be structured for continual improvement processes, such as improving docs, demos etc.
A basic set of separate spaces for 1. students(end-users) 2. instruction/presentation(users) 3. administration/management(admins) 4. developers would go far in reducing the effort required to improve documentation, propose changes etc.
The environment needs to be self-promoting, self-regulating, and self-sufficient as much as possible.
I feel OpenACS.org still needs clearer distinction in this area also.
I've been basically lurking the last few months... taking notes for working on docs in each of the different areas. [..starting writing in June.] The informal structure of this environment must be maintained in order to scoop the greatest amount (and detail) of feedback. However, some basic structure (such as sorting by documentation/use) would go a long way to making the environment more useful to those who are not bitten by the OpenACS evangelist bug ie. willing to put out the extra effort to find answers to basic questions.
I have not had time to delve into the dotLRN package, so I'll leave it to you to know if my comment is relevant or not. In the case of OpenACS.org, the environment remains developer focused --a factor that I believe inhibits growth of the system's deployment. Hopefully, dotLRN's environment is more organized to an open learning-environment --which it will be used in-- without being regimented or bureaucratic ie. requiring an intuitive sitemap view from a system development perspective etc.
[Dear readers, this message is not meant as a flame --only as constructive criticism in context with the posts. None of my comments here are new or original, or need re-hashing in the context of Openacs.org. In any case, I'm not in a position at the moment to re-hash them should you want to. Sorry about that! ;) ]
Torben ... I doubt if you'll find any disagreement among anyone in the community. I'm glad to hear you've been taking notes and want to start writing more documentation in June. Fantastic.
Our website needs a total revamping and reorganization - telling people to scour new-file-storage for tidbits isn't user friendly. It's a matter of time, though. If our community has grown to the point where there are folks available to reorganize and maintain content for developers and for non-developers, that would be a fantastic contribution. Thus far no one's stepped forward.
Torben made a very good point when he divided the audience as:
1. students(end-users) 2. instruction/presentation(users) 3. administration/management(admins) 4. developersI am totally in favor of a dotLRN Central to serve the needs of groups 1 to 3.I've received several offers of help and would love more for developing content for a non-developer site. Please continue to send suggestions and contributions. This will be a group effort, but I'm happy to help coordinate it and Sloan is happy to host it.
For group 4 I like the vision I am seeing in the community of dotLRN/dotWRK as marketing verticals of OACS. There is much work that needs to be done to make that a reality but I would much rather see a reorganization of OpenACS.org to make it more user friendly to developers in all verticals then see a split for dotLRN.
then going away for a few days. I'll try to catch up.
First, I agree that the developer community for dotLRN should
stay on OpenACS.org. An organized space would be nice, of
course, but for now a bboard and a folder in file-storage would
probably suffice. That having been said, I think it will be difficult
sometimes to draw a line between what belongs in the
developer community space and what belongs in the space
created for non-developer users. I fear that separating the two
may not be entirely healthy.
If somebody can get topics working properly on OpenACS.org
bboards, we might try having one bboard here for all dotLRN
user types and allow them to segment them by topic, at least
until the user base grows enough that we clearly need
At the same time, it makes sense maintain a site where
documentation, downloads, etc., are available for dotLRN. It's
great that Sloan is stepping up to the plate to do that.
Regarding the issue of volunteer labor to work on the Windows
installs, etc., exactly what kind of skill is required? I may be able
to scare up some additional resources if they don't require much
OpenACS -specific knowledge.
That is excellent news!
What happened to the work done by Musea in the new openacs.org site. That was great work and I think we should have that up as soon as possible. It would be nice if it happens before that paper comes out.
I am already writing "framework user" (webmaster) documentation. I have been a bit loaded with other work but I expect to focus much more on this during June/July.
I am also writing some "problem sets" for webmasters (as opposed to OACS developers). As soon as I have a more complete draft, I will let you know.
- After Musea did the work to migrate the existing openacs.org bboards to the OACS 4.5 bboard package, we learned that it performed very slowly under Postgres. That was my original motivation for diving in and revamping the tree sortkey implementation in PG, in a way that would allow for effective use of indexes.
- bboard was still slow in calculating its summary data. OF agreed that they'd fix it as part of dotLRN. As part of my adventure in step one I'd discovered that the bboard datamodel was poorly designed in some ways. To make a long story short, OF has decided it would be easiest to just write a new one of dotLRN. This is the one we should use for a new openacs.org
- Integration with SDM/bugtracking software ... nothing adequate exists in OpenACS 4.5. Lars Pind is writing a new bugtracker that looks like it will be much nicer than the existing 4.x ticket tracker. Musea's sponsoring this.
We also use the download repository, of course.
The question as always is who will have the time to bundle up a new site. Musea's work was a great start but ... it was a start.
In the interim - Michael, if you think a bboard and folder would be sufficient to get dotLRN interest focused in the short term, would you check w/Sloan and OF folk and ask if there's general agreement? It only takes a moment to fire up a forum.
The other option for new users is to register for timedesk at once. Experience shows it's 50 /50 as far as newcomers willingness to use either version.
I look forward to the comments from newbies to this system, as I have not provided any documentation. I will just deal with comments one they are posted. I hope this gradual feedback will help creating a user focused set of documentation. Cheers
and file-storage folder for interested developers here at
OpenACS.org. Sloan and OpenForce, in the meantime, will work
on setting up a dotLRN-based community site for the wider (i.e.,
non-developer) audience. (This will probably take a little more
Don, could you please set up the bboard and folder for us?