Versions Compared

Old Version 25

changes.mady.by.user Gildas Lanilis Gmail

Saved on

compared with

New Version 26

changes.mady.by.user Steven wright

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Create and maintain documentation targeted to ONAP user audiences and the tasks they perform.   For example:
    • a platform developer pulling, building, running, hacking and pushing source code;
    • an administrator installing, configuring, and monitoring an ONAP instance;
    • a designer or tester creating, validating, and delivering service models;
    • a VNF developer designing, testing, and certifying a VNF for use on ONAP
    • a Service Provider using VNF Requirements as prototype text for RFPs to acquire VNFs to run in an ONAP context
    • ... others as required for release plans or ONAP committees
  • Establish and maintain a tool chain that supports the integration of documentation source material from all ONAP projects and builds documentation artifacts for each release.
  • Establish documentation source material and final documentation dependencies in the release plan, end to end tests, and CI/CD to insure documents are available when needed in a release cycle and remain current with changes made in other software projects.
  • Enable technical writer (contributors) for each release to create and integrate additional content based on overall release requirements.
  • Benefits include users quickly understand how to do required tasks, documentation is efficiently created/tested as part of the CI/CD process and is in sync with the software in a release.

...

  • How does this project fit into the rest of the ONAP Architecture?  
    A parallel thread to create documentation artifacts with dependencies on the capabilities, configuration, and interfaces provided by software projects as illustrated below.

    • Dependencies on all projects providing source material for documentation.
      • Code changes may drive documentation changes.
      • Some documentation e.g. VNF Requirements may need to be traceable to code modules (e.g. test cases)  
    • Target use cases drive the user audience and task requirements for a release.
  • How does this align with external standards/specifications?
    • Project will identify best practices for a documentation tool chain by looking at other open source projects (eg. open daylight, opnfv)
  • Are there dependencies with other open source projects?
    • Evaluate use of readthedocs.org as way of publishing documents.
    • Evaluate the use of swagger.io for API documentation

...

...