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

[Cameron Shorter]

Paul Spencer wrote:
> 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).

Paul, I agree with you 100%.  And here are my implementation suggestions 
for formal documents like 
http://wiki.osgeo.org/index.php/Project_Status_Template

0. There should only be a limited set of Formal documents - the rest can 
remain in the current wiki format.

1. Formal documents should not editable (via a wiki or similar).  This 
could mean exporting to PDF, HTML or maybe locking the wiki editors to 
one person.

2. The document should be given a version number, release date and 
owner.  The owner will probably be one of the OSGeo committees.  For the 
ProjectStatusTemplate, this would be the Incubator Committee.

3. People should be able to raise "issues" against the document 
(referencing the doc and version number). These issues could be captured 
in the document's wiki, or in a bug tracking system.  I'd be inclined to 
track issues in a bug tracking system.

4. The workflow for a documentation issue would be:
* Open: Issue created by someone referencing document and version
* Open: Comments added to issue
* Fixed: Rough concensus has produced suggested replacement text
* Approved: Owner committee has voted and approved change
* Closed: Change has been incorpored in new version of document

To minimise overhead, the committee would probably approve a number of 
issues at once.

> 
> 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/|
> +-----------------------------------------------------------------+
> 
> 
> 
> 
> 
> ---------------------------------------------------------------------
> 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