DRAFT PROPOSAL FOR COMMENTS
The content of this template is expected to be fill out for Release Planning review.
...
| Table of Contents | ||
|---|---|---|
|
Overview
| Project Name | Enter the name of the project |
|---|---|
| Target Release Name | Enter the name of the release you are targeting to deliver |
| Project Lifecycle State | Either Incubation, Core, Mature. Refer to Project Lifecycle for details on Project Lifecycle |
| Participating Company | List the company participating in this release. At least 3-4 organizations, including an operator are expected |
Scope
What is this release trying to address?
...
List the functionalities that this release is committing to deliver.
| Functionality Name | In or Out | Priority | Stretch |
|---|---|---|---|
| IN or OUT | H, M, L | Indicate that a functionality may or not be delivered |
| Info | ||
|---|---|---|
| ||
List the functionalities proposed for this release. In the Priority column, specify the priority (either High, Medium, Low). The priority will be used in case de-scoping is required. Don't assign High priority to all functionalities. |
...
Indicate the outcome (Executable, Source Code, Library, API description, Tool, Documentation, Release Note...) of this release.
| Deliverable Name | Deliverable Description |
|---|---|
| To fill out | To fill out |
Sub-Components
List all sub-components part of this release.
Activities related to sub-component must be in sync with the overall release.
...
Prior to the delivery date, it is a good practice to organize an API review.
| API Name | API Description | API Definition Date | API Delivery date | API Definition link (i.e.swagger) |
|---|---|---|---|---|
| To fill out | High level description of the API | Date for which the API is reviewed and agreed | To fill out | Link toward the detailed API description |
API Outgoing Dependencies
API this release is delivering to other releases.
| API Name | API Description | API Definition Date | API Delivery date | API Definition link (i.e.swagger) |
|---|---|---|---|---|
| To fill out | High level description of the API | Date for which the API is reviewed and agreed | To fill out | Link toward the detailed API description |
Third Party Products Dependencies
Third Party Products mean products that are mandatory to provide services for your components. Development of new functionality in third party product may or not be expected.
List the Third Party Products (RabbitMQ, ElasticSearch,Crystal Reports, ODL, OPNFV...).
| Name | Description | Version |
|---|---|---|
| To fill out | To fill out | To fill out |
Testing and Integration Plans
...
This section is used to document a limitation on a functionality or platform support. We are currently aware of this limitation and it will be delivered in the future.
List identified release gaps (if any), and its impact.
| Gaps identified | Impact |
|---|---|
| To fill out | To fill out |
Known Defects and Issues
Provide a link toward the list of all known project defects.
...
List the risks identified for this release along with the plan to prevent the risk to occur (mitigation) and the plan of action in the case the risk would materialized (contingency).
| Risk identified | Mitigation Plan | Contingency Plan |
|---|---|---|
| To fill out | To fill out | To fill out |
Resources
Resources assigned to project are consolidated in a single place. Edit all the table with the ALL information, that helps to expedite Linux Foundation operations.
...
It is not expected to have a detailed project plan.
| Date | Project | Deliverable |
|---|---|---|
| To fill out | To fill out | To fill out |
Development Practices
From the suggested recommend [[Development Practices|development practices]], indicate which practice you plan to apply.
...