Page to be filled in based on: Project Graduation Checklist .

1. Open: projects are expected to function in an open and public manner and include:
   • Open source license (s): GPL
   • Open communication channels: geoserver-devel, geoserver-user, issue tracker
   • Open decision making process: public change control (GeoServer Improvement Process), bi-weekly cross project meetings
2. 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.
     • Collaboration on latest GeoServer 2.2 Release
     • Recent addition of geoserver-user rep to PSC
   • Long term viability of the project is demonstrated by showing participation and direction from multiple developers, who come from multiple organisations.
     • Yes, project is held by neutral party under direction of a project steering committee. A range of organisations are represented and participate in the project, spanning from commercial companies, research institutes and individuals.

1. All project source code is available under an Open Source license.

   • done: GeoServer License Page - for GPL with EPL Exception

2. Project documentation is available under an open license.

   • done: User Manual - see footer for CC

3. The project code, documentation and data has been adequately vetted to assure it is all properly licensed, and a copyright notice included.

   • done: [GeoServer Provenance Review](GeoServer Provenance Review)

4. The project maintains a list of all copyright holders identified in the Provenance Review Document.

   • Done: OpenPlans asks for copyright assignment

5. All code contributors have agreed to abide by the project’s license policy, and this agreement has been documented and archived.

   • Done: OpenPlans maintains an archived of signed agreement, we also ask contributors for email confirmation to geoserver-devel list.

1. The project has code under configuration management:

   • Done: http://github.com/geoserver

2. The project uses an issue tracker and keeps the status of the issue tracker up to date:

   • Done: http://jira.codehaus.org/browse/GEOS

3. The project has documented its management processes:

   • Done: http://docs.geoserver.org/stable/en/developer/

1. The project has user documentation

   • Including sufficient detail to guide a new user through performing the core functionality provided by the application: http://docs.geoserver.org/stable/en/user/

2. The project has developer documentation: Geoserver Developers Manual

   • Including checkout and build instructions: Quickstart

   • Including commented code, ideally published for developer use.

     Each release Stable has API Documentation download, and Source Code download archives.

   • Providing sufficient detail for an experience programmer to contribute patches or a new module in accordance with the project’s programming conventions.

     Developers Manual includes Policies and Procedures covers the nuts and bolts of committing, submitting patches, code reviews. Community process including formal GSIP change control and the functioning of the steering committee.

     There is a relaxed community module sandbox to foster new developers.

1. The project follows a defined release process:

   • Done: We have long maintained a Release Guide, recently this has been improved with automated release scripts which can be executed on our build box.
   • Which includes execution of the testing process before releasing a stable release. We have a Release Testing Checklist and CITE Test Guide, moreover the continuous build server builds GeoServer and runs the build tests whenever a new commit is spotted in the revision control.

2. The project follows a documented testing process.

   • Ideally, this includes both automated and manual testing:

     The build box (http://hudson.opengeo.org/hudson/) contains automated testing as part of the build process.

     In addition integration tests with databases are available, along with CITE conformance tests.

   • Ideally this includes documented conformance to set quality goals, such as reporting Percentage Code Coverage of Unit Tests.

     Test coverage of 40% is required for a community module to be promoted for formal inclusion in the application.

     CITE test conformance is required for release.

     All large modifications, as well as any contribution outside of the core developer circle are subject to peer review.

3. Release and testing processes provide sufficient detail for an experienced programmer to follow.

   • The Developers Manual includes the section Release Guide documenting how volunteers can step up and make a release.

1. Provide a Project Officer as a contract point:
   • Done: Andrea has accepted the nomination

1. Marketing artefacts have been created about the project in line with the incubation criteria listed in the OSGeo Marketing Committee’s Marketing Artefacts.

• Done: OSGeo Live Overview and Quickstart
• Logo: “GeoServer Branding”Powered by GeoServer and GeoServer Branding Guide (PDF)

2. Ideally, stable version (s) of executable applications are bundled with appropriate distributions.
   • Done: Platform independent packages as well as Windows and OSX installers are build for every release, moreover platform independent packages are built every night and made available to the user community for testing.
   • Done: OSGeo Live GeoServer Overview

Projects do not exist in isolation; and are expected to communicate and collaborate on key issues.

• GeoServer has bi-weekly meetings with the GeoTools project
• uDig releases are tested against the latest GeoServer
• PostGIS release procedure tests against GeoServer

1. The following should be set up: http://geoserver.osgeo.org domain name

   • not requested - The osgeo.org website links to geoserver.org

2. A project may optionally request SAC help to make use of:

   • OSGeo issue tracker - not requested
   • OSGeo mailing list - not requested
   • OSGeo svn - not requested
   • http://downloads.osgeo.org - not requested