CORD : CORD Project Lifecycle

Overview

CORD Project’s technical projects (“Projects”) shall consist of individual projects (each a “Project”), and each Project may have one or more modules (each a “Module”).  The creation, maintenance, promotion and archiving of Projects shall follow a lifecycle described in this Project Lifecycle document.  

The TST shall create, align and coordinate Projects and Modules.  The TST shall have the power to reorganize Projects and Modules after sufficient review and discussion with the Projects and community involved.  Subject to the foregoing, individual Projects can organize Modules within each such Project. 

The TST shall encourage new Projects and innovation in the technical community. New Projects enter the CORD technical community through a proposal (a “Proposal”) to the TST and if approved, are granted Incubation-state status.  Any voting member of the CORD technical community may submit a Proposal to the TST.  

Any TST member may request that the TST to consider promoting a Project, and, with respect to an Incubation-state project, any voting member of that Project may request the TST consider promoting said Project. 

Any TST member may request that a Project be considered for promotion to Core or transitioned to Archived-state. In this context, Core means included in the periodic releases of the CORD reference implementation (which may or may not be a "core" part of the CORD platform).

Projects shall change state following TST reviews. Projects typically change states independently from each other, but can cooperate closely and leverage each other’s results.

Along one dimension, Projects graduate from Proposal-state, through Incubation-state and Mature-state, with Archived–state being reserved for those Projects no longer being actively developed or used by the community. Along a second dimension, Projects are considered either a Core Project or a Deploy project, where the former are included in releases of the CORD reference implementation and the latter correspond to deployments (or trials) of CORD in one setting or another. Deploy Projects typically exist "downstream" from CORD, and correspond to uses cases that configure CORD for some target environment. Note that it is not necessary to classify a Project as Core or Deploy until it reaches the Mature-state.

Project States

 

Project State

Description

Proposal

Project does not formally exist yet, may not have real resources (yet), but is being worked on by the community to submit a formal proposal to the TST.

Incubation

Project has been approved by the TST, has resources, but is recognized to be nascent.

Mature

Project is fully functioning and stable, has achieved successful releases, but is not a required component of the CORD Core.

Core

Project is a required component of the CORD Core. (Projects must reach the Mature state to be considered for CORE.)

DeployProject uses CORD, configuring it for some target deployment or trial.

Archived

Project has been recognized as no longer being actively used or developed. This could be for a variety of reasons, e.g. project successfully accomplished its goals but is no longer used, project failed, etc., and has been archived as it's no longer a going concern.

 

Project state transitions

From State

To State

Review

<null>

Proposal

n/a

Proposal

Incubation

Creation Review

Incubation

{Mature, Deploy}

Graduation Review

{Mature, Deploy}

Core

Core Review

{Proposal, Incubation, Mature, Deploy, Core}

Archived

Archive Review

Reviews

Creation Review

  • Proposal posted for two weeks, evaluated on metrics of:
    • Name is okay (e.g. no use of a trademark)
    • Project contact name and email
    • Description is complete
    • Scope and project plan is well defined
    • Resources are committed
    • Initial Committers Reviewers named
    • Contributors have been identified
    • Meets the CORD Project’s policies (e.g. IP Policy)
    • Proposal has been socialized with potentially interested or affected existing Projects
    • Proposal email has been sent to the TST mailing list
    • Review by TST: Confirm that the proposal is complete and the above listed requirements have been sufficiently met.

Graduation Review

  • It is intended that threshold for having projects graduated to Mature-state will be lower and the process streamlined relative to having projects graduated to Core-state.
  • Graduation proposal posted for two weeks:
  • Module owner named
  • The Project demonstrates stable output (code base, documents, tests)
  • Active community working on the Project
  • History of successful, consistent releases in accordance with the release process
  • TST review 
    • Working and stable code base exists
    • Active community exists
    • Project has demonstrated a history of releases following the release process and cadence
    • Confirmed acceptance and successful integration of contributions/code tpartner/upstream projects. 
    • Testing/integration environment defined and mature, tests and integration run successfully
    • Detailed documentation available documenting the code

Core Review

  • Core-state proposal posted for two weeks
  • The requirements for Graduation review are also met
  • Project is shown tbe viable, necessary or broadly useful module, subsystem or component of the CORD Project
  • Project build and test scripts have been created to work with the rest of CORD Core
  • Project shown to not break continuous development and integration environment 
  • TST review metrics
  • Core review assesses projects based on the metrics of the graduation review and the necessity of the project relative to the codebase and user requirements. 
  • In addition the project is required to have confirmed longevity (e.g. the project has been active for at least one year, participates in release activities, and has release plans outlined to stay active for at least another year). 

Termination Review

  • Termination proposal posted for two weeks
  • States reason for project termination being sought
    • Termination proposal to include acceptable triggers for termination (e.g. protracted idleness, or request by the project)
  • Estimates impact on other projects and how to mitigate
  • Impact and possible breakage to APIs or builds
  • Location identified and links created for archived project
  • If Archival is not approved, the Project remains in its pre-reviewed state