Difference between revisions of "Project Graduation Checklist"
Jump to navigation
Jump to search
| Line 39: | Line 39: | ||
| − | ==<font color="red">Quality</font>== | + | ==<font color="red">Quality Control</font>== |
<span style=background:yellow>Cameron Shorter comment: Quality requirements have been moved into this section.</span> | <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. | ||
| Line 45: | Line 45: | ||
<strike># The project has an automated build process.</strike> <span style=background:yellow>Cameron Shorter comment: Covered by following line.</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><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 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><strike>has</strike> a defined release process <font color="red">which includes extensive testing before releasing a stable release</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>. |
| + | <span style=background:yellow>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.</span> | ||
== Marketing == | == Marketing == | ||
Revision as of 02:53, 27 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 Control
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.
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.
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.)