View source for OLPC Ethiopia/2008 09 Daniel visit recap

[[User:DanielDrake|DanielDrake]] visited the Ethiopian deployment team at ecbp in September 2008. This page summarises core principles that were taught to the local team.

= Content bundling =

Content bundles are simply zip files which get extracted in /home/olpc/Library. The customization key does not really do any checking of the content itself, so it is possible (and very easy) to create a bundle of content which is installed successfully but cannot be found through Sugar.

We decided to create one content bundle per grade per region. In other words, we have bundles for Addis-Grade2, Addis-Grade3, ..., Oromia-Grade2, Oromia-Grade3, etc.

You must pay attention to the file structure of the content bundle zip archive. Generally, the PDF content bundles for Ethiopia should have structure:
 BundleName/
 BundleName/library/
 BundleName/library/library.info
 BundleName/index.html
 BundleName/FirstFile.pdf
 BundleName/SecondFile.pdf

library.info contains some basic information about the content bundle, including the title of the content (e.g. "Grade 2 textbooks") and so on. This is how sugar recognises and indexes the content bundle.

index.html is a hand-built HTML file which provides links to all of the PDF files inside the content bundle. We started by writing some instructions for the children in English and Amharic, then we made an index.html file for each bundle including those instructions and a list of links to textbooks.

Finally you zip up the whole thing (''including'' the BundleName directory) and give it a suitable name e.g. Oromia-Grade2.xol. These bundles can then be placed on a customisation stick.

Eskender, Freiwot and Mariamawit now have experience building content bundles (including index.html and library.info files). I believe Dagne also understands the problems that the team were facing beforehand and should be capable of these tasks.

= Requesting help from OLPC =

There are two channels to request assistance from OLPC:

# The private tech support contact address staffed by the internal OLPC deployment support team
# The OLPC bug-tracker (trac) at http://dev.laptop.org.

The tech support contact should be used for questions and unknown problems. A good example is the issue we encountered when one XO forgot its serial number. We needed to know how to rewrite the serial number from the firmware prompt. As this was a question, the techsupport contact is the right channel. If the problem of XOs forgetting serial numbers becomes a regular occurrence then it would be suitable for a trac ticket, but currently this is just a one-off.

Trac should be used for solid, well-defined problems. For example, if you found a way to crash an activity through a certain sequence of events, and this was reproducible on multiple XOs, then trac is suitable. However, high priority issues that must be fixed in the short term should be reported to techsupport, to make sure they are prioritised accordingly inside OLPC.

Trac tickets are always public; tech support requests are private unless explicitly publicised.

You may find that it's not easy to decide which support channel to use (it is not easy to explain either); if in doubt, use tech support.

Mariam and Eskender have experience reporting issues to tech support. Eskender has reported his first trac ticket.

: To come later: tech support training with the rest of the team, and a quick introduction to trac.

= Translations =

See [[Deployment Guide/Localization]]. Mariam is set up: she registered a pootle account, wrote to the mailing list to request access to Amharic translations, and translated a few strings.

: To come later: demo/explanation for the rest of the team, translating offline, discussion about translation policy (use official ICT terms or not?), discussion about targets and order of components to translate

= Mailing lists =

Mailing lists are the best way to get in contact with key players from OLPC, because your mails will usually be read by most of them. It is also the accepted practice; OLPC focuses heavily on making information publicly available and free to all. By writing to mailing lists, your questions and their answers become part of common knowledge.

Mariam has basic experience on the mailing lists.

: To come later: explanation for the rest of the team, demo of subscription and archives

= 8.2 upgrade =

: To come later, a demo/walkthrough and a discussion about upgrade plans

= General upgrading process =

: To come later: discussion about how the team should get involved with testing alpha/beta releases

= Community interaction =

: To come later: followup on mailing lists, introduction to IRC, finding help within the Ethiopian community, contributing to the wiki, generating publicity

= Working with upstream =

: To come later: discussion about the importance of staying with the OLPC way of doing things, the benefits, and costs of not doing so.