>>As Jeff says, we certainly don't have the resources to synch
>>.LRN packages releases at the same time. While all packages
>>are in our CVS tree, and while many are shared (forums,
>>etc), their are substantial packages which, as Jeff says,
>>are of NO USE outside the .LRN environment and the
>>consortium MUST be responsible for maintenance. Those
>>members of our community who, like Jeff, have little
>>interest in selling to the academic e-learning market have
>>no motivation to fix packages like LORS.
That's certainly true - the set of people focusing on the core don't have the time to do all the packages.
But I think the process should be the same. The process around maintaining the forums package should be the same as the process around maintaining the forums package. It should all go under the "how OpenACS packages are done. Not as two separate things.
I'll give you a concrete example:
From the OpenACS process viewpoint, we look at packages from a maturity level. There are certain criteria for each maturity level and a package is labeled appropriately.
From a .LRN viewpoint, there is a concept called ".LRN certified". Now, ".LRN certified" makes great sense from a branding perspective.
From a process perpective - it should be 100% aligned with what OpenACS is doing. ".LRN certified" would signify a certain maturity level and .LRN would focus on maturity levels and working with the OpenACS structure. Instead of .LRN recreating essentially the same process on its own, it would work the process as it already exists in OpenACS.
