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

[Jody Garnett]

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?
Well I am not *sure* GeoTools is going to make it, not even sure we are 
doing our best at the moment - inclusion in OSGeo is does not contribute 
to the code, and all the volunteers we have are interested in code (with 
one exception for documentation).  While the sign of a healthy open 
source project it does throw completion into doubt.  We have also had a 
bit of breakdown in process, but once again a healthy community found a 
way through...

We are also setting our own bar for such things as documentation, my 
impression has always been that we would revise the "standards" after 
seeing what the original 8 projects did on route to being "ready".


> 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)
4) User Documentation
5) Documented Release Cycle
If I am adding to my list, a bug tracker is a fine requirement - but one 
should also consider "release cycle" (something GeoTools only recently 
aquired and is still working on).
My reasoning is this ... it is hard to set deadlines when working with 
open source projects.
I would like people around the world to be able to *depend* on OSGEO 
projects to keep to a documented release process so that those making 
use of the projects can constrain risk and/or have an idea of when 
features will be made available.  I admit a formal cycle (say 6 months) 
would be much better, but a release process that interested parties 
could help along for a deadline would also work.
6) Marketing Requirments
I have not pushed this one because I have been waiting for the VisCon or 
WebCon group to establish what is needed. But for the OSGEO foundation 
to promote a project some minimum of marketting materials should be 
available. An pdf A4 handout and a Feature Matrix would probably cut it 
as a minimum.

Cheers,
Jody