Project Graduation Checklist

The official copy of this document lives at http://www.osgeo.org/incubator/process/project_graduation_checklist.html

= Document Status =

IncCom Document Number: X

Version: 2.0. Updates since 1.0 are in red.

Last Updated: February 2010.

Status: draft

= Purpose =

The purpose of this checklist is to determine whether an Incubator Project produces quality products, remains true to its stated licence and is sustainable. Satisfying this checklist is a pre-requisite for graduation.

A project should have institutionalized the processes in this list or provide justification why the process is not used.

= Terms and Definitions =


 * Mentor : A member of the Incubation Committee chosen to assist a Project through the Incubation Process.
 * Institutionalized Process : A documented process which which addresses a need and is actively in use. It typically takes months before a process becomes institutionalized. A more detailed definition of institutionalization is found in the Capability Maturity Model (CMMI)

= Checklist =

License

 * 1) The code has been adequately vetted to assure it is all properly licensed (a.k.a  as per a provenance review ).
 * 2) All code contributors have agreed to abide by the project's license policy, and this agreement has been documented and archived.

Processes

 * 1) The project has a suitable governance policy and project management committee established that ensures decisions are made, documented and adhered to? Cameron Shorter comment: "suitable" is not defined and doesn't add value to the sentence.
 * 2) The developer community works in a healthy way, open to input, new members and reaching consensus on decisions. Ideally, the developers come from a diversity of backgrounds as there will be a greater variety of technical visions and the project is more resilient to a sponsor leaving.
 * 3) The project has documented its management processes. This is typically done within a Developers Guide or Project Management Plan.
 * 4) The project has code under configuration management  control . Eg, subversion.
 * 5) The project uses an issue tracker and keeps the status of the issue tracker up to date.
 * 6) The project maintains transparency by using  uses public communication channels. Eg archived email lists.

Quality Control
Cameron Shorter comment: Quality requirements have been moved into this section. Cameron Shorter comment: At a later stage, it would be good to expect OSGeo projects to maintain a periodic stable release schedule, ideally linked in with distribution release cycles. However, I don't think we have reached that level of maturity across our projects yet.
 * 1) The project has comprehensive user documentation.
 * 2) The project has comprehensive developer documentation.
 * 3) The project has an automated build process. Cameron Shorter comment: Covered by following line.
 * 4) The project follows a documented  manages quality process . Ideally, this includes both automated and manual testing.  an automated test system.
 * 5) The project follows  has a defined release process which includes extensive testing before releasing a stable release.

Marketing

 * 1) Marketing material has been created about the project for the OSGeo Marketting Committee. (can we assume pdf handout, presentation slides and a feature matrix?)
 * 2) Stable version(s) of the project are bundled with appropriate distributions, (eg: DebianGIS, GeoSpatial Live GIS, osgeo4w, etc.)