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.