Data Project Incubation

From OSGeo
Revision as of 11:53, 2 December 2007 by Wiki-Dpatton (talk | contribs) (update DCP info)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

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 the Degree Confluence Project being an example of a project that might wish to seek shelter/approval from OSGeo as a Data Project. One of the questions raised was how to handle such a project, which consists not only of a set of data, but also the software infrastructure to present that data on the web.

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.