First Draft Development Process Proposal

[C. Scott Ananian]

On Mon, Jun 30, 2008 at 6:13 PM, Edward Cherlin <echerlin at gmail.com> wrote:
> On Fri, Jun 27, 2008 at 8:31 AM, Greg Smith <gregsmitholpc at gmail.com> wrote:
>> I posted a first pass Release Process Overview.
>
> We don't seem to have any process for translating textbooks and
> content. There are teacher training materials in Spanish and Nepali
> that we need in English, and a variety of other content in many
> languages.

In general, I think this is the fundamental weakness of the first
draft: it mentions that a "release" consists of core OS + "other
stuff" but really only talks about dates & deadlines & names for the
"core OS".

I don't think the solution is expanding our scope so that OLPC is
responsible for releasing every country's "other stuff" along with 8.2
at a single release date.

I think the solution is to be more explicit about where the hand offs
are, what the limits of our development/support are, and what
processes are used to support local development.  We should write into
our release process when we gives bits to local translation, activity,
and content teams, and when we need bits back from them, esp. for
localization of "reference" activities and content (library-core,
Write, Words) and for "reference" activities which are not maintained
by OLPC (Tam Tam, Etoys, Squeak).

There may be a separate "release" document that outlines the steps we
will take to support a planned large-scale deployment, including basic
QA of their "activities + core OS" image, converting it to an image
suitable for Quanta and shepherding it through their QA process, QA of
keyboards and manufacturing data on local SKUs, etc.  This timetable
is driven by the deployment, but we should set reasonable expectations
for what steps are required, in what order, and how much time is
needed for each.  I'd also like to see quality expectations set, since
the success and reputation of OLPC may depend on the success of these
large-scale deployments.  This is both technical (their release should
work) and aesthetic (icons for local activities should conform to
Sugar guidelines, the ordering should be logical, etc).

For the bits of non-core OS "other stuff" we do, we should commit to a
schedule.  When is the first draft of the release notes available?
Are the final versions of the reference activities synchronized with
the core OS, or can/do they lag it by a week (or two, or three)?
After how long does a release candidate become a release?  What
happens if there is a critical bug discovered in a "not maintained
here" reference activity?  Our biggest weakness to date is "not
knowing when we're done" because the core OS is "good enough" but the
other stuff isn't getting done.
 --scott

-- 
 ( http://cscott.net/ )