ZOO-Project Incubation Checklist

= Incubation Checklist =
== Open ==
	 
The project has demonstrated that it has an open, active and healthy user and developer community:	
# Open: projects are expected to function in an open and public manner and include:
#* Open source license(s),
#** The ZOO-Project is primarily under the BSD LICENSE and the Provenance Review has confirmed there are no known problems.
#* Open communication channels,
#** The zoo-discuss list is public and active. IRC and other Contact points also available.
#* Open decision making process,
#** zoo-psc list is public (see reference email). PSC meeting agenda and results available (for instance PSC Meeting 19).
# Active and healthy community:
#* The project should have a community of developers and users who actively collaborate and support each other in a healthy way. 
#** Release processes are open and documented at http://zoo-project.org/trac/wiki/ReleaseProcedure
#** Bugs and features on Trac 
#** Disucussions occurs on mailing lists ZOO-Discuss and ZOO-PSC (see )
#** http://www.zoo-project.org/site/ZooWebSite/ZooProject/Tribe provides informations about the community
#* Long term viability of the project is demonstrated by showing participation and direction from multiple developers, who come from multiple organisations. 
#** contributions come from GeoLabs SARL, Fundazione Edmund Mach, Osaka City University and some more.
== Copyright and License ==
We need to ensure that the project owns or otherwise has obtained the ability to release the project code by completing the following steps:
# All project source code is available under an Open Source license.
#* Yes, as seen in LICENSE.
# Project documentation is available under an open license, such as Creative Commons.
#* The documentation license is now well stated on its front page.
# The project code, documentation and data has been adequately vetted to assure it is all properly licensed, and a copyright notice included, as per a Provenance Review.
#* Provenance review completed, no issues.
# The project maintains a list of all copyright holders identified in the Provenance Review Document.
#* In some sense, the prevenance review for the ZOO-Kernel point to the LICENCE file which should bne updated at any new commit as specified in the contribution rules.
# All code contributors have agreed to abide by the project's license policy, and this agreement has been documented and archived.
#* The code contribution guidelines have been documented and agreed to by all developers.
== Processes ==
# The project has code under configuration management. Eg, subversion, git.
#* Yes http://svn.zoo-project.org/svn/
# The project uses an issue tracker and keeps the status of the issue tracker up to date.
#* Yes, at http://zoo-project.org/trac
# The project has documented its management processes. This is typically done within a Developers Guide or Project Management Plan.
#* Yes, at http://zoo-project.org/docs/community/developer.html
# The project has a suitable open governance policy ensuring decisions are made, documented and adhered to in a public manner. This typically means a Project Management Committee has been established with a process for adding new members. A robust Project Management Committee will typically draw upon developers, users and key stakeholders from multiple organisations as there will be a greater variety of technical visions and the project is more resilient to a sponsor leaving.
#* Yes, there is a functioning PSC http://www.zoo-project.org/trac/wiki/PSC/process.
# The project uses public communication channels for decision making to maintain transparency. E.g. archived email list(s), archived IRC channel(s), public issue tracker.
#* Yes, IRC, zoo-discuss, and Trac.
== Documentation ==
# The project has user documentation:
#* Including sufficient detail to guide a new user through performing the core functionality provided by the application.
#** User documentation using Sphinx (source ) is avaiable from .
# The project has developer documentation:
#* Including checkout and build instructions.
#** Checkout instructions are here: 
#** Build instructions are here: 
#* Including commented code, ideally published for developer use. Examples: javadocs for Java applications, or Sphinx documentation for Python applications.
#** The code comments are using Doxygen and available from .
#* Providing sufficient detail for an experience programmer to contribute patches or a new module in accordance with the project's programming conventions.
==Release Procedure==
In order to maintain a consistent level of quality, the project should follow defined release and testing processes.
# The project follows a defined release process:
#* Which includes execution of the testing process before releasing a stable release. 
# The project follows a documented testing process. Ideally, this includes both automated and manual testingIdeally this includes documented conformance to set quality goals, such as reporting Percentage Code Coverage of Unit Tests.
# Release and testing processes provide sufficient detail for an experienced programmer to follow.
= OSGeo Committees and Community =
The OSGeo Foundation is made up of a number of committees, projects and local chapters. This section gathers up information these groups have requested from OSGeo projects. These expectations are not mandatory requirements before graduation, but a project should be prepared to address them in order to be considered a good OSGeo citizen.
== Board ==
The OSGeo Board holds ultimate responsibility for all OSGeo activities. The Board requests:
# A project provide a Project Officer as a contract point:
#* The Project Officer should be listed at: Project Officer
#* This person is established when the incubation committee recommends the project for graduation
#* Your community can change the project officer as needed (just add an agenda item to the next board meeting so they can recognise the change of officer).
== Marketing ==
Access to OSGeo's Marketing_Committee and associated Marketing_Pipeline is one of the key benefits of joining the OSGeo foundation. The Marketing Committee requests:
# Marketing artefacts have been created about the project in line with the incubation criteria listed in the OSGeo Marketing Committee's Marketing Artefacts. This lists the documentation requirements for OSGeo-Live. Marketing Artefacts include:
#* Application Overview
#* Application Quick Start
#* Logo
#* Graphical Image
# Ideally, stable version(s) of executable applications are bundled with appropriate distributions.In most cases, this will at least include OSGeo-Live, but may also include DebianGIS, UbuntuGIS, and/or osgeo4w ms4w, etc.)
== Projects ==
Projects do not exist in isolation; and are expected to communicate and collaborate on key issues. 
As an example the PostGIS release procedure asks that the release be checked with MapServer, GeoServer and others.
== SAC ==
The System Administration Committee is available to help infrastructure and facilities. Information for this committee is collected as part of the Project Status Template. The following should be set up:
* A http://projectname.osgeo.org domain name.
A project may optionally request SAC help to make use of:
* OSGeo issue tracker
* OSGeo mailing list
* OSGeo svn
* http://downloads.osgeo.org
Category: Incubation