Difference between revisions of "Project Graduation Checklist"
Jump to navigation
Jump to search
| Line 7: | Line 7: | ||
'''Version''': <font color="red">1.1. Updates since 1.0 are in red.</font> | '''Version''': <font color="red">1.1. Updates since 1.0 are in red.</font> | ||
| − | '''Last Updated''': <font color="red"> | + | '''Last Updated''': <font color="red">February 2010.</font> |
'''Status''': draft | '''Status''': draft | ||
| Line 26: | Line 26: | ||
== License == | == License == | ||
| − | # The code has been adequately vetted to assure it is all properly licensed (a.k.a [http://www.osgeo.org/incubator/process/codereview.html provenance review]). | + | # 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>. |
| − | # All code contributors have agreed to abide by the project's license policy. | + | # 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 suitable governance policy and project management committee established that ensures decisions are made, documented and adhered to? | + | # 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 testable 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 uses an issue tracker<font color="red"> and keeps the status of the issue tracker up to date</font>. | |
| − | # The project has code under configuration control. Eg, subversion. | + | # The project <font color="red">maintains transparency by using <strike>uses </strike>public communication channels. Eg archived email lists. |
| − | # The project uses an issue tracker. | + | |
| − | # The project uses public communication channels. Eg archived email lists. | + | == <font color="red">Quality</font> == <span bgcolor="yellow">Cameron Shorter comment: Quality requirements have been moved into this section.</span> |
| − | # The project has an automated build process. | + | # The project has <font color="red">comprehensive</font> user documentation. |
| − | # The project manages quality. Ideally, this includes an automated test system. | + | # The project has <font color="red">comprehensive</font> developer documentation. |
| − | # The project has a defined release process. | + | <strike># The project has an automated build process.</strike> <span bgcolor="yellow">Cameron Shorter comment: Covered by following line.</span> |
| + | # The project <font color="red">follows a documented</font><stike> 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><stike>has</strike> a defined release process <font color="red">which includes extensive testing before releasing a stable release</font>. | ||
== Marketing == | == Marketing == | ||
Revision as of 17:59, 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: 1.1. 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 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 testable 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<stike> manages quality process. Ideally, this includes both automated and manual testing.
an automated test system. - The project follows<stike>has a 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?) - The package is bundled with appropriate distributions, (eg: DebianGIS, GeoSpatial Live GIS, osgeo4w, etc.)