Specifications

A short key

[[wiki pages]] and their style guidelines are largely community-driven.   
{notes in curlies} indicate important items whose definitions may change.
* bulleted items are "in progress".
    intro paragraphs to a more detailed article are included inline for illustration

Specs in brief

Each item below needs its own page and detailed discussion. A good bit of development and planning has been done without specifications, and in pursuit of a narrow if admirable set of goals without detailed or spanning use cases.

Content, linking, publishing

Link once, find everywhere : It should be possible to link out to further information without knowing how far away the information is on the network. URLs have to do with location; even URIs have overtones of being a specific resource and not a specific concept. If I want to link out to more information about monkeys, I should be able to denote that without specifying the exact resource I want to use -- the reader will have only a limited set of resources available.

As an example: I might include the link info:monkeys and wish to specify that I want the "info" namespace to look first for a local dictionary service; then for content bundles named "info", "dictionary", "wiki", "wikipedia"; then for a "monkeys" page on a local school server, a regional server, or a set of websites (each with their own mapping of a keyword to a URL). These mappings could be provided in a global database, a most-used subset of which is on every XO; with optional overrides and changes in priority contained within a content bundle. Finally, there should be options for what to do when multiple namespaces exist -- the link to 'monkeys' might indicate on hover how many options there are beyond the obvious; a global preference might cause following a multiple-result hyperlinks to display a list of search results rather than immediately taking you to the top ranked result.

Contribution process : Guidelines and explicit forms for contributing files, bundles, or collections to be automatically-bundled to the [[global library]] and to one's local network; the former through interfaces on the Internet, the latter through the local library interface.

one global process; national addenda*

New language requests : Guidelines for making a new language request -- wiki, pootle, core library, mailing list, keyboard, IRC channel.

Knowledge flow : How ideas and knowledge and information should flow through an XO community and network. See Memebrand.

Libraries and Activities

Library interface : A dynamic and searchable view of the collections and activities on one's XO, including data from one's Journal and from accessible online collections; including a way to add new collections to what is locally accessible, and a way to explicitly see and update one's local cache.

Educational categories : A set of top-level categories for early education, from the source at core library topics, according to guidelines for category priority, with a section for new category suggestions.

one globally. localized*.

XO core content : A set of bundles about the XO and other, filtered up via the featured content page, selected by the {OLPC team}.

one per language*.

XO bundle archive : A set of activity and library bundles stored on-disk, not quite as good or central as the core library but shipped on every laptop. Includes other featured content, bundles chosen for their compliance with the featured content guidelines

one globally. localized*.

Exemplary content bundles : Bundles covering a specific topic in broad, simple strokes, with links to originals and further information online, and clear attribution of authors and curators.

one for select topics (biology, picturbooks, &c). localized*.

XO core activities : A set of core activities that ships on every build (no distinction between 'olpc-maintained', 'etoys-maintained', &c), selected from the list at core activities by the {OLPC team}.

XO bundled activities : A set of activities included in the XO bundle archive, from the list of featured activities, selected for their compliance with featured activity guidelines.

XS school content : A set of free/NC bundles and large datasets for a school library, including all featured bundles; drawn from the [[featured collections]] list and guided by the relevant guidelines, in three versions:

(1) for a 1GB USB stick ( one per language )

(2) for a DVD ( one globally, many langs )

(3) for 150GB of disk ( one globally, " ", with regional non-free variants)

Global library : guidelines for contributing content and code to, organizing, and browsing the global library of collections of material produced by the XO network.

one globally, localized.

Library network : Guidelines for defining and linking to [[local repositories]] of libraries and collections designed for use with the XO; including non-free additions to the XSL (3), existing digital libraries, and any other materials.

Community

Local group creation: A process for identifying and announcing an [[OLPC user group]], including definition on a project page, identifying members, applying for an email account and sending mail to the grassroots list.

includes guidelines for interacting with local government, media, event organizers, NGOs, LUGs, and the like.

Official community hubs: Guidelines for becoming an officially-recognized OLPC community hub, with public details about projects and members, eligible for local receipt and distribution of community XOs. This ties into local aggregation of laptop distribution.

Laptop distribution: Guidelines for submitting a project, use case, or other request for short or long-term use of community XOs to develop, test, promote, research, educate or inspire on or with the laptops; guided by a list of XO request guidelines that encourages community debate, prioritization, and sharing of new projects. A process for regular selection of projects and groups to receive laptops.

Communication

irc channels: Channels should be identified by broad topic (core devel, content, olpc in general, local groups) and by language (olpc-es, olpc-de), with preference to the former. Topical channels should be multilingual. Individual country channels should be merged into the above, since the community is not bound by national borders (and frankly, everyone in the community is interestd in what's going on in individual countries; language barriers happen to be the highest limiting factor to very broad shared discussion.

mailing lists : should be kept to a limited number with reasonable traffic; with olpc and devel being largest, and with devel and sugar restricted to core and not activity issues.

• posting to lists should be open to non-subscribers, archives public and cross-posting encouraged
• proposed groups: devel, sugar, activities*, library, localization | countries, groups, olpc**

  * possibly splitting into new lists for huge activities (etoys)
 ** general discussion; splitting into new lists by language

Suggestion: most of the following can be merged into the bolded lists. devel security networking linux-mm-cc?? activities (new) games etoys? stirme colingoxo gasp? sugar accessibility openec extras (new) peripherals livebackup-xo-cd design (make public) library docs educators (unused) research? localization countries (multilingual), peru [see also olpc-es] argentina [see also olpc-es] brasil [see also olpc-pt] india

groups (multilingual) olpc-chicago olpc-philippines olpc-indonesia toronto-dev olpc-za colombia

olpc (multilingual, mostly english), olpc-open --> olpc research --> olpc egypt-opensource nigeria-opensource aop (sigh) olpc-es (spanish) olpc-pt (portuguese) olpc-de (german)

mail/message syndication : move to a {group-membership + feed-subscription} model, where

• community members have attributes such as group membership defining who they are and what they are interested in
• mailing-list addresses have attributes defining what topics they cover, and associated feeds.

Community members should be able to add attributes such as "olpc-office-list" and "cambridge-group" so that they get all mail intended for the specific office list (however that is defined) or for any cantabridgians (all lists for people in cambridge). This will allow for accurate targeting of emails without spamming lists too broadly. We should also have

• a whitelist for known active users, who should not need to pass through any spam filters such as "has this person joined this public list?" to be able to post.

Visual specifications

Bundles

• Activity bundles
• Content bundles

Graphics

• Graphics API

Controls

• Trays
• Palettes

Services

• Clipboard
• Dialogs
• File Choosers
• Notifications

Security

• Manifest Specification
• Firmware Key and Signature Formats

Activities

• Journal
• Browse
• Read
• Write
• Paint
• Chat
• Record
• Memorize
• Calculate
• Measure