Difference between revisions of "Data Project Incubation"
Wiki-JoWalsh (talk | contribs) (what would it take to incubate a data project into osgeo) |
(add categories) |
||
| Line 20: | Line 20: | ||
Early Dec 2007, [[Chris Schmidt]] is soliciting opinions from the [[Geodata Committee]] as to whether getting [http://openaerialmap.org OpenAerialMap] into an OSGeo project status via incubation would be desirable, possible, or likely. OAM is past the "fledgling" stage now, it is already being hosted on the systems at telascience being made available to members of OSGeo and the [[Geodata Committee]], and it fits with the Committee's mission well. | Early Dec 2007, [[Chris Schmidt]] is soliciting opinions from the [[Geodata Committee]] as to whether getting [http://openaerialmap.org OpenAerialMap] into an OSGeo project status via incubation would be desirable, possible, or likely. OAM is past the "fledgling" stage now, it is already being hosted on the systems at telascience being made available to members of OSGeo and the [[Geodata Committee]], and it fits with the Committee's mission well. | ||
| + | |||
| + | [[Category:Incubation]] | ||
| + | |||
| + | [[Category:Public Geospatial Data Committee]] | ||
Revision as of 10:41, 2 December 2007
Introduction
What would it take to bring a data project into incubation? To what extent could the existing incubation process and the appropriate vehicles - the PSC, any necessary CLA, etc - be useful or re-used? Can we define a process that does not put up too many barriers but helps to guarantee quality and integrity of data (or at least useful assessment of change and variation in quality) as much as of software?
Re-use of the Incubation process
The OSGeo General Principles of Incubation are not really all that software-specific apart from in a few points such as "build and smoke test systems" and "source code management" (for which we could read "metadata management")
The Incubator Application Questionnaire also can be read as not terribly software-specific and where in the few cases it is, - " Type of application does this project represent(client, server, standalone, library, etc.) - could be extended rather than materially amended.
It might be more appropriate to have a rewritten version dedicated to data projects. But often the line drawn between code and data in a distribution is not so clear.
The Project Graduation Checklist is way more software-specific and throws up bigger questions. When can a project be said to be "ready" enough if we don't have the obvious identifying triggers like code audit done, developer documentation, build and release processes. A Data Project would have different qualifying criteria in order to emerge, but when could it be considered "done" enough to graduate?
Background
This initially came up in Oct 2007 when Dave Patton raised the question of Degree Confluence being an example of a project that might wish to seek shelter/approval from OSGeo as a Data Project
Early Dec 2007, Chris Schmidt is soliciting opinions from the Geodata Committee as to whether getting OpenAerialMap into an OSGeo project status via incubation would be desirable, possible, or likely. OAM is past the "fledgling" stage now, it is already being hosted on the systems at telascience being made available to members of OSGeo and the Geodata Committee, and it fits with the Committee's mission well.