[sakai2-tcc] CLE 2.9.4 vs CLE 2.10 effort

[Berg, Alan]

> If we had some minimum number of major new features we wanted, we could for example rename "Site Stats" to "Analytics" and use that to justify the 4.0 moniker.  Adding Analytics would be big.

Would be nice to have Unicon and UvA's efforts around xAPI support in Sakai CLE take off. The easiest part to build would be a recommendation application backed off to a Learning Record Store with a dashboard using BasicLTI. This way we don't get stuck inside any given LMS and we can collect student activities from multiple applications. For example, we expect xAPI support in OAE and uPortal sooner rather than later. Recommendations could be done real time.

At UvA we are running or will do soon a number of pilots across application's. I have even compiled a list of LA pilots in the wild that have resources on the Internet. https://www.surfspace.nl/sig/18-learning-analytics/82-case-studies/

Would make for a discrete effort that would be less scoped than a full LA, student retention, success
 and intervention framework.

Regards,
           Alan


Alan Berg

Innovation working group
On the use of ICT in Education & Research
University of Amsterdam
________________________________
From: Charles Severance [csev at umich.edu]
Sent: 31 August 2013 00:24
To: sakai2-tcc at collab.sakaiproject.org
Cc: Berg, Alan; Noah Botimer
Subject: Re: [sakai2-tcc] CLE 2.9.4 vs CLE 2.10 effort


On Aug 30, 2013, at 11:28 AM, Noah Botimer <botimer at umich.edu<mailto:botimer at umich.edu>> wrote:

My rationale is: there is a ton of stuff (without a good list) already in trunk without major restructuring, etc. There are things "on the roadmap" that might or might not come to be, like crazy portal cleanup, offloading of DB messaging and logging, major module restructuring, source control changes, build tool changes, better responsive support, and more. Holding the already-done stuff hostage for bold initiatives is not a victory for anyone. Charging forward with a mish-mash of a few known and a bunch of unknown things with a brand new 4.0 label is also not a victory. If there is a "marketing shot" to be fired, it should be better planned than "we're tired of calling it 2.x".

I am not a fan of saying - we can't call it "4.0" until we meet some set of this that and another thing.

If we had some minimum number of major new features we wanted, we could for example rename "Site Stats" to "Analytics" and use that to justify the 4.0 moniker.  Adding Analytics would be big.

I also agree with Mark that code names are just code names and make us sound cooler when we talk about the releases - the artifacts, snapshots and releases will have real numbers. But if we have code names - we can say cool things like this:

"I think that Sticky Sessions should not be a priority in the in the MapleBacon release but instead delayed until the HoneyCruller release."

Perhaps an even cooler idea would be to use code names for releases - but each of us can make up our own code names for the releases.   Then when people monitor our mailing lists we will seem extremely clever and complex.

/Chuck


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai2-tcc/attachments/20130901/41e36584/attachment.html