...
POC should be equivalent to "Tech Preview"
Guidelines
- Every POC has a named sponsor for the feature whom acts as spokesperson at all checkpoints/meetings
- POC feature development is second priority to committed feature/tech debt development efforts.
- Dependencies on other projects for POC functionality should be clearly communicated as POC development
- POC (only) related defects cannot block the release
- POC release notes should include details of functionality available, known issues, and known limitations
- Integration and test resources are primarily for the committed features and should not be used for POC until primary functionality is complete OR blocked
- POC issues are not the primary topic at PTL or TSC meetings
- POC development can waive "product completeness" requirements - like S3P, Localization/I18N
- POC development must comply with license scans and vulnerability fixes
- POC may be promoted to fully supported feature prior to the end of the release with approval of the TSC
- POC features may be withdrawn from the release at any time with notification from sponsor