2017-11-26 Doc Project Meeting

Topics, Notes, and Follow-Up Tasks

Topic	Notes	Follow-up

Topic	Notes	Follow-up
Release / Branching Strategy	Amsterdam doc project branch created and tracking updates in any other repo providing documentation that has an Amsterdam branch. For those that did not have an Amsterdam branch, we are using head of the master branch as of ~11/24 4pm EST. Project repos that still need to be tagged: Integration INT-349: amsterdam branchClosed Logging LOG-108: amsterdam branch Closed Modeling Modelspec MODELING-47: amsterdam branchClosed OOM OOM-471: amsterdam branchClosed Portal PORTAL-149: amsterdam branchClosed SDC SDC-713: amsterdam branchClosed VNF Guidelines VNFRQTS-145: amsterdam branchClosed VNF Requirements VNFRQTS-146: amsterdam branchClosed VNF SDK Model VNFSDK-132: amsterdam branchClosed Where Amsterdam changes are expected and should be automatically published when merged, an Amsterdam branch may be created. Both master and amsterdam are being published at read the docs. The default when someone enter http://docs.onap.org is master and the the developer wiki download link currently points to master. Should we change this?	Create JIRA ticket(s) for each item below @Rich Bennett Each PTL committer for the repos list in column 2, to identify the hash and create a release branch "amsterdam". Sync up the doc project amsterdam branch submodule references with created amsterdam branches, DOC-210: Update Amsterdam branch to track all amsterdam submodule branchesClosed Switch DW download link to RTD amsterdam when branches above are completed @Rich Bennett What needs to change for the latest vFW instructions? @Eric Debeau Do we need something for new users (not developers) that want to understand use cases, try higher level service/policy scenarios, etc? @Eric Debeau
Wiki Migration	Sub Tasks for: Setting Up ONAP Integrating with ONAP Using ONAP Architecture Documenting ONAP Developing ONAP	DOC-179: Migrate Release Controlled Wiki ContentClosed Start with (oom kubernetes, quickstart, heat template ), set example / define a best practice for collecting/refining documentation on wiki, following a process with wiki labels, JIRA tickets, etc that keeps everyone aware of state and transition to change controlled documentation in gerrit
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: 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)