...
- 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/incomplete features
- Integration and test resources are primarily for the committed features and should not be used for POC until either
- primary functionality is complete
- testing on the primary functionality is blocked - and cycles are available while blocker gets resolved
- POC issues are secondary topics at PTL or TSC meetings
- POC development can waive "product completeness" requirements - like S3P, Localization/I18N
- Basic documentation is expected so others can access the feature - full commercial grade documentation is not expected
- 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 to the TSC from the sponsor
- 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...