Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

PROPOSAL - following feedback from the ONAP TSC 2019-02-07 the POC definition for Dublin


Proof of concept

Proof of concept (PoC) is a realization of a certain method or idea in order to demonstrate its feasibility,[1] or a demonstration in principle with the aim of verifying that some concept or theory has practical potential.[citation needed] A proof of concept is usually small and may or may not be complete.


The following are guidelines for a POC:

  1. Every POC has a named sponsor for the feature whom acts as spokesperson at all checkpoints/meetings
  2. POC (only) related defects cannot block the release
  3. POC development that includes entry points in the release version must comply with license scans and vulnerability fixes
    1. A POC should not introduce a back-door to the stable features so it must comply with security and license scans
  4. POC features that are visible/accessible in the final product should be documented with limitations and POC status stated
  5. A use case POC using common code, does not change the treatment of the common code with regards to completeness, S3P, documentation and other common code expectations




==-=-=-=-=-=-=-=-=-=-=-CUT LINE, Previous content preserved for continuity... Delete after TSC review-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=



POC is equivalent to "Tech Preview" or "Experimental"


Guidelines

  1. Every POC has a named sponsor for the feature whom acts as spokesperson at all checkpoints/meetings
  2. remove POC feature development is second priority to committed feature/tech debt development efforts. 
  3. Dependencies on other projects for POC functionality should be clearly communicated as POC development
  4. POC (only) related defects cannot block the release
  5. POC release notes should include details of functionality available, known issues, and known limitations/incomplete features
  6. Integration and test resources are primarily for the committed features and should not be used for POC until either
    1. primary functionality is complete 
    2. testing on the primary functionality is blocked - and cycles are available while blocker gets resolved
  7. POC issues are secondary topics at PTL or TSC meetings
  8. POC development can waive "product completeness" requirements - like S3P, Localization/I18N
    1. Basic documentation is expected so others can access the feature - full commercial grade documentation is not expected
  9. POC development must comply with license scans and vulnerability fixes
  10. POC may be promoted to fully supported feature prior to the end of the release with approval of the TSC
  11. POC features may be withdrawn from the release at any time with notification to the TSC from the sponsor 
  12. POC functionality is targeted for full feature in a specific future release


ISSUES:

  • How to treat "use case" POCs that use the common code base? Defects in a use case could impact other functionality...
  • No labels