How to shorten the duration of incubation (Was: Insanity...)

[Jukka Zitting <ju...@gmail.com>]

Hi,

On Tue, Nov 10, 2009 at 5:55 PM, Greg Stein <gs...@gmail.com> wrote:
> My point above was the Board, at least in the past(*), has *not* been
> happy about the average duration.

The way I see it, there are three main things we could do to shorten
the average duration of incubation:

1) Relax the exit criteria: Especially the diversity requirement is a
major barrier for many projects. There have been various calls to
relax the diversity requirements, but so far I see no consensus on
that.

2) Tighten the entry criteria: Many of the podlings that end up
failing or taking a long time here are new projects that start from
scratch or from previously closed codebases with weak or no existing
project communities. We could significantly improve the average
duration of incubation if we only accepted mature open source
projects.

3) Increase the amount of mentoring: The lack of mentor time and
better (not necessarily more) supporting documentation gives
unnecessary administrational and procedural headaches (failed release
votes, etc.) to many podlings.

Without more volunteers there's not much we can do about 3, which
leaves the entry and exit criteria as the variables we can control.

I personally think that the exit criteria are good as they are (in
hindsight, Abdera is a good example of a project that graduated with
barely enough diversity of active committers), so if we do want to
make the Incubator "work faster" my suggestion would be to start by
raising our entry criteria. One way to do that would be to start
requiring the three mentors to show higher levels of personal
commitment than what we currently ask for.

BR,

Jukka Zitting

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: How to shorten the duration of incubation (Was: Insanity...)

[Martijn Dashorst <ma...@gmail.com>]

I like the proposal of 3 steps prior to releasing... In Greg's words:
it teaches instead of hinders. It divides the arduous process of
cutting a release in more manageable steps and would make passing the
actual release easier/faster.

Martijn

On Wed, Nov 11, 2009 at 8:43 AM, Robert Burrell Donkin
<ro...@gmail.com> wrote:
> On Wed, Nov 11, 2009 at 6:08 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
>> On Wed, Nov 11, 2009 at 12:56 AM, Jukka Zitting <ju...@gmail.com> wrote:
>
> <snip>
>
>>> I personally think that the exit criteria are good as they are (in
>>> hindsight, Abdera is a good example of a project that graduated with
>>> barely enough diversity of active committers), so if we do want to
>>> make the Incubator "work faster" my suggestion would be to start by
>>> raising our entry criteria. One way to do that would be to start
>>> requiring the three mentors to show higher levels of personal
>>> commitment than what we currently ask for.
>>
>> And would Subversion qualify ??  Just kidding...
>>
>> We could do both #1 and #2 ... and then there might be a bunch of
>> 'stale' ones that we retire. And with a smaller number of incubating
>> projects, there should be more time for mentors on each one,
>> addressing your #3.
>
> my experience tells me that it's hard to guess which projects are
> going to struggle. so tightening the entry criteria may prevent
> community led projects being admitted without an improvement in
> incubator throughput.
>
> i'm not sure that loosening the entry criteria is a good idea either:
> they give corporations incentives to play our game our way. if
> graduation came to be seen as less difficult then there would be less
> incentive for corporations to invest in community building in the
> incubator.
>
> IMHO the main issue is that now the process works fine for large
> closed source donations (which covers the majority of podlings), the
> IPMC has stopped developing the process
>
> IMHO the next logical step is to break down graduation into a track
> with several modular votes based on the criteria the IPMC has
> developed for graduation. this should give a more finely grained idea
> of where a podling is and would allow immediate approval of steps for
> some podlings. for example, AIUI subversion already uses open
> development so that could be approved right away (whereas this is
> usually the most difficult criterion for podlings which a start as
> close source projects).
>
> releases are a good example. the auditing that is done when the first
> release is presented could be done as three steps of the track
> (license audit, source audit and artifact audit). only once all steps
> were complete would a podling to allowed to submit a release for
> official IPMC approval.
>
> using a track would allow a more linear progression. at the moment,
> there's a lot of work setting up the podling and getting things
> moving. getting release approval and passing community is difficult so
> most podlings drift along for quite a while once the initial effort is
> over. breaking down these big, difficult tasks into a number of
> smaller ones may make them more approachable.
>
> - robert
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org
>
>



