Development Team/Manual/lang-ja

< Development Team‎ | Manual
Revision as of 19:32, 8 April 2009 by Dfarning (talk | contribs) (fix broken links)
This is an on-going translation

This manual tries to provide you with the answers you need to get started either by contributing to existing projects or starting your own development project. Although this Developer's Manual focuses mostly on the software development side of the process, we are also very interested in encouraging the contributions of:

Much of the material in the Developer's manual, particularly the Setup and Communications sections will be applicable to you as well.

  • Developers/Setup
    • Describes how to set up a Sugar development environment, with a discussion of which approach is likely to be the most appropriate for you
  • Developers/Stack
    • Describes the "operating stack" of the OLPC Sugar environment, the combination of hardware, operating system, services, libraries and activities that combine to form the environment in which you will be programming
  • Developers/Issues
    • Describes the special considerations required for working on the OLPC project, particularly those driven by our target hardware and deployment environments
  • Developers/Projects
    • Suggests ways to choose a particular project, whether one that already exists, or one of your own, and how to start working on the project once you have chosen it
  • Developers/Communication
    • Describes the various support and communications channels used by the project, including how to get help with problems, and how to set up your own per-project communications channels
  • Developers/Documentation
    • Collects pointers to the various sources of documentation available for the project. Helping us better document our code is always a welcome contribution.
  • Developers/FAQ
    • Collects and attempts to answer common questions that developers have when working on the Sugar platform

Release Schedule

We expect to be doing updates monthly through the first quarter of 2008. After that, we will likely adopt a three-month update cycle. Eventually we will adopt a six-month update cycle. It should also be noted that we will be—when time permits—moving to a build environment that enables individual activity developers to maintain their own build cycles.