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