Difference between revisions of "Project Graduation Checklist"
Jump to navigation
Jump to search
| Line 4: | Line 4: | ||
'''Version''': 1.0 | '''Version''': 1.0 | ||
| + | |||
| + | |||
| + | '''Last Updated''': August 20, 2006 | ||
'''Status''': draft | '''Status''': draft | ||
| Line 9: | Line 12: | ||
= Purpose = | = Purpose = | ||
| − | The purpose of this checklist is to determine whether | + | 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-requisit for graduation. |
| + | |||
| + | A project should have institutionalized the processes in this list or provide justification why the process is not used. | ||
= Terms and Definitions = | = Terms and Definitions = | ||
| Line 17: | Line 22: | ||
= Checklist = | = Checklist = | ||
| − | == | + | == License == |
# The code has been adequately vetted to assure it is all properly licensed, to the satisfaction of the Mentor. | # The code has been adequately vetted to assure it is all properly licensed, to the satisfaction of the Mentor. | ||
# 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. | ||
| − | |||
| − | |||
| − | == | + | == 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 user documentation. | ||
| + | # The project has developer documentation. | ||
# The project has code under configuration control. Eg, subversion. | # The project has code under configuration control. Eg, subversion. | ||
# The project uses an issue tracker. | # The project uses an issue tracker. | ||
# The project uses public communication channels. Eg archieved email lists. | # The project uses public communication channels. Eg archieved email lists. | ||
| − | |||
| − | |||
# The project has an automated build process. | # The project has an automated build process. | ||
# The project has an automated test system. | # The project has an automated test system. | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
Revision as of 03:34, 20 August 2006
Document Status
IncCom Document Number: X
Version: 1.0
Last Updated: August 20, 2006
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-requisit 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
Checklist
License
- The code has been adequately vetted to assure it is all properly licensed, to the satisfaction of the Mentor.
- All code contributors have agreed to abide by the project's license policy.
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 user documentation.
- The project has developer documentation.
- The project has code under configuration control. Eg, subversion.
- The project uses an issue tracker.
- The project uses public communication channels. Eg archieved email lists.
- The project has an automated build process.
- The project has an automated test system.