Forum .LRN Q&A: F2F leadership team meeting (April 27, 2007)

Meeting minutes:

1. Leadership team: https://openacs.org/xowiki/%2eLRN_Leadership_Team
-be more visible in forums
-Carl reviews rules and suggests changes for next meeting (Avni and Raul asked to be in)
-improve 'how to contribute' page

2. Integrate dotLRN in subsites
-migration path
-packges not dotLRN dependant

3. SCORM support
-Current situation: https://openacs.org/xowiki/SCORM_support
.SCO support does not work
-SCORM RTE in java is just an example --> get rid of the .jar
.there are examples in javascript that can be used
.Nima offered to implement in javascript (talk to Don)

3.1 Roadmap:
-June 2007: SCORM 1.2 support with javascript
-Sept 2007: decision on what to do to implement SCORM 2004

3.2 LORS Central
-get rid of duplicated code (Galileo Univ. & Dave)
-offers: versioning, share resources (admin deploy in differente courses)

3.3 Oracle port
-ported to 2.2.1
-need to know % that needs to be ported now

4 Next release: 2.3.1
-talk in next meeting (Carl emails)

Please, contribute if I missed/misunderstood anything.

Olga

1. Emma mentioned the duplication of xoWiki documentation + old documentation. Would be good if we could figure out how to expedite the migration to xoWiki and get rid of the old documentation?

2. I offered to write an email about how to improve documentation on getting people access to commit. And why it took me a while to commit the workflow UI code. (will do this as soon as I get a chance)

I can help some with the Oracle port but would need more guidance on what needs to be done.

1. Emma mentioned the duplication of xoWiki documentation + old documentation. Would be good if we could figure out how to expedite the migration to xoWiki and get rid of the old documentation?

I have 2 questions/concerns:

1. Access to documentation at openacs.org: the most up-to-date documentation is at the wiki but the "documentation" link is still pointing to the old one. Maybe we could point the "documentation" one to https://openacs.org/xowiki/openacs-handbook and add a link to the "old documentation" on that page.

2. How to pack the wiki doc into OpenACS and .LRN tarballs: IIRC a book can be created from the wiki pages, Gustaf? but can we keep different versions -for different releases- of the documentation? And what's the format of the output (the book) and how can it be included in the tarballs?

The former has the intention of a categorized approach where pages are structured and presented differently depending on the target audience.

The latter has the intention of being a book.

My opinion was and still is that we should have the BOOK as the primary reference and add categories in a smart way so that we do have multiple entry points into it. But others might disagree. And due to this impasse I don't know where to fix documentation or upgrade it and most likely others don't either. So not much get's done.

If you go to /xowiki you will also realize that we have package documentation there twice (https://openacs.org/xowiki/ACS_Admin vs. https://openacs.org/xowiki/acs-admin). In two separate categories. User Installation. There exists a couple of pages, which one will be deemed current?

Another example: If you go to https://openacs.org/xowiki/en/openacs-system-install (which luckily is prominently linked from the main page), on the left hand side you see a ton of pages and options, all flat in one category. Here the category approach clearly fails in my understanding and having sections and subsections would be much better.

Usually I am a person who would get his hands dirty if he feels pationate about it as I do about user documentation. But there exists a documentation team which has different approaches, and this shows. Furthermore, not everything old is bad (read: /test-doc). It is just old and needs updating. But the old documentation was well structured.

Therefore, we might have to open the box of pandora again and discuss what the documentation should do for us, then talk about structure and last but not least talk about implementation. Not to mention the fact that e.g. I do all my user documentation in screencasts and not in writing anymore.

Currently the best way to learn OpenACS is to use google search. Why? Because they also index the forums smartly and we have a lot of hidden gems in there. Sadly it also increases the noise. Maybe .LRN 2.4 could be a documentation release (as it was with ZEN) while OpenACS 5.4 will be the "clean up bug-tracker" release? (the differentiation is purely to suggest who is in charge. .LRN consortium for documentation, OCT for bug-tracker cleanup)

So I will resign from the leadership team to make room for someone who can help with programming.
If one needs know-how I can contribute, I will be glad to join again.

I think, you are doing great work and .lrn is on its way to be the leading learning environment.

I don't think the problem is people who attend meetings not contributing during the meetings.

I think one problem was that during Zen (for a while) we were discussing too
many technical details in the leadership meetings. These technical details should not have been discussed in a leadership meeting and should have been taken offline. I think in today's leadership meeting the Zen team members agreed with this and we will strive to follow this.

Instead of mainly relying on the honchos email, the leadership team will post more discussions in the forums.

In order to be more inclusive, the leadership team will also post meeting agendas and meeting notes in the .LRN Q&A forums when they are available.

Also, I don't think the purpose of the leadership team is purely technical (though this is a software development project) nor should it be. My personal opinion is that it is necessary to have a user/teacher perspective on the .LRN leadership team. 😊

Thanks,
Avni

Please chime in if you have thoughts.

By the way, there is always a way to contribute to the meetings, ... making the minutes and posting them in the fourms!

Olga