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 <[EMAIL PROTECTED]> 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
pgpTRkEhyatlw.pgp
Description: PGP signature
_______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel