New Planning Thoughts draft.

[Martin Dengler]

Peanut gallery comments...

On Thu, Apr 17, 2008 at 12:02:02PM +0200, Marco Pesenti Gritti wrote:
> On Thu, Apr 17, 2008 at 11:23 AM, Michael Stone <michael at laptop.org> wrote:
> > Available at a wiki near you:
> >
> >   http://wiki.laptop.org/go/Plan_of_Record-2008/Draft_2
> 
> Making quick progresses, yay!
> 
> A couple of thoughts about the release process:
> 
> * Reducing the scope of the releases is a reasonable solution to deal
> with lack of QA resources. But I think on the medium term we need to
> scale. The developer community will contribute in direction which we
> don't anticipate. We cannot and should not force community focus on a
> limited number of aspects.

I'm not sure the last sentence I quoted above gets the prominence it
deserves. Focus from OLPC doesn't mean enforcing focus on the
community (probably this is uncontentious but the more it's in the
foreground of people's thoughts, the easier it can be to see the
benefits/costs of current proposals).

> * Smaller-and-faster (focused) releases are an interesting idea but I
> think they are also quite a challenge. We need to ensure that we are
> able to parallelize the various streams. For example, if we do a
> release which focuses on networking, someone will keep working on UI
> and performance at the same time. How do we avoid clashes? Having
> multiple streams going on concurrently certainly complicate the
> development process. I don't have previous experience of this kind of
> development.

In my experience, with quality developers and a bit of an edge towards -
during the development cycle only - "seek forgiveness not permission"
combined with developers being a bit less prickly about their code
than is their normal wont[1], smaller-and-faster has an amazing (ly good)
effect on productivity and quality.

I don't think OLPC lacks quality developers and it appears there is
social momentum building within OLPC for this approach (without this
grass-roots support IMO smaller-and-faster is doomed).  So adopting a
smaller-faster focus while making it easier for the community to
contribute on a more even level with "internal" developers is very
much an approach that finds a very hospitable situation.

This is an opportunity with a lot of potential...

> Marco

Martin


1. In case I'm not being clear, an extreme example of the combination
of forgiveness-not-permission and the requirement to be a bit less
prickly that I'm envisioning are mob-developed[2, 3] projects.  I'm
not saying that extreme approach is warranted (or being proposed)
here.

2. http://repo.or.cz/about.html

3. "The way out of this predicament is this simple: Set up a fairly
clear architectural direction, produce a decent first cut at some of
the functionality, let loose the source code, and then turn it over to
a mob."  http://www.dreamsongs.com/MobSoftware.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080417/2ac9fb21/attachment.sig>