incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martijn Dashorst <>
Subject Re: How to shorten the duration of incubation (Was: Insanity...)
Date Wed, 11 Nov 2009 08:07:49 GMT
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.


On Wed, Nov 11, 2009 at 8:43 AM, Robert Burrell Donkin
<> wrote:
> On Wed, Nov 11, 2009 at 6:08 AM, Niclas Hedhman <> wrote:
>> On Wed, Nov 11, 2009 at 12:56 AM, Jukka Zitting <> 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:
> For additional commands, e-mail:

Become a Wicket expert, learn from the best:
Apache Wicket 1.4 increases type safety for web applications
Get it now:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message