Forum .LRN Q&A: .LRN releases
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 :)
.LRN Releases - Philosophy (https://openacs.org/forums/message-view?message_id=198537)
.LRN release process and roadmap (https://openacs.org/forums/message-view?message_id=176321)
I think the two cents metaphor is the best way to think of our little UAB as our discussions can be really good when developers are looking for two cents of well-meaning opinion and early enough in the design process that something might be done about it, AND in a way that leaves the developers feeling like they can pick and choose among the advice as they see fit. So, give us something to do and I'd say chances are very good we'll rise to the occasion.
We might here think about the best way to do this. We have had some great discussions via "reply all" email. We do have a closed discussing forum. And sometimes we have been active commenting out in the open on this forum. Personally, I prefer this open forum as it lets people know immediately what is going on and invites the contributions of many. I got to know lots of folks through the Dotlrn Gardens thread, and I think there is a consensus that the design hammered out there remains a good one and on the table.
Which brings me to the first weakness of the UAB: we are not funding anything, and so our bright ideas (as I like to think of them) are completely dependent on those who might encourage, translate, and otherwise accommodate them. Our original mission, as I understand it, is as a kind of Steering Committee, but in practice I think we have been more of a sounding board for those with funding or other motivation. When I look back at the best moments, they have almost always been when a developer is working on something and has felt that a second or third opinion might help him/her and so was ready to hear -- with response times of a few hours or days -- some initial opinions. I might add that we have done some more detailed design work on the forums, and so our two cents might also turn into four cents.
The second weakness, in my view, is that there are four of us appointed a year ago and we've got lots of new people on board. Before we busy ourselves with the question of formal organization, I'd recommend that we simply conduct much of our business out here in the .LRN Q & A thread so that everyone who wants to participate is informed and welcome.
I'd love to discuss any one of the elements you have proposed above here in this space and then offer what I/we can with some of the details in a way that the developers might appreciate. So, where might we begin?
All the best,
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.
thanks for your comments, I wanna be simple, then for me:
Usability = UAB
Yes, please Bruce, start a thread on this forum about short term priorities on UI improvements, lets identify our weakness and post solutions, and now, at least Galileo (E-LANE) will work on this starting in about 1 month.
I want to remember my point of view: "we need short term release cycles", we'll keep everybody happy, more bug-fixes, more suggestions from UAB in the toolkit, more competitive, more functionalities and avoid to repeat the extremely slow and painful process that has been the release of .LRN 2.1.0.
We need to increase the momentum:
1. with the UAB
2. with the software releases
3. with new adopters / real scenarios using .LRN
4. with the Marketing (MK) effort
p.d. LORS + Assessment + Evaluation are important for E-LANE and .LRN itself, so we'll put effort to make them become part of the official .LRN release.
Site Nodes Scalability Enhancements (right now at Galileo installation its almost impossible to create a class through the UI)
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?
Its important to notice, that not always coincide the available time to talk about usability stuff and to develop that suggestions, so everybody should be flexible, and after some amount of discussion about UI come with specific to-do's (then no need to talk again about the same stuff). At least at Galileo the intial plan is that from december/04 dedicate about 3-4 months to work periodically on UI.