Fwd: [Incubator] Project Incubation Mentor

[Frank Warmerdam]

Jody Garnett wrote:
> To be something "foundational" I expect geotools to work on its own 
> foundations, with focus on standards support (already there), 
> consistency of code (horrible but shows great signs for improvement), 
> with a lesser focus on completeness of solution (we are a library with a 
> clear focus, and a growing list of things we are not - such as widget 
> toolkit).

Jody,

Do you think that consistency of code ought to be a requirement in
some fashion for completing incubation?  Consistency is obviously
desirable, but if we require GeoTools to satisfy such a requirement, does
that mean we should be holding all projects to the same yardstick?

> And finally the biggest is accessibility - geotools needs to be able to 
> provide at *least* an intro to use, even if that consists of demo 
> programs with comments.

Once again, this is obviously desirable but should it be a requirement of
incubation?

In this case I would be pleased to have something in this regard made
a requirement of incubation.  Essentially, for the sake of the foundation
(and the benefit to it's projects) I would like to see all projects have
a clear route for new users of the project to get into them.

That is, clearly marked and working getting started instructions,
ready to use binaries, general explanatory material and so forth.

For an SDK like GeoTools or GDAL this ought to include some sort of tutorial
for using the API.  For an end user application like GRASS this would be a
"getting started" guide.  Something like OSSIM that has applications and
an SDK might offer both entries, or at least pick one that they think is
primary and cover it well.

It seems to me that for several years MapServer's getting started document
used a demo dataset with gif files that did not work with the common
binaries of MapServer.  It was a source of ongoing churn and frustration
for new users.  Ensuring we don't have something like this hanging around
for long periods of time is what I mean by the "working" requirement on
the getting started document.

Basically, I'm suggesting that foundation projects have to take new users
seriously and make it a project priority.  The foundation is going to go
to a good deal of effort to bring new users to the table and one thing
we would ask is that the projects treat them right when they arrive.

Part of incubation could be that some of the committee members who have
not previously been involved in the project go through the "new user
process" and report on it.

Would anyone supportive of this idea like to write it up in the wiki for
us to consider as a requirement at the next meeting?

> So I do not expect to be fast tracked, it is more important to do things 
> well. One thing we are all using OSGEO for is a venue for improvement, 
> while improvements in publicity may be visible, the incubator committee 
> will be in charge of much of the "maturity" concerns and will set the 
> pace and reputation that will prop up the OSGEO brand.

Agreed.  Till now I haven't perceived much interest in having the
incubator impose maturity requirements (beyond IP and governance).  If
we can reach general agreement on additional requirements that will be
good for the projects and the foundations reputation then I'm up for it
too.

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