What could an Incubation Sprint help achieve? (was Re: [OSGeo-Board] Board meeting April 7)

Jo Walsh jo at frot.org
Fri Apr 7 18:09:52 EDT 2006


dear Frank, all, sorry for the lag on this response (been stuck in an 
MIT event all day) which I want to offer in two pieces, and also offer 
the first half to IncCom.

On Fri, Apr 07, 2006 at 09:51:02AM -0400, Frank Warmerdam wrote:
> >on middle ground between "sprint" on short-term goals (Incubation) and
> >longer-term ones (pilot projects that would benefit from
> >infrastructure already in place) and where the middle ground can be.
> 
> In my mind a sprint should have pretty concrete goals going in, and
> should require the dedicated togetherness in order to reach agreement,
> often involving substantial compromise.  (at least a policy sprint,
> as opposed to a code sprint).

I'm only lurking in Incubation and don't have a personal stake in it, 
so I may not have a clear sense of what needs to be defined in the
process, where the really important areas that need compromise are.
As a relative outsider to the process, here's what I've picked up:

While all "Graduation Criteria" can be problematic to define, some
reach discrete, quantitative resolutions ('project X does this / it
doesn't') easily once they're defined; others are more subjective, and
need to reach a "lowest common denominator" which can be continually
assessed.

Quantitative areas:
- code provenance 
- licensing and legal
- build and smoke testing where applicable

Qualitative areas:
- 'democratic' nature of internal project maintenance
- 'healthiness' of development community and activity
- 'moribundness' that may trigger return to incubation limbo
 
The first project that incubates is going to set a de facto standard. 
To have several projects incubate at once which are facing different 
kinds of problems, would be helpful in establishing a more
durable standard, a contract, for future incubation. 

Right now there is work going on simultaneously to bring projects into
a state where they are ready to leave the Incubator, and to decide
what it actually means to have left the Incubator. There's a broad
description of what it means to incubate, in several pages on the wiki
and in the minds of many people in IncCom. Wiki looks like a good
place to work on this, email can easily trail off into specifics or
get very dialectical.  
 
http://wiki.osgeo.org/index.php/Apache_vs._OSGeo_Incubation_Review
http://wiki.osgeo.org/index.php/Graduating_Incubation_Criteria
http://wiki.osgeo.org/index.php/Incubation_FAQ

Getting code legal status cleared up, and getting clear per-project 
governance process outlined, provides a lot of value to each project; 
the Foundation provides a reason for that to happen.

So I imagine an Incubation Sprint, if the Foundation was in a position
to sponsor one, would address both sides of this, depending on how soon
it could happen or needed to happen: 
1/ To establish a firm contract / ruleset describing 'graduation'
2/ To help more projects resolve their incubation issues

Chris first coined the phrase "Incubation Sprint", and I've been 
using it without fully inspecting it; so this has been an excuse 
for me to look over the Incubation status docs and get a sense 
of where the holes are; and I would appreciate an elucidation
from Chris about what else the term could mean. 

Perhaps there's not enough in Incubation alone to justify people
getting together F2F; the process will evolve through the wiki, and the
projects will complete the process according to their own momentum. 
Something that is simply a "policy" sprint may not generate
excitement; that's why I'd like to include a code/shared project
aspect, and why I thought of the phrase Incubation/Stack Sprint.

Part 2 later, this is probably enough for one email,

warm regards,


jo




More information about the Incubator mailing list