...
This is practically the same as our current "Use case". It's basically an ONAP-level functionality that impacts multiple components and is visible to the end user. The name "Feature" can be replaced with the current "Use case" if community prefers this name. This can be represented as a Jira ticket in a dedicated project or an RST page in a dedicated repo.
Feature may be in one of below states:
- WIP
- Under review
- Waiting for approval
- Approved
- Rejected
- Active
- On Hold
- In testing
- Finished
- Dropped
WIP - default state for every new feature that allows the author to work on it without bothering other people
Under review - the BP is in the review with:
- Architecture
- Requirements subcomittee
- SECCOM
- PTLs
To save submitter time, the review should happen asynchronously by default (unless submitter asked for a VCC to present) and only if subcommittee has additional questions a VCC meeting to answer them should be scheduled. Questions and doubts should be written down before the VCC.
Waiting for approval - The feature has been socialized with required parties and now it is ready to be voted by the TSC
Approved - The Feature has been approved by the TSC. Implementation may be started if the feature is put in the "Active" state before "Spec freeze" for a given release.
Rejected - The Feature has been rejected by the TSC, which means that there is no agreement in the community that this is the right change
Active - The feature is being actively worked on in a current release.
On Hold - The implementation has been started but there is no progress planned for a current release due to some constraints.
In testing - The feature is complete and is now being tested by the integration team
Finished - implemented and tested
Dropped - people lost interest in this feature
Anyone in the community can propose a new feature at any time but the implementation should be started only when Feature is Active for a given release.
A feature may be linked directly to tasks if it's relatively simple or consist of multiple specs from which every one may be tested separately in "early release model".
Spec
This is "a smaller feature" which involves architectural change in only single component ie. some internal design refactoring etc. This can really be a Jira epic that describes where associated tasks are going.
Spec is scoped for single component thus it has to be approved only by people who know this component best - PTL and his or her committers.
PTL may request additional review from subcommittees if needed.
Spec has to be marked as Active before it can be implemented. In fact it behaves similar to Features but is just smaller