Fwd: [Incubator] Project Incubation Mentor

[Jody Garnett]

Frank Warmerdam wrote:
> 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?
Well geotools is a library, so I can and need that yardstick. I do need 
to be
explicit. GeoTools sets some standards, and they actually need to be 
followed
for the library to be used in some environments (like a web server or 
eclipse).
If they are not followed the users get in lots of trouble and 
frustration - so this is
the kind of QA and maturity I would expect from something escaping the
OSGEO process.

So "consistency" was perhaps too lax a word.
>> 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?
Once again for a library I would need to say yes. If this was an 
application that
could be run that is one thing (ie if it runs you can poke at it and use 
it). For a
library I should expect to see some sample use.
> 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.
Agreed, the actual details do not matter - it is the thought (literally 
of your users) that counts.
> 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?
I would consider it basic house keeping...

Cheers,
Jody