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.

POC GUIDELINES:

1. SPONSOR - Every POC shall have a named sponsor for the feature whom acts as spokesperson at all checkpoints/meetings.
2. NON BLOCKING - POC (only) related defects shall not block the release
3. COMPLIANCE - POC should be fully compliant with ONAP development guidelines, including development procedures.
   1. License/Vulnerabilities - POC development that includes entry points in the release version must comply with license scans and vulnerability fixes.
   2. Security - PoC development shall be compliant to security guidelines and incorporate the latest security fixes
   3. Performance - PoC should not impact the performance of the main code; this should be implied as it is kept in a separate Repo. The PoC development team should have an eye on ONAP performance if in the future it might be evolved to be incorporated into the ONAP platform.
   4. Back Doors - A POC should not introduce a back-door to the stable features so it must comply with security, code coverage, and license scans requirements
4. INDEPENDENT OF MAIN RELEASE - POC are not part of the ONAP release product.
   
   1. Documentation - The POC may have documentation in a wiki developed by the community; but will not be incorporated into the official release documentation.
   2. Independence - The POC shall be kept independent of the official release
   3. Integration/Testing responsibility - There is no responsibility from the integration or test teams to test the PoC S/W. The testing, integration and use of the PoC shall be in the purview of the PoC development team.
   4. PoC Release Notes - POC release notes may be developed by the PoC team, they may include details of functionality available, known issues, and known limitations/incomplete features to keep of track development issues as they arise and serve as a communication vehicle for those evolving the PoC in the future.
5. CODE INDEPENDENCE - The PoC software shall be kept separate and independent of the main ONAP branch/repository.
   1. Common Code Usage - POC software using common code, does not change the treatment of the common code with regards to completeness, S3P, documentation and other common code expectations
   2. Separate Branch - POC should be kept in separate repository branch. There should not be PoC S/W introduced into the main ONAP software branch. This prevents complications in testing and integration of the ONAP software in the main branch.
6. SCOPE - A PoC can be used to demonstrate functionality related to a project concept, a Use Case, functional or non-functional requirements, project specific extensions.
   1. Definition - It is the responsibility of the PoC team to define the scope and extent of the PoC. 
7. POC INCORPORATION - The point of a PoC is to demonstrate something (hopefully) useful. PoCs teams that wish to incorporate the PoC code into the main repository should follow the standard procedures for introducing new functionality and use cases in subsequent ONAP releases
   
   1. Feature Proposals - There exists a standard procedure new functionality introduction leading up to M0 shall be followed by a PoC in subsequent releases by the PoC team if they wish to incorporate PoC Software into the main repository.
   2. Partial PoC Introduction - The original PoC scope may be altered from what is introduced in a future release. An ideal case might be that a PoC software might serve as seed code, but it does not have to. Lessons learned can guide what would get incorporated or proposed in the future release.

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