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

[Paul Spencer]

This makes me think that we need to implement a process improvement  
process for the IncCom.  We need a mechanism to take ideas like this  
and ensure that they are seriously considered, debated and actioned  
as necessary.

The process can be informal (which is what we have now - ideas are  
debated on the list until someone creates a motion to the IncCom) or  
more formal (like MapServer RFCs with a documented rationale and list  
of changes required to the current set of official documents).

Debate :)

Personally, I think we should consider a more formal process because  
I think it is too easy to lose things in long email threads.  For  
instance, Jody has suggested 3 more areas of improvement ... its not  
a big stretch to imagine that someone will reply to one or two of  
those and start a new tangent and we will lose the original intent of  
the thread which was to decide what to do about Sean's points.

It also makes it easier to track changes to official documents -  
every version will be tied to a process improvement suggestion (or  
more than one perhaps).

Cheers

Paul

On 21-Jul-06, at 3:54 AM, 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
>

+-----------------------------------------------------------------+
|Paul Spencer                           pspencer at dmsolutions.ca   |
+-----------------------------------------------------------------+
|Applications & Software Development                              |
|DM Solutions Group Inc                 http://www.dmsolutions.ca/|
+-----------------------------------------------------------------+