Consortium activities organization (DRAFT)

DOCUMENT STATUS: A draft that HAS NOT YET been endorsed by the OpenACS OCT, the .LRN Board, or the .LRN Leadership Team (Honchos)

---

These areas and list of activities has been summarized of a discussion over the lists. The aim is to have a more integrated set of activities created and provided by the different working groups (board, leadership team, oct).

Consortium investment in .LRN:

• Create a budget for the next 12 months / year, has to include also all administrative costs. (Alvaro can prepare a preliminary budget).
  
• Figure out the priorities for technical development (QA, new releases, etc.), documentation & tutorials, marketing.

Some areas to invest in that have been already formulated:

1. Bug-fixes: #3 & #4: prioritize technical tasks is OCT and leadership authority
2. QA testing for releases
3. Release Management
4. See original proposed set of jobs: https://docs.google.com/Doc?docid=0AUeGYMa72ygGZGhjbnc0bm1fN2R3czdxeGZ0&hl=en

Documentation:

1. Tutorials for basic areas of openacs technical development.
2. Update on installation process for official documentation (already on creation process, a plan about how to address it will be posted soon, so approval is give to proceed with it)

Marketing:

1. Training on .LRN usage.
2. Users help section
3. A demo-course of .LRN (already on creation process)
4. All these actions (and probably new ones) towards getting more users.

The Consortium investment process:

1. The priorities has to be agreed at the Leadership Team / OCT. Any formulated item will require a description clear enough to be able to justify a given investment.
2. Figure out which investment channels we can have:
3. • There is the initial Jobs small - incentives.
   • Some other people argue for better rates, that can lead us to monthly contract: directly contract monthly time in a yearly basis for some developers (at lets say open source rates, not as small as in the jobs): for instance one or two experienced community recognized developers, and one newbie (which is not expensive) that will do the bee-work.
   • Other possible paths? such as posting for a job and people make an offer and from there negotiate a give amount. Different people might require different amounts.
   • We might contract either an individual or an organization (Institution or a company)
4. Assign a given priority / task to the interested developer / party.
5. OCT / Leadership Team review and approved the work finished
6. Consortium pays.

Oracle support:

At this point we cannot guarantee oracle support for .LRN.
There are specific donations to Oracle, such from UCLA.
Additionally, UNED & Bergen use oracle and has given their donation, so a part of that funds should go to Oracle support.
Also, since UNED has an active group of developers supporting their installation, we should ask them to test Oracle as well.

Increase community participation:

• Consortium will request active and committed technical developer participation in the Leadership Team to the institutions that might have technical developers. (nominate an active developer for open-source with lets say 10-20 hours a week). Additionally, to be able to contribute better the best scenario will be to have this institutions to have their .LRN installations up-to-date, and have mechanisms that allow them to separate their code from what the official distribution is, that as well will let them influence more directly into the official distribution.
  
• Improve communication from OCT & Leadership Team:
• post the meeting minutes in time (the day after at the latest)
• get the IRC logger back and have a usable page to access logs
• move technical discussion to forums
• Improve communication with the board.
• Others?

Community growth:

• Create means to get new developers:  any ideas?
• Emma: That won't happen alone. The main issue is "getting new users" and
  it's a marketing matter.

dotlrn.org:

• git will be replaced with cvs checkout from the cvs.openacs.org
• update content
• The technical management is assigned to the Leadership Team.
  
• Leadership team can assume the technical management BUT ONLY ONCE the
  site is a CVS checkout from the openacs.org tree

The new tutorial:

• Has to have a place, where it links and download it.
• It can be included on the distribution file and in the documentation.
• With which tool we'll produce future tutorials and based on which templates still need to be settled. Maybe a comparison chart will help to make the decision.
• A tutorial has not the same format and purpose of a traditional documentation (format as how is structured, organized and designed, and not to which is the document type).
• Has to reflect any engineering standard that it might come across within its examples. While understanding that the tutorial is not to explain the engineering standards. The engineering standards has to be clearly defined with examples if necessary in the engineering standards section of the standard documentation (including the accessibility ones). The better explained, the easier to follow them!
• It can be exported to different formats but its mandatory format is html.
• As for documentation: we see in the repository no major changes in the documentation itself over the last years, so probably we need good review and really involve people to update on it, since none of the members of the groups seems to be doing maintenance over them.