[Incubator] seang on "How Rigorous is OSGeo Software Incubation?"

[Frank Warmerdam]

Paul Spencer wrote:
> As usual, Sean has clearly and concisely stated his case.  From my 
> reading, there are three specific things that he is suggesting that we 
> address:
> 
> 1) it is implied that all 8 original projects will graduate
> 
> I agree that it is assumed that all the projects will graduate.  I think 
> this is actually built into the process of accepting any project into 
> incubation.  By design, we only accept projects that we think have a 
> reasonable chance of graduating.  Should it be otherwise?  Is this 
> actually a critical flaw?

Paul,

The intention was that the original eight projects were expected to
be able to pass - that in fact we would use them as a sort of guideline
for the level of maturity we were looking for.  But we have also clearly
taken the position that in some respects the original 8 projects will
have to improve themselves to pass, most obviously with regard to the
detailed code audit.

I don't agree that it is assumable that any of the original 8 will
graduate, but I think they all have the potential to graduate given
sufficient work.

> 2) bug tracking
> 
> agreed and this probably should have stopped graduation.  I like 
> Cameron's input on the 6 month timeframe ... so if a project has to 
> implement a new process to adhere to the "OSGeo Way", we should allow 
> that process a minimum of 6 months to mature.

I don't agree that this should have stopped graduation, since a plan
to use a bug tracker was put in place.

I personally think it is over-the-top to demand a six-month waiting
period to see if process improvements "take".  I feel this would
unnecessarily drag out the incubation process with little clear benefit.

Of course, we need to reach some sort of consensus on how to approach
this.

> For this item specifically, I think it would be useful to expand some of 
> the official documentation with some of the text in Sean's blog to 
> justify a more rigid requirement on bug tracking.

I am not opposed to this.  I do think that effective use of a bug tracking
system is an important aspect of a project so it doesn't hurt to be more
explicit about what we are looking for in this regard.

> 3) social health
> 
> In the specific case of GDAL, we should probably apply the above rule 
> and wait about 6 months to see if the new PSC actually starts to work.  
> One of my comments in the status report was that I had not really had a 
> chance to see the PSC in action, and this 'rule of thumb' would 
> certainly address that.
> 
> I don't have a specific proposal to put forward to the IncCom yet, but 
> it seems that we should tighten up the incubation process to include
> 
> - more rigourous requirements for bug tracking (update documentation 
> accordingly)
> - a minimum maturation time of X months for new processes implemented as 
> part of meeting the OSGeo way (i.e. implementing a PSC or bug tracking)

I'm pretty nervous about this talk of "X months wait".   I would agree that
Paul might reasonably withhold a recommendation on GDAL till he sees that the
PSC is actually in control of the project in a meaningful sense.

> I'd like to see some feedback from other IncCom folks too.

Yes, me too.  I'm sorry for having taken so long to respond.

Best regards,
-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGF, http://osgeo.org