| Requirements ||
|| Strictly speaking, this is not a technical feature; however, like technical features, this would require developer time in exchange for enhancing our capabilities to implement and (commercially) support technical features, so I am including it here.
- A separate, non-community-maintained, website for formal user and developer documentation (Precedents: Fedora/Red Hat, Ubuntu), posted in a publicly viewable but edit-protected place. (i.e. not publicwiki as it now stands.)
- On this site, a canonical list of all the technical subcomponents that make up the OLPC system that the organization supports.
- For each subcomponent, a howto/code-tour for the kind of developers we want to have working on that portion of the project.
- Note that this could be "Code is available for download, but community development is not officially supported by the OLPC organization," and a link to the all-community wiki (or appropriate pages as on SugarLabs).
- Intended audience: developers with code experience but no OLPC-specific project background
- Put a link in the library on the XO which links to GIT or other relevant source. (added by Gnu)
| Specification ||
|| If this were implemented mainly by developers, it would be a large task for the developer responsible for each subcomponent to take responsibility for creating this section. So instead, I would suggest putting the load on a single editor who would be in charge of talking with developers, asking them questions, and formatting their (objective: minimize the workload on developers as much as possible). I could see this being half-time contract work, maybe for 2-3 months during 9.1 development, to create and release a first version of a "developers' center" with an infrastructure that can be easily updated for future releases.