Page History

...

This project generates documentation (not code)  for use by other ONAP projects and for publication by ONAP. 

VNFRQTS Project in relation to Documentation Project

The documentation project compiles and publishes the final version of the documentation source material produced by this project.

...

-          If successful issues a RestAPI (webhook api at Readthedocs) to pull the new build into http://onap.readthedocs.io

Committers  & Contributors

You will need to check in/out  your changes to the requirements documentation using git/gerrit. To use Git & Gerrit, ( assuming you do not already have them) will require you to set up your environment.  You will need to clone the ONAP repos from The requirements documentation must follow the rules defined by the Documentation project: http://gerrit.onap.org to your local machine to make your changes as a contributor. The ONAP community is tracking progress using the JIRA system. So please remember to create and close the jira tickets for the tasks you are completing so that the progress we make is visible. The workflow of the ONAP development process and policies are summarized in this figure

Image Removed

Committers

readthedocs.io/en/latest/guides/onap-developer/how-to-use-docs/include-documentation.html#testing

- compliant with Doc8 https://pypi.python.org/pypi/doc8ONAP uses the Gerrit review system for committing changes to the code - including our documentation source files.   Please recall the ONAP policy is that committers cannot merge their own changes. The documentation project has a review checklist for general documentation.

Project Responsibilities 

The VNF Requirements project defines:

• Where our documentation needs to fit in the overall documentation structure, as well as
• The structure of our documents .(We need to clarify what a Document is)
  
  • Chapters
  • .rst files
    • start with assuming one chapter per .rst file
    • if chapters too big then chunk smaller by document sections
    • objective is to keep manage-ably sized, coherent chunks of content together for review/commit purposes  
  • The structure of our documents should be reflected as within the repo structure of our project.
    • directories
      • all the .rst files of one document in one directory
      • only one document per directory

...