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

[Cameron Shorter]

I've attempted to capture the Project Graduation Criteria in a proposed 
OSGeo document at:
http://wiki.osgeo.org/index.php/Project_Graduation_Checklist

Feedback welcomed.

Jody Garnett wrote:
> 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
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: incubator-unsubscribe at incubator.osgeo.org
> For additional commands, e-mail: incubator-help at incubator.osgeo.org
> 
> 


-- 
Cameron Shorter
http://cameron.shorter.net