Release Planning Template - DOC Amsterdam Release
The content of this template is expected to be fill out for M1 Release Planning Milestone.
Info
Use the "Copy" and "Move" options (available under the ..., top right of this page) to duplicate this template into your project wiki.
Use the Wiki to document the release plan. Don't provide PowerPoint.
Use as much diagrams and flow charts as you need, directly in the wiki, to convey your message.
- 1.1 Info
- 2 Overview
- 3 Scope
- 4 Release Deliverables
- 5 Sub-Components
- 6 ONAP Dependencies
- 7 Architecture
- 8 Testing and Integration Plans
- 9 Gaps
- 10 Known Defects and Issues
- 11 Risks
- 12 Resources
- 13 Release Milestone
- 14 Team Internal Milestone
- 15 Documentation, Training
- 15.1 Note
- 16 Other Information
Overview
Project Name | Enter the name of the project |
|---|---|
Target Release Name | Amsterdam |
Project Lifecycle State | Incubation |
Participating Company | AT&T, Amdocs, Huawei, Nokia, China Mobile, ZTE, Accenture |
Scope
What is this release trying to address?
Establish for ONAP a best practice CI/CD tool chain and processes for managing ONAP documentation
Establish templates, guides, examples, relationships to release planning and integration projects that will make documentation an integral easy to perform activity for all projects contributing to an ONAP software release.
Create documentation required by ONAP Release 1 use cases
Migrate seed documentation currently in the wiki or gerrit that is being maintained by approved projects
Use Cases
The new documentation created by this project must support ONAP high level Amsterdam use cases.
Lower level use cases specific to documentation project scope include:
Store documentation source in gerrit project repositories in a form that is easy for multiple authors to create and maintain.
Define and integrate source from multiple repository locations into an complete, organized set for an ONAP release.
Automatically (re)create a complete set of finished documentation whenever any sources change.
Publish the finished set of documentation in where it can be easily referenced by any user audience that is working with an ONAP release.
Minimum Viable Product
Final documentation for ONAP Release 1 Use Cases
Functionalities
List the functionalities that this release is committing to deliver by providing a link to JIRA Epics and Stories. In the JIRA Priority field, 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.
Epics
Stories
Longer term roadmap
Indicate at a high level the longer term roadmap. This is to put things into the big perspective.
Release Deliverables
Indicate the outcome (Executable, Source Code, Library, API description, Tool, Documentation, Release Note...) of this release.
Deliverable Name | Deliverable Description |
|---|---|
doc | Source Repository with a master index for all documentation in an ONAP Release in TBD( .rst, .md, or other) format. |
doc/tools | Scripts used to collect, compose, validate source documentation material and publish final form documentation |
doc/source/<repository> | Repositories as needed to
|
TBD (onap.readthedocs.io, nexus.onap.org raw site) | Published release documentation |
Sub-Components
All components are described as source deliverables above and/or will be identified by:
inclusion in the master index with a reference to another project repository/index file and link from a JIRA story for the other projects to the DOC project story https://lf-onap.atlassian.net/browse/DOC-17
Sub-components are repositories are consolidate in a single centralized place. Edit the Release Components name for your project in the centralized page.
ONAP Dependencies
List the other ONAP projects your depends on.
ci-management
Any project that contains a portion of the documentation source referenced in final documentation set.
A documentation publishing site (eg. readthedocs.io, Nexus raw site)