Difference between revisions of "Draft Project Graduation Checklist Draft"

From OSGeo
Jump to navigation Jump to search
(Redirected page to Project Graduation Checklist)
 
(28 intermediate revisions by 4 users not shown)
Line 1: Line 1:
−
'''Draft copy of [[Project_Graduation_Checklist]]. The official copy of this document lives at http://www.osgeo.org/incubator/process/project_graduation_checklist.html'''.
+
#redirect[[Project Graduation Checklist]]
−
 
 
−
= Document Status =
 
−
 
 
−
'''IncCom Document Number''': X
 
−
 
 
−
'''Version''': 2.0-RC1
 
−
 
 
−
'''Last Updated''': January 2012.
 
−
 
 
−
'''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 [http://www.sei.cmu.edu/pub/documents/02.reports/pdf/02tr012.pdf Capability Maturity Model (CMMI)] - "Generic Goal 2: Institutionalize a Managed Process"''
 
−
 
 
−
= Checklist =
 
−
 
 
−
== Intellectual Property and License ==
 
−
 
 
−
We need to ensure that project owns or otherwise has obtained the ability to release the project code by completing the following steps:
 
−
# The project code, documentation and data has been adequately vetted to assure it is all properly licensed as per a [http://www.osgeo.org/incubator/process/codereview.html provenance review].
 
−
# All code contributors have agreed to abide by the project's license policy, and this agreement has been documented and archived.
 
−
# The project has checked for inappropriate use of trademark or patents and the results of such checks have been documented.
 
−
# The project has the ability to shut off downloads if a blocking legal issue is found.
 
−
 
 
−
== Processes ==
 
−
 
 
−
# The project has code under configuration management. <i>Eg, subversion, git.</i>
 
−
# The project uses an issue tracker and keeps the status of the issue tracker up to date.
 
−
# The project has documented its management processes. <i>This is typically done within a Developers Guide or Project Management Plan.</i>
 
−
#* The project has a suitable governance policy ensuring decisions are made, documented and adhered to. <i>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.</i>
 
−
#* The project uses public communication channels for decision making to maintain transparency.<i> E.g. archived email list(s), archived IRC channel(s), public issue tracker.</i>
 
−
 
 
−
== Documentation ==
 
−
 
 
−
# The project has user documentation:
 
−
#* Including sufficient detail to guide a new user through performing the core functionality provided by the application.
 
−
# The project has developer documentation:
 
−
#* Including checkout and build instructions.
 
−
#* Including commented code, ideally published for developer use. Examples: javadocs for Java applications, or Sphinx documentation for Python applications.
 
−
#* 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 testing
 
−
#* Ideally this includes documentation 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.
 
−
 
 
−
= 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.
 
−
 
 
−
== 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: [[Contacts#Software_Projects|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 [http://wiki.osgeo.org/wiki/Marketing_Artefacts Marketing Artefacts]. This lists the documentation requirements for [http://live.osgeo.org 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 [http://live.osgeo.org OSGeo-Live], but may also include [http://wiki.debian.org/DebianGis DebianGIS], [https://wiki.ubuntu.com/UbuntuGIS UbuntuGIS], and/or [http://trac.osgeo.org/osgeo4w/ osgeo4w] [http://www.maptools.org/ms4w/ 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 [[SAC|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]]
 

Latest revision as of 08:40, 28 October 2013

Redirect to:

Retrieved from "http://wiki.osgeo.org/w/index.php?title=Draft_Project_Graduation_Checklist_Draft&oldid=74736"