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

Frank Warmerdam warmerdam at pobox.com
Mon Aug 7 14:04:27 EDT 2006


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

Cameron Shorter wrote:
> 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.

Cameron,

There are currently only a limited number of formal documents, and they
are published on the incubator.osgeo.org web site.

> 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.

The formal documents exist under SVN and are only editable by those with
developer or better privs on the incubator project (ideally this should
be all members of the incubation committee).

> 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.

Per Paul's earlier work each document has a version, a status, and a
last edited date.

> 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.

We could do this via the CN bug tracker if folks want.

> 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

We do have roughly the above process with the rough copy worked on in the
wiki, and the updates to the formal copy occuring when they are applied
on the public web site.

I will agree with the general point, that possibly changes can get lost
on the mailing list as discussions swerve in various directions.  Currently
I would claim it is up to a change proponent to stay on top of the change
requested, and bring the issue to a formal motion when they have a change
ready.

Ultimately, I don't feel like change management is a big issue, but if the
committee feels it is, I can live with a more formal approach.  I think our
issues are more along the lines of not having consensus on how high a bar
to set for incubation.

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





More information about the Incubator mailing list