-- 
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.4 increases type safety for web applications
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.0

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: How to shorten the duration of incubation (Was: Insanity...)

[Robert Burrell Donkin <ro...@gmail.com>]

On Wed, Nov 11, 2009 at 6:08 AM, Niclas Hedhman <ni...@hedhman.org> wrote:
> On Wed, Nov 11, 2009 at 12:56 AM, Jukka Zitting <ju...@gmail.com> wrote:

<snip>

>> I personally think that the exit criteria are good as they are (in
>> hindsight, Abdera is a good example of a project that graduated with
>> barely enough diversity of active committers), so if we do want to
>> make the Incubator "work faster" my suggestion would be to start by
>> raising our entry criteria. One way to do that would be to start
>> requiring the three mentors to show higher levels of personal
>> commitment than what we currently ask for.
>
> And would Subversion qualify ??  Just kidding...
>
> We could do both #1 and #2 ... and then there might be a bunch of
> 'stale' ones that we retire. And with a smaller number of incubating
> projects, there should be more time for mentors on each one,
> addressing your #3.

my experience tells me that it's hard to guess which projects are
going to struggle. so tightening the entry criteria may prevent
community led projects being admitted without an improvement in
incubator throughput.

i'm not sure that loosening the entry criteria is a good idea either:
they give corporations incentives to play our game our way. if
graduation came to be seen as less difficult then there would be less
incentive for corporations to invest in community building in the
incubator.

IMHO the main issue is that now the process works fine for large
closed source donations (which covers the majority of podlings), the
IPMC has stopped developing the process

IMHO the next logical step is to break down graduation into a track
with several modular votes based on the criteria the IPMC has
developed for graduation. this should give a more finely grained idea
of where a podling is and would allow immediate approval of steps for
some podlings. for example, AIUI subversion already uses open
development so that could be approved right away (whereas this is
usually the most difficult criterion for podlings which a start as
close source projects).

releases are a good example. the auditing that is done when the first
release is presented could be done as three steps of the track
(license audit, source audit and artifact audit). only once all steps
were complete would a podling to allowed to submit a release for
official IPMC approval.

using a track would allow a more linear progression. at the moment,
there's a lot of work setting up the podling and getting things
moving. getting release approval and passing community is difficult so
most podlings drift along for quite a while once the initial effort is
over. breaking down these big, difficult tasks into a number of
smaller ones may make them more approachable.

- robert

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: How to shorten the duration of incubation (Was: Insanity...)

["Alan D. Cabrera" <li...@toolazydogs.com>]

On Nov 10, 2009, at 10:08 PM, Niclas Hedhman wrote:

> On Wed, Nov 11, 2009 at 12:56 AM, Jukka Zitting <jukka.zitting@gmail.com 
> > wrote:
>>
>> 1) Relax the exit criteria: Especially the diversity requirement is a
>> major barrier for many projects. There have been various calls to
>> relax the diversity requirements, but so far I see no consensus on
>> that.
>
> Diversity requirement is actually a derived requirement of "community
> sustainability" to avoid a sponsoring entity to pull the plug of paid
> developers.

I agree that diversity is a derivative requirement however, I think  
that there should be a list of all the committers and their company  
affiliation, if they are being paid to work on the project, for every  
project web site.  I know that it's being done with varying degrees.   
But if we're going explicitly downplay diversity requirements for some  
projects then I think we need to be diligent on being upfront on the  
community makeup.


Regards,
Alan


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: How to shorten the duration of incubation (Was: Insanity...)

