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.
  • present their proposed best practice to the PTLs
  • incorporate any feedback and/or clarifications into the proposal
  • request the TSC to review and approve it as a best practice.
• A Best Practice can be approved by the TSC at any time, but must be approved at or before the M1 milestone for it to be applicable to that release cycle. 
• Once approved as a TSC Best Practice it is carried forward for every subsequent release, unless other action is taken by the TSC.

TSC Global Requirement

• Prior to the Honolulu release, these were commonly referred to as "TSC Must-Haves" and usually specific to that release. 
• From Honolulu onwards, a TSC Global Requirement was formalized to be any 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.
  • incorporate any feedback and/or clarifications into the proposal
  • Any feedback or clarifications need to be incorporated and then a request is made of the TSC to review and approve it.
• A Global Requirement can be approved by the TSC at any time, but must be approved at or before the M1 milestone for it to be applicable to that release cycle. 
• Once approved as a TSC Global Requirement it is carried forward for every subsequent release. 

Canonical List of TSC Best Practice and Global Requirements

Other content related definitions 

• 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.