Page History

Doc Writer SOW Kenny Paul

Budget available. 

To be focused on operational parts. depth rather than wide

Meeting will be dedicated this topic. Kenny Paulto

invite  Brandon Wick and

Amar Kapadia

Sofia Wallin asked who owns the resources and the workforce/project

• Brandon Wick will be responsible on the LF side
• Amar Kapadia on the Arana side

Suggestions by the doc project based on community feedback and the work done by the doc project:

• Need to ensure that this is not a general bucket where people think they can just throw all doc issues at the writer.
• API documentation not included in SOW
• Modeling team has provided the "how to document APIs" 

• Topic based documentation 
  • Re-structure current content to improve usability. Helping end users and other interested to easy find what they are looking for
• Review with the team next week what's available today and based on that come up with a work plan
• Is this content creation only or also clean-up? Adding more content or structure clean up ?
  • will obviously require participation of PTLs from the project areas
  • Thomas Kulik has been doing some wiki migration 
  • Doc project team, ArchCom and Modeling have set structure a proposal that doc writers need to follow
    DOC Challenges and Proposals
    2020 March 11th Documentation Hackathon

• SOW
  • Review of existing documentation - lots of content wiki RTD 
  • 6 month SOW proposed
• Proposed topics
• I think the work matches the proposed team size quite well.
  • We can have 0.5 person on basics,
  • 1.5 persons on deep dive,
  • 1 person on the ops stuff (install, upgrade; backup, restore).
  • documentation,exercise. not debug+documentation, or development+debug+documentation
•  Prioritization
  • 1 Walkthrough the basics (high-level architecture, short description of each component)
    • "core implementation bundle" description
  • 2 Deep dive tutorials of the more mature components priorities:
    • how to use SDC - design time is important, gaps in control-loop, known resource limitations on the project.  May have some legacy docs that ncan be leveraged and updated, 
    • how to use DCAE - required for design time 
  • 3 Installation & upgrade procedure
    • E2E from download, install, create and 1st service instance up and running (hello world)
      • "core implementation bundle" description
    • E2E how to upgrade: OOM guides exist but can be improved 
  • 4 Backup, upgrade and restore procedure
    • common guideline for the ONAP platform
    • component specific admin guide 
    • trying out recipes and documenting them as opposed to having to figure them out from scratch or to debug them
  • 5 how to use SO