Difference between revisions of "Project Graduation Checklist"
| Line 33: | Line 33: | ||
== Processes == | == Processes == | ||
| − | # The project has a | + | # The project has a suitable governance policy and project management committee established that ensures decisions are made, documented and adhered to? |
# 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. | ||
| Line 39: | Line 39: | ||
# 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 </font><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 Control</font>== | ==<font color="red">Quality Control</font>== | ||
Revision as of 13:04, 29 November 2011
The official copy of this document lives at http://www.osgeo.org/incubator/process/project_graduation_checklist.html
Wiki version 50824 of this document was discussed at Incubation Meeting 14, and a number of suggested changes were made. Logs here: http://irclogs.geoapt.com/osgeo/%23osgeo.2010-03-03.log
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) - "Generic Goal 2: Institutionalize a Managed Process"
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 suitable governance policy and project management committee established that ensures decisions are made, documented and adhered to?
- 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
managesquality 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 Marketing Committee.
(can we assume pdf handout, presentation slides and a feature matrix?) - Stable version(s) of executable applications are bundled with appropriate distributions, (eg: OSGeo-Live, DebianGIS, UbuntuGIS, osgeo4w, etc.)