Michael Sparks recently provided a follow-up to a post I made to the Kamaelia list regarding my most recent Kamaelia-related post here on this blog.

There is TONS and TONS of *EXTREMELY* valuable information contained in what amounts to about 2 printed pages of text. As such, and with his permission, I am re-publishing his entire post such that those who might read this can gain a full understanding of the methods Michael has chosen in regards to managing the Kamaelia project, the influences that helped form his chosen method, and an understanding of some of the benefits he has already started to notice because of this choice.

NOTE: Once I notice his original post archived on the SF.net list server, I will update accordingly with a link.

With that, via a post to the Kamaelia project list dated Oct 22, 2006 9:27 AM (MDT(-0600)), Michael Sparks, a scientist working for the Research & Development arm of the British Broadcasting Corporation (BBC R&D), provides the following information, re-published in its entirety, in regards to that in which is mentioned above.

[Michael Sparks:Original Post:Start]

Thanks for this. Incidentally our approach with meetings is based on some good
practice I’ve seen from Canonical and the PyPy projects.

Kamaelia development inside the BBC went cross site (when I moved sites)
earlier in the year, and we decided at that point to formalise our meeting
practices, and also take advantage of what I’d seen as best practice.

I don’t think the pypy project still produce minutes, and I don’t know if
canonical produce them either, but we find minutes useful, especially when
going back and finding out how long something’s actually taken rather than
what we expected. Others can also go back and see when, where, how and why
design decisions were taken.

Our current project management processes (including use of IRC and meetings)
are described here:
* http://kamaelia.sourceforge.net/KamaeliaProjectProcesses.html

Similarly we have a page for how development progresses from initial idea
(sketch) through to inclusion in the main codebase & release:
* http://kamaelia.sourceforge.net/KamaeliaProjectDevelopment.html

And as I say influenced by what I’ve seen working well in a variety of
different projects over time. Both sets of processes are open to debate
and update.

The process from sketch to production code is partly influenced by Paul
Graham’s Hacker’s & Painter’s essay in that it correctly recognises that
lots of early development (often termed hacks) can be termed Sketches (in
the usual artistic view), but that what you want to release may want to
be more engineered than that. (Allowing a migration route from something
hacked together to something reusable).

This stems from the fact that I feel development is akin to painting early on,
but is closer engineering as the design/implementation idea becomes more
concrete. So far this approach seems to work out quite nicely. (as a sketch
becomes more useful, and more used there’s a kind of developmental gravity
well that pulls it back into /Code, and as an idea formulates or becomes
volatile it becomes natural to either start it or migrate it to /Sketches)

The really nice side effect of this is that it’s very natural to want
to offer hosting space in Kamaelia /Sketches area to people developing
Kamaelia components since it helps with managing the growth and direction
of the main release tree.

It also encouraged the creation of the Kamaelia.Community bundling format:

http://kamaelia.sourceforge.net/cgi-bin/blog/blog.cgi?rm=viewpost&nodeid=1148942995

Which is kinda based on a melding of a development process with both perl &
python’s approach to packaging & namespaces :-)

Michael.

[Michael Sparks:Original Post:End]

For extended information regarding the Kamaelia project, please visit the project home located @ http://kamaelia.sourceforge.net/Home

To read more in regards to what Michael has to say on various topics, I would *HIGHLY* recommend both visiting and subscribing to his blog located @ http://yeoldeclue.com/blog

Thanks for this information, Michael! *VERY* much appreciated :)