Topic | Notes | Follow-up |
---|
Release / Branching Strategy | - Branches completed for all projects with Nexus artifacts; No branches for others (e.g. Doc, Requirements)
We need to: - Decide when to create the Amsterdam branch and versions of project submodules to reference (gitmodules branch = value) - Do we force branches or continue to track from master?
- Create tag and branch in gerrit
- Update jjb/doc stream list
- Provide default branch in .gitreview
- Update readthedocs settings for the new branch
| - Create Amsterdam release branch for Doc ASAP, will be same branch for the Amsterdam maintenance release. Do we need to tag version original (1.0.0) content?
- Continue new / updated documentation in the master
- Latest version will always be in readthedocs
Immediate To Do's - Create branches for all projects - Greg / Rich
|
Wiki Migration | Sub Tasks for: - Setting Up ONAP
- Integrating with ONAP
- Using ONAP
- Architecture
- Documenting ONAP
- Developing ONAP
| New JIRA Issue |
Structure Clean-Up | - Developing ONAP: Structure and Headings clean-up
| New JIRA Issue |
Carrier Grade | - "Carrier Grade" usability - what does that mean for Documentation?
- Insuring standards/consistency across projects (e.g. terminology, monitoring, clustering)
- Usability (e.g. Designer, VNF Providers, Operations)
| New JIRA Issue |
APIs | - REST API
- HealthCheck API
- Components API (eg Java class API)
| New JIRA Issue |
Glossary | Modeling team responsible - Definitions to RsT
- Indexing / tagging to enable Searching
| Address during Release 2 Create JIRA issue - Greg follow up |
Tooling / Utilities documentation | How to: - Gerrit guide
- Guidelines (Builds, etc.)
- Utilities: Jenkins, Conversion tools (e.g. LFPandocs)
| New JIRA Issue (LF pursuing Quarter 3, 2018) |