[Niclas Hedhman <ni...@hedhman.org>]

On Wed, Nov 11, 2009 at 12:56 AM, Jukka Zitting <ju...@gmail.com> wrote:
> On Tue, Nov 10, 2009 at 5:55 PM, Greg Stein <gs...@gmail.com> wrote:
>> My point above was the Board, at least in the past(*), has *not* been
>> happy about the average duration.
>
> The way I see it, there are three main things we could do to shorten
> the average duration of incubation:

Agree with your points...

> 1) Relax the exit criteria: Especially the diversity requirement is a
> major barrier for many projects. There have been various calls to
> relax the diversity requirements, but so far I see no consensus on
> that.

Diversity requirement is actually a derived requirement of "community
sustainability" to avoid a sponsoring entity to pull the plug of paid
developers. Another is number of active developers, ensuring that
community survives if the "main guy" get tired or is hit by bus.
So, in reality, it boils down to ASF "unwillingness" to deal with
project failures. But, ALL projects will fail, sooner or later. We
could also embrace this, and change the exit criteria to something
like "Do we think that this community will thrive for N years ahead?"
and apply that even though there are only 2 guys on it. And with Attic
getting better at folding up projects, we shouldn't worry too much
over failing communities.

> 2) Tighten the entry criteria: Many of the podlings that end up
> failing or taking a long time here are new projects that start from
> scratch or from previously closed codebases with weak or no existing
> project communities. We could significantly improve the average
> duration of incubation if we only accepted mature open source
> projects.

This is tricky. There are quite a handful of "Let's implement
JSR-1234, and I have this initial codebase..." kind of requests that
generally turn out well. I worry less about "new projects" than over
"mature closed ones" from companies lacking OSS experience.

> 3) Increase the amount of mentoring: The lack of mentor time and
> better (not necessarily more) supporting documentation gives
> unnecessary administrational and procedural headaches (failed release
> votes, etc.) to many podlings.

> Without more volunteers there's not much we can do about 3, which
> leaves the entry and exit criteria as the variables we can control.

Agree...

> I personally think that the exit criteria are good as they are (in
> hindsight, Abdera is a good example of a project that graduated with
> barely enough diversity of active committers), so if we do want to
> make the Incubator "work faster" my suggestion would be to start by
> raising our entry criteria. One way to do that would be to start
> requiring the three mentors to show higher levels of personal
> commitment than what we currently ask for.

And would Subversion qualify ??  Just kidding...

We could do both #1 and #2 ... and then there might be a bunch of
'stale' ones that we retire. And with a smaller number of incubating
projects, there should be more time for mentors on each one,
addressing your #3.


Cheers
-- 
Niclas Hedhman, Software Developer
http://www.qi4j.org - New Energy for Java

I  live here; http://tinyurl.com/2qq9er
I  work here; http://tinyurl.com/2ymelc
I relax here; http://tinyurl.com/2cgsug

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org

Re: How to shorten the duration of incubation (Was: Insanity...)

[Ross Gardler <ro...@googlemail.com>]

2009/11/10 Jukka Zitting <ju...@gmail.com>:
> 3) Increase the amount of mentoring: The lack of mentor time and
> better (not necessarily more) supporting documentation gives
> unnecessary administrational and procedural headaches (failed release
> votes, etc.) to many podlings.
>
> Without more volunteers there's not much we can do about 3, which
> leaves the entry and exit criteria as the variables we can control.

The new community development project is focussing on creating a
continuous mentoring programme based on the highly successful GSoC
programme. Whilst the project is to focus on mentoring of individuals
not initially attached to a project I suspect the materials and
processes we create will be of significant value to the mentoring of
new community members entering via podlings. To this end Noel has
requested that he be made a member of the Community Development PMC,
he will almost certainly be voted in once the projects mailing lists
are set up.

In other words, #3 may not be possible right now, but I hope that we
can improve on this area in the future.

Ross

---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org