Here are some suggestions on how we can plan the releases for .LRN and a short term path for next releases.
Those are my 2 cents, please give us feedback so we all can create a road-map for the next 6 months or so...

1. The release cycles should be not that long (something already mentioned / planned by others)
2. Aim for 3 months medium-major releases cycles (i.e. official support for tools like evaluation, lors, assessment, wimpy-point, etc.; this is a change like 2.1 to 2.2)
3. Minor releases in between more often, mainly bug-fixing, small features (those are 2.1.1, 2.1.2, etc.; around a month release)

While this model is simple, is as well flexible, since we are a cooperative community, we can help each other and be sure that .LRN releases meets institutions needs.

Now the suggested plan for .LRN in the short term is:

.LRN 2.1.0rc1: First half of november 04
* needs some successful upgrades (at GT we'll at least 3 successful upgrades, plus Sloan will have its own) + plus few bug-fixes


.LRN 2.1.1:  beginning of january 05
* Inclusion of TCL CR API for oacs-5-1
* Bug-tracker support for installation errors (e)
* New template for .LRN (from Sloan)
* Notifications on GC, blogger & news (e)
* release of oacs 5.1.3

.LRN 2.1.2: begining of february 05
* UI improvements (e)
* Official Manuals included (e)
* Official Jabber support? (e)
* IMS Enterprise support (changes on acs-authentication) (e)
* release of oacs 5.1.4
* probably other minor releases depending on needs

.LRN 2.2.0: april 05 (this might become 3.0.0)
* Don's new portal system included (this will make our lives easier for include stuff into the portal system), and I hope we can start testing on this year
* Registration system additions (in combination with assessment) (hd)
* incoming email processing (e) (from ctk-musea)
* release of oacs 5.2.0 (which includes many oacs core changes)

.LRN 2.2.1: may 05
* official support of lors, evaluation & assessment (e)
* probably we have more stuff to put inside, but I want to keep the plan for a six month, simple and based on the priorities that we have seen from several users.

All of them will include bug-fixing. (e)

While the dates are no rigid, for adopters (actual / future ones) its important to have a clear road to show and somewhat accurate dates...

Those (e) means who's gonna take care of it:
(e) = some e-lane partner
(hd) = Heidelberg
Anyone else willing to take something or include another thing, please tell us here, then we can even release stuff before than planned.

We want with these avoid forks from the institutions, which is always tempting specially because the slow bug-fixing / release process that sometimes happen. Maybe AndrewG can bring back to the source the Viena guys :)


cheers,
roc@

References:
.LRN Releases - Philosophy (http://openacs.org/forums/message-view?message_id=198537)
.LRN release process and roadmap (http://openacs.org/forums/message-view?message_id=176321)

Thank you for your posting. It's timely.

We do need to clarify the release process for .LRN. You will hear more from Carl on this topic soon, particularly concrete steps and process.

Let me make a couple of general points from the perspective of the .LRN Board.

First, beginning with the 2.1 release the focus will be on performance, reliability, and usability. New features will be secondary. We have made considerable progress with performance and reliability, but we need to continue to monitor large installations (e.g. Valencia) and incorporate best practices from Bergen and Vienna. We have made minor improvements in usability and, therefore, it remains the key challenge and priority for .LRN during the next few releases. We need to pay attention to our users and they are telling us: Usability, Usability, Usability!

Second, we need to establish proper governance so that users (not bureacrats like me) are empowered to establish the priorities for the release. In particular, the User Advisory Board as representatives of the user community should be in the driver's seat and have the greatest voice in determining priorities and establishing direction. Now that the .LRN consortium has been formed we are now in a much better position to establish user-driven governance and user-driven innovation.

Roc, thank you again for opening this very important topic and dialogue.

.LRN 2.1.1
Site Nodes Scalability Enhancements (right now at Galileo installation its almost impossible to create a class through the UI)

.LRN 2.2.1
Users Merge (this is quite useful and without that its a pain to deal with duplicated users)

Before I begin that thread, I'd like to hear from others on the question of how we might best go about it. I think one way to that that is to ask people what kinds of contributions they might like to make and might actually make and why they think this might be helpful.

For example, it is the begining of our semester and I'm involved in implementing both Dotlrn and Blackboard. I've got a bunch of people organizing short case studies based on some "over the shoulder" observation and interviews and the preparation of one-page reports. I'm doing everything they are doing, and so this week I'm scheduled to observe in-class training of students by their instructurs and teaching assistants in one Dotlrn class and one Blackboard class.

I'm hoping my notes and photographs will help me better understand how new users figure out how to use the stuff, and since these are being done in class, how come, for example, they are apparently not using the written documentation I and others have prepared for them. I hope to hear some telling comments, as I have heard recently, like how warm and fuzzy people feel when they join Dotlrn groups (and how exposed and uncertain they feel when using Blackboard) and based on these comments come up with little bits of advice.

For instance, the warm and fuzzy comment led me to appreciate the soft, rounded corners and neatly stacked containers I find in the Dotlrn interface as well as the alternative to the "security violation, this incident has been logged" I penned this week in response to an even more hateful and confusing logon error message in Blackboard, something like: "Ooops! I think I recognize your email address, but I don't recognize what you just typed into that password box! Try typing it again carefully, and if that doesn't work, you'll need to get yourself a new password by ...." This is a bit wordy, but unlike the "authentication failure" message it would replace, most normal people would understand it and finish reading it knowing what to do next. It is also a concrete suggestion that I could deliver to a developer, and part of my case study will be the difference between what happens when one makes such suggestions in Dotlrn and what will happen this week I follow my suggestion's fate through my own institution and, as we can't mess with Blackboard, how it is handled by Blackboard.

I fully understand that there are many ways to skin a cat, so I'm hoping that others will suggest other ways. I do hope we might establish some underlying criteria or standards or goals for this enterprise.

First, I'd like to be sure we have someone contributing from each of the major implementations. Second, I'm hoping that the contributions will be based not only on the good advice we developers and administrators might offer from our valuable experience, but also, on some interviews with non-professionals so we might see and hear things we might not have heard and discover some new uses and trends.

Finally, I would propose that we go to all this trouble only when we identify one or more developers who might actually put whatever we might have to say to good use. This is why, in my earlier post in this thread, I used the figure of the "sounding board" rather than "steering development" -- I get uncomfortable whenever I feel like I am making suggestions other people don't want to hear, or that no one is hearing, but I feel just wonderfully useful when I can give a simple account of what I have seen or heard to a developer who has gotten to the point where he is about to make some decisions based on presumptions that he is not sure have been fully tested and so might appreciate what someone outside of his immediate craft might have to say. Also, I like it when I can speak not simply from my own experiences, but also, as if I were a sociologist or anthropologist (thank you, John Seely Brown) offering an even-handed survey of social life.

OK, that's my starting point. I'm hoping some others will discuss what they think the protocols might include, and then maybe we can move on to listing and scheduling topics and functionality, and then how we might start, intensify, extend, and then conclude some discussion threads.

I'm here to go! How about you?