2017-11-19 Doc Project Meeting

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

• Differentiate:

1. REST API

2. HealthCheck API

3. 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)