OpenG Candidate Process

Before a VI can be added to an OpenG Library it must first pass through the candidate stage, where it's Functional Specification and Technical Specification can be refined and reviewed by OpenG Developers and other community members. This process is called the OpenG Candidate Process.

For a list of all OpenG Candidates see the Category:OpenG Candidates page.

Process Artifacts
Process artifacts are the various work products of the development process:
 * Primary Artifacts
 * Functional Specification (what does the user need and what can they expect?)
 * Technical Specification (how are we going to do it)
 * Implementation (the finished product that the user will see, which meets the above specifications)
 * Secondary Artifacts
 * Meeting notes (kept in a "Meetings" subfolder in svn)
 * Process improvements (which change these process documents)
 * Coding Standards improvements

Process Overview
Software development naturally follows the following path:

Functional Specification ==> Technical Specification ==> Implementation (code)

This is because:
 * We can't code (create the implementation) until we know how we're going to implement it (technical specifications)
 * We don't know how to implement it until we know what the code has to do (functional specification).

That said, change happens and we should be willing to adapt to change. As such we do not require that upstream artifacts be finalized (locked down) before we can begin downstream artifacts -- this process is sometimes called continuous integration, spiral model, iterative development, agile development, and other things.

While we allow these artifacts to be developed in parallel, it's natural that an upstream artifact will be "closer to completion", at any given time, than downstream artifacts.

Process Stages
Each artifact will go through the following stages: Notes:
 * 1) Initial Review Period (artifact should be in "rough draft" form by the start of this stage might be revised several times during this stage as feedback is obtained)
 * 2) Final Review Period (artifact should be "done" by the start of this stage)
 * The implementation should be kept reasonably in sync with the specifications. This will significantly expedite the development process.
 * The start and end of each stage should be announced in the forums

Process Flow

 * 1) Someone comes up with a great idea
 * 2) OpenG developer sponsors the great idea
 * 3) Prototype Implementation and Functional Specification are developed and announced
 * 4) peer review and community feedback is collected & distilled, and the Functional Specification is revised
 * 5) Final Review Period of Functional Specification is started
 * 6) Implementation is refined & Technical Specification developed and announced
 * 7) peer review and community feedback is collected & distilled, and the Functional Specification is revised
 * 8) Final Review Period of Technical Specification is started
 * 9) Implementation further refined and announced
 * 10) peer review and community feedback is collected & distilled, and the implementation is revised
 * 11) Final Review Period of implementation is started
 * 12) Candidate is moved into the appropriate library and released.

SVN
Candidate implementation should be kept in the OpenG SVN repository, in a folder (named after the candidate) located at /trunk/candidates/.

Wiki Pages

 * Wiki page should be named after the candidate (e.g., see Arithmetic_Mean)
 * Make sure that it has a link to the Functional Specification page
 * Make sure that it has a link to the Technical Specification page
 * Make sure that it's categorized as a member of Category:OpenG Candidates

Related Pages

 * Functional Specification
 * Technical Specification
 * Category:OpenG Candidates (a list of all OpenG Candidates)