Difference between revisions of "Project Graduation Checklist"
Jump to navigation
Jump to search
| Line 5: | Line 5: | ||
'''IncCom Document Number''': X | '''IncCom Document Number''': X | ||
| − | '''Version''': <font color="red"> | + | '''Version''': <font color="red">2.0. Updates since 1.0 are in red.</font> |
'''Last Updated''': <font color="red">February 2010.</font> | '''Last Updated''': <font color="red">February 2010.</font> | ||
| Line 26: | Line 26: | ||
== License == | == License == | ||
| − | # The code has been adequately vetted to assure it is all properly licensed <strike>(a.k.a</strike><font color="red">as per</font> [http://www.osgeo.org/incubator/process/codereview.html provenance review]<strike>)</strike>. | + | # The code has been adequately vetted to assure it is all properly licensed <strike>(a.k.a</strike><font color="red">as per a</font> [http://www.osgeo.org/incubator/process/codereview.html provenance review]<strike>)</strike>. |
# All code contributors have agreed to abide by the project's license policy<font color="red">, and this agreement has been documented and archived</font>. | # All code contributors have agreed to abide by the project's license policy<font color="red">, and this agreement has been documented and archived</font>. | ||
== Processes == | == Processes == | ||
| − | # The project has a <strike>suitable </strike>governance policy and project management committee established that ensures decisions are made, documented and adhered to?<span style=background:yellow>Cameron Shorter comment: "suitable" is not | + | # The project has a <strike>suitable </strike>governance policy and project management committee established that ensures decisions are made, documented and adhered to?<span style=background:yellow>Cameron Shorter comment: "suitable" is not defined and doesn't add value to the sentence.</span> |
# 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. | # 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. | ||
# The project has documented its management processes. This is typically done within a Developers Guide or Project Management Plan. | # The project has documented its management processes. This is typically done within a Developers Guide or Project Management Plan. | ||
# The project has code under configuration <font color="red">management</font><strike>control</strike>. Eg, subversion. | # The project has code under configuration <font color="red">management</font><strike>control</strike>. Eg, subversion. | ||
# The project uses an issue tracker<font color="red"> and keeps the status of the issue tracker up to date</font>. | # The project uses an issue tracker<font color="red"> and keeps the status of the issue tracker up to date</font>. | ||
| − | # The project <font color="red">maintains transparency by using <strike>uses </strike>public communication channels. Eg archived email lists. | + | # The project <font color="red">maintains transparency by using </font><strike>uses </strike>public communication channels. Eg archived email lists. |
| − | == <font color="red">Quality</font> == <span | + | |
| + | ==<font color="red">Quality</font>== | ||
| + | <span style=background:yellow>Cameron Shorter comment: Quality requirements have been moved into this section.</span> | ||
# The project has <font color="red">comprehensive</font> user documentation. | # The project has <font color="red">comprehensive</font> user documentation. | ||
# The project has <font color="red">comprehensive</font> developer documentation. | # The project has <font color="red">comprehensive</font> developer documentation. | ||
| − | <strike># The project has an automated build process.</strike> <span | + | <strike># The project has an automated build process.</strike> <span style=background:yellow>Cameron Shorter comment: Covered by following line.</span> |
| − | # The project <font color="red">follows a documented</font>< | + | # The project <font color="red">follows a documented</font><srtike> manages</strike> quality <font color="red">process</font>. Ideally, this includes <font color="red>both automated and manual testing.</font><strike>an automated test system.</strike> |
| − | # The project <font color="red">follows</font>< | + | # The project <font color="red">follows</font><strike>has</strike> a defined release process <font color="red">which includes extensive testing before releasing a stable release</font>. |
== Marketing == | == Marketing == | ||
# Marketing material has been created about the project for the [http://wiki.osgeo.org/index.php/Marketing_Committee OSGeo Marketting Committee]. <strike>(can we assume pdf handout, presentation slides and a feature matrix?)</strike> | # Marketing material has been created about the project for the [http://wiki.osgeo.org/index.php/Marketing_Committee OSGeo Marketting Committee]. <strike>(can we assume pdf handout, presentation slides and a feature matrix?)</strike> | ||
| − | # <font color="red"> | + | # <font color="red">Stable version(s) of the project are bundled with appropriate distributions, (eg: [http://wiki.debian.org/DebianGis DebianGIS], [http://wiki.osgeo.org/wiki/Live_GIS_Disc GeoSpatial Live GIS], [http://trac.osgeo.org/osgeo4w/ osgeo4w], etc.)</font> |
[[Category: Incubation]] | [[Category: Incubation]] | ||
Revision as of 18:12, 26 February 2010
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
- The code has been adequately vetted to assure it is all properly licensed
(a.k.aas per a provenance review). - All code contributors have agreed to abide by the project's license policy, and this agreement has been documented and archived.
Processes
- The project has a
suitablegovernance 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. - 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.
- The project has documented its management processes. This is typically done within a Developers Guide or Project Management Plan.
- The project has code under configuration management
control. Eg, subversion. - The project uses an issue tracker and keeps the status of the issue tracker up to date.
- The project maintains transparency by using
usespublic communication channels. Eg archived email lists.
Quality
Cameron Shorter comment: Quality requirements have been moved into this section.
- The project has comprehensive user documentation.
- The project has comprehensive developer documentation.
# The project has an automated build process. Cameron Shorter comment: Covered by following line.
- The project follows a documented<srtike> manages quality process. Ideally, this includes both automated and manual testing.
an automated test system. - The project follows
hasa defined release process which includes extensive testing before releasing a stable release.
Marketing
- Marketing material has been created about the project for the OSGeo Marketting Committee.
(can we assume pdf handout, presentation slides and a feature matrix?) - Stable version(s) of the project are bundled with appropriate distributions, (eg: DebianGIS, GeoSpatial Live GIS, osgeo4w, etc.)