View Source

TSC Best Practice:

A design pattern or methodology which must be followed for any new code associated with a new container(s).
To establish something as a TSC Best Practice the team requesting it are required to open a REQ Jira describing the request. They must then present their best practice to the PTLs and after incorporating any feedback and/or clarifications, then request the TSC to review and approve it as a best practice.
Once approved as a TSC Best Practice it is carried forward for every subsequent release.

Prior to the Honolulu release, these were referred to as "TSC Must-Haves".
From Honolulu onwards, a TSC Global Requirement is a previously approved TSC Best Practice that must be applied to whole code base beginning with a particular release .
To establish a TSC Global Requirement the team requesting it must present their previously approved best practice to the PTLs in the context of promoting it to a a Global Requirement beginning with the appropriate release. Any feedback or clarifications need to be incorporated and then a request is made of the TSC to review and approve it.
A TSC Global Requirement must be approved at or before the M1 milestone for it to be included in that release.
Once approved as a TSC Global Requirement it is carried forward for every subsequent release.

POC - Proof of Concept - (detailed definition)
Use case: High level feature that ONAP is supposed to support. Require Arch review, Req review, Impacted PTL review, all has to be GO from all the PTLs.
Feature*: A functional change that touches multiple projects. A feature requires an Architecture and Requirements Subcommittee review -AND- a review by all PTL's whose code would be impacted. For a feature to be approved for inclusion in a release it must receive an OK from all the PTLs.
Spec*: A functional change that touches only a single project. A PTL can decide on GO/NO GO based upon the component impact.

*Both Specs and Features were referred to as Functional Requirements until the Honolulu release.